cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Questions/Suggestions for Woody
Date Sat, 02 Aug 2003 06:57:32 GMT

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 

> 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

> 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

the future bringing in more of our different experiences will 
most likely fine-tune that

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message