Judson Lester wrote:
>
> 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.
You can place more than one bean into the servlet context.
> > 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.
Granted. This is always so with 'legacy' stuff and believe it or not,
servlets are already considered legacy stuff by somebody and we should
make all possible effort to allow them to use Cocoon without requiring
them to change their stuff.
At the same time, we should show them the advantages they get by using
Cocoon architecture directly.
> > 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.
good point.
> > 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.
Agreed. Even if/then/else could be written with gotos, but we all know
this is bad practice since the 60's. What we need is to resurrect the
same old principles over to the web. Which is not as easy as it seems.
:/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
