>
>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.
regards - peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
