On Mon, 17 Jun 2002, Sylvain Wallez wrote: > Stefano Mazzocchi wrote:
> >[NOTE: Giacomo and I spent a full evening and the next day (during > >"Italy vs. Mexico"! consider that!) talking about these things, so the > >above reflects design concepts of both of us] > > > > Wow, so this is *really important* for you ;) Of course ;) > In France, we no more have this kind of problem :( I'd like to express my condolences ;) > > >More explicit sitemap markup > >---------------------------- > > > >Here is what I think would be a much better approach to connect a > >sitemap and a flowmap: > > > ><map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0";> > > > > <map:flowmaps default="calculator"> > > <map:flowmap name="calculator" src="calc.js" language="javascript"/> > > </map:flowmaps> > > > > <map:pipelines> > > <map:pipeline> > > <map:match pattern=""> > > <map:call function="calculator('prefix','/kont')"/> > > </map:match> > > > > <map:match pattern="kont/*"> > > <map:call with-continuation="{1}"/> > > </map:match> > > > > <map:match pattern="*.html"> > > <map:generate src="{1}.xsp" type="serverpages"/> > > <map:serialize/> > > </map:match> > > </map:pipeline> > > </map:pipelines> > > > ></map:sitemap> > > > >There are a couple of major differences: > > > > 1) a flowmap isn't a sitemap resource, but it's something else. The > >above semantics reflect this. > > > > > > +1 : flowmaps aren't resources and should be separated from them. > > A side question : should flowmaps be inherited by subsitemaps ? While > thinking of that, I was wondering if flowmaps should be declared in > <map:components> since only components are inherited by subsitemaps. Good point. I have not thought about it. My vision was that a flowmap was coupled with *one* sitemap for its "views". I can't see what one gains if the can make a general flowmap available to every sib-sitemap, do you? > >More ways to get flowmap data > >----------------------------- > > > >Currently, in order to have access to flowmap data (parameters or > >continuations), you need to use the XSP or write java code yourself (I'm > >not even sure the latest is possible, Ovidiu?) > > > > > > You're not stuck to XSP : all the information produced by the flow will > be stored request attributes. Note that I wrote "will" : for now Ovidiu > uses the Environment object in a somewhat hacky way and we had some > private discussions where I suggested to use request attributes instead. > But this is still on the todo list. Stefano and I talked about it, too. My suggestion was to provide the data as request attributes, too. > >I'd like to have at least a few others: > > > > 1) XSTL > > > Typo for "XSLT" ? Think so. > > 2) Velocity > > 3) JSP? > > > >I don't know how hard it is to implement them and I'd like to have > >suggestions on how to implement at least the first one (the problem with > >velocity is that its output must be parsed, unlike XSP, so Velocity > >templates are inherently slower than a compiled XSP, but at least they > >are easier to understand and to use for many, expecially HTML > >designers). > > > > > > We currently don't have access to request attributes from XSLT, but this > should be fairly easy to implement, just as we already do for request > parameters. Velocity and JSP shouldn't have any problem once they have > the request. Yup. > >VOILA'! We have the ability to use serializers to write on disk, without > >even touching the sitemap! > > > >So, consider this sitemap: > > > ><map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0";> > > > > <map:flowmaps default="editor"> > > <map:flowmap name="editor" src="editor.js" language="javascript"/> > > </map:flowmaps> > > > > <map:pipelines> > > > > <map:pipeline internal="true"> > > <map:match pattern="save2disk"> > > <map:generate type="stream"> > > <map:parameter name="content" value="content"/> > > </map:generate> > > <map:serialize type="xml"/> > > </map:match> > > </map:pipeline> > > > > <map:pipeline> > > <map:match pattern="save"> > > <map:call function="save2disk()"/> > > </map:match> > > </map:pipeline> > > > > </map:pipelines> > ></map:sitemap> > > > >and your flowmap is something like > > > >function save2disk() { > > OutputStream output = new FileOutputStream("/usr/local/docs"); > > callPipeline("save",cocoon.request, output); > >} > > > >it would be *THAT* easy! > > > > > > The only thing to say is : Way cool ! Yes, this would make CMS/DMS implementations much easier. > > - oooo - > > > >There are a few important issues with the flowmap: > > > > 1) documentation must be provided on the FOM (flowmap object model), > >sort of a DOM for flowmaps. Currently, objects like 'cocoon', 'log' and > >others are provided, but there is no documentation presenting this > > > > 2) mappings between java and javascript: I don't know how much coupling > >can be done between java and javascript in the flowmap, this must be > >documented more. > > > > > > This item has been discussed in the scope of performance, as we can't > imagine writing the whole business logic in JavaScript. Rhino provides a > natural interface to Java, and the flowmap should be considered as a > continuation-enabled glue between various business logic components > written in Java. Also, business logic can return Java objects that are > held in flow script variables, and thus benefit from the continuations > mechanism (provided they are serializable). So both worlds are > complementary : the intrepreted flow script provides continuation > support to compiled Java business logic. We also talked about having a Java implementation of the flowmap even if we have to sacrifice continuation for that but can gain performance. > What is missing in the FOM is the component manager that would allow the > flowmap to have access to Avalon components. This is absolutely necessary I think. > > > - oooo - > > > >Ok, please, send your comments. > > > > > > Some additional food for thought : continuations can be used not only as > the driver for the interaction of a single user, but also for multi-user > workflows. Consider e.g. a purchase order workflow : the emitter fills > in a form, this form is then "sent" to it's manager that validates (or > cancels) it, then to the purchase department, etc, etc. > > All this process can be described by a global multi-user flowmap > aggregating mono-user flowmaps that drive each of the individual > activities. Since continuations can be serialized and archived, you > could write a lengthy process (even weeks long) just as a simple > sequential program that "goes" from one user to the other. > > After revolutionizing webapp development, will flowmaps revolutionize > workflow systems ? This sounds very interesting. We need to take it in mind. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
