On Wednesday 19 December 2001 10:51 am, Stefano wrote: > Good point. > > Anyway, as long as those servlets are used as "actors" (mean they don't > return a stream, but beans), otherwise we'll end up having to parse this > stream to make it fit into the pipeline and then a ServletGenerators > would be much more handy for that (just like the JSPGenerator).
Beans plural? Or actors return beans -> one actor returns one bean? If the later... I'll get to that. > > Moreover, is there an advantage to avoiding the use of the Servlet > > scopes (notably session scope)? (I'm led to this conclusion by the > > "continuation identifier URLs" in Ovidiu's example) If not, what call is > > there for return values in the flowmap? <snip/> > > I recall criticisms about business logic in the flowmap, and encouraging > > the use of Servlets in this way would help, I think. > > I personally came to the conclusion that once you have continuations, > you get the power of servlet 'sessions' for free. And more. You are no longer responsible for the store-and-retrieve part of session management, variables are either assigned or not, etc. > Using servlet API concepts might help those programmers who are already > used to servlets, but those (and are *MUCH* more out there!) that are > used to command line programming or GUI programming are not used to > 'store data into some persistent object that flows across the sky'. > > It took me a couple of days to explain what a 'servlet context' was to a > friend of mine who did programming for decades, but nothing on the web. > > Sure, it could sound easier to you because you already know the > concept... also, if you had to work with previous web technologies, you > were probably delighted to see the concept of session implemented by the > servlet engine and not by your own code. Honestly, while I found the notion of sessions scope relatively graspable (by analogy to global scope, and class and instance variables...) they are notions that ran counter to long training of best practices; specifically that global variables are bad. And, incidentally, having implemented a session-style data collector in my own code, (for a different purpose, but one closely related to this thread) as far as having servlet scopes implemented for me: Amen! :) > But at the same time, would it be even better if you didn't have to > think about it altogether and program like you'd do for your command > line? Being able to avoid the management of the session would help a lot. And yes, minimizing the amount of new pardigm to be learned would make everything gravy. Putting desktop developers in a position to quickly be coding web apps is veryt attractive. But by the same token, I've had the idea of painless migration in mind for my site (a Servlet & JSP house at present), and I wonder how much in tune that is with the Cocoon mission. For instance, a user-contributed JSPReader fulfilled the requirements of one of my own future projects, since it allows existing JSP to be used as Cocoon generators. I'm sure this begins to smell of FS, but the more existing code could be reused, the easier it will be to get Cocoon accepted. > > > Two: <snip/ reason="brevity"> > > I'll let Ovidiu reply to the specific example. > > I'd tentatively suggest that returns not be allowed, since it would be > > incredibly difficult to implement logic in the flowmap without them. Of > > course "continuations" as they exist in Scheme rely on them, but the idea > > of an object to keep track of the current position doesn't strictly > > require a call stack. > > Correct: in fact, you can implement what you want with sessions. > > The real question is: is it be easier to program web-apps with > continuations than with sessions, as state maintainers? I disagree. I think <emp>a</emp> real question is ease-of-use. Another, equally valid question is what will emphasize SoC, and keep business logic in its place (with the subquestion: what relationship do flow and business logic have? I propose that they are not identical, and that their intersection should be limited to flow's dependance on business logic)? If variable assignment must come from Java code, because flow units can't return anything, it becomes very difficult to use flowmaps for business logic. > If, at the end, it comes out that it's easier to use sessions, we'll > happily forget about continuations. Reflection leads me to ask, though: is the idea I'm suggesting of continuation-based "flow units" (I have a hard time thinking of them as "functions" without returns) differ significantly from FSM/goto programming? The difference I can see is that state transitions are seperated from input, which is fairly significant in my mind, and almost exactly what is wanted. Judson --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
