Also please look at the Flowscript samples in the core and in the Petstore block rather than in Woody. Other than for Woody, Flowscript should be stable, usable, and documented.
Regards,
Chris
----- Original Message ----- 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. (?)
(suggestions, links, publications, documentation, ...)
Excellent - I have always thought this use needed more press.
> Are there any "Best Practices" for Cocoon working with EJBs?
example by using business delegation pattern)
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
> When using flow scripts, does it make sense to use actions? (how matureis 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]
