Hi Sylvain, > ...can I do all I want in my web application > with Cocoon????....
Looks like there's not a rush to reply to this one... Quite frankly I don't know the precise status of the current implementations of forms handling and flow. These would help you a lot in filling the blanks in your concept, so you might want to ask more specific questions about them here. Let me reply on what I know... > 2) Search data: form to enter the query => select data in database => > display result If you're reading directly from the database (but read below about this), ESQL seems to be the most flexible option here, followed by XSLT transforms for HTML or PDF generation. I don't think you need a form handling module for this, you can start with a (static or XSLT-generated) HTML form and use the request parameters to build the SQL query. > 4) Generate file: choose the file to generate (from a result or a form) => > select data in database => generate the file What kind of file? XML? HTML? PDF? RTF? In any case I think XSLT transforms followed by the appropriate serializers will do the job. This is something that is definitely mature in Cocoon today (with some limitations in PDF output and some more in RTF output). The forms handling module might also be overkill here IMO if you're just selecting 2-3 options on a form to trigger file generation. *** OK,BUT - do you want a monolithic system? *** So I don't have all the answers, but even if Cocoon allows you to build your complete app today, I would by all means avoid creating a big monolithic thing. Cleanly separated application layers are a must in my book, with at least a (stable and testable) backend to handle database transactions and a (more subject to change and harder to test) frontend for the user interface. It's great that Cocoon offers (or will soon offer) all components required to build a complete webapp, but this might cause a tendency of using too much of it at the same time. IMHO the WebServicesProxyGenerator [1] is a great step towards cleanly modularized applications, by allowing a clean separation of application layers. It doesn't mean you won't use Cocoon for the backend as well, but if you do you might be better off using *another instance* of Cocoon for the backend, separate process, maybe separate server. Of course modularizing usually means some loss of performance compared to more tightly integrated systems. For most applications this is irrelevant I think, or more precisely the benefits far outweigh the disadvantages. Hope this helps! -Bertrand [1] http://xml.apache.org/cocoon/userdocs/generators/wsproxy-generator.html --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>