cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Flowmaps
Date Mon, 17 Jun 2002 19:06:07 GMT
Nicola Ken Barozzi wrote:
>
> I think that
>       <map:match pattern="kont/*">
>        <map:call with-continuation="{1}"/>
>       </map:match>
> 
> Is unnecessary and *will* create confusion, since there is no way to
> enforce it while using a flowmap.
> Users will forget to write it and flood us with mails of "why doesn't it
> work?".

I would love to make continuations transparent, but I couldn't see any
reasonable way to do it. NOTE: people ask how sessions work anyway, even
if the Servlet API made them almost transparent.

> How about:
>       <map:match pattern="">
>        <map:call function="calculator('prefix','/kont')
>                  continuation-match="kont/*"/>
> 
>       </map:match>

No, this is wrong: you are not calling a particular function with a
continuation, you are simply stating to resurrect the state of the
flowmap with the given continuation, that's a big difference.

moreover, since the continuation *is* encoded in a URI, the above will
simply not work since the pattern matching will not succeed.
 
> >  3) the "map:call" element is used to call sitemap resources (pipelines)
> > and flowmap resources (functions), an attribute is used to indicate the
> > behavior that should be used and it's consistent with the rest of the
> > sitemap.
> 
> -0
> 
> Is a flowmap a resource or not?
> Hmmm...

map:call is not about resource, is about branching the execution flow. I
don't think it makes sense to have more than one element that implements
that semantics to jump from one location to another, we just have to
provide hints how *how* this is done.

> >  4) the "map:call" element can use both nested map:parameters or
> > directly using the 'function(param, param)' syntax inside the attribute.
> > This makes it more readable in some cases.
> 
> -0
> 
> The more xml we use in the sitemap, the more validations-enforcements we
> can have.

As a general rule I agree, but I wouldn't hinder the ability to make the
sitemap more readable

[anyway, this is a smaller detail compared to the other ones]

> > Making continuations transparent
> > --------------------------------
> >
> > I personally don't have a clear view of the usability of this concept
> > myself: I like it very much, it's clear and consistent and it's similar
> > to the session concept.
> >
> > The only thing is that we might provide a
> > "ContinuationURLEncodingTransformer" of some sort to separate the
> > concern of those who write the forms and those who write the sitemap,
> > even if, passing the 'kont/' prefix as I showed above allows to keep the
> > URI space totally self-contained in the sitemap.
> 
> Yes, I understood that we should have the sitemap define the uri needed
> to "store" continuations, see above for a possible solution.

That doesn't work :/

> > I'd be happy to hear more comments in this area (Daniel?)
> >
> > 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?)
> >
> > I'd like to have at least a few others:
> >
> >  1) XSTL
> >  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).
> >
> > Using JSP as an MVC view makes sense in those cases where a tool is
> > required for HTML designers to connect to the parameters passed to the
> > JSP. I personally don't care but others might.
> 
> Why would you need access to continuations?
> I think they should remain transparent.

Look: you can do magic only until a certain point. You have to pass
state somehow between the client and the server. This state can be as
simple as a single hidden value passed back and forward in a get/post
roundtrip or it could be as complex as a random number that connects to
the continuation object on the server side.

No matter what, you *HAVE* to pass it somehow.

Now, Ovidiu did this by encoding it in the URI. This is, by far, the
most general and elegant solution that I can think of. You don't need
cookies, you don't need special browsers, you don't need special HTTP
versions nor actions, it is proxy-friendly and keeps the URI space as
clean as possible.

In general, I see three possible locations where the continuation ID can
be encoded:

 1) in the URI path (example /kont/38494849484)
 2) in the URI parameters (example /whatever?kont=3849484948)
 3) in the request body (example as a hidden parameter in a form)

I find the first one the most elegant, even if (admittedly) it requires
the URI space designer (who writes the sitemap) to be aware of the
flowmap behavior.

Anyway, I'm wide open to suggestions in this area since I do perceive
that this concept might be too hard to understand for many (even if we
cannot be sure anyway until we try and see the users feedback outselves)

> As for parameters, can't we make them available in the Sitemap Context,
> so that no new stuff is necessary?

Currently, they are included in the Environment but I'm not sure if the
TrAX transformer is able to access them transparently (I wouldn't think
so).

Anyway, I agree it's not that hard to do anyway.
 
> > There is only one big thing missing: when I thought originally at the
> > flowmap concept, I wanted it to be interchangeable with the sitemap, now
> > I've changed my mind and I think it makes sense to have a sitemap always
> > up front, no matter how 'procedural' your web application is (might even
> > have a single URI for the whole thing and handle everything inside the
> > flowmap)
> 
> Since we need a sitemap to manage the URI space, it makes sense.
> 
> > At the same time, when I was explaining the flowmap concept to the guys
> > at SwissRisk, we came up with an idea [gosh, forgot the name of the guy
> > who suggested me to think in that direction, hope he is subscribed and
> > makes himself known!].
> >
> > Consider this flowmap call
> >
> >    sendPage("hello.html");
> >
> > this means:
> >
> >   1) ask the sitemap to redirect to "hello.html"
> >   2) send the output to the client
> >   3) wait for a request to make me continue
> >
> > Now, suppose we do this
> >
> >    callPipeline("hello.html", input, output);
> >
> > where we mean:
> >
> >  1) call the internal "hello.html" URI connecting the input and output
> > that I give you.
> >  2) come back here without sending anything to the client
> >
> > <drum-roll/>
> >
> > 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!
> >
> > [NOTE: the 'input' and 'output' parameters of the callPipeline() method
> > will have to be carefully choosen, here I'm just making this up as an
> > example, don't take this as a complete proposal, but just a way to
> > sparkle discussion]
> 
> :-O
> 
> > 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
> 
> We should strive to have the *same* objects available to sitemap and
> flowmap.

No, you didn't understand what I meant with FOM.

JavaScript is different than Java. It requires an implicit object model.

Currently, there are a few objects available in the FOM:

 - cocoon
 - log
 - global
 - WebContinuation

[Ovidiu, please, correct me if I'm wrong, my knowledge of Rhyno is not
that great ATM]

the cocoon object is something that connects you to cocoon. You can then
have access to the entire object model that you get in sitemap
components.

Ivelin was asking for a way to simply populate a bean from a request, we
might want to include those utitity functions in the FOM and it wouldn't
make any sense to provide them in the object model of sitemap
components.

At least, that's my opinion.

> >  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.
> 
> +1
> 
> Just 1 tip:
> on the Ant list I've seen that someone has made a javadoc system for
> Javascript, and it would be cool to have it used in flowmaps!
> I'll keep you guys informed.

Great, even if I don't think it will be that useful. We don't have a
javadoc system for sitemaps and nobody ever asked for one.

>                      -oOo-
> 
> Last, I would like to thank Ovidiu for making the Cocoon Flowmap in the
> first place.
> He kept coding even when it seemed hopeless to many of us, and now we
> have a real killer app.

I'm not part of those who considered his effort hopeless (actually, I
think I was his main sponsor, for this), but I do have to thank him a
lot for the *outstanding* job that he did.

> Thank you, thank you, thank you :-)

Hopefully, one of you might be able to give him a job so that he can
continue to work on those things full time like he did in the past.

I'm serious: Ovidiu is looking for a job. If you want the flowmap to
happen faster, you might consider sponsor him directly for this.

Worth thinking about.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message