FWIW: I have a use case "add object" that goes like this:
1 get "empty" object from the backend 2 display object for user to fill in 3 transfer the filled-in object to the backend 4 if the object turns out to be a duplicate, show an error message and redisplay the form 5 if not, the object is stored and the completed info is displayed in another page. I have a specialized backend, so I needed to write my own classes for this. At first I tried doing this using XSP for step 1 and woody for step 2. I got the idea that flow was preferable over actions, so I tried to tie it to the flowscript used to display the form. Then I got stuck. There was no elegant way to get step 3/4/5 implemented using XSP and I hated the idea to build pipelines that would only be used to do some "helper conversions". Then Marc suggested the idea to build the entire use case in a flow script and that proved to be much more elegant. I now have 2 kinds of pipelines: one for the flowscript to be called, one for the form to be displayed. They are distinctly different, so it's easy to figure out which one is which. Bye, Helma > -----Original Message----- > From: Ralph Goers [mailto:[EMAIL PROTECTED] > Sent: Saturday, 01 May 2004 18:20 > To: '[EMAIL PROTECTED]' > Subject: RE: JXT or XSP? > > > You have to draw a line in the sand somewhere. Instantiating > the objects > might not be so bad, but the next thing you know you'll be > calling methods > on those business objects because its easy and then you'll > really start to > pollute the controller with the model. > > Ralph > > -----Original Message----- > From: beyaNet Consultancy [mailto:[EMAIL PROTECTED] > Sent: Saturday, May 01, 2004 9:11 AM > To: [EMAIL PROTECTED] > Subject: Re: JXT or XSP? > > Ralph, > is there any particular reason why you don't instantiate business > objects from within flowscript, or is purely preference that > you don't? > > Peter > On 1 May 2004, at 15:09, Ralph Goers wrote: > > > I didn't mean to imply that there is no place for flowscript. There > > certainly is. As I said, we are using it. > > > > The controller in Cocoon is not the Actions; it used to be > the entire > > sitemap. Now it is the sitemap + flowscript. The problem > is that it > > is easy > > to have flowscript become part of the model and the view as well. > > > > When you look for doc on flowscript one of the first things > you will > > find > > are pages title "Advanced Flow Control". That is really what > > flowscript is > > for - managing flows that would be very painful to do in > the sitemap. > > For > > example, we have cases where the user requests a specific > page and in > > the > > process of generating it we discover that they must be > presented with > > some > > legal text that they have to accept or decline. Based on their > > response we > > either display the requested page or send them somewhere else. We > > handle > > the "normal" request purely in the sitemap. When the > alternate flow is > > detected the user is sent to another pipeline managed by > flowscript. > > While > > the alternate can be, and has been, managed directly in the > sitemap, > > this is > > a case where flowscript makes it a lot easier. > > > > What we don't do is instantiate or manipulate any business > objects in > > flowscript. > > > > Ralph > > > > -----Original Message----- > > From: Christian Rosenberger [mailto:[EMAIL PROTECTED] > > Sent: Saturday, May 01, 2004 3:21 AM > > To: [EMAIL PROTECTED] > > Subject: RE: JXT or XSP? > > > > Hello! > > > > I think in concerns of MVC, the solution Ralph mentioned > seems to be > > the > > best. You have a clear seperation between prsentation, > controller and > > business logic. > > > > The system would look like this: > > > > Presentation: Plain XHTML or whatever output format you like > > > > Controller Actions > > > > Modell: Business Delegate/Business Logic Manager > (connected to > > database in whatever way) > > > > All controlled in sitemap. As Ralph mentioned, if you put > controlling > > or > > logic in flowscript, the sitemap will loose all powerful > possibilites > > it > > has. > > > > Regards, > > > > Christian > > > > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
