cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: [RT] forms
Date Fri, 20 Jul 2001 15:02:07 GMT
I agree completely. The second format would make customisations a lot
easier. 

On 20.Jul.2001 -- 03:10 PM, Peter Nuetzel - inglobo wrote:
> >
> >Well, as I stated in my last post maybe we can circumvent the XForm
> >conformance problem by using a different namespace for that.
> >But it is still not very nice...
> >
> >(including the selector logicsheet [as follows] there would be 3 NS
> involved
> >for a simple form then!)
> >
> 
> I think better would be to use only one self defined namespace and keep as
> close to Xforms as possible. I guess the Xform WD will undergo even more
> big changes (see changes from last version to current). I think its even
> impossible to fully implement XForms with a HTML (or other) client server
> solution. AFAIK XForms is specified to be processed by special clients
> (next generation browsers?).
> 
> 
> >> I think adding the evaluated values as
> >> elements to the form controls like you proposed in your last mail is a
> nice
> >> solution. So you get a simple and straight XML document which may be
> easily
> >> transformed to special presentations by user stylesheets. Easy if
> >
> >Hm... yes of course but if we only add it as intermediate format extension
> >(even in a different ns) we will end up spitting out the form data twice.
> >Once in the instance and again in the elements themself.
> >
> 
> I think of two similar formats:
> the form descriptor: contains all information which is necessary to specify
> formhandling splitted in MVC parts (similar to XForm). Model corresponds to
> the instance element which is written in the file directlly and/or
> referenced by XLink and/or cocoon: URL. View are the form controls. Model
> and View are connected with the XForm binding expressions (ref attributes).
> More complicated is the controller part. There are easy to define common
> controller actions like validation, multipage navigation and updating. And
> there are more complex controller functions like calculation and dynamic
> form generation. Here probably XSP or some scripting is needed.
> 
> The second format is the intermediate which is the current evaluated form
> presentation itself. It contains no instance element nor any meta data for
> form processing. In multipage forms it represents the current page. So you
> have an device independent view of the form which may be transformed to
> HTML, WML or whatever appropriate.
> I admit this is a bit complicated, but its the only solution i can think of
> which allows generic device independent form handling and definition and
> allows the user to style the forms with XSLT to the presentation he wants.
> 
> 
> >...
> >If we use a taglib - it won't. But we could create another
> >taglib useful even for other things:
> >
> ><sel:selector type="sitemap" parameter="page">
> >  <sel:case name="fillin">
> >    <xform:.../>
> >  </sel:case>
> >  <sel:case name="overview">
> >    <xform:.../>
> >  </sel:case>
> >  <sel:case name="thanks">
> >    <p>Thank you!</p>
> >  </sel:case>
> >  <sel:otherwise>
> >  </sel:otherwise>
> ></sel:selector>
> >
> 
> I dont't know if this is really necessary - I thought this would be defined
> in the form-descriptor and handled in a common way by the form-action and
> form-transformer.

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message