I haven't used flow either, primarily because it doesn't seem mature - at least from a documentation standpoint.
However, my take on what I read was a little different than yours. I've looked at things like Weblogic's Java Page Flow and Cocoon's version seems similar. I believe the concept here is to manage a sequence of views. The pipeline seems to do a very good job in causing a single view to be presented but it is hard to make sure that pages are presented in the correct order. I belive Cocoon flow tries to address that problem. I see it more as a wrapper around a set of pipelines. Of course, if I have it wrong please correct me. Ralph > -----Original Message----- > From: jcplerm [mailto:[EMAIL PROTECTED] > Sent: Monday, September 08, 2003 6:56 PM > To: [EMAIL PROTECTED] > Subject: Re: EJB + Cocoon, "Best Practices" > > > I checked what I could find in terms of documentation and > code related to the Flow, certainly I am missing something > (is there is a document that clearly presents Flow from a > conceptual to a lower level?). > > My objection is that so much emphasis has been made > in terms of using as much as possible the sitemap and > sitemap components, so applications are easily > maintainable, and all of a sudden I see this Flow > concept in which one really ends up burying the > page chaining info in Javascript. > > Because that's what I see in the "form2xml.flow" > example: the invocation of "form2-display-pipeline" > and "form2-success-pipeline" > is hardcoded in the binding_example.js script. > > That's totally the opposite of the sitemap concept. > > I really don't know how this could be done, but > I would like to see that type of information > specified in some sort of pipeline too. > > Sorry for my ignorance... > > jlerm > > > ----- Original Message ----- > From: "Geoff Howard" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, September 08, 2003 8:28 PM > Subject: Re: EJB + Cocoon, "Best Practices" > > > > Bastian Breithaupt wrote: > > > Hi! > > > > > > I would like to set up a Model2 application with Cocoon > end EJBs. Cocoon > would be the presentation layer (also the controller layer?) and the > business logic would be represented by the EJBs. (?) > > > > Excellent - I have always thought this use needed more press. > > > > > Are there any "Best Practices" for Cocoon working with EJBs? > (suggestions, links, publications, documentation, ...) > > > > Unfortunately, precious little has been written about the subject. > > Those who have used Cocoon and EJBs have not written much about it. > > > > > I suppose, calling the EJB-API is done by Cocoon-Actions...? (for > example by using business delegation pattern) > > > When using flow scripts, does it make sense to use > actions? (how mature > is flow script?) > > > > Usually you would not need to call actions and flow. As you are > > designing from scratch, I'd recommend starting with flow. If done > > right, your logic would be re-usable as an action should the need > > arise. Conceptually flow will probably turn out to be > pretty stable. > > The implementation is fairly new so using it may turn up unexpected > > issues. The good news is that most developers are paying a lot of > > attention to it, so there may be quick turn-around on > resolving whatever > > comes up. > > > > In the end, the flow is just supposed to glue together your business > > logic especially as it relates to page flow within your application. > > This may make its young age less important. > > > > > Any help, hint, link, ... is appreciated. > > > > No links that I'm aware of, but there are several people on list > > interested in writing up some examples of EJB and Cocoon > who I'm sure > > would help you navigate the process. Give a little info about your > > specific needs/questions and some useful info is bound to turn up. > > > > For starters, are your EJBs on a remote server from Cocoon? > > > > Geoff > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
