there are a few reasons we didn't use flow scripts even though they are quite cool technologically.
--> we wanted to execute a series of actions which can not only follow different paths like selectors but can also emit XML which is concatenated into the response stream. there's no cocoon component like this so we're already into custom code. --> flow scripts seem to present the same problem as ASPs, JSPs, and XSPs in that too much process logic ends up on the web server, disjoined from the business objects they work with. granted, if you write them correctly they are simple, but i've never seen this in practice. it's too tempting for someone to put code in the view layer to just "get it done" --> flow scripts encourage you to link multiple pages together into a series, but i think this is a bad idea in terms of maintenance. on any given page of our site, there are 20-50 outlinks for the user to choose from, so it's very important for us to maintain modularity between pages. to achive this, we've broken our backend actions into two parts: actions you invoke while leaving page A and actions you invoke while entering page B. we then can mix-and-match page A to page C or C to B etc. writing flow scripts which cross page boundries would make our navigation logic a nightmare. --> the action engine we wrote not only handles long-running-request continuations but can also provide an updated view of the data processing. that is, our long-running backend actions can iteratively add data to the response stream, and our continuation controller will display whatever results have been given so far. this allows us to do things like show progress bars that change with every refresh. while a flow script could be made to do this, you would have to (artifically) break your long-running process into multiple stages and return different pages between each. in our solution, you can have a single long-running stage and a single progress page. > -----Original Message----- > From: Christopher Oliver [mailto:[EMAIL PROTECTED] > Sent: Monday, September 22, 2003 11:33 PM > To: [EMAIL PROTECTED] > Subject: Re: EJB + Cocoon, "Best Practices" > > > Tim Olson wrote: > > >to get EJBs into cocoon, we have a custom Action / Generator > pair. the > >action can be configured to make any EJB call (uses > reflection) and stuff > >the results into a HashMap. the custom generator then sends > that hashmap > >through Castor to generate SAX events. it's very nice, > since we can turn > >any series of ejb calls into XML data with just a few lines > of sitemap code. > >note: remote interfaces are tricky to castorize so use the > value object (aka > >data transfer object) pattern. > > > >we eschewed flow scripts and wrote our own action engine, > but i should post > >separately about that. > > > > > > > Why did you "eschew" flow scripts? Just curious. > > > --------------------------------------------------------------------- > 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]
