cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] Flowmaps
Date Mon, 17 Jun 2002 20:19:15 GMT

Stefano Mazzocchi wrote:
> 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.
> 

One thing is knowing how it works, another is having to deal with it.
I know how a motor of a car works, and I can drive, but I don't need to 
touch the motor to start the car, although my knowledge of the motor can 
help me in getting the best performance from it.


>>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.

Then it simply means that it's not good.
I kept some implementation assumptions implied to see how it showed, and 
you have clearly explained why it's worse than having explicit matching.

This makes me think that or we keep continuations fully exposed, or 
fully hidden, like Servlet Sessions.

I go for the latter.

>>> 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.

I could agree with you, but I think this is not what users will 
generally think.
If you give the map:call a more general meaning, it would be too natural 
to want to call anything in the pipeline, and create confusion.
Did you follow the user list lately? ;-)

>>> 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]

Definately.

>>>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 :/
> 

It could, but it would imply that we have "hidden" matchers and stuff 
that just creates more confusion :-/

>>>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.

Which is something I really don't want to see.
URI space should generally have a meaning; using a hash key in it just 
snaturates it. Parameters instead are per-invocation stuff, so IMHO it 
makes perfect sense to put them there.

> 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)

I had some feedback from my collaborators, and believe me, they said 
they are never gonna use this "continuation thing", that reminds them of 
having had to use .encodeURL().

I really want to see continuations as parameters, like:

       <map:match pattern="calculate">
        <map:call function="calculator('prefix','/kont')
                  continuation-param="mykont"/>
       </map:match>

This would match always, right?

first call  calculate
second call calculate?mykont=3849484948
thirdcall   calculate?mykont=3757567654

It would also be easy to explain that a continuation is a sort of 
special Cocoon Session.

>>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.

cool :-)

> 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.

Dunno, we'll see.
The important thing is that the OM available to sitemap components is 
available to the flowmap.

> 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

...

                        -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.

...

> Ovidiu is looking for a job. If you want the flowmap to
> happen faster, you might consider sponsor him directly for this.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------




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


Mime
View raw message