Andreas Hochsteger wrote:
Hi!
Most form examples in the current woody discussions assume, that the forms are
presented in HTML.
Is it (or will it be) possible to support different output formats while reusing most of the form definition?
I'm interested in the following output formats: * HTML with JavaScript (for Client-Side validation) * Pure HTML * XHTML + XForms * WML * PDF Forms (not that important) * Word Forms (not that important either) * Web Services (isn't that something XMLForm supported?) * anything else?
Can someone explain to me how such a scenario would look like (in terms of woody config files)?
(note: there is some changes underway so some of this might change)
most of the above look like you need the correct **ML-specific version of the form (supposing you can render all of the above from specific XML gramars)
I am not sure about PDF and Word Forms sending back valid HTTP request params from within their respective clients, if they don't you probably don't need to bother using woody at all
but if they all do, then you'll have to make some decissions on smart management of stylesheets and the like to get most if not everything from one (at least a limited number of) source-file...
I think it will take some of us actually doing these things before we get a real feel to the matter (we plan on a smaller try-out with WML in the not too distant future)
Another issue I see however is the mismatch of number of widgets per screen for each of these targets... this might call for splitting up a lot more of these sources then the big XML dream was promising :-)
Still Woody could at least do a best effort to ensure that all these targets can be reached by applying the same competence mix somewhat.
That's a concern I raised in the early discussions about Woody : the size and capabilities of devices such as phones or PDAs require a very different organisation of forms. As such, the templates will be different. Forms definitions will also be different, although we can think of having a singel model displayed by a single template for HTML and several ones for WML/PDA.
Additionally I've got a suggestion for the many woody config files which my satisfy both simple and advanced forms:
For really simple forms it is better to have everything in one file.
For advanced forms this becomes easily unmaintainable and doesn't support SoC.
In this case it might be possible to swap certain parts out to other files and include these.
As I understand it the current work Sylvain is doing is exactly about finding this balance
Exactly !
The only problem which might be with this solution is that this way all parts of the config have to be parsed during each request, even if they wouldn't have to.
But I don't know much of the woody internals to answer this question myself.
It largely depends on the upcoming proposal, knowing Sylvain a bit that will be quite well-balanced by his broad experience
Oh, Marc, you make me blush ;-)
the future bringing in more of our different experiences will most likely fine-tune that
Yep. We never do it right the first time : it's only usage that tells us how it should be. Note that Woody already benefits from some XMLForm experience, and so the number of iterations may be more limited.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
