ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | xmlc List | May 2000 Index

<--  Date Index  --> <--  Thread Index  -->

Re: Rocks: some XMLC ideas


Hi Mark.

That's interesting, I would like to know where ROCKS is in terms of code or 
design.
We could use these patterns directly in BROCK, since there will be a section 
of the
doc that manages the workflow, the kind of control you want to put in ROCKS 
could be
used. And since some initialization and validation methods will be provided, 
we also
need to adresse the security issues aroung those automatic methods.

If any doc is available for ROCKS, requirements or design, I would like to 
peek in
them to see where we connect together.

ciao.


markd@xxxxxxxxx wrote:


> Hi Beth,
>    Thanks for the input... Some discussion below.
>
> Beth McCanlies <beth@xxxxxxxxxx> writes:
>
> > - Provide automatic type/format checking of input fields via onChange 
> > events
> > and javascript validator functions for client validation, and an 
> > XMLC-created
> > method(s) for server validation.  This would provide rapid development of 
> > form
> > pages, and give a desktop gui input validation behavior to the user -
> > providing user validation feedback at the client level where the feedback 
> > is
> > much more immediate.
>
> Form validation and support of libraries of javascript are under 
> consideration
> as part of Rocks; tieing them together is an interesting idea.  Validation
> has to be done on both the client and server.  This needs to be done for
> individual field values and for the form as a whole.
>
> > This functionality could be driven automatically by denoting the expected
> > format of an input field - perhaps by adding a suffix to the ID value that
> > denotes the expected format, i.e., myField_DATE (This is somewhat hacky 
> > and
> > hopefully there is a better way to do this.)
>
> We are looking into having a table-driven method for generating the form
> initialization where validation methods could be specified.
>
> > So - what's missing here :
> > - Provide server-side include functionality in the toDocument method
>
> Does your application need runtime server-side includes or would it be
> possible to do them when the page is compiled?
>
> Note that the toDocument() method should normally not be used in
> Enhydra applications.  Instead, use comms.response.writeHTML(Document).
> This will allow cookieless sessions to work automatically.
>
>
> > Extending the toDocument method to perform server-side includes following
> > the apache include convention - and also allowing these includes to be 
> > .po's
> > in addition to static data - would provide server-side include 
> > functionality
> > to all dynamic pages.
>
> The API to presentation objects and servlets is an HTTP request, its not
> possible to call them from a SSI; one needs a URL to do that.  Some other
> SSI handler mechanism would be possible.  Can you describe the problem
> you need to solve with this?
>
> Thanks,
> MArk
> -----------------------------------------------------------------------------
> To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx
> with the text "unsubscribe rocks-group" in the body of the email.
> If you have other questions regarding this mailing list, send email to
> the list admin at owner-rocks-group@xxxxxxxxxxxx

--
------------------------------------------------------------------------------
Eric Giguère, ing.
Directeur département informatique
CPM Technologies de pointe
email : eric.giguere@xxxxxxxxxx
------------------------------------------------------------------------------

begin:vcard 
n:Giguère;Eric
tel;work:(514) 671-2011 ext 236
x-mozilla-html:TRUE
org:CPM Technologies de pointe;Informatique
adr:;;;;;;
version:2.1
email;internet:eric.giguere@xxxxxxxxxx
title:ing, Directeur informatique
fn:Eric Giguère
end:vcard


<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.