Hello Sylvain, All our xml is dynamic - infact, no validation is done on the presentation layer at all - it's all delegated to the middleware (SLSB).
Briefly, here it how it works (I must write a FAQ for the Cocoon site about this): For every page in the sitemap, there are several actions that always run - eg to check for session, a middleware handle, security, etc. Finally, a pipeline has been selected, and the generator runs. All generators are custom (written in Java, extending org.apache.cocoon.components.language.markup.xsp.XSPGenerator). We implement generateKey(), generateValidity() and generate(). *** Note that there is no XSP in the whole system at present - we only use actions and generators, most of which we have written ourselves. *** Most generators make calls to the middleware to get or update their data. Some generate SAX events directly, some dynamically generate "include" events, for the cinclude transformer to process (and call other pipelines) Then sometimes the standard cinclude and/or log transformer run. Then a XSLT to produce HTML, and a XHTML serialiser as normal. Obviously all presentation details are in the XSLT. POSTs are handled as follows: We have written many small custom actions (extending org.apache.cocoon.acting.AbstractAction implementing act() ) These are grouped into action sets, and called according to the value of "cocoon-action" posted. This is normal cocoon stuff. The actions update data either in the session, or in the middleware (sometimes asking the middleware for validation). Then the actions let the generator for their own pipeline run (which may do a middleware request or validation if it deems it necessary), or perhaps redirect to a different page (using redirector.redirect(false, "target") ). Valdation errors and prepop data are just turned into SAX/XML elements by the generator, and the XSLT has to show the user that there was an error or prepop. That's it, really. It's actually quite simple and flexible. And it has the advantage that all the validation is done at the middleware level with the rest of the business logic. This will become really useful when we will need to write non http clients of the business logic engine. Oh, yes, there is a handle to a single EJB (in our case a SFSB) which is stored with each HTTP session, and is used for all the requests of this session. As this is a SFSB, all the business state is stored there. There's not much in the HTTP session object(s) other than the handle. And another thing - we use the value object pattern for communication between the presentation layer (cocoon actions and/or generators) and the middleware. At present we write code to convert these simple java beans from the middleware into SAX in the generators, but I want to ditch this code and use a bean-to-SAX framework for this. Good luck.... Nick ps. I will cc the cocoon-users list in case anyone else might find this useful. On Tue, 2002-06-18 at 15:02, [EMAIL PROTECTED] wrote: > Hello, > > Your architecture is very interesting! I want to start a new project in the same way >and I search some experiences. > > If you use Cocoon as presentation layer, I think you have XML files as views. How do >you create your XML views? Are they static? Do you create dynamically your XML data >and then transform it to HTML (or another format) with Cocoon? > > Thank you > Sylvain > > -----Message d'origine----- > De: Nick Airey [mailto:[EMAIL PROTECTED]] > Date: lundi, 17. juin 2002 16:50 > À: Cocoon Users > Objet: Re: jboss, cocoon, jetty > > > > Hello, > > I am using Cocoon as the presentation layer of a J2EE application. It is > deployed on the jboss 244/tomcat 401 combination. > > It works fine, and I am happy with the speed - my entire ear (the cocoon > based webapp and 42 EJB's) and misc JMS and database connections takes > 45 sec to start on a modest desktop PC (600MHz, 512MB ram, redhat linux > 72). The whole thing is fronted by Apache for SSL support. I am using > JVM 1.3.1 . > > I was considering deploying cocoon on a standalone servlet container, > but I couldn't get JAAS security working with tomcat standalone and > jboss standalone. I could, however, get it working in the single JVM > configuration. I've never tried it with jetty, because the prvailing > wisdom of this user group about 3 months ago was to go with tomcat, as > cocoon had the most testing on this container. > > As for parsers, I was forced to use crimson instead of xerces because of > a well documented problem in Jboss 244 - ajp13 connector configuration. > See the jboss user groups for more of this... It went really easily - > just ensure that a recent version of crimson.jar is in the jboss/lib > directory, and is first on the classpath and it works. > > As for xslt engines, that is correct - you need xalan-xxx.jar and > xml-api.jar in jboss/lib/ext, and in your WEB-INF/lib directory of your > ear, but you don't need it in your classpath. > > > Regs, > Nick > > ps. In my opinion, cocoon makes an excellent presentation layer to front > a J2EE application - you have to write some custom generators to access > your ejb's, and some custom actions to do your control logic, but they > are all easy when you get the hang of them. (ie cocoon is the V and C > from the MVC paradigm). > > > > On Thu, 2002-06-13 at 14:30, Emmanuel Charpentier wrote: > > > > Hi > > > > I've managed to install and configure different setups: > > 1) jetty+cocoon, fast and clean. Startup takes no time and pages take > > only 10 to 20 milliseconds to execute > > 2) jboss/jetty+cocoon, huge and slow. Statup takes two minutes, and > > pages take whole seconds to execute. > > > > jetty+cocoon standalone talking to jboss is a great setup, but > > security seem to be much tougher to configure if at all possible (JAAS > > security). > > > > Plus I have to install xerces in jboss/lib and add it into jboss's > > classpath otherwise I get > > "SAX2 driver class org.apache.xerces.parsers.SAXParser not found" > > > > Anybody know anything or has any experience with that setup? > > Why is jboss/jetty+cocoon so painfully slowwww? > > Why isn't jboss's crimson.jar and jaxp.jar sufficient as a xml parser??? > > > > emmanuel charpentier > > > > gnu-linux/debian, j2sdk1.3 > > > > > > > > java.lang.ClassNotFoundException: org.apache.xerces.parsers.SAXParser > > at > > org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory.java:121) > > at > > org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory.java:96) > > at > > >org.apache.cocoon.components.language.markup.AbstractMarkupLanguage.generateCode(AbstractMarkupLanguage.java:377) > > at > > >org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:365) > > at > > >org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.createResource(ProgramGeneratorImpl.java:328) > > at > > >org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:291) > > at org.apache.cocoon.sitemap.Handler.run(Handler.java:270) > > at java.lang.Thread.run(Thread.java:484) > > > > > > --------------------------------------------------------------------- > > 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]> > > > > --------------------------------------------------------------------- > 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]> > > > --------------------------------------------------------------------- > 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]> --------------------------------------------------------------------- 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]>
