> >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).
Well, I do share to fear of the next big change...
...but most people I was talking to weren't very enthusiastic
about a propriatary spec (even when close to the standard)
> 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?).
Correct. Even if XForm spec has improved a lot there are still some things
that are not addressed in a sufficient way.
Maybe we should have a vote on this? Problem is:
a basic vote might lead into a simple
standard - good
propriatary - bad
result. And this will make us hack some propriatary sollution by ourselfs
until the XForm spec is what we want it to be... Or am I to pessimistic?
> >> 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.
I don't think dynamic form generation should be a controller task.
> 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.
So if I got you right you want to have the descriptor in XForm spec.
Used as Input for e.g. a logicsheet. What comes out is NOT XForm compliant
but easier to process via XSLT. Which gives us then HTML or WML or whatever.
Probably everyone already has noticed: I'm a friend of examples. Could you
give one per format?
> >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.
So you would vote for a transformer instead of a logicsheet?
regards
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
