> > activities often have results which need to be displayed by > > the generated page, and the emission of XML seems very > > natural to me. > > ah, okay. this requirement is neither an argument for nor against > flowscript (it should be very easy to implement it using flowscript)
oh? i'd like to hear about that. > > i consider flow script to be part of the view layer. > > nonono, flowscript is *another* layer, it controlls your application > (--> controller). It decides which pipeline is sent to the client (--> > view) and also decides which data this pipeline uses (--> model). well for the scale of our application, the controller logic needs to be on the backend servers. our "controller" is really just a forwarder that can be sequenced. in some ways it's less powerful than flowscript, which is intentional. you could make the same argument that ASP/JSP/XSP code is also controller code, but the entanglement with the view is clear. > - flowscript gives you the possibility to describe the logic > of your application at one single place (it does everything > a controller has to do) ok, but it's the wrong place for us. most of the controller logic needs to be on our business process servers, not the web servers. > - the state of your application is *frozen* using continuations and > you don't have to find out each and every time the current state > of your application > --> this also solves the back-button problem nice. p.s. what kind of performance penalty does freezing the application state involve? what is included in "application state"? what about all the state in our EJBs and other backend services? that still would need managed of course. > - a page sent to the client doesn't have any information which > page comes next for us, the page that gets sent to the client has ALL the info about what comes next, and our controller has very little of it. that allows our designers to change the site flow with very little tweaking (if any) in the controller. > > true, and i believe that (at least for our site), you > > SHOULDN'T code any page-to-page relations. but then, what > > makes flow script so cool? > > also your controller needs rules which page follows another page. You > wrote your own solution which is fine. Since 2.1 flowscript would be > another possibility how you can do it actually the controller doesn't know about which page follows another; this is important. our view layer provides an exit key and an entry key. the exit key triggers a series of activities which cleans up from any posted data etc from the page just left. the entry key identifies and prepares the new page. with this scheme, we are able to mix-and-match pages in our view layer without modifying the controller. honestly, i'm not happy about having to write our own solution. if flow script could emit XML and invoke remote EJBs then we might use it. it seems that cocoon is taking the direction of trying to be/do everything, but i'd rather have a fast, stable XSL pipeline engine that can integrate well with other technologies. we already have app servers that work great; we just needed a better view solution.
