[RT] Flowmaps

[Stefano Mazzocchi <st...@apache.org>]

Last time I wrote an RT about these things, the flowmap wasn't
implemented. Today it's working, but there are things that I would like
to change.

This RT is to start a discussion that will hopefully lead to a coherent
and community-driven design on what the flowmap engine will look like.

First of all, since there is no clear howto about the current flowmap
and I need to give you context in order to make you partecipate in the
discussion, I'll write a basic explaination of what's going on.

                              - oooo -

How Ovidiu implemented the flowmap concept
------------------------------------------

First of all, do a 'cvs checkout' of HEAD if you haven't done so. I'm
referring to the samples that you find in 

 /xml-cocoon2/src/webapp/samples/flow/examples/calc/

which is a sample about a very simple web application that implements a
calculator using the flowmap.

First of all, I'll outline the 'procedural flow logic' of this
application using highly-pseudo code:

 1) tell me the first operand
 2) tell me the second operand
 3) tell me the operation to apply
 4) here is your result

You'll see how much similar to the actual implementing code this will
look like. This is probably already a great advantage over anything that
we had before.

Let us look at the sitemap:

<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">

  [skipping component declaration]

  <map:resources>
    <map:resource name="flow">
      <map:script src="calc.js"/>
    </map:resource>
  </map:resources>

  <map:pipelines>
    <map:pipeline>
      <map:match pattern="kont/*">
        <map:continue with="{1}"/>
      </map:match>

      <map:match pattern="">
        <map:call function="calculator">
          <map:parameter name="prefix"
value="/samples/flow/examples/calc/"/>
        </map:call>
      </map:match>

      <map:match pattern="*.html">
        <map:generate src="{1}.xsp" type="serverpages"/>
        <map:serialize/>
      </map:match>
    </map:pipeline>
  </map:pipelines>
</map:sitemap>

So, Ovidiu added three concepts that weren't found in the previous
sitemap implementations:

 1) a new "map:script" component connects a sitemap resource with a
flowmap (which is here implemented as a javascript program)

 2) a new attribute "map:call/@function" allows you to pass control from
the sitemap to the flowmap, calling the function defined in the
attribute and passing the nested "map:parameter" to the function as a
regular call.

 3) a "map:continue" element indicates that the flow must be continued
with the continuation passed in the attribute "@with".

Let's look at the flowmap:

  var prefix;

  function calculator(uriPrefix)
  {
    prefix = uriPrefix;
    var a = getNumber("a");
    var b = getNumber("b", a);
    var op = getOperator(a, b);

    if (op == "plus")
      sendResult(a, b, op, a + b);
    else if (op == "minus")
      sendResult(a, b, op, a - b);
    else if (op == "multiply")
      sendResult(a, b, op, a * b);
    else if (op == "divide")
      sendResult(a, b, op, a / b);
    else
      sendResult("Error: Unkown operator!");
  }

the 'calculator' function is the one that is called from the sitemap. As
you can see, the procedural logic of your flow is *very well* described:
I'm sure that it would takes a few minutes for anybody to understand
what your application is doing.

This is *NOT* possible with any other FSM-based approach.

If you think about it, in Cocoon 1.x we used PI to encode state
transitions in every stage, then we identified this as a problem and we
centralized it into the sitemap: the location where you can understand
what your URI does in a central and confortable location.

Here we are doing it again, but instead of contralizing declarative
client/server behavior, we are centralizing procedural web-app flow.

But let's keep looking into the flowmap:

   function getNumber(name, a, b)
   {
1     var uri = prefix + "getNumber" + name.toUpperCase() + ".html";
2     sendPage(uri, { "a" : a, "b" : b });
3     return parseFloat(cocoon.request.getParameter(name));
   }

This function collects the number required by the flow:

line 1: the URI of the resource to use is created
line 2: the URI is sent to the client, along with some parameters in a
map
line 3: a float is returned from the cocoon request parameter named with
the given name

Anybody who ever wrote a webapp would think we are nuts: line 2
generates a response and line 3 reads a request. But here is where the
flowmap gets magic, there are bunch of things that you don't see
happening.

So, let's look at that function from what really happens behind the
lines, let us suppose we call

  var a = getNumber("a");

then

a) the sitemap is called to process a the URI 'getNumberA.html'
b) the sitemap matches with this matcher

     <map:match pattern="*.html">
        <map:generate src="{1}.xsp" type="serverpages"/>
        <map:serialize/>
      </map:match>

c) the sitemap executes the "getNumberA.xsp", which is given by

<xsp:page
  language="java"
  xmlns:xsp="http://apache.org/xsp"
  xmlns:jpath="http://apache.org/xsp/jpath/1.0"
>

<document>
 <body>
  <s1 title="Calculator">
   <form>
    <xsp:attribute name="action">
     <xsp:expr>"kont/" + <jpath:continuation/></xsp:expr>
    </xsp:attribute>

    <p>Enter value of <strong>a</strong>: 
          <input type="text" name="a"/></p>
    <input type="submit" name="submit" value="Enter"/>
   </form>
  </s1>
 </body>
</document>
</xsp:page>

where the "jpath" logicsheet is used to obtain the "continuation" of the
current flow and is then encoded in the URI called.

So, when the users hits 'submit', Cocoon will receive a request for an
hypotetical URI "kont/39849834983498", then Cocoon will match it with:

      <map:match pattern="kont/*">
        <map:continue with="{1}"/>
      </map:match>

and resurrect the flow logic from where it was left. So, again, between

   function getNumber(name, a, b)
   {
1     var uri = prefix + "getNumber" + name.toUpperCase() + ".html";
2     sendPage(uri, { "a" : a, "b" : b });
3     return parseFloat(cocoon.request.getParameter(name));
   }

line 2 and line 3, several things happen

 1) control is given to the sitemap
 2) the sitemap produces a response which encodes the continuation
 3) this response is sent to the client
 4) the client acts with the response
 5) cocoon receives a request for a continuation-decoding URI
 6) the flowmap is called with the given continuation (think of it as a
starting point)

If you think of the above as a command line environment, line 2 gives
you the dialog where to enter the number and line 3 uses the number
returned from the user.

[the rest of the flowmap is easy to understand if you understood so far,
so I'll skip it]

                              - oooo -

The problems with this approach
-------------------------------

First of all, let me say that I consider the above concept the biggest
advancement in server-side web technology since servlets.

This design not only makes it a breeze to implement MVC, but it shows
you how natural and clear things become once you separate the procedural
flow, from the declarative serving of resources.

At the same time, I think there are a number of issues that we might
solve before freezing the concept in a beta release:

1) the semantics to call a flowmap from a sitemap are too implicit:
users must assume to much from what they read (ie self-readability of
the concept is very poor).

2) the concept of continuations is not transparent, there is concern
overlap between the view designers and the sitemap managers since the
view designers must be aware of the URI location of the
continuation-decoding URI.

[NOTE: it is *not* required that you use continuations for your flow
logic, you can use whatever means you have to control state as you did
previously, such as REST-like passing style, sessions or cookies]

3) there is currently only one way to implement the MVC "view" and that
forces you to use XSP. This might not be a performance problem, but it
might become a usability problem.

Let's talk about each one of them independently.

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

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.

 2) you can have more than one flowmap in a sitemap (then you can define
a default one or use a 'flowmap' attribute in "map:call" to identify
which flowmap you are calling)

[of course, in order to accomplish this, the implementation must
completely isolate the different flowmaps and its global variables]

 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.

 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.

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.

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.

                              - oooo -

Ok, almost there.

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)

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]

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

                              - oooo -

Ok, please, send your comments.

Ciao.

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


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

Re: [RT] Flowmaps

[Ivelin Ivanov <iv...@apache.org>]

Stefano Mazzocchi wrote:
> Bruno Dumon wrote:
> 
>>On Sun, 2002-06-16 at 17:52, Stefano Mazzocchi wrote:
>>[snip]
>>
>>>[NOTE: it is *not* required that you use continuations for your flow
>>>logic, you can use whatever means you have to control state as you did
>>>previously, such as REST-like passing style, sessions or cookies]
>>>
>>
>>You state that "it is *not* required that you use continuations".
>>Suppose that I choose not to, then what advantage do flowmaps provide
>>over actions?
> 
> 
> I see mostly a big one:
> 
>   try/fail cycle is reduced by orders of magnitude
> 
> with actions, you have to compile the java,

true

> move the class,

I don't do that. My webapp is running off of \cvs\xml-cocoon2\src\webapp

> restart cocoon (if not the servlet container, in some cases) 

I reload the cocoon web app.

I don't know enough about the flowmap, but depending on the binding 
between Rhino and Java, reloading Cocoon may be required.

 > and retry.

isn't that true either way :-?

> 
> I personally see others, but the above is the only big objective one I
> can think of.
> 



-- 

-= Ivelin =-


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

Re: [RT] Flowmaps

[Stefano Mazzocchi <st...@apache.org>]

Bruno Dumon wrote:
> 
> On Sun, 2002-06-16 at 17:52, Stefano Mazzocchi wrote:
> [snip]
> >
> > [NOTE: it is *not* required that you use continuations for your flow
> > logic, you can use whatever means you have to control state as you did
> > previously, such as REST-like passing style, sessions or cookies]
> >
> 
> You state that "it is *not* required that you use continuations".
> Suppose that I choose not to, then what advantage do flowmaps provide
> over actions?

I see mostly a big one:

  try/fail cycle is reduced by orders of magnitude

with actions, you have to compile the java, move the class, restart
cocoon (if not the servlet container, in some cases) and retry.

I personally see others, but the above is the only big objective one I
can think of.

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



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

Re: [RT] Flowmaps

[Bruno Dumon <br...@outerthought.org>]

On Sun, 2002-06-16 at 17:52, Stefano Mazzocchi wrote:
[snip]
> 
> [NOTE: it is *not* required that you use continuations for your flow
> logic, you can use whatever means you have to control state as you did
> previously, such as REST-like passing style, sessions or cookies]
> 

You state that "it is *not* required that you use continuations".
Suppose that I choose not to, then what advantage do flowmaps provide
over actions?

-- 
Bruno Dumon



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

Re: [RT] Flowmaps

[Stefano Mazzocchi <st...@apache.org>]

Ivelin Ivanov wrote:
> 
>  > c) the sitemap executes the "getNumberA.xsp", which is given by
>  >
>  > <xsp:page
>  >   language="java"
>  >   xmlns:xsp="http://apache.org/xsp"
>  >   xmlns:jpath="http://apache.org/xsp/jpath/1.0"
>  >
>  > <document>
>  >  <body>
>  >   <s1 title="Calculator">
>  >    <form>
>  >     <xsp:attribute name="action">
>  >      <xsp:expr>"kont/" + <jpath:continuation/></xsp:expr>
>  >     </xsp:attribute>
>  >
>  >     <p>Enter value of <strong>a</strong>:
>  >           <input type="text" name="a"/></p>
>  >     <input type="submit" name="submit" value="Enter"/>
>  >    </form>
>  >   </s1>
>  >  </body>
>  > </document>
>  > </xsp:page>
> 
> What if this is represented by:
> 
> <document xmlns:xf="http://xml.apache.org/cocoon/xmlform/2002">
>     <xf:form id="form-calculator" view="enter_A" action="kont">
>           <xf:caption>Enter Value For A</xf:caption>
>           <xf:textbox ref="a">
>               <xf:caption>number A</xf:caption>
>               <xf:violations class="error"/>
>           </xf:textbox>
>           <xf:submit id="submit" class="button">
>               <xf:caption>Enter</xf:caption>
>           </xf:submit>
>     </xf:form>
> </document>
> 
> The XMLForm transformer can automatically do the job of the jpath logic
> sheet and append the continuation parameter to the request.

Absolutely! The extremely nice thing about the current flowmap design is
that SoC is maintained. The flowmap deals with the logic, but the URI
handling and response generation is the sitemap's responsibility since
it's nothing about 'flow'.

This allows you to do whatever you want to come up with the response,
and your flowmap-aware transformers can be as complex/capable as you
like, just they don't require you to write actions anymore.

>  >
>  > where the "jpath" logicsheet is used to obtain the "continuation" of the
>  > current flow and is then encoded in the URI called.
>  >
>  > So, when the users hits 'submit', Cocoon will receive a request for an
>  > hypotetical URI "kont/39849834983498", then Cocoon will match it with:
>  >
>  >       <map:match pattern="kont/*">
>  >         <map:continue with="{1}"/>
>  >       </map:match>
>  >
>  > and resurrect the flow logic from where it was left. So, again, between
> 
> We can come back to this later, since it affects performance and
> scalability, not functionality, but I'll raise the issue early.
> There is a potential for overloading the server memory with stale
> continuations. This will happen if halfway through the wizard a user
> decides to jump to an unrelated part of the site. The next time they
> decide to return to the wizard, it will start a new continuation stack,
> unless they return with the Back button, which may or may not be the case.

This is a good point: out of my head, we could solve this like we do for
sessions by using an expiration time. In that case, an expired
continuation will trigger you back to the initial state.

Anyway, this requires more thinking... hmmm, great point anyway.

>  >
>  > First of all, let me say that I consider the above concept the biggest
>  > advancement in server-side web technology since servlets.
> 
> It certainly is quite ambitious.

Granted.

> It choses to follow a command line driven input model, versus desktop
> GUI model. Most web apps today chose to act on commands/events much like
> a desktop GUI app.
> It may not be easy or cost efficient to describe some page flows
> with a flowmap. Multi page forms are used often but they are not
> dominating.

Everywhere I looked in the programming circles I've been involved with,
there is somebody feeling lost without the good old procedural
programming.

I know many (myself included) who dislike GUI builders because they are
so declarative that it's scary: they build the skeleton for you (and
this is great), but then you are left with a bunch of work to do to fill
the holes and no global vision whatsover.

When I wrote JMeter, I started with JBuilder and I had a monolythic
piece of software. So I erased it, went back to good old text editor and
came up with a highly modular GUI solution (which is still in place
today after 4 years).

Sure, I agree with you that the flowmap might not map 100% of the cases
well, but if it maps even only 80% of the cases with the simplicity and
RAD of a client side javascript code and the full power of the cocoon
framework, I strongly doubt anybody will complain for that 20% which
requires them to write specific java components.

At least, this is my personal vision.
 
>  > This design not only makes it a breeze to implement MVC, but it shows
>  > you how natural and clear things become once you separate the procedural
>  > flow, from the declarative serving of resources.
> 
> It certainly makes natural describing linear workflow.
> There is a variety of UI usage patterns which are not linear
> and might be easier handled with command/event handling model.

Absolutely. But remember: you are *not* forced to use the flowmap and
for sure, we won't deprecate actions until everybody agrees that they
are not needed anymore (which I grant might be an overstatement from my
side)

> Since I never experimented with the newly proposed approach though, I
> remain very interested in its use cases.

I find myself in the same situation.

Hopefully, by providing more docs and howtos people will try it out and
show us enough usecases to let us validate the concept in real life.
[even if, to be honest with you, it seems just too appealing on paper
not to work in practice]

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



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

Re: [RT] Flowmaps

[Ivelin Ivanov <iv...@apache.org>]

Jens Lorenz wrote:

> Exactly. It's already used within our own Cocoon-based projects.
> Currently the interface from Cocoon to JState is via an Action.
> 
> Well, if your apps grow a bit bigger this tends to get messy.
> It would be great, if we could integrate this into a Java-based
> Flowmap (best maintainable). Integration into Flow Object Model
> also does the job, but would probably look a bit awkward - have
> to see this first.


I've looked at JStated and now I am a bit confused.
JState appears to be a framework list Struts, not just a state machine 
package.
Can you write a sample of how this could work with Cocoon flow or XMLForm?


Ivelin



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

Re: [RT] Flowmaps

[Jens Lorenz <je...@interface-projects.de>]

From: "Ivelin Ivanov" <iv...@apache.org>
To: <co...@xml.apache.org>
Sent: Monday, June 17, 2002 2:40 PM
Subject: Re: [RT] Flowmaps


> Jens Lorenz wrote:
> >>It certainly is quite ambitious.
> >>It choses to follow a command line driven input model, versus desktop
> >>GUI model. Most web apps today chose to act on commands/events much
like
> >>a desktop GUI app.
> >>It may not be easy or cost efficient to describe some page flows
> >>with a flowmap. Multi page forms are used often but they are not
> >>dominating.
> >
> >
> > What about using something like a State-Machine for this ? If there
> > would be a Java-Language for Flowmaps then it would be also quite
> > easy to implement (especially if you use something like JState).
>
> I'll take a look.
> Do you mean http://sourceforge.net/projects/jstatemachine/
> or another tool?
>


Exactly. It's already used within our own Cocoon-based projects.
Currently the interface from Cocoon to JState is via an Action.

Well, if your apps grow a bit bigger this tends to get messy.
It would be great, if we could integrate this into a Java-based
Flowmap (best maintainable). Integration into Flow Object Model
also does the job, but would probably look a bit awkward - have
to see this first.


Regards,

Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH                             \\|//
Tolkewitzer Strasse 49                              (o o)
01277 Dresden                               ~~~~oOOo~(_)~oOOo~~~~
Germany


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

Re: [RT] Flowmaps

[Ivelin Ivanov <iv...@apache.org>]

Jens Lorenz wrote:
> ----- Original Message -----
>>It certainly is quite ambitious.
>>It choses to follow a command line driven input model, versus desktop
>>GUI model. Most web apps today chose to act on commands/events much like
>>a desktop GUI app.
>>It may not be easy or cost efficient to describe some page flows
>>with a flowmap. Multi page forms are used often but they are not
>>dominating.
> 
> 
> What about using something like a State-Machine for this ? If there
> would be a Java-Language for Flowmaps then it would be also quite
> easy to implement (especially if you use something like JState).

I'll take a look.
Do you mean http://sourceforge.net/projects/jstatemachine/
or another tool?

-- 

-= Ivelin =-


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

Re: [RT] Flowmaps

[Jens Lorenz <je...@interface-projects.de>]

----- Original Message -----
From: "Ivelin Ivanov" <iv...@apache.org>
To: <co...@xml.apache.org>
Sent: Sunday, June 16, 2002 10:17 PM
Subject: Re: [RT] Flowmaps

<snip/>

>  > First of all, let me say that I consider the above concept the
biggest
>  > advancement in server-side web technology since servlets.
>
> It certainly is quite ambitious.
> It choses to follow a command line driven input model, versus desktop
> GUI model. Most web apps today chose to act on commands/events much like
> a desktop GUI app.
> It may not be easy or cost efficient to describe some page flows
> with a flowmap. Multi page forms are used often but they are not
> dominating.

What about using something like a State-Machine for this ? If there
would be a Java-Language for Flowmaps then it would be also quite
easy to implement (especially if you use something like JState).

>  > This design not only makes it a breeze to implement MVC, but it shows
>  > you how natural and clear things become once you separate the
procedural
>  > flow, from the declarative serving of resources.
>
> It certainly makes natural describing linear workflow.
> There is a variety of UI usage patterns which are not linear
> and might be easier handled with command/event handling model.
>
> Since I never experimented with the newly proposed approach though, I
> remain very interested in its use cases.
>
>
>
> Cheers,
>
>
> Ivelin
>

Regards,


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH                             \\|//
Tolkewitzer Strasse 49                              (o o)
01277 Dresden                               ~~~~oOOo~(_)~oOOo~~~~
Germany


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

Re: [RT] Flowmaps

[Ivelin Ivanov <iv...@apache.org>]

 > c) the sitemap executes the "getNumberA.xsp", which is given by
 >
 > <xsp:page
 >   language="java"
 >   xmlns:xsp="http://apache.org/xsp"
 >   xmlns:jpath="http://apache.org/xsp/jpath/1.0"
 >
 > <document>
 >  <body>
 >   <s1 title="Calculator">
 >    <form>
 >     <xsp:attribute name="action">
 >      <xsp:expr>"kont/" + <jpath:continuation/></xsp:expr>
 >     </xsp:attribute>
 >
 >     <p>Enter value of <strong>a</strong>:
 >           <input type="text" name="a"/></p>
 >     <input type="submit" name="submit" value="Enter"/>
 >    </form>
 >   </s1>
 >  </body>
 > </document>
 > </xsp:page>


What if this is represented by:

<document xmlns:xf="http://xml.apache.org/cocoon/xmlform/2002">
    <xf:form id="form-calculator" view="enter_A" action="kont">
          <xf:caption>Enter Value For A</xf:caption>
          <xf:textbox ref="a">
              <xf:caption>number A</xf:caption>
              <xf:violations class="error"/>
          </xf:textbox>
          <xf:submit id="submit" class="button">
              <xf:caption>Enter</xf:caption>
          </xf:submit>
    </xf:form>
</document>


The XMLForm transformer can automatically do the job of the jpath logic
sheet and append the continuation parameter to the request.

 >
 > where the "jpath" logicsheet is used to obtain the "continuation" of the
 > current flow and is then encoded in the URI called.
 >
 > So, when the users hits 'submit', Cocoon will receive a request for an
 > hypotetical URI "kont/39849834983498", then Cocoon will match it with:
 >
 >       <map:match pattern="kont/*">
 >         <map:continue with="{1}"/>
 >       </map:match>
 >
 > and resurrect the flow logic from where it was left. So, again, between

We can come back to this later, since it affects performance and
scalability, not functionality, but I'll raise the issue early.
There is a potential for overloading the server memory with stale
continuations. This will happen if halfway through the wizard a user
decides to jump to an unrelated part of the site. The next time they
decide to return to the wizard, it will start a new continuation stack,
unless they return with the Back button, which may or may not be the case.


 >
 > First of all, let me say that I consider the above concept the biggest
 > advancement in server-side web technology since servlets.

It certainly is quite ambitious.
It choses to follow a command line driven input model, versus desktop
GUI model. Most web apps today chose to act on commands/events much like
a desktop GUI app.
It may not be easy or cost efficient to describe some page flows
with a flowmap. Multi page forms are used often but they are not
dominating.


 > This design not only makes it a breeze to implement MVC, but it shows
 > you how natural and clear things become once you separate the procedural
 > flow, from the declarative serving of resources.

It certainly makes natural describing linear workflow.
There is a variety of UI usage patterns which are not linear
and might be easier handled with command/event handling model.

Since I never experimented with the newly proposed approach though, I
remain very interested in its use cases.



Cheers,


Ivelin


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

Re: [RT] Flowmaps

[Nicola Ken Barozzi <ni...@apache.org>]

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

Re: [RT] Flowmaps

[Stefano Mazzocchi <st...@apache.org>]

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.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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

Re: [RT] Flowmaps

[Nicola Ken Barozzi <ni...@apache.org>]

Vadim Gritsenko wrote:
>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>Stefano Mazzocchi wrote:
> 

  <snip/>

> Why not replace these two with something more simple/obvious and
> something which better correlates with map:mount syntax we have now?
> 
> Something similar to:
> 
> <map:match pattern="calc/*">
>   <map:mount-flow check-reload="yes"
>                   src="calc/calculator.xflow"
>                   uri-prefix="calc" />
> </map:match>
> 
> Here, it will be not necessary to have additional and confusing to
> newbies "kont/*" matcher. Everything below calc/ goes to flowmap, and in
> flowmap you can use e.g. calc/kont/ to indicate continuation.
> 
> And, if flowmap has map:mount notion, all necessary for the calculator
> XSPs can be served by sub-sitemap with matcher:
> 
>>>    <map:match pattern="*.html">
>>>     <map:generate src="{1}.xsp" type="serverpages"/>
>>>     <map:serialize/>
>>>    </map:match>
>>>   </map:pipeline>
>>
> 
> Then, flowmap directory will be self-contained.
> Isn't this simpler and more logical?

I really like 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

Re: [RT] Flowmaps

[Nicola Ken Barozzi <ni...@apache.org>]

Stefano Mazzocchi wrote:
> Vadim Gritsenko wrote:
> 
> 
>>I also strongly hope that we can eliminate this extra matcher and won't
>>trip your alarms :)
> 
> 
> Let's see :)
>  
> 
>>I hear your fears. Let me make second try on this. This snippet below
>>will allow sitemap designer to choose what method of continuation
>>passing he wants to use. You can use either URI matching, or Cookie
>>matching, or parameter matching. Here, continuation obtained from the
>>URI:
>>
>><map:match pattern="calc/*">
>>  <map:flow method="calculator" continuation="{1}" />
>></map:match>
>>
>>This means: start flow if no continuation is provided or continue flow
>>if continuation is present.
>>
>>We can change wording (map:flow -> map:whatever), can change number of
>>arguments, etc, but my feelings is that it will be easier to use and
>>understand if flow requires only one sitemap "operator", but not two as
>>of now: map:continue and map:call.
> 
> 
> I hear no alarm ringing, that's a good thing :)

I like it too :-)

One more thing, last night I was thinking of what you said, that 
flowmaps should be a new type of Actions, not a component on the same 
level of a sitemap.

Though conceptually the sitemap-flowmap duality is appealing and seems 
more clean, I do see the problem: sitemaps that mount flowmaps that call 
sitemaps that mount flowmaps that get it all in an *undebuggable* mess.

I think that we could even change the name "flowmap", that is too 
similar to "sitemap". It's not a "map".

It could be quite easy to explain that a "flow" is a new type of action 
that keeps "special session=continuations" between requests.

>>I agree with Nicola's argument: users might get confused if call is
>>loaded with one more meaning.
>>
>>Or might be not...
> 
> What do others think about 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

Re: [RT] Flowmaps

[Andy Lewis <aj...@ascii27.net>]

VERY clean...I really like it....


> Vadim Gritsenko wrote:
>
>> I also strongly hope that we can eliminate this extra matcher and won't trip your alarms :)
>
> Let's see :)
>
>> I hear your fears. Let me make second try on this. This snippet below will allow sitemap
>> designer to choose what method of continuation passing he wants to use. You can use either URI
>> matching, or Cookie matching, or parameter matching. Here, continuation obtained from the URI:
>>
>> <map:match pattern="calc/*">
>>   <map:flow method="calculator" continuation="{1}" />
>> </map:match>
>>
>> This means: start flow if no continuation is provided or continue flow if continuation is
>> present.
>>
>> We can change wording (map:flow -> map:whatever), can change number of arguments, etc, but my
>> feelings is that it will be easier to use and understand if flow requires only one sitemap
>> "operator", but not two as of now: map:continue and map:call.
>
> I hear no alarm ringing, that's a good thing :)
>
>> I agree with Nicola's argument: users might get confused if call is loaded with one more
>> meaning.
>>
>> Or might be not...
>
> What do others think about this?
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                          able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------- To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


-- 
"The heights of genius are only measurable by the depths of stupidity."



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

Re: [RT] Flowmaps

[Stefano Mazzocchi <st...@apache.org>]

Vadim Gritsenko wrote:

> I also strongly hope that we can eliminate this extra matcher and won't
> trip your alarms :)

Let's see :)
 
> I hear your fears. Let me make second try on this. This snippet below
> will allow sitemap designer to choose what method of continuation
> passing he wants to use. You can use either URI matching, or Cookie
> matching, or parameter matching. Here, continuation obtained from the
> URI:
> 
> <map:match pattern="calc/*">
>   <map:flow method="calculator" continuation="{1}" />
> </map:match>
> 
> This means: start flow if no continuation is provided or continue flow
> if continuation is present.
> 
> We can change wording (map:flow -> map:whatever), can change number of
> arguments, etc, but my feelings is that it will be easier to use and
> understand if flow requires only one sitemap "operator", but not two as
> of now: map:continue and map:call.

I hear no alarm ringing, that's a good thing :)
 
> I agree with Nicola's argument: users might get confused if call is
> loaded with one more meaning.
> 
> Or might be not...

What do others think about this?

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


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

RE: [RT] Flowmaps

[Vadim Gritsenko <va...@verizon.net>]

> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> 
> Vadim Gritsenko wrote:
> >
> > > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > >
> > > Stefano Mazzocchi wrote:

<snip/>


> > > > More explicit sitemap markup
> > > > ----------------------------

<snip what="flowmap declaration"/>


> > > >   <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>
> >
> > Why not replace these two with something more simple/obvious and
> > something which better correlates with map:mount syntax we have now?
> 
> Because I don't want the people to perceive that a 'flowmap' is just
> another way to process pipelines.
> 
> In the past, I had that impression myself that this symmetry was a
good
> thing, but I've changed my mind: I think that flowmaps should replace
> actions, not replace a subsitemap.
> 
> > Something similar to:
> >
> > <map:match pattern="calc/*">
> >   <map:mount-flow check-reload="yes"
> >                   src="calc/calculator.xflow"
> >                   uri-prefix="calc" />
> > </map:match>
> >
> > Here, it will be not necessary to have additional and confusing to
> > newbies "kont/*" matcher. Everything below calc/ goes to flowmap,
and in
> > flowmap you can use e.g. calc/kont/ to indicate continuation.
> >
> > And, if flowmap has map:mount notion, all necessary for the
calculator
> > XSPs can be served by sub-sitemap with matcher:
> 
> I perfectly see your point because this was my previous idea as well:
> sitemap and flowmap both implement 'pipeline processor', one uses a
> declarative markup syntax, the other uses a procedural code-like
syntax.
> 
> While appealing conceptually, my FS alarms start ringing when I fear

:)


> people asking to be able to control and assemble pipelines directly
from
> the flowmap.
> 
> What you are proposing opens the door to major overlap between sitemap
> and flowmap in functionality and this might result, in the future, to
us
> writing big time docos about 'best practices' that say "keep things
> separate".
> 
> The approach I proposed *forces* things to be separate: there is no
way
> for a flowmap to assemble a pipeline, since it's not its concern. Flow
> logic is anything that is not directly related to XML.
> 
> I fear that if we make the sitemap and flowmap functionally overlap
> (like you are somewhat proposing with the semantics above), then we'll
> have to surrender to people asking for more granular pipeline control,
> then we'll have to wait years until they figure out that the sitemap
is
> the place to control pipelines and the flowmap is the place to control
> flow logic that doesn't deal with the pipeline directly but calls
them.
> 
> Of course, this is just my personal impression of the future evolution
> of the concept, but I can't stop my FS alarms from ringing on this.

<snip what="mount sub sitemap from flowmap"/>


> > > 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?".
> >
> > +1 to eliminate it. I would love to see flowmaps working same way
> > sub-sitemaps do.
> 
> I strongly hope you change your mind after what I wrote above.

I also strongly hope that we can eliminate this extra matcher and won't
trip your alarms :)

I hear your fears. Let me make second try on this. This snippet below
will allow sitemap designer to choose what method of continuation
passing he wants to use. You can use either URI matching, or Cookie
matching, or parameter matching. Here, continuation obtained from the
URI:

<map:match pattern="calc/*">
  <map:flow method="calculator" continuation="{1}" />
</map:match>

This means: start flow if no continuation is provided or continue flow
if continuation is present.

We can change wording (map:flow -> map:whatever), can change number of
arguments, etc, but my feelings is that it will be easier to use and
understand if flow requires only one sitemap "operator", but not two as
of now: map:continue and map:call.

 
> > > How about:
> > >       <map:match pattern="">
> > >        <map:call function="calculator('prefix','/kont')
> > >                  continuation-match="kont/*"/>
> > >       </map:match>
> >
> > As stated below, flowmaps aren't resources, hence map:call doesn't
fit
> > here well.
> 
> Again, map:call is not about resources but it's about jumping to
another
> execution point, as the 'call' word clearly implies. I see no issues
in
> keeping the semantic coherent.

I agree with Nicola's argument: users might get confused if call is
loaded with one more meaning.

Or might be not...


Vadim

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


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

Re: [RT] Flowmaps

[Stefano Mazzocchi <st...@apache.org>]

Vadim Gritsenko wrote:
> 
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> > Stefano Mazzocchi wrote:
> 
> <snip/>
> 
> Guys, I'd like to question some of the sitemap markup also...

Great.

> > > 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>
> 
> Is this necessary step? We do not declare like this all sitemaps we
> mount later. Why it is necessary to declare flowmaps, can't this step be
> omitted?

This is good point. See more comments below.

> > >   <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>
> 
> Why not replace these two with something more simple/obvious and
> something which better correlates with map:mount syntax we have now?

Because I don't want the people to perceive that a 'flowmap' is just
another way to process pipelines.

In the past, I had that impression myself that this symmetry was a good
thing, but I've changed my mind: I think that flowmaps should replace
actions, not replace a subsitemap.

> Something similar to:
> 
> <map:match pattern="calc/*">
>   <map:mount-flow check-reload="yes"
>                   src="calc/calculator.xflow"
>                   uri-prefix="calc" />
> </map:match>
> 
> Here, it will be not necessary to have additional and confusing to
> newbies "kont/*" matcher. Everything below calc/ goes to flowmap, and in
> flowmap you can use e.g. calc/kont/ to indicate continuation.
> 
> And, if flowmap has map:mount notion, all necessary for the calculator
> XSPs can be served by sub-sitemap with matcher:

I perfectly see your point because this was my previous idea as well:
sitemap and flowmap both implement 'pipeline processor', one uses a
declarative markup syntax, the other uses a procedural code-like syntax.

While appealing conceptually, my FS alarms start ringing when I fear
people asking to be able to control and assemble pipelines directly from
the flowmap.

What you are proposing opens the door to major overlap between sitemap
and flowmap in functionality and this might result, in the future, to us
writing big time docos about 'best practices' that say "keep things
separate".

The approach I proposed *forces* things to be separate: there is no way
for a flowmap to assemble a pipeline, since it's not its concern. Flow
logic is anything that is not directly related to XML.

I fear that if we make the sitemap and flowmap functionally overlap
(like you are somewhat proposing with the semantics above), then we'll
have to surrender to people asking for more granular pipeline control,
then we'll have to wait years until they figure out that the sitemap is
the place to control pipelines and the flowmap is the place to control
flow logic that doesn't deal with the pipeline directly but calls them.

Of course, this is just my personal impression of the future evolution
of the concept, but I can't stop my FS alarms from ringing on this.

> > >     <map:match pattern="*.html">
> > >      <map:generate src="{1}.xsp" type="serverpages"/>
> > >      <map:serialize/>
> > >     </map:match>
> > >    </map:pipeline>
> 
> Then, flowmap directory will be self-contained.
> Isn't this simpler and more logical?

See above.

> > 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?".
> 
> +1 to eliminate it. I would love to see flowmaps working same way
> sub-sitemaps do.

I strongly hope you change your mind after what I wrote above.
 
> > How about:
> >       <map:match pattern="">
> >        <map:call function="calculator('prefix','/kont')
> >                  continuation-match="kont/*"/>
> >       </map:match>
> 
> As stated below, flowmaps aren't resources, hence map:call doesn't fit
> here well.

Again, map:call is not about resources but it's about jumping to another
execution point, as the 'call' word clearly implies. I see no issues in
keeping the semantic coherent.

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


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

RE: [RT] Flowmaps

[Vadim Gritsenko <va...@verizon.net>]

> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> 
> Stefano Mazzocchi wrote:

<snip/>

Guys, I'd like to question some of the sitemap markup also...


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

Is this necessary step? We do not declare like this all sitemaps we
mount later. Why it is necessary to declare flowmaps, can't this step be
omitted?


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

Why not replace these two with something more simple/obvious and
something which better correlates with map:mount syntax we have now?

Something similar to:

<map:match pattern="calc/*">
  <map:mount-flow check-reload="yes"
                  src="calc/calculator.xflow"
                  uri-prefix="calc" />
</map:match>

Here, it will be not necessary to have additional and confusing to
newbies "kont/*" matcher. Everything below calc/ goes to flowmap, and in
flowmap you can use e.g. calc/kont/ to indicate continuation.

And, if flowmap has map:mount notion, all necessary for the calculator
XSPs can be served by sub-sitemap with matcher:


> >     <map:match pattern="*.html">
> >      <map:generate src="{1}.xsp" type="serverpages"/>
> >      <map:serialize/>
> >     </map:match>
> >    </map:pipeline>

Then, flowmap directory will be self-contained.
Isn't this simpler and more logical?



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

+1 to eliminate it. I would love to see flowmaps working same way
sub-sitemaps do.


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

As stated below, flowmaps aren't resources, hence map:call doesn't fit
here well.


Vadim

> > 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  The sitemap should reflect real semantics, ie flowmap!=resource

<snip/>



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

Re: [RT] Flowmaps

[Nicola Ken Barozzi <ni...@apache.org>]

Stefano Mazzocchi wrote:

> The problems with this approach
> -------------------------------
> 
> First of all, let me say that I consider the above concept the biggest
> advancement in server-side web technology since servlets.

I would say since web servers.

Some weeks ago I showed it to a friend of mine that I have been helping 
out on C2 for his-our value-chain management system, and he almost fainted!

Ten minutes after I showed it to him, that is, since it takes some time 
for the concept to get to the correct neurons ;-)

I've snipped the analysis, which I find correct and clean, as always :-)


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

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

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

      </map:match>


> 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  The sitemap should reflect real semantics, ie flowmap!=resource

>  2) you can have more than one flowmap in a sitemap (then you can define
> a default one or use a 'flowmap' attribute in "map:call" to identify
> which flowmap you are calling)
> 
> [of course, in order to accomplish this, the implementation must
> completely isolate the different flowmaps and its global variables]

+1  This is almost obvious, but very important to state.

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

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

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

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

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


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

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

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

Thank you, thank you, thank you :-)

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

Re: [RT] Flowmaps

[Torsten Curdt <tc...@dff.st>]

>  /xml-cocoon2/src/webapp/samples/flow/examples/calc/
>
> which is a sample about a very simple web application that implements a
> calculator using the flowmap.
>
> First of all, I'll outline the 'procedural flow logic' of this
> application using highly-pseudo code:
>
>  1) tell me the first operand
>  2) tell me the second operand
>  3) tell me the operation to apply
>  4) here is your result
>
> You'll see how much similar to the actual implementing code this will
> look like. This is probably already a great advantage over anything that
> we had before.

Everyone is so enthusiastic about the new flowmap implementation (indeed great 
work!) but I am actually wondering how a more complex application could look 
like:

for the xmlform / precept stuff we aggreed on the following requirements for a 
more complex example (IIRC):

 - 3 page form
 - should be possible to go back and forth
 - a summary page at the end
 - and a result page (success/failed)
 - validation against a schema
 - everything should be i18n aware

How could this look like implemented with the current flowmap? 
Here is my first try: (please bear with me - a lot is NYI ;-)

function wizard(uriPrefix) {
  var id = cocoon.request.getParameter("someid");
  
  var factory = SchemaFactory.getInstance("ns");
  //maybe we can get the schema from a pipeline??
  var schema = factory.compile("someschema.xsd.dtd.rng.sch"); 
  var validator = schema.createValidator();
  var instance = new Instance();

  loadInstance(instance,id);
  
  do {
   do {
    sendPage(uriPrefix + "page1.html");
    Instance.populate(instance,cocoon.request);
   } while(!validator.isValid(instance, "page1"));

   do {
    sendPage(uriPrefix + "page2.html");
    Instance.populate(instance,cocoon.request);
   } while(!validator.isValid(instance, "page2"));

   do {
    sendPage(uriPrefix + "page3.html");
    Instance.populate(instance,cocoon.request);
   } while(!validator.isValid(instance, "page3"));

  } while(!validator.isValid(instance));

  if(saveInstance(instance,id)) {
   sendPage("success.html");
  }
  else {
   sendPage("failed.html");
  }
}

function loadInstance( instance, id ) {
  // how to get the values from the pipeline into the instance?
  callPipeline("loadInstance.xsp",input,output);
}

function saveInstance( instance, id ) {
  // same here...
  callPipeline("saveInstance.xsp",input,output);
}


A lot of details are still missing. Maybe someone can help out here...
Especially how would you implement the "go back" button?

If have still dozens of thoughts in head (what about sub-flows? flow-2-flow 
communications,..) need to sort them first.


> This is *NOT* possible with any other FSM-based approach.

Sorry, for the (maybe) stupid question but... why not?

cheers
--
Torsten

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

Re: [RT] Flowmaps

["Andrew C. Oliver" <ac...@apache.org>]

Thank you eversomuch!  Thats very helpful.  I'm going to take some time 
and digest it all and then
I'll provide any thoughts.

Stefano Mazzocchi wrote:

>Last time I wrote an RT about these things, the flowmap wasn't
>implemented. Today it's working, but there are things that I would like
>to change.
>
>This RT is to start a discussion that will hopefully lead to a coherent
>and community-driven design on what the flowmap engine will look like.
>
>First of all, since there is no clear howto about the current flowmap
>and I need to give you context in order to make you partecipate in the
>discussion, I'll write a basic explaination of what's going on.
>
>                              - oooo -
>
>How Ovidiu implemented the flowmap concept
>------------------------------------------
>
>First of all, do a 'cvs checkout' of HEAD if you haven't done so. I'm
>referring to the samples that you find in 
>
> /xml-cocoon2/src/webapp/samples/flow/examples/calc/
>
>which is a sample about a very simple web application that implements a
>calculator using the flowmap.
>
>First of all, I'll outline the 'procedural flow logic' of this
>application using highly-pseudo code:
>
> 1) tell me the first operand
> 2) tell me the second operand
> 3) tell me the operation to apply
> 4) here is your result
>
>You'll see how much similar to the actual implementing code this will
>look like. This is probably already a great advantage over anything that
>we had before.
>
>Let us look at the sitemap:
>
><map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
>
>  [skipping component declaration]
>
>  <map:resources>
>    <map:resource name="flow">
>      <map:script src="calc.js"/>
>    </map:resource>
>  </map:resources>
>
>  <map:pipelines>
>    <map:pipeline>
>      <map:match pattern="kont/*">
>        <map:continue with="{1}"/>
>      </map:match>
>
>      <map:match pattern="">
>        <map:call function="calculator">
>          <map:parameter name="prefix"
>value="/samples/flow/examples/calc/"/>
>        </map:call>
>      </map:match>
>
>      <map:match pattern="*.html">
>        <map:generate src="{1}.xsp" type="serverpages"/>
>        <map:serialize/>
>      </map:match>
>    </map:pipeline>
>  </map:pipelines>
></map:sitemap>
>
>So, Ovidiu added three concepts that weren't found in the previous
>sitemap implementations:
>
> 1) a new "map:script" component connects a sitemap resource with a
>flowmap (which is here implemented as a javascript program)
>
> 2) a new attribute "map:call/@function" allows you to pass control from
>the sitemap to the flowmap, calling the function defined in the
>attribute and passing the nested "map:parameter" to the function as a
>regular call.
>
> 3) a "map:continue" element indicates that the flow must be continued
>with the continuation passed in the attribute "@with".
>
>Let's look at the flowmap:
>
>  var prefix;
>
>  function calculator(uriPrefix)
>  {
>    prefix = uriPrefix;
>    var a = getNumber("a");
>    var b = getNumber("b", a);
>    var op = getOperator(a, b);
>
>    if (op == "plus")
>      sendResult(a, b, op, a + b);
>    else if (op == "minus")
>      sendResult(a, b, op, a - b);
>    else if (op == "multiply")
>      sendResult(a, b, op, a * b);
>    else if (op == "divide")
>      sendResult(a, b, op, a / b);
>    else
>      sendResult("Error: Unkown operator!");
>  }
>
>the 'calculator' function is the one that is called from the sitemap. As
>you can see, the procedural logic of your flow is *very well* described:
>I'm sure that it would takes a few minutes for anybody to understand
>what your application is doing.
>
>This is *NOT* possible with any other FSM-based approach.
>
>If you think about it, in Cocoon 1.x we used PI to encode state
>transitions in every stage, then we identified this as a problem and we
>centralized it into the sitemap: the location where you can understand
>what your URI does in a central and confortable location.
>
>Here we are doing it again, but instead of contralizing declarative
>client/server behavior, we are centralizing procedural web-app flow.
>
>But let's keep looking into the flowmap:
>
>   function getNumber(name, a, b)
>   {
>1     var uri = prefix + "getNumber" + name.toUpperCase() + ".html";
>2     sendPage(uri, { "a" : a, "b" : b });
>3     return parseFloat(cocoon.request.getParameter(name));
>   }
>
>This function collects the number required by the flow:
>
>line 1: the URI of the resource to use is created
>line 2: the URI is sent to the client, along with some parameters in a
>map
>line 3: a float is returned from the cocoon request parameter named with
>the given name
>
>Anybody who ever wrote a webapp would think we are nuts: line 2
>generates a response and line 3 reads a request. But here is where the
>flowmap gets magic, there are bunch of things that you don't see
>happening.
>
>So, let's look at that function from what really happens behind the
>lines, let us suppose we call
>
>  var a = getNumber("a");
>
>then
>
>a) the sitemap is called to process a the URI 'getNumberA.html'
>b) the sitemap matches with this matcher
>
>     <map:match pattern="*.html">
>        <map:generate src="{1}.xsp" type="serverpages"/>
>        <map:serialize/>
>      </map:match>
>
>c) the sitemap executes the "getNumberA.xsp", which is given by
>
><xsp:page
>  language="java"
>  xmlns:xsp="http://apache.org/xsp"
>  xmlns:jpath="http://apache.org/xsp/jpath/1.0"
>  
>
>
><document>
> <body>
>  <s1 title="Calculator">
>   <form>
>    <xsp:attribute name="action">
>     <xsp:expr>"kont/" + <jpath:continuation/></xsp:expr>
>    </xsp:attribute>
>
>    <p>Enter value of <strong>a</strong>: 
>          <input type="text" name="a"/></p>
>    <input type="submit" name="submit" value="Enter"/>
>   </form>
>  </s1>
> </body>
></document>
></xsp:page>
>
>where the "jpath" logicsheet is used to obtain the "continuation" of the
>current flow and is then encoded in the URI called.
>
>So, when the users hits 'submit', Cocoon will receive a request for an
>hypotetical URI "kont/39849834983498", then Cocoon will match it with:
>
>      <map:match pattern="kont/*">
>        <map:continue with="{1}"/>
>      </map:match>
>
>and resurrect the flow logic from where it was left. So, again, between
>
>   function getNumber(name, a, b)
>   {
>1     var uri = prefix + "getNumber" + name.toUpperCase() + ".html";
>2     sendPage(uri, { "a" : a, "b" : b });
>3     return parseFloat(cocoon.request.getParameter(name));
>   }
>
>line 2 and line 3, several things happen
>
> 1) control is given to the sitemap
> 2) the sitemap produces a response which encodes the continuation
> 3) this response is sent to the client
> 4) the client acts with the response
> 5) cocoon receives a request for a continuation-decoding URI
> 6) the flowmap is called with the given continuation (think of it as a
>starting point)
>
>If you think of the above as a command line environment, line 2 gives
>you the dialog where to enter the number and line 3 uses the number
>returned from the user.
>
>[the rest of the flowmap is easy to understand if you understood so far,
>so I'll skip it]
>
>                              - oooo -
>
>The problems with this approach
>-------------------------------
>
>First of all, let me say that I consider the above concept the biggest
>advancement in server-side web technology since servlets.
>
>This design not only makes it a breeze to implement MVC, but it shows
>you how natural and clear things become once you separate the procedural
>flow, from the declarative serving of resources.
>
>At the same time, I think there are a number of issues that we might
>solve before freezing the concept in a beta release:
>
>1) the semantics to call a flowmap from a sitemap are too implicit:
>users must assume to much from what they read (ie self-readability of
>the concept is very poor).
>
>2) the concept of continuations is not transparent, there is concern
>overlap between the view designers and the sitemap managers since the
>view designers must be aware of the URI location of the
>continuation-decoding URI.
>
>[NOTE: it is *not* required that you use continuations for your flow
>logic, you can use whatever means you have to control state as you did
>previously, such as REST-like passing style, sessions or cookies]
>
>3) there is currently only one way to implement the MVC "view" and that
>forces you to use XSP. This might not be a performance problem, but it
>might become a usability problem.
>
>Let's talk about each one of them independently.
>
>[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]
>
>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.
>
> 2) you can have more than one flowmap in a sitemap (then you can define
>a default one or use a 'flowmap' attribute in "map:call" to identify
>which flowmap you are calling)
>
>[of course, in order to accomplish this, the implementation must
>completely isolate the different flowmaps and its global variables]
>
> 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.
>
> 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.
>
>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.
>
>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.
>
>                              - oooo -
>
>Ok, almost there.
>
>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)
>
>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]
>
>                              - 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.
>
>                              - oooo -
>
>Ok, please, send your comments.
>
>Ciao.
>
>  
>




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

Re: [RT] Flowmaps

[F Baube <fb...@welho.com>]

not sure if this helps, but ...

thusly spake Sylvain Wallez:
>
> [..]
> 
> 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.

Wyona discusses something (?)similar.

http://www.wyona.org/docs/wyona-cms-docs/developer-guide/wf/index.html
http://www.wyona.org/docs/wyona-cms-docs/developer-guide/cm/index.html



fred

-- 
F. Baube 
fbaube @ welho.com
+ 358 41 536 8192 


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

Re: [RT] Flowmaps

[Stefano Mazzocchi <st...@apache.org>]

Sylvain Wallez wrote:

> +1000 ! People to which I explain this at first don't understand it as
> it is "too much simple" : over the years, we have twisted our minds to
> overcome the limitations of the web infrastructure. But once they grasp
> it, they fall on the floor !

That's exactly the same experience I had: people simply say "c'mon it
can't be that easy"... well, it general it's not but the good old
"simple things should be simple and hard things should be possible" not
only applies to Perl :)
 
> >[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 ;)
> In France, we no more have this kind of problem :(

I'll comment this tomorrow afternoon :)
 
> > 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?

Good question: I really don't know. I would keep the basic anti-FS
pattern: do it only when you need it, not because it's symmetric.

> While
> thinking of that, I was wondering if flowmaps should be declared in
> <map:components> since only components are inherited by subsitemaps.

Nah, flowmaps are not components anyway.
 
> > 2) you can have more than one flowmap in a sitemap (then you can define
> >a default one or use a 'flowmap' attribute in "map:call" to identify
> >which flowmap you are calling)
> >
> >[of course, in order to accomplish this, the implementation must
> >completely isolate the different flowmaps and its global variables]
> >
> > 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.
> >
> > 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.5 on this : it introduces some programming language constructs in the
> sitemap. And if this is allowed for flowmaps, why shouldn't it be
> allowed for other components as well, e.g. <map:transform
> type="xslt(use-parameters : true, use-browser-capabilities : false)"/> ?

Ok, this is a good point.
 
> >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.
> >
> >
> 
> That isn't so easy, as there can be many ways to pass the continuation
> id, and the example shows only one :
> - as part of the request URI (as in this example)
> - as a request parameter (from a hidden form field)
> - in an XML document (SOAP webservices)
> 
> So IMHO, encoding and extracting the continuation id is the
> responsibility of the presentation layer and the sitemap.

I tend to agree here: it's just another contract you have to learn to
make this work. In fact, writing webapps *is* inherently more complex
than writing command line apps anyway.
 
> >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?)
> >
> >
> 
> 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.

Ok, great.

> >I'd like to have at least a few others:
> >
> > 1) XSTL
> >
> Typo for "XSLT" ?

yes, sorry :)
 
> > 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.

Great to hear. Anyway, let's keep these up high in the flowmap Todo
list. (would you or Ovidiu care to write one?)

[skip the 'detachable pipeline' concept] 

> The only thing to say is : Way cool !

If continuations will make the flowmap shine, detachable pipelines will
skyrocket cocoon component reusability into orbit!
 
> > 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.

No, no, no. Careful here:

 flow logic != business logic

I hope this is clear to everyone.

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

Most absolutely! Just like the sitemap is a way to compose your
xml-processing components, the flowmap is a way to glue your business
logic to drive the webapp flow.

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

Amen!
 
> What is missing in the FOM is the component manager that would allow the
> flowmap to have access to Avalon components.

Good point. Maybe we need an 'avalon' object in the FOM.
 
> >                              - 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 ?

Thank you much for asking this question.

Yes, I would dare to say so.

In fact, I use my own definitions of flow and workflow:

 - flow: a description of the sequences of actions that happen between
subsequent user interactions.

 - workflow: a description of the sequences of actions that happen
between subsequent interactions of more than one user.

In short: flow is about one user, workflows are about more than one user
(otherwise, they become flows again).

The flowmap was implemented to describe flows and since workflows are a
bigger set than flows, it is not automatic to think that a flowmap would
be able to describe workflows as well.

But I have the perception there are no design obstacles to make this
happen, as long as we provide a way to save the state of a continuation
persistently or at least set a pretty long expiration time (this is
probably something that will be connected with the 'continuation' object
in the FOM)

This said, it is *NOT* sci-fi to imagine a visual workflow editor being
able to create a sitemap, a flowmap, a bunch of views and auto-generate
a cocoon block for you to deploy in your running Cocoon.

It might be years away, I know, but it will be possible.

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



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

Accessing the current CM (was Re: [RT] Flowmaps)

[Sylvain Wallez <sy...@anyware-tech.com>]

Christian Haul wrote:

> Sylvain Wallez wrote:
>
>> Christian Haul wrote:
>>
>>> a) reference to the sitemap's component manager in flow. I have 
>>> found two possibilities, either extending some routines' signatures 
>>> (many modifications) or placing it into the Environment. But I seem 
>>> not to find the place where it   is created. It seems related to 
>>> CocoonComponentManager.getCurrentEnvironment() but  I didn't quite 
>>> understand the mechanics.
>>
>>
>> Look at o.a.c.components.flow.JavaScript.JSCocoon, which makes some 
>> Cocoon objects available to the flow : it already has a 
>> ComponentManager attribute, but doesn't publish it to the script. 
>> This should be a simple matter of adding a jsGet_manager method 
>> (Ovidiu, am I right ?).
>
>
> But - is it the parent ComponentManager or the one used by the 
> sitemap, i.e. are components declared in a sitemap available through 
> that manager? If it is OK to use it, that would be great and I'll try 
> to work  on it tomorrow :-)


It appears to be the CM that declares the interpreter, which is not the 
one you're looking for...

So storing the CM as an attribute of Environment should be the way to 
go, as the current enviromnent is passed to the script upon invocation 
(no need for CocoonComponentSelector).

>>>   Another issue would be components / classes that use a 
>>> ComponentManager without implementing Composable.... but that should 
>>> be OK(?)
>>>   What do you think? Pointers?
>>
>>
>>
>> There are cases where this is needed, but care should be taken to 
>> explicitely release these objects so that they can properly release 
>> the components they obtain from the ComponentManager.
>>
>>> b) to get input modules support into the sitemap, a reference to the 
>>> ComponentManager is needed in several places to pass it to   
>>> MapStackResolver.getResolver. Again, I'm unsure what the best 
>>> strategy would be here. Suggestions?
>>
>>
>> Input modules in the sitemap is on the way on my PC... Little time = 
>> slow speed, but it should be ready this week. Just as you suggest it, 
>> there's an additional "manager" parameter to getResolver(), and 
>> resolvers have a release() method as described above.
>
>
> Good to hear. In the mean time I have spent more time trying to 
> understand the treeprocessor and I may well try to beat you on 
> implementing this ;-) 


Gosh ! Turbo mode on !! ;-)

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




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

Re: [RT] Flowmaps

[Christian Haul <ha...@informatik.tu-darmstadt.de>]

Sylvain Wallez wrote:
> Christian Haul wrote:
>> a) reference to the sitemap's component manager in flow. I have found 
>> two possibilities, either extending some routines' signatures (many 
>> modifications) or placing it into the Environment. But I seem not to 
>> find the place where it   is created. It seems related to 
>> CocoonComponentManager.getCurrentEnvironment() but  I didn't quite 
>> understand the mechanics.
> 
> 
> 
> Look at o.a.c.components.flow.JavaScript.JSCocoon, which makes some 
> Cocoon objects available to the flow : it already has a ComponentManager 
> attribute, but doesn't publish it to the script. This should be a simple 
> matter of adding a jsGet_manager method (Ovidiu, am I right ?).

But - is it the parent ComponentManager or the one used by the sitemap, 
i.e. are components declared in a sitemap available through that 
manager? If it is OK to use it, that would be great and I'll try to work 
  on it tomorrow :-)

>>   Another issue would be components / classes that use a 
>> ComponentManager without implementing Composable.... but that should 
>> be OK(?)
>>   What do you think? Pointers?
> 
> 
> There are cases where this is needed, but care should be taken to 
> explicitely release these objects so that they can properly release the 
> components they obtain from the ComponentManager.
> 
>> b) to get input modules support into the sitemap, a reference to the 
>> ComponentManager is needed in several places to pass it to   
>> MapStackResolver.getResolver. Again, I'm unsure what the best strategy 
>> would be here. Suggestions?
> 
> Input modules in the sitemap is on the way on my PC... Little time = 
> slow speed, but it should be ready this week. Just as you suggest it, 
> there's an additional "manager" parameter to getResolver(), and 
> resolvers have a release() method as described above.

Good to hear. In the mean time I have spent more time trying to 
understand the treeprocessor and I may well try to beat you on 
implementing this ;-)

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/23/02 2:09 PM, "Sylvain Wallez" <sy...@anyware-tech.com>
wrote:

> Christian Haul wrote:
>> Ovidiu, Sylvain,
>> 
>> I spend some time to look into both treeprocessor and flow. In order
>> to achieve the above and input modules in sitemap I would need two
>> things:
>> 
>> a) reference to the sitemap's component manager in flow. I have found
>> two possibilities, either extending some routines' signatures (many
>> modifications) or placing it into the Environment. But I seem not to
>> find the place where it   is created. It seems related to
>> CocoonComponentManager.getCurrentEnvironment() but  I didn't quite
>> understand the mechanics.
> 
> 
> Look at o.a.c.components.flow.JavaScript.JSCocoon, which makes some
> Cocoon objects available to the flow : it already has a ComponentManager
> attribute, but doesn't publish it to the script. This should be a simple
> matter of adding a jsGet_manager method (Ovidiu, am I right ?).

Yes, adding such a method should work.

For an introduction on how to make objects and classes available to
JavaScript, check out this tutorial:

http://www.mozilla.org/rhino/tutorial.html

Regards,
Ovidiu


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

Re: [RT] Flowmaps

[Sylvain Wallez <sy...@anyware-tech.com>]

Christian Haul wrote:

> Christian Haul wrote:
>
>> Anyway, given that we are going to be able to use input modules in
>> the sitemap through "{modulename:parameter}" it would be great if it
>> would be the same for the flow.
>>
>> Just another thought (I'm not yet up to speed with the flow so ignore
>> if I'm talking rubbish): Is it possible (and would it make sense) to
>> call an action like
>>
>> result = actions('database', { 'parameter' :'value', 'parameter2' : 
>> 'value'});
>>
>> With the script engine adding the 'usual' parameters
>> for the act call and result being an associative array containing the
>> returned map. This way we could continue using all the nice actions. :-)
>>  
>>
> Ovidiu, Sylvain,
>
> I spend some time to look into both treeprocessor and flow. In order 
> to achieve the above and input modules in sitemap I would need two 
> things:
>
> a) reference to the sitemap's component manager in flow. I have found 
> two possibilities, either extending some routines' signatures (many 
> modifications) or placing it into the Environment. But I seem not to 
> find the place where it   is created. It seems related to 
> CocoonComponentManager.getCurrentEnvironment() but  I didn't quite 
> understand the mechanics.


Look at o.a.c.components.flow.JavaScript.JSCocoon, which makes some 
Cocoon objects available to the flow : it already has a ComponentManager 
attribute, but doesn't publish it to the script. This should be a simple 
matter of adding a jsGet_manager method (Ovidiu, am I right ?).

>   Another issue would be components / classes that use a 
> ComponentManager without implementing Composable.... but that should 
> be OK(?)
>   What do you think? Pointers?


There are cases where this is needed, but care should be taken to 
explicitely release these objects so that they can properly release the 
components they obtain from the ComponentManager.

> b) to get input modules support into the sitemap, a reference to the 
> ComponentManager is needed in several places to pass it to   
> MapStackResolver.getResolver. Again, I'm unsure what the best strategy 
> would be here. Suggestions?


Input modules in the sitemap is on the way on my PC... Little time = 
slow speed, but it should be ready this week. Just as you suggest it, 
there's an additional "manager" parameter to getResolver(), and 
resolvers have a release() method as described above.

Sylvain

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org




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

Re: [RT] Flowmaps

[Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>]

Christian Haul wrote:

>Anyway, given that we are going to be able to use input modules in
>the sitemap through "{modulename:parameter}" it would be great if it
>would be the same for the flow.
>
>Just another thought (I'm not yet up to speed with the flow so ignore
>if I'm talking rubbish): Is it possible (and would it make sense) to
>call an action like
>
>result = actions('database', { 'parameter' :'value', 'parameter2' : 'value'});
>
>With the script engine adding the 'usual' parameters
>for the act call and result being an associative array containing the
>returned map. This way we could continue using all the nice actions. :-)
>  
>
Ovidiu, Sylvain,

I spend some time to look into both treeprocessor and flow. In order to 
achieve the above and input modules in sitemap I would need two things:

a) reference to the sitemap's component manager in flow. I have found two 
   possibilities, either extending some routines' signatures (many modifications)
   or placing it into the Environment. But I seem not to find the place where it 
   is created. It seems related to CocoonComponentManager.getCurrentEnvironment() but
   I didn't quite understand the mechanics.
   Another issue would be components / classes that use a ComponentManager 
   without implementing Composable.... but that should be OK(?)
   What do you think? Pointers?

b) to get input modules support into the sitemap, a reference to the
   ComponentManager is needed in several places to pass it to 
   MapStackResolver.getResolver. Again, I'm unsure what the best strategy
   would be here. Suggestions?

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08



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

Re: [RT] Flowmaps

[Christian Haul <ha...@informatik.tu-darmstadt.de>]

Christian Haul wrote:

>Anyway, given that we are going to be able to use input modules in
>the sitemap through "{modulename:parameter}" it would be great if it
>would be the same for the flow.
>
>Just another thought (I'm not yet up to speed with the flow so ignore
>if I'm talking rubbish): Is it possible (and would it make sense) to
>call an action like
>
>result = actions('database', { 'parameter' :'value', 'parameter2' : 'value'});
>
>With the script engine adding the 'usual' parameters
>for the act call and result being an associative array containing the
>returned map. This way we could continue using all the nice actions. :-)
>  
>
Ovidiu, Sylvain,

I spend some time to look into both treeprocessor and flow. In order to 
achieve the above and input modules in sitemap I would need two things:

a) reference to the sitemap's component manager in flow. I have found two 
   possibilities, either extending some routines' signatures (many modifications)
   or placing it into the Environment. But I seem not to find the place where it 
   is created. It seems related to CocoonComponentManager.getCurrentEnvironment() but
   I didn't quite understand the mechanics.
   Another issue would be components / classes that use a ComponentManager 
   without implementing Composable.... but that should be OK(?)
   What do you think? Pointers?

b) to get input modules support into the sitemap, a reference to the
   ComponentManager is needed in several places to pass it to 
   MapStackResolver.getResolver. Again, I'm unsure what the best strategy
   would be here. Suggestions?

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08



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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/18/02 12:48 AM, "Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de>
wrote:

> On 18.Jun.2002 -- 12:09 AM, Ovidiu Predescu wrote:
>> On 6/17/02 11:22 PM, "Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de>
>> wrote:
>> 
>>> On 17.Jun.2002 -- 09:35 PM, Ovidiu Predescu wrote:
>>> 
>>>> 
>>>> - automatic binding of JavaScript variables to form values. This would
>>>> allow
>>>> you to declare something like:
>>>> 
>>>>   var username, password;
>>>> 
>>>>   // Send a page to collect the user name and the password
>>>>   sendPage("login.html");
>>>> 
>>>>   // When the user fills in the form and presses the submit button, the
>>>>   // script restarts here. The flow engine automatically binds the username
>>>>   // and password to the values submitted in the form.
>>> 
>>> Don't. It was one of the biggest mistakes PHP did securitywise. Always
>>> access request parameters explicitly.
>> 
>> Yes, I read somewhere about this, but don't know the details. Can you
>> explain some more?
> 
> The real problem is that an attacker could provide additional parameters
> that coincidently have the same name as a variable used for other
> purposes in the php script like changing the database connection name,
> path to a file (i.e. /etc/password) or to an include.
> 
> Therefore php now enforces the use of $HTTP_PARAMETERS['name'].

Ah, I remember this problem. No, I wasn't thinking to have this type of
automatic binding, sorry for not explaining the idea better. Instead, what I
was thinking of is a way to specify how to map a form parameter to a
JavaScript variable.

>> I actually like the way variables are automatically bound in WebObjects,
>> where you have to explicitly define the automatic binding, by mapping an
>> instance variable to a form parameter. I was thinking to follow a similar
>> pattern, and have a way to specify that a given local variable in a function
>> is to be bound to a form parameter. In WebObjects this association is
>> totally under the control of the programmer, and the same way should be done
>> in Cocoon.
>> 
>> Could this be a potential security problem?
> 
> No, that is absolutely OK since the author controls exactly which
> variables contain unchecked values which are safe to use.
> 
> Anyway, given that we are going to be able to use input modules in
> the sitemap through "{modulename:parameter}" it would be great if it
> would be the same for the flow.

I'm not sure it would be the same thing though. With the mechanism you
mention, you can pass values to functions in the sitemap only when you enter
a function. When you restart an existing continuation, which could restart a
function from the middle, I'd still like to have the ability to specify how
existing request parameters are to be bound to script variables.

> Just another thought (I'm not yet up to speed with the flow so ignore
> if I'm talking rubbish): Is it possible (and would it make sense) to
> call an action like
> 
> result = actions['database']( { 'parameter' -> 'value', 'parameter' ->
> 'value'});
> 
> (I know javascript uses associative arrays, but is there really a
> literal form?)  With the script engine adding the 'usual' parameters
> for the act call and result being an associative array containing the
> returned map. This way we could continue using all the nice actions. :-)

I think it should be possible to do this, as long as we wrap actions as
JavaScript functions. This way an action appears as nothing else as a
function you can call from your script. I haven't looked at it though.

Ovidiu


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

Re: [RT] Flowmaps

[Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>]

On 18.Jun.2002 -- 12:09 AM, Ovidiu Predescu wrote:
> On 6/17/02 11:22 PM, "Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de>
> wrote:
> 
> > On 17.Jun.2002 -- 09:35 PM, Ovidiu Predescu wrote:
> > 
> >> 
> >> - automatic binding of JavaScript variables to form values. This would allow
> >> you to declare something like:
> >> 
> >>   var username, password;
> >> 
> >>   // Send a page to collect the user name and the password
> >>   sendPage("login.html");
> >> 
> >>   // When the user fills in the form and presses the submit button, the
> >>   // script restarts here. The flow engine automatically binds the username
> >>   // and password to the values submitted in the form.
> > 
> > Don't. It was one of the biggest mistakes PHP did securitywise. Always
> > access request parameters explicitly.
> 
> Yes, I read somewhere about this, but don't know the details. Can you
> explain some more?

The real problem is that an attacker could provide additional parameters
that coincidently have the same name as a variable used for other
purposes in the php script like changing the database connection name,
path to a file (i.e. /etc/password) or to an include.

Therefore php now enforces the use of $HTTP_PARAMETERS['name'].

> I actually like the way variables are automatically bound in WebObjects,
> where you have to explicitly define the automatic binding, by mapping an
> instance variable to a form parameter. I was thinking to follow a similar
> pattern, and have a way to specify that a given local variable in a function
> is to be bound to a form parameter. In WebObjects this association is
> totally under the control of the programmer, and the same way should be done
> in Cocoon.
> 
> Could this be a potential security problem?

No, that is absolutely OK since the author controls exactly which
variables contain unchecked values which are safe to use.

Anyway, given that we are going to be able to use input modules in
the sitemap through "{modulename:parameter}" it would be great if it
would be the same for the flow.

Just another thought (I'm not yet up to speed with the flow so ignore
if I'm talking rubbish): Is it possible (and would it make sense) to
call an action like

	result = actions['database']( { 'parameter' -> 'value', 'parameter' -> 'value'});

(I know javascript uses associative arrays, but is there really a
literal form?)  With the script engine adding the 'usual' parameters
for the act call and result being an associative array containing the
returned map. This way we could continue using all the nice actions. :-)

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08



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

Re: [RT] Flowmaps

[Ivelin Ivanov <iv...@apache.org>]

Ovidiu Predescu wrote:
> On 6/18/02 5:21 AM, "Ivelin Ivanov" <iv...@apache.org> wrote:
> 
> 
>>Ovidiu Predescu wrote:
>>
>>>On 6/17/02 11:22 PM, "Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de>
>>>wrote:
>>
>>
>>>I actually like the way variables are automatically bound in WebObjects,
>>>where you have to explicitly define the automatic binding, by mapping an
>>>instance variable to a form parameter. I was thinking to follow a similar
>>>pattern, and have a way to specify that a given local variable in a function
>>>is to be bound to a form parameter. In WebObjects this association is
>>>totally under the control of the programmer, and the same way should be done
>>>in Cocoon.
>>
>>XMLForm is already doing it.
> 
> 
> What are you referring to? Binding request parameters to the object model?

yes.

-- 

-= Ivelin =-


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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/18/02 5:21 AM, "Ivelin Ivanov" <iv...@apache.org> wrote:

> Ovidiu Predescu wrote:
>> On 6/17/02 11:22 PM, "Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de>
>> wrote:
> 
> 
>> I actually like the way variables are automatically bound in WebObjects,
>> where you have to explicitly define the automatic binding, by mapping an
>> instance variable to a form parameter. I was thinking to follow a similar
>> pattern, and have a way to specify that a given local variable in a function
>> is to be bound to a form parameter. In WebObjects this association is
>> totally under the control of the programmer, and the same way should be done
>> in Cocoon.
> 
> XMLForm is already doing it.

What are you referring to? Binding request parameters to the object model?

>> Could this be a potential security problem?
> 
> I guess Christian suggests that a malicious attacker can pass parameters
> which will modify undesired parts of the model.

There was a misunderstanding of the concept I was talking about, which in
the meantime has been solved (I posted another reply describing this). With
the originally proposed model there is no security issue, as far as I can
tell.

Greetings,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

Re: [RT] Flowmaps

[Ivelin Ivanov <iv...@apache.org>]

Ovidiu Predescu wrote:
> On 6/17/02 11:22 PM, "Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de>
> wrote:


> I actually like the way variables are automatically bound in WebObjects,
> where you have to explicitly define the automatic binding, by mapping an
> instance variable to a form parameter. I was thinking to follow a similar
> pattern, and have a way to specify that a given local variable in a function
> is to be bound to a form parameter. In WebObjects this association is
> totally under the control of the programmer, and the same way should be done
> in Cocoon.

XMLForm is already doing it.


> 
> Could this be a potential security problem?

I guess Christian suggests that a malicious attacker can pass parameters 
which will modify undesired parts of the model.





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



-- 

-= Ivelin =-


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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/17/02 11:22 PM, "Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de>
wrote:

> On 17.Jun.2002 -- 09:35 PM, Ovidiu Predescu wrote:
> 
>> 
>> - automatic binding of JavaScript variables to form values. This would allow
>> you to declare something like:
>> 
>>   var username, password;
>> 
>>   // Send a page to collect the user name and the password
>>   sendPage("login.html");
>> 
>>   // When the user fills in the form and presses the submit button, the
>>   // script restarts here. The flow engine automatically binds the username
>>   // and password to the values submitted in the form.
> 
> Don't. It was one of the biggest mistakes PHP did securitywise. Always
> access request parameters explicitly.

Yes, I read somewhere about this, but don't know the details. Can you
explain some more?

I actually like the way variables are automatically bound in WebObjects,
where you have to explicitly define the automatic binding, by mapping an
instance variable to a form parameter. I was thinking to follow a similar
pattern, and have a way to specify that a given local variable in a function
is to be bound to a form parameter. In WebObjects this association is
totally under the control of the programmer, and the same way should be done
in Cocoon.

Could this be a potential security problem?

Greetings,
Ovidiu


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

Re: [RT] Flowmaps

[Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>]

On 17.Jun.2002 -- 09:35 PM, Ovidiu Predescu wrote:

> 
> - automatic binding of JavaScript variables to form values. This would allow
> you to declare something like:
> 
>   var username, password;
> 
>   // Send a page to collect the user name and the password
>   sendPage("login.html");
> 
>   // When the user fills in the form and presses the submit button, the
>   // script restarts here. The flow engine automatically binds the username
>   // and password to the values submitted in the form.

Don't. It was one of the biggest mistakes PHP did securitywise. Always
access request parameters explicitly.

	Chris.

-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/18/02 3:54 AM, "giacomo" <gi...@apache.org> wrote:

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

Me too, to both of you ;)

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

This sounds interesting. Can you give us some more hints along these lines?

Greetings,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

Re: [RT] Flowmaps

[giacomo <gi...@apache.org>]

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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Flowmaps

[Ivelin Ivanov <iv...@apache.org>]

Ovidiu Predescu wrote:
> On 6/18/02 5:03 AM, "Ivelin Ivanov" <iv...@apache.org> wrote:
> 
> 
>>Ovidiu Predescu wrote:
>>
>>[...]
>>
>>
>>>6. Multi-page forms are not dominating, and continuation based compared to
>>>even driven (GUI-like) programming approaches.
>>>
>>>10. Torsten asks how xmlform/precept could be implemented with flow scripts.
>>>
>>>
>>>12. Torsten: sub-flows, flow-2-flow, what are these? Is assembly of
>>>functions that represent independent flows enough?
>>>
>>>13. Piroumian asks how to cancel a continuation.
>>>
>>>14. Another question Piroumian has is how to validate against business
>>>logic. 
>>
>>
>>I am not entirely satisfied by the response the the questions above.
>>You provided a partial example and some ideas on how to do things.
>>I think it would be best if you can rewrite the feedback wizard demo
>>using flowscript, so that we can compare side by side both techniques.
>>The requirements for this wizard were carefully selected by Torsten,
>>Konstanting, myself and others to cover a lot of subtle problems with
>>HTML form handling.
> 
> 
> I've started working on it, but had to focus for the moment on different
> things. I'll get back to it ASAP.


Much appreciated !


-= Ivelin =-


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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/18/02 5:03 AM, "Ivelin Ivanov" <iv...@apache.org> wrote:

> Ovidiu Predescu wrote:
>
> [...]
>
>> 6. Multi-page forms are not dominating, and continuation based compared to
>> even driven (GUI-like) programming approaches.
>> 
>> 10. Torsten asks how xmlform/precept could be implemented with flow scripts.
>> 
>> 
>> 12. Torsten: sub-flows, flow-2-flow, what are these? Is assembly of
>> functions that represent independent flows enough?
>> 
>> 13. Piroumian asks how to cancel a continuation.
>> 
>> 14. Another question Piroumian has is how to validate against business
>> logic. 
> 
> 
> I am not entirely satisfied by the response the the questions above.
> You provided a partial example and some ideas on how to do things.
> I think it would be best if you can rewrite the feedback wizard demo
> using flowscript, so that we can compare side by side both techniques.
> The requirements for this wizard were carefully selected by Torsten,
> Konstanting, myself and others to cover a lot of subtle problems with
> HTML form handling.

I've started working on it, but had to focus for the moment on different
things. I'll get back to it ASAP.

Greetings,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

Re: [RT] Flowmaps

[Ivelin Ivanov <iv...@apache.org>]

Ovidiu Predescu wrote:
> Guys,
> 
> I'm really overwhelmed by your reaction to the flow idea! Thanks all for
> sharing your thoughts!


Thanks for the detailed reply.

> 
> 6. Multi-page forms are not dominating, and continuation based compared to
> even driven (GUI-like) programming approaches.
> 
> 10. Torsten asks how xmlform/precept could be implemented with flow scripts.
> 
> 
> 12. Torsten: sub-flows, flow-2-flow, what are these? Is assembly of
> functions that represent independent flows enough?
> 
> 13. Piroumian asks how to cancel a continuation.
> 
> 14. Another question Piroumian has is how to validate against business
> logic. 


I am not entirely satisfied by the response the the questions above.
You provided a partial example and some ideas on how to do things.
I think it would be best if you can rewrite the feedback wizard demo
using flowscript, so that we can compare side by side both techniques.
The requirements for this wizard were carefully selected by Torsten, 
Konstanting, myself and others to cover a lot of subtle problems with 
HTML form handling.


Thanks,

-- 

-= Ivelin =-


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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/20/02 1:21 AM, "Sylvain Wallez" <sy...@anyware-tech.com>
wrote:

> Ovidiu Predescu wrote:
> 
>> On 6/18/02 7:59 AM, "Sylvain Wallez" <sy...@anyware-tech.com>
>> wrote:
>> 
>> Your assumption is that the flow scripts are visible to all the
>> applications. I don't think this is reasonable. Just think of an ISP who
>> deploys Cocoon, people running their Web app want to be isolated from
>> everybody else. How can we achieve this if we describe flow scripts as
>> components, inheritable in all the Cocoon blocks that implement user apps?
>> 
> 
> You seem to have misunderstood what I meant about visibility : a flow
> isn't globally visible, but could be visible - just as other components
> - in the sitemap that declared it and all its subsitemaps. If an ISP
> wants to hide a particular flow, then this flow should be declared in an
> ISP-private subsitemap of the main sitemap.
> 
> This "hide on a branch" strategy is the one used by Tomcat classloaders
> to hide the servlet engine classes from the webapp classes, and it works
> quite well.
> 
> Note that the same visibility problems currently applies to components
> we already have : if an ISP-private datasource or a sensitive action is
> declared in cocoon.xconf or the main subsitemap, they are globally
> visible. Declaring them in a subsitemap hides them from other sitemap
> branches.

I see, it makes sense.

But I still don't see why flow scripts declared in a parent sitemap should
be visible to children. I believe a flow script is essentially part of a
self-contained application, and there is no reason to have that visible to
children sitemaps.

>> But it doesn't prevent other flow scripts deployed in the same Cocoon
>> instance to reverse engineer scripts deployed by somebody else (think of the
>> ISP scenario).
> 
> Sorry, I don't understand what you mean here. Is this related to
> filesystem access ?

At least in JavaScript, if you have access to a Scriptable object, the
object that contains the internal representation of a script, you can ask it
to decompile itself. Thus you get access to the source code of the flow,
which may be a security problem.

Best regards,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

Re: [RT] Flowmaps

[Sylvain Wallez <sy...@anyware-tech.com>]

Ovidiu Predescu wrote:

>On 6/18/02 7:59 AM, "Sylvain Wallez" <sy...@anyware-tech.com>
>wrote:
>
<snip/>

>>So what about a simple <map:flows> composed of named <map:flow>, or even
>>a <map:controllers> composed of <map:controller> ?
>>    
>>
>
>I would agree with you here. <map:flows> as the container and <map:flow> for
>a particular flow, seem like better names.
>  
>

Cool.

>>Also, the <map:script> element is intimately tied to the fact that the
>>enclosing <map:flowscript> is of the JavaScript language, and this
>>strongly looks like a component configuration. So once again, is there a
>>fundamental difference between actions, matchers, etc, and flows ?
>>
>>I really don't think so, and consider a flow to be a new kind of sitemap
>>component with the associated primitives in the sitemap language. This
>>feeling is also encouraged by the fact that we all agree that there
>>should be no symmetry between the sitemap and flow, and that the sitemap
>>is the main entry point that drives everything else.
>>
>>So we could have :
>><map:components>
>><map:generators>
>>  ...
>></map:generators>
>>...
>><map:flows>
>>  <map:flow name="calculator"
>>src="org.apache.cocoon.components.flow.JavaScriptInterpreter">
>>    <!-- specific configuration for JavaScriptInterpreter -->
>>    <script src="calc.js"/>
>>  </map:flow>
>></map:flows>
>></map:components>
>>
>><map:pipelines>
>>...
>>
>>Thoughts ?
>>    
>>
>
>Your assumption is that the flow scripts are visible to all the
>applications. I don't think this is reasonable. Just think of an ISP who
>deploys Cocoon, people running their Web app want to be isolated from
>everybody else. How can we achieve this if we describe flow scripts as
>components, inheritable in all the Cocoon blocks that implement user apps?
>

You seem to have misunderstood what I meant about visibility : a flow 
isn't globally visible, but could be visible - just as other components 
- in the sitemap that declared it and all its subsitemaps. If an ISP 
wants to hide a particular flow, then this flow should be declared in an 
ISP-private subsitemap of the main sitemap.

This "hide on a branch" strategy is the one used by Tomcat classloaders 
to hide the servlet engine classes from the webapp classes, and it works 
quite well.

Note that the same visibility problems currently applies to components 
we already have : if an ISP-private datasource or a sensitive action is 
declared in cocoon.xconf or the main subsitemap, they are globally 
visible. Declaring them in a subsitemap hides them from other sitemap 
branches.


>>>Each named flow script declared in <map:flowscripts> could and should be
>>>independent on the others. Each script should have different set of global
>>>variables, which is different from another script, and of course, is
>>>different each user gets his/her own set of values for these variables.
>>>      
>>>
>>This IMO enforces the fact that they are individual component instances.
>>    
>>
>
>But it doesn't prevent other flow scripts deployed in the same Cocoon
>instance to reverse engineer scripts deployed by somebody else (think of the
>ISP scenario).
>  
>

Sorry, I don't understand what you mean here. Is this related to 
filesystem access ?

<snip/>

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/18/02 7:59 AM, "Sylvain Wallez" <sy...@anyware-tech.com>
wrote:

> Ovidiu Predescu wrote:
> 
>> Guys,
>> 
>> I'm really overwhelmed by your reaction to the flow idea! Thanks all for
>> sharing your thoughts!
>> 
>> First of all, I think the thanks should go to Christian Queinnec, who came
>> up with the idea, and to Christopher Oliver, who implemented continuations
>> in Rhino. I just put all the things together and implement the support in
>> Cocoon.
> 
> A question about Christopher Oliver : is he using Cocoon, or is he using
> the continuation-enabled version of Rhino in another context ?

I think he's using the modified Rhino in another context.

>> 1. Stefano points out that flowmaps (I don't really like this term, a "map"
>> is more appropriate for state machines, how about flowscript instead?)
>> should not be considered as ordinary resources, but a separate concept. I
>> have no issue declaring them in a different way, just to emphasize this
>> point. So something like
>> 
>>  <map:flowscripts default="calculator">
>>   <map:flowscript name="calculator" language="javascript">
>>     <map:script src="calc.js"/>
>>   </map:flowscript>
>>  </map:flowscripts>
>> 
>> should be OK. Beside a different name for elements, the fundamental
>> difference between this syntax and Stefano's is that it allows multiple
>> files to contain the implementation of a flow script.
>>  
>> 
> 
> I think we are too much focused on either "script" or "map" : the flow
> engine is a controller (in the MVC sense), and it doesn't really matter
> whether it is defined by a script or a map. We currently have one
> implementation which is JavaScript, but some people seem to prefer state
> automata, and it is certainly possible to write an implementation based
> on an XML file describing a state automaton. Note also that Ovidiu also
> likes Scheme, so this makes a third candidate implementation ;)
> 
> So what about a simple <map:flows> composed of named <map:flow>, or even
> a <map:controllers> composed of <map:controller> ?

I would agree with you here. <map:flows> as the container and <map:flow> for
a particular flow, seem like better names.

> Also, the <map:script> element is intimately tied to the fact that the
> enclosing <map:flowscript> is of the JavaScript language, and this
> strongly looks like a component configuration. So once again, is there a
> fundamental difference between actions, matchers, etc, and flows ?
> 
> I really don't think so, and consider a flow to be a new kind of sitemap
> component with the associated primitives in the sitemap language. This
> feeling is also encouraged by the fact that we all agree that there
> should be no symmetry between the sitemap and flow, and that the sitemap
> is the main entry point that drives everything else.
> 
> So we could have :
> <map:components>
> <map:generators>
>   ...
> </map:generators>
> ...
> <map:flows>
>   <map:flow name="calculator"
> src="org.apache.cocoon.components.flow.JavaScriptInterpreter">
>     <!-- specific configuration for JavaScriptInterpreter -->
>     <script src="calc.js"/>
>   </map:flow>
> </map:flows>
> </map:components>
> 
> <map:pipelines>
> ...
> 
> Thoughts ?

Your assumption is that the flow scripts are visible to all the
applications. I don't think this is reasonable. Just think of an ISP who
deploys Cocoon, people running their Web app want to be isolated from
everybody else. How can we achieve this if we describe flow scripts as
components, inheritable in all the Cocoon blocks that implement user apps?

>> Each named flow script declared in <map:flowscripts> could and should be
>> independent on the others. Each script should have different set of global
>> variables, which is different from another script, and of course, is
>> different each user gets his/her own set of values for these variables.
> 
> This IMO enforces the fact that they are individual component instances.

But it doesn't prevent other flow scripts deployed in the same Cocoon
instance to reverse engineer scripts deployed by somebody else (think of the
ISP scenario).

>> 2. (Stefano) How to encode the continuation ids.
>> 
>> Stefano would like to have ContinuationURLEncodingTransformer, which takes
>> care of encoding the continuation id. Sylvain points out that continuation
>> ids can be passed not only as part of the URL, but also as request
>> parameter.
>> 
>> I think it makes sense to have a transformer which encodes the continuation
>> URL. This would make it very easy to change the way the continuation id is
>> generated, without having to go to each XSP, JSP, whatever and change it.
>> The transformer would probably work best when the continuation id is encoded
>> in the URL. When the id is encoded as a request parameter, there will be
>> some awareness required from the page designer to have this id enclosed
>> inside a form.
> 
> It will be good to provide a default mechanism that will make it as
> transparent as possible, but we must keep the door opened for specific
> needs (I'm mainly thinking of ids contained in a SOAP message).

Yes, me too. Some current SOAP-based protocols make use of ids encoded
inside messages.

> 
>> 5. Ivelin points out the potential of stale continuations.
>> 
>> I think this is indeed a real issue. One way to avoid it is to have
>> continuations automatically expire after a time of inactivity, or do
>> deactivate them manually in the flow script. The first approach is something
>> I considered, and there are some hooks in the current code, but more support
>> code needs to be written. The second approach can be implemented today: you
>> can invalidate not only a single continuation, but the whole subtree of
>> continuations which start from it. You just need to keep a hold on the
>> continuation at the top of the tree, and invoke invalidate() on it.
>>  
>> 
> 
> We could also swap some old but not expired continuations on disk.

Yes, indeed, this should be possible. Christopher Oliver added support for
this type of scenarios as well in his Rhino version.

>> 20. My job - thanks Stefano for bringing it up. Here's my shameless plug :)
>> If you think of using Cocoon for building Web apps or Web services, and you
>> need support in doing so, I am providing consultancy for doing it, anytime,
>> anywhere.
> 
> Hey, what about posting this to cocoon-users, which certainly has a
> greater potential of people searching for consultancy than cocoon-dev.
> As Stefano says, "this is how the community pays back", and you deserve it.

Good idea, I'll do it!

Greetings,
Ovidiu

-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

Re: [RT] Flowmaps

[Sylvain Wallez <sy...@anyware-tech.com>]

Ovidiu Predescu wrote:

>Guys,
>
>I'm really overwhelmed by your reaction to the flow idea! Thanks all for
>sharing your thoughts!
>
>First of all, I think the thanks should go to Christian Queinnec, who came
>up with the idea, and to Christopher Oliver, who implemented continuations
>in Rhino. I just put all the things together and implement the support in
>Cocoon.
>  
>

A question about Christopher Oliver : is he using Cocoon, or is he using 
the continuation-enabled version of Rhino in another context ?

>1. Stefano points out that flowmaps (I don't really like this term, a "map"
>is more appropriate for state machines, how about flowscript instead?)
>should not be considered as ordinary resources, but a separate concept. I
>have no issue declaring them in a different way, just to emphasize this
>point. So something like
>
>  <map:flowscripts default="calculator">
>   <map:flowscript name="calculator" language="javascript">
>     <map:script src="calc.js"/>
>   </map:flowscript>
>  </map:flowscripts>
>
>should be OK. Beside a different name for elements, the fundamental
>difference between this syntax and Stefano's is that it allows multiple
>files to contain the implementation of a flow script.
>  
>

I think we are too much focused on either "script" or "map" : the flow 
engine is a controller (in the MVC sense), and it doesn't really matter 
whether it is defined by a script or a map. We currently have one 
implementation which is JavaScript, but some people seem to prefer state 
automata, and it is certainly possible to write an implementation based 
on an XML file describing a state automaton. Note also that Ovidiu also 
likes Scheme, so this makes a third candidate implementation ;)

So what about a simple <map:flows> composed of named <map:flow>, or even 
a <map:controllers> composed of <map:controller> ?

Also, the <map:script> element is intimately tied to the fact that the 
enclosing <map:flowscript> is of the JavaScript language, and this 
strongly looks like a component configuration. So once again, is there a 
fundamental difference between actions, matchers, etc, and flows ?

I really don't think so, and consider a flow to be a new kind of sitemap 
component with the associated primitives in the sitemap language. This 
feeling is also encouraged by the fact that we all agree that there 
should be no symmetry between the sitemap and flow, and that the sitemap 
is the main entry point that drives everything else.

So we could have :
<map:components>
  <map:generators>
    ...
  </map:generators>
  ...
  <map:flows>
    <map:flow name="calculator" 
src="org.apache.cocoon.components.flow.JavaScriptInterpreter">
      <!-- specific configuration for JavaScriptInterpreter -->
      <script src="calc.js"/>
    </map:flow>
  </map:flows>
</map:components>

<map:pipelines>
  ...

Thoughts ?

>Each named flow script declared in <map:flowscripts> could and should be
>independent on the others. Each script should have different set of global
>variables, which is different from another script, and of course, is
>different each user gets his/her own set of values for these variables.
>  
>

This IMO enforces the fact that they are individual component instances.

>This is an issue today, as it does not really happen. I'm working on solving
>it.
>
>2. (Stefano) How to encode the continuation ids.
>
>Stefano would like to have ContinuationURLEncodingTransformer, which takes
>care of encoding the continuation id. Sylvain points out that continuation
>ids can be passed not only as part of the URL, but also as request
>parameter.
>
>I think it makes sense to have a transformer which encodes the continuation
>URL. This would make it very easy to change the way the continuation id is
>generated, without having to go to each XSP, JSP, whatever and change it.
>The transformer would probably work best when the continuation id is encoded
>in the URL. When the id is encoded as a request parameter, there will be
>some awareness required from the page designer to have this id enclosed
>inside a form.
>  
>

It will be good to provide a default mechanism that will make it as 
transparent as possible, but we must keep the door opened for specific 
needs (I'm mainly thinking of ids contained in a SOAP message).

<snip/>

>5. Ivelin points out the potential of stale continuations.
>
>I think this is indeed a real issue. One way to avoid it is to have
>continuations automatically expire after a time of inactivity, or do
>deactivate them manually in the flow script. The first approach is something
>I considered, and there are some hooks in the current code, but more support
>code needs to be written. The second approach can be implemented today: you
>can invalidate not only a single continuation, but the whole subtree of
>continuations which start from it. You just need to keep a hold on the
>continuation at the top of the tree, and invoke invalidate() on it.
>  
>

We could also swap some old but not expired continuations on disk.

<snip/>

>13. Piroumian asks how to cancel a continuation.
>

His first name is "Konstantin" ;)

<snip/>

>20. My job - thanks Stefano for bringing it up. Here's my shameless plug :)
>If you think of using Cocoon for building Web apps or Web services, and you
>need support in doing so, I am providing consultancy for doing it, anytime,
>anywhere.
>  
>

Hey, what about posting this to cocoon-users, which certainly has a 
greater potential of people searching for consultancy than cocoon-dev. 
As Stefano says, "this is how the community pays back", and you deserve it.

>Thanks for reading so far,
>Ovidiu
>  
>

Thanks for this great work,
Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

Hi Vadim,

On 6/19/02 5:10 PM, "Vadim Gritsenko" <va...@verizon.net> wrote:

>> From: Ovidiu Predescu [mailto:ovidiu@apache.org]
> 
> <snip/>
> 
>>>> 8. Vadim's idea about making the syntax easier.
>>>> 
>>>> I think the idea of having something as simple as:
>>>> 
>>>> <map:match pattern="calc/*">
>>>>   <map:flow method="calculator" continuation="{1}" />
>>>> </map:match>
>>>> 
>>>> makes a lot of sense. Using different matchers, the continuation id
> can be
>>>> extracted from the request parameters, cookies, you name it. The
> only
>>>> problem with it is that is a bit inflexible in terms of the URI
> design. If
>>>> I'd like to have calc/kont/*, there's no easy way to specify it.
>>> 
>>> <map:match pattern="calc/kont/*">
>>> 
>>> Did I miss somehting?
>> 
>> How do you extract the continuation id if it's embedded in a request
>> parameter?
> 
> You asked for calc/kont/* - and that's very easy to achieve as shown
> above. If you want to hide continuation ID to request parameter, that's
> also very easy with existing request parameter matcher:
> 
> <map:match pattern="calc">
> <map:match type="parameter" pattern="cont-id-param">
>   <map:flow continuation="{1}" /> [here we could omit method=""]
> </map:match>
> <map:flow method="calculator"/> [here we can omit continuation=""]
> </map:match>
> 
> 
> I poked around with continuation sample today... Seems this is even
> possible right now, with your current code. The only difference is that
> instead of one map operator you have to use two different ones (and one
> of them is (over) overloaded map:call):
> 
> <map:match pattern="calc">
> <map:match type="parameter" pattern="cont-id-param">
>   <map:continue with="{1}"/>
> </map:match>
> <map:call function="calculator"/>
> </map:match>
> 
> 
> Difference is only in syntax.

Thanks a lot for the analysis, it's great!

To conclude, the simplest form would be:

<map:match pattern="calc/*">
  <map:flow function="calculator" continuation="{1}"/>
</map:match>

If more control is needed, we can use <map:flow> with different attributes,
like below:

<!-- starts script because continuation is empty (or "continuation"
     attribute is missing -->
<map:match pattern="calc/">
  <map:flow function="calculator"/>
</map:match>

<!-- continues script because "function" is missing -->
<map:match pattern="calc/kont/*">
  <map:flow continuation="{1}" />
</map:match>

Or we can have the continuation id passed as a request parameter, like
below:

<map:match pattern="calc">
  <map:match type="parameter" pattern="cont-id-param">
    <map:flow continuation="{1}"/>
  </map:match>
  <map:flow function="calculator"/>
</map:match>

We can use either "function" or "method", I don't have any preference.
"function" however is more appropriate for JavaScript where what is actually
invoked are functions, not methods.

The change to use the above API involves only the treeprocessor portion of
Cocoon, and some calls to the flow API. The change could be modeled on the
current implementation, so it should be fairly straightforward. Any
volunteers to implement this?


Best regards,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

RE: [RT] Flowmaps

[Vadim Gritsenko <va...@verizon.net>]

> From: Ovidiu Predescu [mailto:ovidiu@apache.org]

<snip/>

> >> 8. Vadim's idea about making the syntax easier.
> >>
> >> I think the idea of having something as simple as:
> >>
> >> <map:match pattern="calc/*">
> >>   <map:flow method="calculator" continuation="{1}" />
> >> </map:match>
> >>
> >> makes a lot of sense. Using different matchers, the continuation id
can be
> >> extracted from the request parameters, cookies, you name it. The
only
> >> problem with it is that is a bit inflexible in terms of the URI
design. If
> >> I'd like to have calc/kont/*, there's no easy way to specify it.
> >
> > <map:match pattern="calc/kont/*">
> >
> > Did I miss somehting?
> 
> How do you extract the continuation id if it's embedded in a request
> parameter?

You asked for calc/kont/* - and that's very easy to achieve as shown
above. If you want to hide continuation ID to request parameter, that's
also very easy with existing request parameter matcher:

<map:match pattern="calc">
  <map:match type="parameter" pattern="cont-id-param">
    <map:flow continuation="{1}" /> [here we could omit method=""]
  </map:match>
  <map:flow method="calculator"/> [here we can omit continuation=""]
</map:match>


I poked around with continuation sample today... Seems this is even
possible right now, with your current code. The only difference is that
instead of one map operator you have to use two different ones (and one
of them is (over) overloaded map:call):

<map:match pattern="calc">
  <map:match type="parameter" pattern="cont-id-param">
    <map:continue with="{1}"/>
  </map:match>
  <map:call function="calculator"/>
</map:match>


Difference is only in syntax.

Vadim

<snip/>


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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/18/02 2:32 AM, "Torsten Curdt" <tc...@dff.st> wrote:

>> 4. Stefano's callPipeline() function. Is this equivalent to
>> sendPageAndContinue(), which is already implemented in the flow layer? It
>> essentially allows you to have a page processed through a pipeline, and
>> continue the execution of the script. BTW, I think your sitemap snippet has
>> a bug in it, shouldn't it have the <map:match> names swapped?
>> 
>> Also in your callPipeline(), how does the output parameter get used? It
>> should be the task of the sitemap pipeline where the file is written. Am I
>> missing something?
> 
> what about loading stuff from a pipeline? an stream does not look very useful
> in our little XML world

Not sure I understand what you mean by this, can you elaborate?

>> 5. Ivelin points out the potential of stale continuations.
>> 
>> I think this is indeed a real issue. One way to avoid it is to have
>> continuations automatically expire after a time of inactivity, or do
>> deactivate them manually in the flow script. The first approach is
>> something I considered, and there are some hooks in the current code, but
>> more support code needs to be written. The second approach can be
>> implemented today: you can invalidate not only a single continuation, but
>> the whole subtree of continuations which start from it. You just need to
>> keep a hold on the continuation at the top of the tree, and invoke
>> invalidate() on it.
> 
> that's one of the things that scares me off most!! this actually smells to be
> a security issue. (Think of a machine alway starting new continuation objects
> until or VM is out of memory...) We need a max limit of continuations like
> there is for sessions too. (Same problem also applies to sessions)
> 
> And we need a continuation-"janitor" to expire them...

Yes, these are on my TODO list (which BTW I think I forgot it in the
schecoon directory ;)

>> 6. Multi-page forms are not dominating, and continuation based compared to
>> even driven (GUI-like) programming approaches.
>> 
>> I used to program GUIs a lot, I think for certain things, event-driven is
>> better than using continuations. I do think however that continuations have
>> a place, especially for multi-page forms. Now I think it depends a lot on
>> the application, whether these forms are prevalent or not.
> 
> What do think makes multi-page forms special in terms of not using an event
> driven approach? Somehow I'd consider the precept approach going this
> direction... a pressed button is mapped to a java function... not exactly
> event-driven but more like that...

The fact that you can say what's going on in the application by just looking
at a function is, I think, the most appealing thing about using
continuations. Sure you can achieve the same thing in an event driven type
of approach, but the flow is just scattered across multiple
functions/methods.

>> Since these functions share the same global variables, it's very
>> easy to share data between them. You can share data using the session
>> object, but with explicit variables is much easier to follow what's going
>> on.
> 
> true. but one could bind references to session variables so you can work with
> them as they were local. But you would have to set this up... but it's
> possible...
> 
> Even in java...

Yes, I know is possible.

>> If you don't care about sharing data between actions, then there's probably
>> little value describing your action logic in a flow script. Other than the
>> fact that you don't have to write Java code, which means compile, build war
>> file, restart tomcat. With flow scripts, you just modify the script file
>> and resend the request: the script is automatically reloaded and parsed by
>> Cocoon, there's no need to restart anything.
> 
> Well, this also depends on the servlet engine. If you have your actions in
> WEB-INF/classes at least resin does fine and even auto-compiles them for
> you!!

Without reloading the whole Web app? I'd be surprised if this is the case,
since your app may be inconsistent if only some classes are loaded, but not
the others.

>> 8. Vadim's idea about making the syntax easier.
>> 
>> I think the idea of having something as simple as:
>> 
>> <map:match pattern="calc/*">
>>   <map:flow method="calculator" continuation="{1}" />
>> </map:match>
>> 
>> makes a lot of sense. Using different matchers, the continuation id can be
>> extracted from the request parameters, cookies, you name it. The only
>> problem with it is that is a bit inflexible in terms of the URI design. If
>> I'd like to have calc/kont/*, there's no easy way to specify it.
> 
> <map:match pattern="calc/kont/*">
> 
> Did I miss somehting?

How do you extract the continuation id if it's embedded in a request
parameter?

>> So I'd say we can have two alternative ways of writing this: using the
>> above proposal and what is already implemented, for power users that want
>> more control. How about this?
> 
> I think it would be cool not have it in the sitemap (or only in the root
> sitemap) so things happen more automagically... like with sessions

Hm, interesting thought. I think it makes sense, we can have a default
setup, and if the user doesn't care to change the default, it is used.
Otherwise, the user can customize it for his/her tastes.

> [...]
>
>> Torsten's example uses a heavily xmlform type of approach, where the data
>> to be validated is kept in a Java object or a DOM tree.
> 
> Well, don't wanna be picky - but the precept approach ;-)

Yes, sorry, I keep forgetting this :(

>> This is one way of
>> doing things; another one would be to use explicit variables which, at the
>> end of the validation, could be written in the database directly, or used
>> to construct a object hierarchy which is then saved in the database using
>> JDO, EJBs or whatever other means.
> 
> that's the hell I'd like to escape!! for a simple form that's no problem. But
> as soon as you have 30 variables this becomes a mess! Since we are always
> working with XML structures an instance / DOM is much easier / convenient to
> handle - especially if you want to perform validation against it!

In this case, you can simply edit the DOM tree, as you described in your
example. You just use the flow layer to keep track of where you are in the
form.

>> The validation could be done directly in
>> JavaScript, instead of a Schema approach. The code that does the validation
>> could then be used on the client side as well.
> 
> Arrgh! don't push me into hell again ;-) This sounds like "you just need to
> code the logic of whole form" that's exaclty what should considered "bad
> practise" for larger forms!
> You can really boost productivity expressing it in XML - only depends on the
> XML structure ;-)

Perhaps, I didn't have problems with this. With the right set of validation
functions, coding them in JavaScript is just as easy as describing the
schema and the constraints.

>> As Stefano mentioned, the flow layer is an infrastructure which can be used
>> to create higher level abstractions. Here are some things I am currently
>> looking at, which can improve the usability of the flow script engine:
>> 
>> - automatic binding of JavaScript variables to form values. This would
>> allow you to declare something like:
>> 
>>   var username, password;
>> 
>>   // Send a page to collect the user name and the password
>>   sendPage("login.html");
> 
> As christian pointed out - that's a major security whole!!! And be avoided!
> BTW: same goes for examples floating around using the request logicsheet with
> esql where request parameters are directly used in the esql query! EVIL!

I already replied on this one. The idea is not to define variables on the
fly, but to have predefined variables in your script bound to form
parameters. This shouldn't pose any security problem. A similar thing is
done in various other frameworks I'm aware of.

>>   // When the user fills in the form and presses the submit button, the
>>   // script restarts here. The flow engine automatically binds the username
>>   // and password to the values submitted in the form.
>> 
>>   // make use of username and passwd here
> 
> you could consider an special array for that... like GLOBALS["var"] in PHP.
> (or a varibale prefix)
> 
> With flowscript it could even be persistent...

Yes, you can always access request parameters using request.getParameter().
What I was suggesting is a way to bind _predefined_ variables in your script
to request parameters. The framework would then take care of automatically
assigning values to variables, before the continuation is restarted.

>> - automatic validation of form values on both server and client side. This
>> should allow the same piece of JavaScript validation code to be executed
>> both on the server and client side. More on this later.
> 
> I'm looking forward on this one!!! Tell me 8-))

I don't have much details to give you right now, as I'm still trying to
figure out the best way to do it. But the general idea is to have the
validation code done in a separate file, which could be used as is both on
the client and server side. On the server side you just include this file in
your flow script and call the functions to do the necessary validation. For
the client side, you make the file available through the sitemap, so the
same validation can happen in the browser.

>> 11. With respect to how to put a back button on a page, I think I replied
>> to this some time ago. The idea is to use the <jpath:continuation
>> select="1"/> which selects the previous continuation.
> 
> but that means go back one step in the continuation execution tree (or
> something) ...but what if that's not the same? What if you want to actually
> "do something" and then go back one step!?

An example for such a scenario would be very good, could you provide one?

>> As I mentioned in some other message, the continuations created during the
>> execution will form a tree, or a list if the user never presses the back
>> button and starts on a different path. At any given point you can access
>> the continuations above you in the tree, which identify the past pages, by
>> using the "select" attribute in <jpath:continuation>.
> 
>> 12. Torsten: sub-flows, flow-2-flow, what are these? Is assembly of
>> functions that represent independent flows enough?
> 
> Ok...
> 
> sub-flow: imagine you have a form and in it a branch to a different flow...
> you could map it as an indepent flow - but actually it's a sub-flow. If we
> implement this "sub-flow" by just switching to another flow and then come
> back to the orignial flow. One flow needs to pass variables to the other
> flow! that's what I meant by flow-2-flow communication!
> 
> see what I mean?

I think I do. As I said in the last email, what is wrong with a function
call? Generally you have a high-level function implementing the flow for a
particular portion of your application. From this function you can call any
function you like, including one that does its own thing, and sends a bunch
of pages to the user. When this function finishes, you get back in the flow
you left.

And since you're using a programming language, you can pass any variables
you like to a function. Or you can make use of global variables. Or you can
make use of objects, and have those variables be instance variables, and the
functions be methods of the object, so you can directly access any instance
variable from any method.

> [...]
> 
>> 16. Sylvain: should flow scripts be inherited by sub-sitemaps?
>> 
>> I'm not sure of the security implications of allowing them to be inherited:
>> what should be the behavior if a developer alters definitions from an
>> inherited flow script?
> 
> that's again the discussion we had with blocks ;-)
> I think it should be possible! Otherwise you have to declare your flowscript
> in each sub-sitemap - and we have dozens of them!

Yes, maybe, I'm not sure. I think we need to experiment with it for a while.

> [...]
> 
>> Variables in this global variable space will act as session variables. To
> 
> what does that mean exactly? you mean they are persistent... but local to the
> continuation's object, arent't they?

Yes, they are persistent, well, as long as the continuation object is
around. They are indeed local to the continuation object. And each user has
his own set of values for these global vars.

>> facilitate communication between applications or share constant values
>> between users of the same application, an application and a global space
>> will be introduced.
> 
> so this could be used for flow-2-flow communication?!

Now, I saw what you meant by sub-flow, but what is flow-2-flow?

>> 20. My job - thanks Stefano for bringing it up. Here's my shameless plug :)
>> If you think of using Cocoon for building Web apps or Web services, and you
>> need support in doing so, I am providing consultancy for doing it, anytime,
>> anywhere.
> 
> Aren't you still working for HP?

So far, yes, but I don't know if I will next week ;)

Cheers,
Ovidiu

-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

Re: [RT] Flowmaps

[Torsten Curdt <tc...@dff.st>]

> First of all, I think the thanks should go to Christian Queinnec, who came
> up with the idea, and to Christopher Oliver, who implemented continuations
> in Rhino. I just put all the things together and implement the support in
> Cocoon.

Thanks to all of you then ;-)

> Now, there are few points that have been raised here. I'll try to answer to
> all of them in this email, both as a way to synthesize this great
> discussion, and to minimize the time I take to respond to individual
> messages (otherwise I can easily spend my entire evening replying). Please
> raise your issue again if you don't see an answer for it here.

As well it's a good summary :-)

> 1. Stefano points out that flowmaps (I don't really like this term, a "map"
> is more appropriate for state machines, how about flowscript instead?)
> should not be considered as ordinary resources, but a separate concept. I
> have no issue declaring them in a different way, just to emphasize this
> point. So something like
>
>   <map:flowscripts default="calculator">
>    <map:flowscript name="calculator" language="javascript">
>      <map:script src="calc.js"/>
>    </map:flowscript>
>   </map:flowscripts>
>
> should be OK. Beside a different name for elements, the fundamental
> difference between this syntax and Stefano's is that it allows multiple
> files to contain the implementation of a flow script.

yepp, feel the same. flowscript make more sense currently.

> 2. (Stefano) How to encode the continuation ids.
>
> Stefano would like to have ContinuationURLEncodingTransformer, which takes
> care of encoding the continuation id. Sylvain points out that continuation
> ids can be passed not only as part of the URL, but also as request
> parameter.
>
> I think it makes sense to have a transformer which encodes the continuation
> URL. This would make it very easy to change the way the continuation id is
> generated, without having to go to each XSP, JSP, whatever and change it.
> The transformer would probably work best when the continuation id is
> encoded in the URL. When the id is encoded as a request parameter, there
> will be some awareness required from the page designer to have this id
> enclosed inside a form.

true... but does not sound like a problem

> 3. (Stefano) Template languages other than XSP to be used with the flow
> layer.
>
> This should certainly be possible, I've started with XSP because it was
> very easy to get implement. JSP and Velocity should be equally easy to
> implement though. We just need somebody to do it ;)

yepp - same as for 2.)

> 4. Stefano's callPipeline() function. Is this equivalent to
> sendPageAndContinue(), which is already implemented in the flow layer? It
> essentially allows you to have a page processed through a pipeline, and
> continue the execution of the script. BTW, I think your sitemap snippet has
> a bug in it, shouldn't it have the <map:match> names swapped?
>
> Also in your callPipeline(), how does the output parameter get used? It
> should be the task of the sitemap pipeline where the file is written. Am I
> missing something?

what about loading stuff from a pipeline? an stream does not look very useful 
in our little XML world

> 5. Ivelin points out the potential of stale continuations.
>
> I think this is indeed a real issue. One way to avoid it is to have
> continuations automatically expire after a time of inactivity, or do
> deactivate them manually in the flow script. The first approach is
> something I considered, and there are some hooks in the current code, but
> more support code needs to be written. The second approach can be
> implemented today: you can invalidate not only a single continuation, but
> the whole subtree of continuations which start from it. You just need to
> keep a hold on the continuation at the top of the tree, and invoke
> invalidate() on it.

that's one of the things that scares me off most!! this actually smells to be 
a security issue. (Think of a machine alway starting new continuation objects 
until or VM is out of memory...) We need a max limit of continuations like 
there is for sessions too. (Same problem also applies to sessions)

And we need a continuation-"janitor" to expire them...

> 6. Multi-page forms are not dominating, and continuation based compared to
> even driven (GUI-like) programming approaches.
>
> I used to program GUIs a lot, I think for certain things, event-driven is
> better than using continuations. I do think however that continuations have
> a place, especially for multi-page forms. Now I think it depends a lot on
> the application, whether these forms are prevalent or not.

What do think makes multi-page forms special in terms of not using an event 
driven approach? Somehow I'd consider the precept approach going this 
direction... a pressed button is mapped to a java function... not exactly 
event-driven but more like that...

> 7. Bruno's question regarding the advantage of flow scripts versus actions.
>
> The advantage would be that with flow scripts you can describe all the
> actions in a single flow script, where each action becomes a separate
> function.

I don't think that's the real advantage... I could have this easily with the 
MultiAction (hm.. is it still in scratchpad? I'll have look)

> Since these functions share the same global variables, it's very
> easy to share data between them. You can share data using the session
> object, but with explicit variables is much easier to follow what's going
> on.

true. but one could bind references to session variables so you can work with 
them as they were local. But you would have to set this up... but it's 
possible...

Even in java...

> If you don't care about sharing data between actions, then there's probably
> little value describing your action logic in a flow script. Other than the
> fact that you don't have to write Java code, which means compile, build war
> file, restart tomcat. With flow scripts, you just modify the script file
> and resend the request: the script is automatically reloaded and parsed by
> Cocoon, there's no need to restart anything.

Well, this also depends on the servlet engine. If you have your actions in 
WEB-INF/classes at least resin does fine and even auto-compiles them for 
you!!

> 8. Vadim's idea about making the syntax easier.
>
> I think the idea of having something as simple as:
>
> <map:match pattern="calc/*">
>   <map:flow method="calculator" continuation="{1}" />
> </map:match>
>
> makes a lot of sense. Using different matchers, the continuation id can be
> extracted from the request parameters, cookies, you name it. The only
> problem with it is that is a bit inflexible in terms of the URI design. If
> I'd like to have calc/kont/*, there's no easy way to specify it.

<map:match pattern="calc/kont/*">

Did I miss somehting?

> So I'd say we can have two alternative ways of writing this: using the
> above proposal and what is already implemented, for power users that want
> more control. How about this?

I think it would be cool not have it in the sitemap (or only in the root 
sitemap) so things happen more automagically... like with sessions

> 9. Reinhard asks what happens if two different flow scripts have a function
> with a similar name name.
>
> Since the flow scripts have their own variable space (not now due to some
> problems in the current implementation), there shouldn't be any problem.
> Each flow script can use its own variable and function names, without
> worrying about possible conflicts with other scripts.

ok

> 10. Torsten asks how xmlform/precept could be implemented with flow
> scripts.

well, not exaclty... it was meant more generic...

> I think the more generic question is how to implement multi-page forms
> using flow scripts. It would also be nice if the validation could happen
> not only on the server side, but also in the client browser, using
> JavaScript if that's available.

that's the spirit ;-)

> Your example would become a lot simpler if you factor out the repetitive
> code in a function:
>
> var validator;
> var instance;
> var prefix;
>
> function wizard(uriPrefix) {
>   var id = cocoon.request.getParameter("someid");
>
>   var factory = SchemaFactory.getInstance("ns");
>   //maybe we can get the schema from a pipeline??
>   var schema = factory.compile("someschema.xsd.dtd.rng.sch");
>   validator = schema.createValidator();
>   instance = new Instance();
>   prefix = uriPrefix;
>
>   loadInstance(instance,id);
>
>   do {
>     showAndValidatePage(1);
>     showAndValidatePage(2);
>     showAndValidatePage(3);
>   } while(!validator.isValid(instance));
>
>   if(saveInstance(instance,id)) {
>    sendPage("success.html");
>   }
>   else {
>    sendPage("failed.html");
>   }
> }
>
> function showAndValidatePage(number)
> {
>    do {
>     sendPage(prefix + "page" + number + ".html");
>     Instance.populate(instance, cocoon.request);
>    } while(!validator.isValid(instance, "page" + number));
> }

Well, true! ..but how would I implement a step backwards? (see later)

> Torsten's example uses a heavily xmlform type of approach, where the data
> to be validated is kept in a Java object or a DOM tree.

Well, don't wanna be picky - but the precept approach ;-)

> This is one way of
> doing things; another one would be to use explicit variables which, at the
> end of the validation, could be written in the database directly, or used
> to construct a object hierarchy which is then saved in the database using
> JDO, EJBs or whatever other means. 

that's the hell I'd like to escape!! for a simple form that's no problem. But 
as soon as you have 30 variables this becomes a mess! Since we are always 
working with XML structures an instance / DOM is much easier / convenient to 
handle - especially if you want to perform validation against it!

> The validation could be done directly in
> JavaScript, instead of a Schema approach. The code that does the validation
> could then be used on the client side as well.

Arrgh! don't push me into hell again ;-) This sounds like "you just need to 
code the logic of whole form" that's exaclty what should considered "bad 
practise" for larger forms!
You can really boost productivity expressing it in XML - only depends on the 
XML structure ;-)

> As Stefano mentioned, the flow layer is an infrastructure which can be used
> to create higher level abstractions. Here are some things I am currently
> looking at, which can improve the usability of the flow script engine:
>
> - automatic binding of JavaScript variables to form values. This would
> allow you to declare something like:
>
>   var username, password;
>
>   // Send a page to collect the user name and the password
>   sendPage("login.html");

As christian pointed out - that's a major security whole!!! And be avoided!
BTW: same goes for examples floating around using the request logicsheet with 
esql where request parameters are directly used in the esql query! EVIL!

>   // When the user fills in the form and presses the submit button, the
>   // script restarts here. The flow engine automatically binds the username
>   // and password to the values submitted in the form.
>
>   // make use of username and passwd here

you could consider an special array for that... like GLOBALS["var"] in PHP. 
(or a varibale prefix)

With flowscript it could even be persistent...

> - automatic validation of form values on both server and client side. This
> should allow the same piece of JavaScript validation code to be executed
> both on the server and client side. More on this later.

I'm looking forward on this one!!! Tell me 8-))

> 11. With respect to how to put a back button on a page, I think I replied
> to this some time ago. The idea is to use the <jpath:continuation
> select="1"/> which selects the previous continuation.

but that means go back one step in the continuation execution tree (or 
something) ...but what if that's not the same? What if you want to actually 
"do something" and then go back one step!?

> As I mentioned in some other message, the continuations created during the
> execution will form a tree, or a list if the user never presses the back
> button and starts on a different path. At any given point you can access
> the continuations above you in the tree, which identify the past pages, by
> using the "select" attribute in <jpath:continuation>.

> 12. Torsten: sub-flows, flow-2-flow, what are these? Is assembly of
> functions that represent independent flows enough?

Ok...

sub-flow: imagine you have a form and in it a branch to a different flow... 
you could map it as an indepent flow - but actually it's a sub-flow. If we 
implement this "sub-flow" by just switching to another flow and then come 
back to the orignial flow. One flow needs to pass variables to the other 
flow! that's what I meant by flow-2-flow communication!

see what I mean?

> 13. Piroumian asks how to cancel a continuation.
>
> As I mentioned in several ocasions, sendPage() returns the saved
> continuation. If you want to cancel the continuation just invoke on it the
> invalidate() method. It will cancel all the receiver and all the
> continuations that inherit from it.

ok

> 14. Another question Piroumian has is how to validate against business
> logic. Since JavaScript is tightly integrated with Java, you can call Java
> logic from the flow script to do the business logic validation. This way
> you can invoke whatever logic you want. If this is too generic, then
> provide some use case and I'll try to sketch a solution.

ok

> 15. Flow management: obtaining a list of all active flows.
>
> All the flows are kept in an array, which is managed by a Cocoon component.
> Each flow is a tree of continuations, where each continuation is a
> JavaScript object which can be dynamically inspected for properties and so
> on.

ok

> 16. Sylvain: should flow scripts be inherited by sub-sitemaps?
>
> I'm not sure of the security implications of allowing them to be inherited:
> what should be the behavior if a developer alters definitions from an
> inherited flow script?

that's again the discussion we had with blocks ;-)
I think it should be possible! Otherwise you have to declare your flowscript 
in each sub-sitemap - and we have dozens of them!

> 17. The proposal to use map:call with "function(arg, arg, ...)".
>
> I think this is more like a syntactic sugar than real value. I don't think
> passing arguments via map:param would confuse people, the semantic is still
> the same as function invocation.

ok

> 18. Access to continuations.
>
> I think there is a bit of confusion of terms in this discussion. The
> continuation id is passed in the HTTP request in some way or another: as
> part of the URL, as a request parameter etc. This encoding should be
> visible to the sitemap only. I'd very much like to have it hidden from the
> view layer as well, so if we can avoid putting explicit URLs in page
> templates, that would be great! This reduces the dependency between the URL
> design in the sitemap and the view generation.

sounds reasonable! I'd like to see it work just like session do currently

> 19. There are some other things that need to be fixed, but the following
> item is the biggest one.
>
> Currently the global variable space is shared between _all_ the flow
> scripts and _all_ the users. This is clearly wrong, and it will change
> soon. 

ok

> What we should have is the global variable space common only to a
> flow script, and only to a single user. This has been a challenge so far
> with the Rhino, but I think I have a solution for it.

great!

> Variables in this global variable space will act as session variables. To

what does that mean exactly? you mean they are persistent... but local to the 
continuation's object, arent't they?

> facilitate communication between applications or share constant values
> between users of the same application, an application and a global space
> will be introduced.

so this could be used for flow-2-flow communication?!

> In this new approach, it should be possible to have multiple top level
> functions be invoked from the same sitemap, and have them share the same
> global variable scope, for a given user. This makes things a lot easier
> when programming with the flow layer, as you are not forced to always use
> continuations. You can store your application variables as global variables
> in a JavaScript script, and have multiple functions operated on them, where
> each function is called from the sitemap.

hm... ok

> 20. My job - thanks Stefano for bringing it up. Here's my shameless plug :)
> If you think of using Cocoon for building Web apps or Web services, and you
> need support in doing so, I am providing consultancy for doing it, anytime,
> anywhere.

Aren't you still working for HP?
--
Torsten

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

Re: [RT] Flowscript [was Re: [RT] Flowmaps]

[Ovidiu Predescu <ov...@cup.hp.com>]

On 6/20/02 1:21 AM, "Stefano Mazzocchi" <st...@apache.org> wrote:

> Ovidiu Predescu wrote:
> 
>> I think the idea is to have something which just works by default, with no
>> configuration necessary. In addition to this, more experienced developers
>> can use the current method, which is more complex. Vadim's proposal is for
>> the first method. What is already implemented in the current code is the
>> second method.
> 
> Ah, ok. Just one point, the code above:
> 
> <map:match pattern="calc/*">
>  <map:flow method="calculator" continuation="{1}" />
> </map:match>
> 
> would not match "calc/" (at least, in the past I had problems with this,
> maybe behavior changed today, I'm not sure), probably
> 
> <map:match type="regexp" pattern="calc/?(.*)">
>  <map:flow method="calculator" continuation="{1}"/>
> </map:match>
> 
> is a better way to handle it. What do you think?

The approach you mention will also match things like "calculator", which is
probably not what we want.

Vadim already pointed out the first approach works fine, which I think is
what we need.

>>>> 9. Reinhard asks what happens if two different flow scripts have a function
>>>> with a similar name name.
>>>> 
>>>> Since the flow scripts have their own variable space (not now due to some
>>>> problems in the current implementation), there shouldn't be any problem.
>>>> Each flow script can use its own variable and function names, without
>>>> worrying about possible conflicts with other scripts.
>>> 
>>> Yes, and also I was thinking about having something like
>>> 
>>> <map:call flow="calculator" method="calculator"/>
>>> 
>>> that provides sort of namespacing and avoids collisions.
>> 
>> In the new scheme I'm working on, there's no potential for collisions, each
>> flow script has its own namespace, separated from the others.
> 
> Internally, yes, but how would you specify which flowscript you want to
> call between all those you have declared in your sitemap?
> 
> For example
> 
> <map:flowscripts default="a">
> <map:flowscript name="a">
>  <map:script src="first.js" language="javascript"/>
>  <map:script src="second.js" language="javascript"/>
> </map:flowscript>
> <map:flowscript name="b">
>  <map:script src="first.js" language="javascript"/>
>  <map:script src="third.js" language="javascript"/>
> </map:flowscript>
> </map:flowscripts>
> 
> as you can see, both flowscripts include the same script 'first.js', so
> the function calls between the two overlap completely. Let us assume
> that the function 'blah' is described in 'first.js', then you call it
> with
> 
> <map:flow function="blah" continuation="..."/>
> 
> and it defaults to the 'a' flowscript (since the
> map:flowscripts/@default attribute states so). But how would you call
> the 'blah' function of the 'b' flowscript?
> 
> I would follow the same pattern we use for components and use
> 
> <map:flow flowscript="b" function="blah" continuation="..."/>
> 
> I see no transparent ways to do this.

Sorry, you're right, I misunderstood what you have in mind. This would be
the right approach to differentiate between things.

>> The automatic binding happens under the strict control of the programmer.
>> What I was thinking to have is the ability to map a request parameter to a
>> script variable, _if_ the programmer requests so for a particular variable.
>> How the mapping is done is completely under the control of the programmer.
> 
> Ah, I get your point. You want to do something like what IE does with
> DOM in DHTML:
> 
> document.blah
> 
> is equivalent of 
> 
> document.getElementById("blah");
> 
> so that instead of doing
> 
> cocoon.getRequest().getParameter("password");
> 
> you call something like
> 
> request.password
> 
> directly. Is that your point?

Yes, we can use either this approach, or a separate mapping file, or a
programmatic way to specify the mapping between a variable name in a
function and a request parameter. I think the approach you mention above is
the easiest however.

>> The counting starts from a node in the tree and goes upwards, that was the
>> reason why the number is positive. To me this makes more sense than using
>> negative numbers, but I have no strong opinions.
> 
> I think you saw this from a development point of view, from a user point
> of view, the flow of the continuation goes with the arrow of time, so
> you go "back" to retrieve your past continuation. And "1" seems to imply
> a step 'forward' in the arrow of time (which doesn't make any sense and
> would confuse people at first, at least, that's what happened to me...
> but I'm by far not the average Cocoon user :)

OK, I got your point.

>>> Cool. Ovidiu, we *definately* need more docs on what you wrote. It's
>>> simply too undocumented right now... don't need to be XML-ized edited or
>>> anything, just bare raw but with juicy info inside, we'll make them
>>> better ourselves.
>> 
>> Yes, I know it's undocumented. I spent a lot of time describing the ideas on
>> emails, but didn't actually takes those and put in a document. I'll try to
>> come up with some docs, but there are simply too many things to work on at
>> the same time ;)
> 
> I would kindly suggest you to escape your 'ego trap' and start writing
> crude docs before anything else. I know it would be very nice if you
> could provide us with all we asked for already implemented, but then you
> become the bottleneck and the community suffers from this.
>
> Instead, if you provide even a very basic description of what we have
> there (don't worry, doesn't need to be coherent or well written, just
> contain the information for the other developers to catch up on your
> work), work can parallelize.
> 
> Hope you get my point.

Kevin O'Neill <ke...@rocketred.com.au> has volunteered to start collecting
some of the old email threads and assemble them in a more or less coherent
document, which describes the main ideas.

>>>> 14. Another question Piroumian has is how to validate against business
>>>> logic. Since JavaScript is tightly integrated with Java, you can call Java
>>>> logic from the flow script to do the business logic validation. This way
>>>> you
>>>> can invoke whatever logic you want. If this is too generic, then provide
>>>> some use case and I'll try to sketch a solution.
>>> 
>>> I think you should provide a real-life example of use of a java data
>>> model to show how java can be called from the flowscript.
>> 
>> This too is on my TODO list ;)
> 
> Ok, please, make *your* TODO list *ours*. :)

Yep, I've tried it.

But the code is crappy, and there's no documentation to explain the ideas.
The only place where these ideas are presented is on the mailing list, and
there the messages span across multiple months. I don't expect *my* TODO
list to suddenly become everybody else's. There is simply no critical mass
of developers that understand the ideas and the code enough for this to
happen. This is the reality of any open source project, the original
developer has to drive it to a certain point until people pick it up from
there.

> And don't worry if you don't have time, nobody really does... and who
> does is wasting it to work on something so stupid as Cocoon instead of
> appreciating what they have in their life, myself first :(

I concur to these statements ;)

Best regards,
-- 
Ovidiu Predescu <ov...@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

RE: [RT] Flowscript [was Re: [RT] Flowmaps]

[Vadim Gritsenko <va...@verizon.net>]

> From: Stefano Mazzocchi [mailto:stefano@apache.org]

<snip/>

> Ah, ok. Just one point, the code above:
> 
>   <map:match pattern="calc/*">
>    <map:flow method="calculator" continuation="{1}" />
>   </map:match>
> 
> would not match "calc/" (at least, in the past I had problems with
this,
> maybe behavior changed today, I'm not sure),

It matches (be sure).


> probably
> 
>   <map:match type="regexp" pattern="calc/?(.*)">

You mean "calc/(.*)?", right?


>    <map:flow method="calculator" continuation="{1}"/>
>   </map:match>
> 
> is a better way to handle it. What do you think?

<snip/>

> > > Yes, and also I was thinking about having something like
> > >
> > > <map:call flow="calculator" method="calculator"/>
> > >
> > > that provides sort of namespacing and avoids collisions.
> >
> > In the new scheme I'm working on, there's no potential for
collisions, each
> > flow script has its own namespace, separated from the others.
> 
> Internally, yes, but how would you specify which flowscript you want
to
> call between all those you have declared in your sitemap?
> 
> For example
> 
>  <map:flowscripts default="a">
>   <map:flowscript name="a">
>    <map:script src="first.js" language="javascript"/>
>    <map:script src="second.js" language="javascript"/>
>   </map:flowscript>
>   <map:flowscript name="b">
>    <map:script src="first.js" language="javascript"/>
>    <map:script src="third.js" language="javascript"/>
>   </map:flowscript>
>  </map:flowscripts>
> 
> as you can see, both flowscripts include the same script 'first.js',
so
> the function calls between the two overlap completely. Let us assume
> that the function 'blah' is described in 'first.js', then you call it
> with
> 
>  <map:flow function="blah" continuation="..."/>
> 
> and it defaults to the 'a' flowscript (since the
> map:flowscripts/@default attribute states so). But how would you call
> the 'blah' function of the 'b' flowscript?
> 
> I would follow the same pattern we use for components and use
> 
>  <map:flow flowscript="b" function="blah" continuation="..."/>

More consistent with the rest will be:

<map:flow type="b" function="blah" continuation="..."/>

Vadim


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

Re: [RT] Flowscript [was Re: [RT] Flowmaps]

[Stefano Mazzocchi <st...@apache.org>]

Ovidiu Predescu wrote:

> > Hmmm, call me picky, but what's wrong with
> >
> >  <map:flowscripts default="calculator">
> >   <map:flowscript name="calculator" src="calc.js"
> > language="javascript"/>
> >  </map:flowscripts>
> 
> Because my calculator implementation may be composed of multiple script
> files. This is not the case in this simple example, but I may need to split
> the implementation for clarity in multiple files. Having the ability to
> specify multiple files by adding <map:script> as needed solves the problem.

Ah, got it. Cool, makes sense.
 
> > Many ask to make continuations ID as transparent as session IDs. Do you
> > think this is possible/desirable?
> 
> I think it is both desirable and possible. I think the responsibility for
> deciding this should be in the sitemap, and only in one place.

Totally agree. That would be the perfect scenario. Do you people have
any ideas on how we can achieve this in practice?
 
> >> Also in your callPipeline(), how does the output parameter get used?
> >
> > That's the key issue: many people, in the past, pointed out that they
> > would like to reuse the concept of cocoon pipelines to create stuff but
> > send it somewhere else, not back to the client.
> >
> > Currently, there is no way for a pipeline stage to call another pipeline
> > *detaching* it from the client output stream and attaching it a
> > different output stream. I would like the flowscript to be able to do
> > that.
> 
> Yes, that's right! HP's SOAP server based on Cocoon had to do some really
> nasty things to achieve this. I see what you mean, and it should be
> possible.

Great, I think so too.

> >> It
> >> should be the task of the sitemap pipeline where the file is written. Am I
> >> missing something?
> >
> > It's *not* the sitemap concern to know where the output stream is. If
> > you look at how the sitemap is implemented, it's the sitemap caller's
> > concern to provide the output stream. Servlets call the sitemap engine
> > passing the ResponseOutputStream and the CLI calls the sitemap engine
> > passing FileOutputStreams.
> >
> > But the granularity is all or nothing. I would like to be able to call a
> > pipeline 'detaching it' from the output stream that the container
> > passed.
> >
> > Why? simply because it allows very creative uses of cocoon pipelines and
> > would instantly stop all those requests for 'forking pipelines' that
> > keep bugging me in the back of my mind.
> 
> OK, I get it! That's indeed a nice feature to have.

Yep, this will sure make Cocoon fly :)

> >> 5. Ivelin points out the potential of stale continuations.
> >>
> >> I think this is indeed a real issue. One way to avoid it is to have
> >> continuations automatically expire after a time of inactivity, or do
> >> deactivate them manually in the flow script. The first approach is something
> >> I considered, and there are some hooks in the current code, but more support
> >> code needs to be written. The second approach can be implemented today: you
> >> can invalidate not only a single continuation, but the whole subtree of
> >> continuations which start from it. You just need to keep a hold on the
> >> continuation at the top of the tree, and invoke invalidate() on it.
> >
> > Speaking of which, would it good to have a 'continuation' object in the
> > FOM?
> 
> It is already there, together with the data object. Check-out the jpath.xsl
> logicsheet to see how this works.

uh, impressive :)

> >> 8. Vadim's idea about making the syntax easier.
> >>
> >> I think the idea of having something as simple as:
> >>
> >> <map:match pattern="calc/*">
> >>   <map:flow method="calculator" continuation="{1}" />
> >> </map:match>
> >>
> >> makes a lot of sense. Using different matchers, the continuation id can be
> >> extracted from the request parameters, cookies, you name it. The only
> >> problem with it is that is a bit inflexible in terms of the URI design. If
> >> I'd like to have calc/kont/*, there's no easy way to specify it.
> >>
> >> So I'd say we can have two alternative ways of writing this: using the above
> >> proposal and what is already implemented, for power users that want more
> >> control. How about this?
> >
> > Sorry, but I lost you here.
> 
> I think the idea is to have something which just works by default, with no
> configuration necessary. In addition to this, more experienced developers
> can use the current method, which is more complex. Vadim's proposal is for
> the first method. What is already implemented in the current code is the
> second method.

Ah, ok. Just one point, the code above:

  <map:match pattern="calc/*">
   <map:flow method="calculator" continuation="{1}" />
  </map:match>

would not match "calc/" (at least, in the past I had problems with this,
maybe behavior changed today, I'm not sure), probably

  <map:match type="regexp" pattern="calc/?(.*)">
   <map:flow method="calculator" continuation="{1}"/>
  </map:match>

is a better way to handle it. What do you think?

> >> 9. Reinhard asks what happens if two different flow scripts have a function
> >> with a similar name name.
> >>
> >> Since the flow scripts have their own variable space (not now due to some
> >> problems in the current implementation), there shouldn't be any problem.
> >> Each flow script can use its own variable and function names, without
> >> worrying about possible conflicts with other scripts.
> >
> > Yes, and also I was thinking about having something like
> >
> > <map:call flow="calculator" method="calculator"/>
> >
> > that provides sort of namespacing and avoids collisions.
> 
> In the new scheme I'm working on, there's no potential for collisions, each
> flow script has its own namespace, separated from the others.

Internally, yes, but how would you specify which flowscript you want to
call between all those you have declared in your sitemap?

For example

 <map:flowscripts default="a">
  <map:flowscript name="a">
   <map:script src="first.js" language="javascript"/>
   <map:script src="second.js" language="javascript"/>
  </map:flowscript>
  <map:flowscript name="b">
   <map:script src="first.js" language="javascript"/>
   <map:script src="third.js" language="javascript"/>
  </map:flowscript>
 </map:flowscripts>

as you can see, both flowscripts include the same script 'first.js', so
the function calls between the two overlap completely. Let us assume
that the function 'blah' is described in 'first.js', then you call it
with

 <map:flow function="blah" continuation="..."/>

and it defaults to the 'a' flowscript (since the
map:flowscripts/@default attribute states so). But how would you call
the 'blah' function of the 'b' flowscript?

I would follow the same pattern we use for components and use

 <map:flow flowscript="b" function="blah" continuation="..."/>

I see no transparent ways to do this.

> > [...]
> >
> >> - automatic binding of JavaScript variables to form values. This would allow
> >> you to declare something like:
> >>
> >>   var username, password;
> >>
> >>   // Send a page to collect the user name and the password
> >>   sendPage("login.html");
> >>
> >>   // When the user fills in the form and presses the submit button, the
> >>   // script restarts here. The flow engine automatically binds the username
> >>   // and password to the values submitted in the form.
> >>
> >>   // make use of username and passwd here
> >
> > I didn't know PHP had problems with this approach, but it smells a lot
> > anyway. I'm always afraid of implicity behavior, expecially when it's
> > user-triggerable.
> >
> > This is not automatically a security hole, but it could become one since
> > you are letting potential attackers one step closer to your door. And
> > you are making things hidden so harder to spot.
> >
> > I would be against anything so implicit.
> 
> No, no, I wanted to say something completely different. I replied to this
> topic already, but I'll repeat it here to be clear.
> 
> The automatic binding happens under the strict control of the programmer.
> What I was thinking to have is the ability to map a request parameter to a
> script variable, _if_ the programmer requests so for a particular variable.
> How the mapping is done is completely under the control of the programmer.

Ah, I get your point. You want to do something like what IE does with
DOM in DHTML:

 document.blah

is equivalent of 

 document.getElementById("blah");

so that instead of doing 

 cocoon.getRequest().getParameter("password");

you call something like

 request.password

directly. Is that your point?

> >> - automatic validation of form values on both server and client side. This
> >> should allow the same piece of JavaScript validation code to be executed
> >> both on the server and client side. More on this later.
> >>
> >> 11. With respect to how to put a back button on a page, I think I replied to
> >> this some time ago. The idea is to use the <jpath:continuation select="1"/>
> >> which selects the previous continuation.
> >
> > I agree with Torsten: I'd like to keep the flow layer detached from the
> > jpath logicsheet. (I would also use -1 as well to indicate backwards)
> 
> Again, I was only lazy to come up with a new logicsheet, so I reused things
> in the same logicsheet.
> 
> The counting starts from a node in the tree and goes upwards, that was the
> reason why the number is positive. To me this makes more sense than using
> negative numbers, but I have no strong opinions.

I think you saw this from a development point of view, from a user point
of view, the flow of the continuation goes with the arrow of time, so
you go "back" to retrieve your past continuation. And "1" seems to imply
a step 'forward' in the arrow of time (which doesn't make any sense and
would confuse people at first, at least, that's what happened to me...
but I'm by far not the average Cocoon user :)

> >> 13. Piroumian asks how to cancel a continuation.
> >>
> >> As I mentioned in several ocasions, sendPage() returns the saved
> >> continuation. If you want to cancel the continuation just invoke on it the
> >> invalidate() method. It will cancel all the receiver and all the
> >> continuations that inherit from it.
> >
> > Cool. Ovidiu, we *definately* need more docs on what you wrote. It's
> > simply too undocumented right now... don't need to be XML-ized edited or
> > anything, just bare raw but with juicy info inside, we'll make them
> > better ourselves.
> 
> Yes, I know it's undocumented. I spent a lot of time describing the ideas on
> emails, but didn't actually takes those and put in a document. I'll try to
> come up with some docs, but there are simply too many things to work on at
> the same time ;)

I would kindly suggest you to escape your 'ego trap' and start writing
crude docs before anything else. I know it would be very nice if you
could provide us with all we asked for already implemented, but then you
become the bottleneck and the community suffers from this.

Instead, if you provide even a very basic description of what we have
there (don't worry, doesn't need to be coherent or well written, just
contain the information for the other developers to catch up on your
work), work can parallelize.

Hope you get my point.

> >> 14. Another question Piroumian has is how to validate against business
> >> logic. Since JavaScript is tightly integrated with Java, you can call Java
> >> logic from the flow script to do the business logic validation. This way you
> >> can invoke whatever logic you want. If this is too generic, then provide
> >> some use case and I'll try to sketch a solution.
> >
> > I think you should provide a real-life example of use of a java data
> > model to show how java can be called from the flowscript.
> 
> This too is on my TODO list ;)

Ok, please, make *your* TODO list *ours*. :)

And don't worry if you don't have time, nobody really does... and who
does is wasting it to work on something so stupid as Cocoon instead of
appreciating what they have in their life, myself first :(

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



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

Re: [RT] Flowscript [was Re: [RT] Flowmaps]

[Ovidiu Predescu <ov...@apache.org>]

On 6/18/02 8:35 AM, "Stefano Mazzocchi" <st...@apache.org> wrote:

> Ovidiu Predescu wrote:
> [...]
>
>> First of all, I think the thanks should go to Christian Queinnec, who came
>> up with the idea, and to Christopher Oliver, who implemented continuations
>> in Rhino. I just put all the things together and implement the support in
>> Cocoon.
> 
> Once flow docos are in place, we'll make sure to give all credits to
> those who deserve it. For sure, you deserve lots of it.

Thanks!

>> 1. Stefano points out that flowmaps (I don't really like this term, a "map"
>> is more appropriate for state machines, how about flowscript instead?)
> 
> You are right. The concept of 'flowmap' came because of a mental
> parallel I had between a declarative approach and a procedural one...
> but after understanding that we don't need that, being the HTTP
> client/server model intrinsically declarative.
> 
> So +1 for 'flowscript'.

OK.

>> should not be considered as ordinary resources, but a separate concept. I
>> have no issue declaring them in a different way, just to emphasize this
>> point. So something like
>> 
>>   <map:flowscripts default="calculator">
>>    <map:flowscript name="calculator" language="javascript">
>>      <map:script src="calc.js"/>
>>    </map:flowscript>
>>   </map:flowscripts>
>> 
>> should be OK. 
> 
> Hmmm, call me picky, but what's wrong with
> 
>  <map:flowscripts default="calculator">
>   <map:flowscript name="calculator" src="calc.js"
> language="javascript"/>
>  </map:flowscripts>

Because my calculator implementation may be composed of multiple script
files. This is not the case in this simple example, but I may need to split
the implementation for clarity in multiple files. Having the ability to
specify multiple files by adding <map:script> as needed solves the problem.

>> Beside a different name for elements, the fundamental
>> difference between this syntax and Stefano's is that it allows multiple
>> files to contain the implementation of a flow script.
> 
> yes, this is also a parallel with any other sitemap concept, such as
> components, resources and views.

Yes.

> [...]
>
>> The transformer would probably work best when the continuation id is encoded
>> in the URL. When the id is encoded as a request parameter, there will be
>> some awareness required from the page designer to have this id enclosed
>> inside a form.
> 
> Many ask to make continuations ID as transparent as session IDs. Do you
> think this is possible/desirable?

I think it is both desirable and possible. I think the responsibility for
deciding this should be in the sitemap, and only in one place.

>> 3. (Stefano) Template languages other than XSP to be used with the flow
>> layer.
>> 
>> This should certainly be possible, I've started with XSP because it was very
>> easy to get implement. JSP and Velocity should be equally easy to implement
>> though. We just need somebody to do it ;)
> 
> Great. Please explain how then, because I think lack of knowledge and
> docos was the real issue (see how things changed with a single email)!

The only thing which needs to be implemented is the equivalent of the
jpath.xsl logicsheet. The idea of the logicsheet is very simple: to extract
data from a Java object model or DOM tree using XPath expressions. If you
look at the logicsheet, you'll get the idea.

> [...]
>
>> It
>> essentially allows you to have a page processed through a pipeline, and
>> continue the execution of the script. BTW, I think your sitemap snippet has
>> a bug in it, shouldn't it have the <map:match> names swapped?
>> 
>> Also in your callPipeline(), how does the output parameter get used?
> 
> That's the key issue: many people, in the past, pointed out that they
> would like to reuse the concept of cocoon pipelines to create stuff but
> send it somewhere else, not back to the client.
> 
> Currently, there is no way for a pipeline stage to call another pipeline
> *detaching* it from the client output stream and attaching it a
> different output stream. I would like the flowscript to be able to do
> that.

Yes, that's right! HP's SOAP server based on Cocoon had to do some really
nasty things to achieve this. I see what you mean, and it should be
possible.

>> It
>> should be the task of the sitemap pipeline where the file is written. Am I
>> missing something?
> 
> It's *not* the sitemap concern to know where the output stream is. If
> you look at how the sitemap is implemented, it's the sitemap caller's
> concern to provide the output stream. Servlets call the sitemap engine
> passing the ResponseOutputStream and the CLI calls the sitemap engine
> passing FileOutputStreams.
> 
> But the granularity is all or nothing. I would like to be able to call a
> pipeline 'detaching it' from the output stream that the container
> passed.
> 
> Why? simply because it allows very creative uses of cocoon pipelines and
> would instantly stop all those requests for 'forking pipelines' that
> keep bugging me in the back of my mind.

OK, I get it! That's indeed a nice feature to have.

>> 5. Ivelin points out the potential of stale continuations.
>> 
>> I think this is indeed a real issue. One way to avoid it is to have
>> continuations automatically expire after a time of inactivity, or do
>> deactivate them manually in the flow script. The first approach is something
>> I considered, and there are some hooks in the current code, but more support
>> code needs to be written. The second approach can be implemented today: you
>> can invalidate not only a single continuation, but the whole subtree of
>> continuations which start from it. You just need to keep a hold on the
>> continuation at the top of the tree, and invoke invalidate() on it.
> 
> Speaking of which, would it good to have a 'continuation' object in the
> FOM?

It is already there, together with the data object. Check-out the jpath.xsl
logicsheet to see how this works.

>> 6. Multi-page forms are not dominating, and continuation based compared to
>> even driven (GUI-like) programming approaches.
>> 
>> I used to program GUIs a lot, I think for certain things, event-driven is
>> better than using continuations. I do think however that continuations have
>> a place, especially for multi-page forms. Now I think it depends a lot on
>> the application, whether these forms are prevalent or not.
> 
> I agree and this is the reason why I think deprecating Actions is a bad
> thing (at least, today). We'll provide options and guidelines, users
> will decide what to do with the tools we provide.

OK.

>> 8. Vadim's idea about making the syntax easier.
>> 
>> I think the idea of having something as simple as:
>> 
>> <map:match pattern="calc/*">
>>   <map:flow method="calculator" continuation="{1}" />
>> </map:match>
>> 
>> makes a lot of sense. Using different matchers, the continuation id can be
>> extracted from the request parameters, cookies, you name it. The only
>> problem with it is that is a bit inflexible in terms of the URI design. If
>> I'd like to have calc/kont/*, there's no easy way to specify it.
>> 
>> So I'd say we can have two alternative ways of writing this: using the above
>> proposal and what is already implemented, for power users that want more
>> control. How about this?
> 
> Sorry, but I lost you here.

I think the idea is to have something which just works by default, with no
configuration necessary. In addition to this, more experienced developers
can use the current method, which is more complex. Vadim's proposal is for
the first method. What is already implemented in the current code is the
second method.

>> 9. Reinhard asks what happens if two different flow scripts have a function
>> with a similar name name.
>> 
>> Since the flow scripts have their own variable space (not now due to some
>> problems in the current implementation), there shouldn't be any problem.
>> Each flow script can use its own variable and function names, without
>> worrying about possible conflicts with other scripts.
> 
> Yes, and also I was thinking about having something like
> 
> <map:call flow="calculator" method="calculator"/>
> 
> that provides sort of namespacing and avoids collisions.

In the new scheme I'm working on, there's no potential for collisions, each
flow script has its own namespace, separated from the others.

> [...]
>
>> - automatic binding of JavaScript variables to form values. This would allow
>> you to declare something like:
>> 
>>   var username, password;
>> 
>>   // Send a page to collect the user name and the password
>>   sendPage("login.html");
>> 
>>   // When the user fills in the form and presses the submit button, the
>>   // script restarts here. The flow engine automatically binds the username
>>   // and password to the values submitted in the form.
>> 
>>   // make use of username and passwd here
> 
> I didn't know PHP had problems with this approach, but it smells a lot
> anyway. I'm always afraid of implicity behavior, expecially when it's
> user-triggerable.
> 
> This is not automatically a security hole, but it could become one since
> you are letting potential attackers one step closer to your door. And
> you are making things hidden so harder to spot.
> 
> I would be against anything so implicit.

No, no, I wanted to say something completely different. I replied to this
topic already, but I'll repeat it here to be clear.

The automatic binding happens under the strict control of the programmer.
What I was thinking to have is the ability to map a request parameter to a
script variable, _if_ the programmer requests so for a particular variable.
How the mapping is done is completely under the control of the programmer.

>> - automatic validation of form values on both server and client side. This
>> should allow the same piece of JavaScript validation code to be executed
>> both on the server and client side. More on this later.
>> 
>> 11. With respect to how to put a back button on a page, I think I replied to
>> this some time ago. The idea is to use the <jpath:continuation select="1"/>
>> which selects the previous continuation.
> 
> I agree with Torsten: I'd like to keep the flow layer detached from the
> jpath logicsheet. (I would also use -1 as well to indicate backwards)

Again, I was only lazy to come up with a new logicsheet, so I reused things
in the same logicsheet.

The counting starts from a node in the tree and goes upwards, that was the
reason why the number is positive. To me this makes more sense than using
negative numbers, but I have no strong opinions.

>> 13. Piroumian asks how to cancel a continuation.
>> 
>> As I mentioned in several ocasions, sendPage() returns the saved
>> continuation. If you want to cancel the continuation just invoke on it the
>> invalidate() method. It will cancel all the receiver and all the
>> continuations that inherit from it.
> 
> Cool. Ovidiu, we *definately* need more docs on what you wrote. It's
> simply too undocumented right now... don't need to be XML-ized edited or
> anything, just bare raw but with juicy info inside, we'll make them
> better ourselves.

Yes, I know it's undocumented. I spent a lot of time describing the ideas on
emails, but didn't actually takes those and put in a document. I'll try to
come up with some docs, but there are simply too many things to work on at
the same time ;)

>> 14. Another question Piroumian has is how to validate against business
>> logic. Since JavaScript is tightly integrated with Java, you can call Java
>> logic from the flow script to do the business logic validation. This way you
>> can invoke whatever logic you want. If this is too generic, then provide
>> some use case and I'll try to sketch a solution.
> 
> I think you should provide a real-life example of use of a java data
> model to show how java can be called from the flowscript.

This too is on my TODO list ;)

>> 16. Sylvain: should flow scripts be inherited by sub-sitemaps?
>> 
>> I'm not sure of the security implications of allowing them to be inherited:
>> what should be the behavior if a developer alters definitions from an
>> inherited flow script?
> 
> My perception is that flowscripts are not components and should not be
> inherited.

I think the same too, but I'll keep my eyes opened for counterexamples.

>> 17. The proposal to use map:call with "function(arg, arg, ...)".
>> 
>> I think this is more like a syntactic sugar than real value. I don't think
>> passing arguments via map:param would confuse people, the semantic is still
>> the same as function invocation.
> 
> All right, let's remove this.

OK.

>> 18. Access to continuations.
>> 
>> I think there is a bit of confusion of terms in this discussion. The
>> continuation id is passed in the HTTP request in some way or another: as
>> part of the URL, as a request parameter etc. This encoding should be visible
>> to the sitemap only. I'd very much like to have it hidden from the view
>> layer as well, so if we can avoid putting explicit URLs in page templates,
>> that would be great! This reduces the dependency between the URL design in
>> the sitemap and the view generation.
>> 
>> A continuation is a real object that lives on the server side, which is
>> represented by its id in the request. A continuation object is returned by
>> sendPage(). A continuation id is fairly much useless in a flow script, what
>> you really need is the continuation object itself, which contains this
>> information and more.
> 
> Yes, there is confusing between the 'continuation object' and the
> 'continuation id'.
> 
> Many don't like the fact that you have to explicitly pass along the
> 'continuation id', unlike sessions where the 'session id' is (generally)
> transparently passed back and forth (which was one of the biggest values
> of the Servlet API)

Yes, I should think of a better solution.

> [...]
>
>> 20. My job - thanks Stefano for bringing it up. Here's my shameless plug :)
>> If you think of using Cocoon for building Web apps or Web services, and you
>> need support in doing so, I am providing consultancy for doing it, anytime,
>> anywhere.
> 
> Good luck for all this!

Thanks!

Regards,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

[RT] Flowscript [was Re: [RT] Flowmaps]

[Stefano Mazzocchi <st...@apache.org>]

Ovidiu Predescu wrote:
> 
> Guys,
> 
> I'm really overwhelmed by your reaction to the flow idea! Thanks all for
> sharing your thoughts!
> 
> First of all, I think the thanks should go to Christian Queinnec, who came
> up with the idea, and to Christopher Oliver, who implemented continuations
> in Rhino. I just put all the things together and implement the support in
> Cocoon.

Once flow docos are in place, we'll make sure to give all credits to
those who deserve it. For sure, you deserve lots of it.

> Now, there are few points that have been raised here. I'll try to answer to
> all of them in this email, both as a way to synthesize this great
> discussion, and to minimize the time I take to respond to individual
> messages (otherwise I can easily spend my entire evening replying). Please
> raise your issue again if you don't see an answer for it here.
> 
> 1. Stefano points out that flowmaps (I don't really like this term, a "map"
> is more appropriate for state machines, how about flowscript instead?)

You are right. The concept of 'flowmap' came because of a mental
parallel I had between a declarative approach and a procedural one...
but after understanding that we don't need that, being the HTTP
client/server model intrinsically declarative.

So +1 for 'flowscript'.

> should not be considered as ordinary resources, but a separate concept. I
> have no issue declaring them in a different way, just to emphasize this
> point. So something like
> 
>   <map:flowscripts default="calculator">
>    <map:flowscript name="calculator" language="javascript">
>      <map:script src="calc.js"/>
>    </map:flowscript>
>   </map:flowscripts>
> 
> should be OK. 

Hmmm, call me picky, but what's wrong with

   <map:flowscripts default="calculator">
    <map:flowscript name="calculator" src="calc.js"
language="javascript"/>
   </map:flowscripts>

> Beside a different name for elements, the fundamental
> difference between this syntax and Stefano's is that it allows multiple
> files to contain the implementation of a flow script.

yes, this is also a parallel with any other sitemap concept, such as
components, resources and views.
 
> Each named flow script declared in <map:flowscripts> could and should be
> independent on the others. Each script should have different set of global
> variables, which is different from another script, and of course, is
> different each user gets his/her own set of values for these variables.
> 
> This is an issue today, as it does not really happen. I'm working on solving
> it.

Great to hear that.
 
> 2. (Stefano) How to encode the continuation ids.
> 
> Stefano would like to have ContinuationURLEncodingTransformer, which takes
> care of encoding the continuation id. Sylvain points out that continuation
> ids can be passed not only as part of the URL, but also as request
> parameter.
> 
> I think it makes sense to have a transformer which encodes the continuation
> URL. This would make it very easy to change the way the continuation id is
> generated, without having to go to each XSP, JSP, whatever and change it.

Exactly.

> The transformer would probably work best when the continuation id is encoded
> in the URL. When the id is encoded as a request parameter, there will be
> some awareness required from the page designer to have this id enclosed
> inside a form.

Many ask to make continuations ID as transparent as session IDs. Do you
think this is possible/desirable?
 
> 3. (Stefano) Template languages other than XSP to be used with the flow
> layer.
> 
> This should certainly be possible, I've started with XSP because it was very
> easy to get implement. JSP and Velocity should be equally easy to implement
> though. We just need somebody to do it ;)

Great. Please explain how then, because I think lack of knowledge and
docos was the real issue (see how things changed with a single email)!
 
> 4. Stefano's callPipeline() function. Is this equivalent to
> sendPageAndContinue(), which is already implemented in the flow layer?

No, I don't think so (see below).

> It
> essentially allows you to have a page processed through a pipeline, and
> continue the execution of the script. BTW, I think your sitemap snippet has
> a bug in it, shouldn't it have the <map:match> names swapped?
> 
> Also in your callPipeline(), how does the output parameter get used?

That's the key issue: many people, in the past, pointed out that they
would like to reuse the concept of cocoon pipelines to create stuff but
send it somewhere else, not back to the client.

Currently, there is no way for a pipeline stage to call another pipeline
*detaching* it from the client output stream and attaching it a
different output stream. I would like the flowscript to be able to do
that.

> It
> should be the task of the sitemap pipeline where the file is written. Am I
> missing something?

It's *not* the sitemap concern to know where the output stream is. If
you look at how the sitemap is implemented, it's the sitemap caller's
concern to provide the output stream. Servlets call the sitemap engine
passing the ResponseOutputStream and the CLI calls the sitemap engine
passing FileOutputStreams.

But the granularity is all or nothing. I would like to be able to call a
pipeline 'detaching it' from the output stream that the container
passed.

Why? simply because it allows very creative uses of cocoon pipelines and
would instantly stop all those requests for 'forking pipelines' that
keep bugging me in the back of my mind.
 
> 5. Ivelin points out the potential of stale continuations.
> 
> I think this is indeed a real issue. One way to avoid it is to have
> continuations automatically expire after a time of inactivity, or do
> deactivate them manually in the flow script. The first approach is something
> I considered, and there are some hooks in the current code, but more support
> code needs to be written. The second approach can be implemented today: you
> can invalidate not only a single continuation, but the whole subtree of
> continuations which start from it. You just need to keep a hold on the
> continuation at the top of the tree, and invoke invalidate() on it.

Speaking of which, would it good to have a 'continuation' object in the
FOM?

> 6. Multi-page forms are not dominating, and continuation based compared to
> even driven (GUI-like) programming approaches.
> 
> I used to program GUIs a lot, I think for certain things, event-driven is
> better than using continuations. I do think however that continuations have
> a place, especially for multi-page forms. Now I think it depends a lot on
> the application, whether these forms are prevalent or not.

I agree and this is the reason why I think deprecating Actions is a bad
thing (at least, today). We'll provide options and guidelines, users
will decide what to do with the tools we provide.

> 7. Bruno's question regarding the advantage of flow scripts versus actions.
> 
> The advantage would be that with flow scripts you can describe all the
> actions in a single flow script, where each action becomes a separate
> function. Since these functions share the same global variables, it's very
> easy to share data between them. You can share data using the session
> object, but with explicit variables is much easier to follow what's going
> on.
> 
> If you don't care about sharing data between actions, then there's probably
> little value describing your action logic in a flow script. Other than the
> fact that you don't have to write Java code, which means compile, build war
> file, restart tomcat. With flow scripts, you just modify the script file and
> resend the request: the script is automatically reloaded and parsed by
> Cocoon, there's no need to restart anything.
> 
> 8. Vadim's idea about making the syntax easier.
> 
> I think the idea of having something as simple as:
> 
> <map:match pattern="calc/*">
>   <map:flow method="calculator" continuation="{1}" />
> </map:match>
> 
> makes a lot of sense. Using different matchers, the continuation id can be
> extracted from the request parameters, cookies, you name it. The only
> problem with it is that is a bit inflexible in terms of the URI design. If
> I'd like to have calc/kont/*, there's no easy way to specify it.
> 
> So I'd say we can have two alternative ways of writing this: using the above
> proposal and what is already implemented, for power users that want more
> control. How about this?

Sorry, but I lost you here.

> 9. Reinhard asks what happens if two different flow scripts have a function
> with a similar name name.
> 
> Since the flow scripts have their own variable space (not now due to some
> problems in the current implementation), there shouldn't be any problem.
> Each flow script can use its own variable and function names, without
> worrying about possible conflicts with other scripts.

Yes, and also I was thinking about having something like

 <map:call flow="calculator" method="calculator"/>

that provides sort of namespacing and avoids collisions.

> 10. Torsten asks how xmlform/precept could be implemented with flow scripts.
> 
> I think the more generic question is how to implement multi-page forms using
> flow scripts. It would also be nice if the validation could happen not only
> on the server side, but also in the client browser, using JavaScript if
> that's available.
> 
> Your example would become a lot simpler if you factor out the repetitive
> code in a function:
> 
> var validator;
> var instance;
> var prefix;
> 
> function wizard(uriPrefix) {
>   var id = cocoon.request.getParameter("someid");
> 
>   var factory = SchemaFactory.getInstance("ns");
>   //maybe we can get the schema from a pipeline??
>   var schema = factory.compile("someschema.xsd.dtd.rng.sch");
>   validator = schema.createValidator();
>   instance = new Instance();
>   prefix = uriPrefix;
> 
>   loadInstance(instance,id);
> 
>   do {
>     showAndValidatePage(1);
>     showAndValidatePage(2);
>     showAndValidatePage(3);
>   } while(!validator.isValid(instance));
> 
>   if(saveInstance(instance,id)) {
>    sendPage("success.html");
>   }
>   else {
>    sendPage("failed.html");
>   }
> }
> 
> function showAndValidatePage(number)
> {
>    do {
>     sendPage(prefix + "page" + number + ".html");
>     Instance.populate(instance, cocoon.request);
>    } while(!validator.isValid(instance, "page" + number));
> }
> 
> Torsten's example uses a heavily xmlform type of approach, where the data to
> be validated is kept in a Java object or a DOM tree. This is one way of
> doing things; another one would be to use explicit variables which, at the
> end of the validation, could be written in the database directly, or used to
> construct a object hierarchy which is then saved in the database using JDO,
> EJBs or whatever other means. The validation could be done directly in
> JavaScript, instead of a Schema approach. The code that does the validation
> could then be used on the client side as well.
> 
> As Stefano mentioned, the flow layer is an infrastructure which can be used
> to create higher level abstractions. Here are some things I am currently
> looking at, which can improve the usability of the flow script engine:
> 
> - automatic binding of JavaScript variables to form values. This would allow
> you to declare something like:
> 
>   var username, password;
> 
>   // Send a page to collect the user name and the password
>   sendPage("login.html");
> 
>   // When the user fills in the form and presses the submit button, the
>   // script restarts here. The flow engine automatically binds the username
>   // and password to the values submitted in the form.
> 
>   // make use of username and passwd here

I didn't know PHP had problems with this approach, but it smells a lot
anyway. I'm always afraid of implicity behavior, expecially when it's
user-triggerable.

This is not automatically a security hole, but it could become one since
you are letting potential attackers one step closer to your door. And
you are making things hidden so harder to spot.

I would be against anything so implicit.

> - automatic validation of form values on both server and client side. This
> should allow the same piece of JavaScript validation code to be executed
> both on the server and client side. More on this later.
> 
> 11. With respect to how to put a back button on a page, I think I replied to
> this some time ago. The idea is to use the <jpath:continuation select="1"/>
> which selects the previous continuation.

I agree with Torsten: I'd like to keep the flow layer detached from the
jpath logicsheet. (I would also use -1 as well to indicate backwards)

> As I mentioned in some other message, the continuations created during the
> execution will form a tree, or a list if the user never presses the back
> button and starts on a different path. At any given point you can access the
> continuations above you in the tree, which identify the past pages, by using
> the "select" attribute in <jpath:continuation>.
> 
> 12. Torsten: sub-flows, flow-2-flow, what are these? Is assembly of
> functions that represent independent flows enough?
> 
> 13. Piroumian asks how to cancel a continuation.
> 
> As I mentioned in several ocasions, sendPage() returns the saved
> continuation. If you want to cancel the continuation just invoke on it the
> invalidate() method. It will cancel all the receiver and all the
> continuations that inherit from it.

Cool. Ovidiu, we *definately* need more docs on what you wrote. It's
simply too undocumented right now... don't need to be XML-ized edited or
anything, just bare raw but with juicy info inside, we'll make them
better ourselves.

> 14. Another question Piroumian has is how to validate against business
> logic. Since JavaScript is tightly integrated with Java, you can call Java
> logic from the flow script to do the business logic validation. This way you
> can invoke whatever logic you want. If this is too generic, then provide
> some use case and I'll try to sketch a solution.

I think you should provide a real-life example of use of a java data
model to show how java can be called from the flowscript.

> 15. Flow management: obtaining a list of all active flows.
> 
> All the flows are kept in an array, which is managed by a Cocoon component.
> Each flow is a tree of continuations, where each continuation is a
> JavaScript object which can be dynamically inspected for properties and so
> on.
> 
> 16. Sylvain: should flow scripts be inherited by sub-sitemaps?
> 
> I'm not sure of the security implications of allowing them to be inherited:
> what should be the behavior if a developer alters definitions from an
> inherited flow script?

My perception is that flowscripts are not components and should not be
inherited.

> 17. The proposal to use map:call with "function(arg, arg, ...)".
> 
> I think this is more like a syntactic sugar than real value. I don't think
> passing arguments via map:param would confuse people, the semantic is still
> the same as function invocation.

All right, let's remove this.

> 18. Access to continuations.
> 
> I think there is a bit of confusion of terms in this discussion. The
> continuation id is passed in the HTTP request in some way or another: as
> part of the URL, as a request parameter etc. This encoding should be visible
> to the sitemap only. I'd very much like to have it hidden from the view
> layer as well, so if we can avoid putting explicit URLs in page templates,
> that would be great! This reduces the dependency between the URL design in
> the sitemap and the view generation.
> 
> A continuation is a real object that lives on the server side, which is
> represented by its id in the request. A continuation object is returned by
> sendPage(). A continuation id is fairly much useless in a flow script, what
> you really need is the continuation object itself, which contains this
> information and more.

Yes, there is confusing between the 'continuation object' and the
'continuation id'.

Many don't like the fact that you have to explicitly pass along the
'continuation id', unlike sessions where the 'session id' is (generally)
transparently passed back and forth (which was one of the biggest values
of the Servlet API)

> 19. There are some other things that need to be fixed, but the following
> item is the biggest one.
> 
> Currently the global variable space is shared between _all_ the flow scripts
> and _all_ the users. This is clearly wrong, and it will change soon. What we
> should have is the global variable space common only to a flow script, and
> only to a single user. This has been a challenge so far with the Rhino, but
> I think I have a solution for it.
>
> Variables in this global variable space will act as session variables. To
> facilitate communication between applications or share constant values
> between users of the same application, an application and a global space
> will be introduced.
> 
> In this new approach, it should be possible to have multiple top level
> functions be invoked from the same sitemap, and have them share the same
> global variable scope, for a given user. This makes things a lot easier when
> programming with the flow layer, as you are not forced to always use
> continuations. You can store your application variables as global variables
> in a JavaScript script, and have multiple functions operated on them, where
> each function is called from the sitemap.

Great to hear.

> 20. My job - thanks Stefano for bringing it up. Here's my shameless plug :)
> If you think of using Cocoon for building Web apps or Web services, and you
> need support in doing so, I am providing consultancy for doing it, anytime,
> anywhere.

Good luck for all this!

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



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

[RT] Flowmaps

[Denis Thierry <de...@aic-info.com>]

Hi all,

I'm following this *very* interesting discussion on the flowmap concepts
and I would just like to contribute to the easiest part: tag names ... ;-))

Ovidiu Predescu wrote:
>>> Guys,
>>>
>>> I'm really overwhelmed by your reaction to the flow idea! Thanks all
>> for
>>> sharing your thoughts!
>>
>> Welcome!
>>
>> ... snips scattered below ...
>>
>>> 1. Stefano points out that flowmaps (I don't really like this term, a
>> "map"
>>> is more appropriate for state machines, how about flowscript instead?)
>>
>> One more to consider: sitescript (as opposed to site-map), or webscript.
>> Flowscript sounds great though.
>
>One thing I don't like is that all of them end in "script", which is really
>confusing. Consider this likely phrase in the documentation: You need to
>write a JavaScript flow script, which is composed of two file scripts.
>
If I did understand well, all this is about defining webapps and hence why
not using the following terminology :

  <map:flowapps default="calculator">
   <map:flowapp name="calculator" language="javascript">
     <map:flowscript src="calc.js"/>
   </map:flowapp>
  </map:flowapps>

Regards,

Denis



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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

On 6/17/02 9:50 PM, "Vadim Gritsenko" <va...@verizon.net> wrote:

>> From: Ovidiu Predescu [mailto:ovidiu@apache.org]
>> 
>> Guys,
>> 
>> I'm really overwhelmed by your reaction to the flow idea! Thanks all
> for
>> sharing your thoughts!
> 
> Welcome!
> 
> ... snips scattered below ...
> 
>> 1. Stefano points out that flowmaps (I don't really like this term, a
> "map"
>> is more appropriate for state machines, how about flowscript instead?)
> 
> One more to consider: sitescript (as opposed to site-map), or webscript.
> Flowscript sounds great though.

One thing I don't like is that all of them end in "script", which is really
confusing. Consider this likely phrase in the documentation: You need to
write a JavaScript flow script, which is composed of two file scripts.

>> 8. Vadim's idea about making the syntax easier.
>> 
>> I think the idea of having something as simple as:
>> 
>> <map:match pattern="calc/*">
>>   <map:flow method="calculator" continuation="{1}" />
>> </map:match>
>> 
>> makes a lot of sense. Using different matchers, the continuation id
> can be
>> extracted from the request parameters, cookies, you name it. The only
>> problem with it is that is a bit inflexible in terms of the URI
> design. If
>> I'd like to have calc/kont/*, there's no easy way to specify it.
> 
> Please, as easy as:
> 
> <!-- starts script because continuation is empty (or remove attribute -
> if it is optional) -->
> <map:match pattern="calc/">
> <map:flow method="calculator" continuation="" />
> </map:match>
> 
> <!-- continues script -->
> <map:match pattern="calc/kont/*">
> <map:flow method="calculator" continuation="{1}" />
> </map:match>

A continuation id is not really associated with a function/method, but with
a continuation. You can assign the continuation id to a different
continuation, which perhaps started from a different function. But I get
your idea: use map:flow rather than map:call, which has a different semantic
in the current Cocoon. But we'll still have the additional "continue"
matcher, which was the initial point of discussion you started. Wasn't this
supposed to ease the way a sitemap developer writes the sitemap? Personally
I don't think this is a problem, since without the "continue" matcher,
things fail immediately. Thoughts?

Greetings,
Ovidiu


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

RE: [RT] Flowmaps

[Vadim Gritsenko <va...@verizon.net>]

> From: Ovidiu Predescu [mailto:ovidiu@apache.org]
> 
> Guys,
> 
> I'm really overwhelmed by your reaction to the flow idea! Thanks all
for
> sharing your thoughts!

Welcome!

... snips scattered below ...

> 1. Stefano points out that flowmaps (I don't really like this term, a
"map"
> is more appropriate for state machines, how about flowscript instead?)

One more to consider: sitescript (as opposed to site-map), or webscript.
Flowscript sounds great though.

...

> 8. Vadim's idea about making the syntax easier.
> 
> I think the idea of having something as simple as:
> 
> <map:match pattern="calc/*">
>   <map:flow method="calculator" continuation="{1}" />
> </map:match>
> 
> makes a lot of sense. Using different matchers, the continuation id
can be
> extracted from the request parameters, cookies, you name it. The only
> problem with it is that is a bit inflexible in terms of the URI
design. If
> I'd like to have calc/kont/*, there's no easy way to specify it.

Please, as easy as:

<!-- starts script because continuation is empty (or remove attribute -
if it is optional) -->
<map:match pattern="calc/">
  <map:flow method="calculator" continuation="" />
</map:match>

<!-- continues script -->
<map:match pattern="calc/kont/*">
  <map:flow method="calculator" continuation="{1}" />
</map:match>



Vadim

...


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

Re: [RT] Flowmaps

[Ovidiu Predescu <ov...@apache.org>]

Guys,

I'm really overwhelmed by your reaction to the flow idea! Thanks all for
sharing your thoughts!

First of all, I think the thanks should go to Christian Queinnec, who came
up with the idea, and to Christopher Oliver, who implemented continuations
in Rhino. I just put all the things together and implement the support in
Cocoon.

Now, there are few points that have been raised here. I'll try to answer to
all of them in this email, both as a way to synthesize this great
discussion, and to minimize the time I take to respond to individual
messages (otherwise I can easily spend my entire evening replying). Please
raise your issue again if you don't see an answer for it here.

1. Stefano points out that flowmaps (I don't really like this term, a "map"
is more appropriate for state machines, how about flowscript instead?)
should not be considered as ordinary resources, but a separate concept. I
have no issue declaring them in a different way, just to emphasize this
point. So something like

  <map:flowscripts default="calculator">
   <map:flowscript name="calculator" language="javascript">
     <map:script src="calc.js"/>
   </map:flowscript>
  </map:flowscripts>

should be OK. Beside a different name for elements, the fundamental
difference between this syntax and Stefano's is that it allows multiple
files to contain the implementation of a flow script.

Each named flow script declared in <map:flowscripts> could and should be
independent on the others. Each script should have different set of global
variables, which is different from another script, and of course, is
different each user gets his/her own set of values for these variables.

This is an issue today, as it does not really happen. I'm working on solving
it.

2. (Stefano) How to encode the continuation ids.

Stefano would like to have ContinuationURLEncodingTransformer, which takes
care of encoding the continuation id. Sylvain points out that continuation
ids can be passed not only as part of the URL, but also as request
parameter.

I think it makes sense to have a transformer which encodes the continuation
URL. This would make it very easy to change the way the continuation id is
generated, without having to go to each XSP, JSP, whatever and change it.
The transformer would probably work best when the continuation id is encoded
in the URL. When the id is encoded as a request parameter, there will be
some awareness required from the page designer to have this id enclosed
inside a form.

3. (Stefano) Template languages other than XSP to be used with the flow
layer.

This should certainly be possible, I've started with XSP because it was very
easy to get implement. JSP and Velocity should be equally easy to implement
though. We just need somebody to do it ;)

4. Stefano's callPipeline() function. Is this equivalent to
sendPageAndContinue(), which is already implemented in the flow layer? It
essentially allows you to have a page processed through a pipeline, and
continue the execution of the script. BTW, I think your sitemap snippet has
a bug in it, shouldn't it have the <map:match> names swapped?

Also in your callPipeline(), how does the output parameter get used? It
should be the task of the sitemap pipeline where the file is written. Am I
missing something?

5. Ivelin points out the potential of stale continuations.

I think this is indeed a real issue. One way to avoid it is to have
continuations automatically expire after a time of inactivity, or do
deactivate them manually in the flow script. The first approach is something
I considered, and there are some hooks in the current code, but more support
code needs to be written. The second approach can be implemented today: you
can invalidate not only a single continuation, but the whole subtree of
continuations which start from it. You just need to keep a hold on the
continuation at the top of the tree, and invoke invalidate() on it.

6. Multi-page forms are not dominating, and continuation based compared to
even driven (GUI-like) programming approaches.

I used to program GUIs a lot, I think for certain things, event-driven is
better than using continuations. I do think however that continuations have
a place, especially for multi-page forms. Now I think it depends a lot on
the application, whether these forms are prevalent or not.

7. Bruno's question regarding the advantage of flow scripts versus actions.

The advantage would be that with flow scripts you can describe all the
actions in a single flow script, where each action becomes a separate
function. Since these functions share the same global variables, it's very
easy to share data between them. You can share data using the session
object, but with explicit variables is much easier to follow what's going
on.

If you don't care about sharing data between actions, then there's probably
little value describing your action logic in a flow script. Other than the
fact that you don't have to write Java code, which means compile, build war
file, restart tomcat. With flow scripts, you just modify the script file and
resend the request: the script is automatically reloaded and parsed by
Cocoon, there's no need to restart anything.

8. Vadim's idea about making the syntax easier.

I think the idea of having something as simple as:

<map:match pattern="calc/*">
  <map:flow method="calculator" continuation="{1}" />
</map:match>

makes a lot of sense. Using different matchers, the continuation id can be
extracted from the request parameters, cookies, you name it. The only
problem with it is that is a bit inflexible in terms of the URI design. If
I'd like to have calc/kont/*, there's no easy way to specify it.

So I'd say we can have two alternative ways of writing this: using the above
proposal and what is already implemented, for power users that want more
control. How about this?

9. Reinhard asks what happens if two different flow scripts have a function
with a similar name name.

Since the flow scripts have their own variable space (not now due to some
problems in the current implementation), there shouldn't be any problem.
Each flow script can use its own variable and function names, without
worrying about possible conflicts with other scripts.

10. Torsten asks how xmlform/precept could be implemented with flow scripts.

I think the more generic question is how to implement multi-page forms using
flow scripts. It would also be nice if the validation could happen not only
on the server side, but also in the client browser, using JavaScript if
that's available.

Your example would become a lot simpler if you factor out the repetitive
code in a function:

var validator;
var instance;
var prefix;

function wizard(uriPrefix) {
  var id = cocoon.request.getParameter("someid");
  
  var factory = SchemaFactory.getInstance("ns");
  //maybe we can get the schema from a pipeline??
  var schema = factory.compile("someschema.xsd.dtd.rng.sch");
  validator = schema.createValidator();
  instance = new Instance();
  prefix = uriPrefix;

  loadInstance(instance,id);
  
  do {
    showAndValidatePage(1);
    showAndValidatePage(2);
    showAndValidatePage(3);
  } while(!validator.isValid(instance));

  if(saveInstance(instance,id)) {
   sendPage("success.html");
  }
  else {
   sendPage("failed.html");
  }
}

function showAndValidatePage(number)
{
   do {
    sendPage(prefix + "page" + number + ".html");
    Instance.populate(instance, cocoon.request);
   } while(!validator.isValid(instance, "page" + number));
}


Torsten's example uses a heavily xmlform type of approach, where the data to
be validated is kept in a Java object or a DOM tree. This is one way of
doing things; another one would be to use explicit variables which, at the
end of the validation, could be written in the database directly, or used to
construct a object hierarchy which is then saved in the database using JDO,
EJBs or whatever other means. The validation could be done directly in
JavaScript, instead of a Schema approach. The code that does the validation
could then be used on the client side as well.

As Stefano mentioned, the flow layer is an infrastructure which can be used
to create higher level abstractions. Here are some things I am currently
looking at, which can improve the usability of the flow script engine:

- automatic binding of JavaScript variables to form values. This would allow
you to declare something like:

  var username, password;

  // Send a page to collect the user name and the password
  sendPage("login.html");

  // When the user fills in the form and presses the submit button, the
  // script restarts here. The flow engine automatically binds the username
  // and password to the values submitted in the form.

  // make use of username and passwd here

- automatic validation of form values on both server and client side. This
should allow the same piece of JavaScript validation code to be executed
both on the server and client side. More on this later.

11. With respect to how to put a back button on a page, I think I replied to
this some time ago. The idea is to use the <jpath:continuation select="1"/>
which selects the previous continuation.

As I mentioned in some other message, the continuations created during the
execution will form a tree, or a list if the user never presses the back
button and starts on a different path. At any given point you can access the
continuations above you in the tree, which identify the past pages, by using
the "select" attribute in <jpath:continuation>.

12. Torsten: sub-flows, flow-2-flow, what are these? Is assembly of
functions that represent independent flows enough?

13. Piroumian asks how to cancel a continuation.

As I mentioned in several ocasions, sendPage() returns the saved
continuation. If you want to cancel the continuation just invoke on it the
invalidate() method. It will cancel all the receiver and all the
continuations that inherit from it.

14. Another question Piroumian has is how to validate against business
logic. Since JavaScript is tightly integrated with Java, you can call Java
logic from the flow script to do the business logic validation. This way you
can invoke whatever logic you want. If this is too generic, then provide
some use case and I'll try to sketch a solution.

15. Flow management: obtaining a list of all active flows.

All the flows are kept in an array, which is managed by a Cocoon component.
Each flow is a tree of continuations, where each continuation is a
JavaScript object which can be dynamically inspected for properties and so
on.

16. Sylvain: should flow scripts be inherited by sub-sitemaps?

I'm not sure of the security implications of allowing them to be inherited:
what should be the behavior if a developer alters definitions from an
inherited flow script?

17. The proposal to use map:call with "function(arg, arg, ...)".

I think this is more like a syntactic sugar than real value. I don't think
passing arguments via map:param would confuse people, the semantic is still
the same as function invocation.

18. Access to continuations.

I think there is a bit of confusion of terms in this discussion. The
continuation id is passed in the HTTP request in some way or another: as
part of the URL, as a request parameter etc. This encoding should be visible
to the sitemap only. I'd very much like to have it hidden from the view
layer as well, so if we can avoid putting explicit URLs in page templates,
that would be great! This reduces the dependency between the URL design in
the sitemap and the view generation.

A continuation is a real object that lives on the server side, which is
represented by its id in the request. A continuation object is returned by
sendPage(). A continuation id is fairly much useless in a flow script, what
you really need is the continuation object itself, which contains this
information and more.

19. There are some other things that need to be fixed, but the following
item is the biggest one.

Currently the global variable space is shared between _all_ the flow scripts
and _all_ the users. This is clearly wrong, and it will change soon. What we
should have is the global variable space common only to a flow script, and
only to a single user. This has been a challenge so far with the Rhino, but
I think I have a solution for it.

Variables in this global variable space will act as session variables. To
facilitate communication between applications or share constant values
between users of the same application, an application and a global space
will be introduced.

In this new approach, it should be possible to have multiple top level
functions be invoked from the same sitemap, and have them share the same
global variable scope, for a given user. This makes things a lot easier when
programming with the flow layer, as you are not forced to always use
continuations. You can store your application variables as global variables
in a JavaScript script, and have multiple functions operated on them, where
each function is called from the sitemap.

20. My job - thanks Stefano for bringing it up. Here's my shameless plug :)
If you think of using Cocoon for building Web apps or Web services, and you
need support in doing so, I am providing consultancy for doing it, anytime,
anywhere.

Thanks for reading so far,
Ovidiu

-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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

Re: [RT] Flowmaps

[Sylvain Wallez <sy...@anyware-tech.com>]

Stefano Mazzocchi wrote:

>Last time I wrote an RT about these things, the flowmap wasn't
>implemented. Today it's working, but there are things that I would like
>to change.
>
>This RT is to start a discussion that will hopefully lead to a coherent
>and community-driven design on what the flowmap engine will look like.
>
>First of all, since there is no clear howto about the current flowmap
>and I need to give you context in order to make you partecipate in the
>discussion, I'll write a basic explaination of what's going on.
>
>                              - oooo -
>

<snip what="presentation of the flowmap concept"/>

>                              - oooo -
>
>The problems with this approach
>-------------------------------
>
>First of all, let me say that I consider the above concept the biggest
>advancement in server-side web technology since servlets.
>  
>

+1000 ! People to which I explain this at first don't understand it as 
it is "too much simple" : over the years, we have twisted our minds to 
overcome the limitations of the web infrastructure. But once they grasp 
it, they fall on the floor !


>This design not only makes it a breeze to implement MVC, but it shows
>you how natural and clear things become once you separate the procedural
>flow, from the declarative serving of resources.
>
>At the same time, I think there are a number of issues that we might
>solve before freezing the concept in a beta release:
>
>1) the semantics to call a flowmap from a sitemap are too implicit:
>users must assume to much from what they read (ie self-readability of
>the concept is very poor).
>
>2) the concept of continuations is not transparent, there is concern
>overlap between the view designers and the sitemap managers since the
>view designers must be aware of the URI location of the
>continuation-decoding URI.
>
>[NOTE: it is *not* required that you use continuations for your flow
>logic, you can use whatever means you have to control state as you did
>previously, such as REST-like passing style, sessions or cookies]
>
>3) there is currently only one way to implement the MVC "view" and that
>forces you to use XSP. This might not be a performance problem, but it
>might become a usability problem.
>
>Let's talk about each one of them independently.
>
>[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 ;)
In France, we no more have this kind of problem :(

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

> 2) you can have more than one flowmap in a sitemap (then you can define
>a default one or use a 'flowmap' attribute in "map:call" to identify
>which flowmap you are calling)
>
>[of course, in order to accomplish this, the implementation must
>completely isolate the different flowmaps and its global variables]
>
> 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.
>
> 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.5 on this : it introduces some programming language constructs in the 
sitemap. And if this is allowed for flowmaps, why shouldn't it be 
allowed for other components as well, e.g. <map:transform 
type="xslt(use-parameters : true, use-browser-capabilities : false)"/> ?

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

That isn't so easy, as there can be many ways to pass the continuation 
id, and the example shows only one :
- as part of the request URI (as in this example)
- as a request parameter (from a hidden form field)
- in an XML document (SOAP webservices)

So IMHO, encoding and extracting the continuation id is the 
responsibility of the presentation layer and the sitemap.

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

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.

>I'd like to have at least a few others:
>
> 1) XSTL
>
Typo for "XSLT" ?

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

>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.
>
>                              - oooo -
>
>Ok, almost there.
>
>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)
>
>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!
>  
>

The only thing to say is : Way cool !

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

What is missing in the FOM is the component manager that would allow the 
flowmap to have access to Avalon components.

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

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




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

Re: [RT] Flowmaps

["J.Pietschmann" <j3...@yahoo.de>]

Some rather random thoughts:

A flow (workflow) can be represented as a DAG. An edge
in the DAG represents a page sent to the user, and a
certain set of data recieved as a result of a user
action. The same page sent to a user may be part of
many different edges, which are differentiated by the
result data. Whether it is useful to have several
outgoing pages associated with an edge is a matter
of opinion, I'd prefer several, parallel edges instead.

There are several possibilities to describe a DAG
representing a flow:
- Focus on the nodes. Declare the incoming and outgoing
  edges. This is quite similar to the current ssitemap
  approach, with a complex matcher matching potentially
  both on the location part of the URL as well as the
  parameters, then invoking the business logic, and
  finally generating one of many possible output
  pages.
- Focus on the edges. Describe an edge as a pair
  consisting of an outgoing page and a match on the
  result data, rather similar to the description
  above. Declare nodes separately and reference them
  from the edge. There is still the problem of describing
  the selection of the outgoing page, which somehow must
  be attached to the node description.

The conceptual difficulty in either of the approaches
above is that the same outgoing page can be associated
(does "start") several different edges, the real edge
to traverse is only determined after the response from
the user (i.e. the next *request* to the server) has
been matched. Using the same page in the description
for several edges can be seen as introducing redundancy,
therefore declaring them separately and reference them
in the edge description can be useful.

Then there is the problem of a hidden state, for example
whether the user has successfully logged in. While this
is commonly seen as error situation, this formally adds
a huge amount of edges to the flow graph, usually making
it completely incomprehensible.

Each of the approaches has its merits. There are a lot
of degrees of freedom in designing a web application.
It could be useful to fix some choices and see what
can happen to the others.

1. Only a very limited set of push buttons on each page,
as an extreme case, use only an "ok" (think of the
browser's "back" button as "cancel") everything else is
"data" and is handled by lower level application code, not
by the flow description. In this case, there is a one-to-one
mapping from pages to edges, apart from hidden state
concerns. Because the description of the edges is rather
trivial, it makes sense to focus on the nodes.

2. Each nodes generates exactly one page. In this case,
the page selection after the business logic of a node is
performed becomes trivial, and the page can be dropped
from the edge description.

3. Combine 1+2. This gives a linear flow, the simplest
possible flow available. Not very useful in itself but
serves as a base for more complicated patterns.

4. A flow where two edges flow out of each edge (except
the last), one ending in an "cancel node", one ending in
the next node. This is a common pattern in GUI "wizards",
especially if you allow for expanding nodes into sub-flows.
This means two buttons per page "ok" (next node) and
"cancel" (the whole task so far).
Node and edge description is still simple, provided the
"cancel node"  for the whole flow is specifically marked.

5. Additionally to 4, edges which bent back to the node
where they come from. Something like "reenter or complete
data". These edges can be implicitely added, because there
is only one edge and one page coming from another node
to the actual node, so resending it is trivial.

6. Sub-flows. If a sub-flow exits for whatever reason,
the or one of the edges flowing out of the parent node
of the sub-flow is activated.

Designing and describing a general flow is far from trivial.
Well, workflow applications/toolkits usually come with a
graphical designer.

UML provides two diagrams for expressing some sort
of flows: state diagrams and activity diagrams. The
latter are meanwhile quite often used for designing
workflows, or flows of objects, or whatever similar
concept one likes to discuss.

There is an open source UML editor, ArgoUML, they
support activity diagrams, it is Java, and the model
is saved as XMI, which is XML of course. Perhaps
this could be taken advantage of?

J.Pietschmann


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

Re: [RT] Flowmaps

[Ivelin Ivanov <iv...@apache.org>]

Reinhard Poetz wrote:
> 
> +10
> very important because I think that many people (and me too) don't like XSPs

I'm not an XSP fan either.

> 
>>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
> 
> 
> +1
> 
> and ...
> with the same concept we can implement validation in XMLForms if you need
> access to your backend for this purpose because xml-schemes are not powerful
> enough
> (e.g. a customer wants to book a hotel room and you have to check before
> confirming the reservation whether the room is still available)

Can you elaborate some more on this idea.
I didn't undertand Stefano's thought on input/output either.
It appeared that the function was recursively calling the pipeline which
called the function in the first place.




-- 

-= Ivelin =-


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

RE: [RT] Flowmaps

[Reinhard Poetz <re...@gmx.net>]

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

What happens if you define two (or more) functions with the same name
expecting the same parameters in the same or in different flowmaps?


> The problems with this approach
> -------------------------------
>
> First of all, let me say that I consider the above concept the biggest
> advancement in server-side web technology since servlets.

I'm really impressed too! Thank you Ovidiu!!!

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

+10
very important because I think that many people (and me too) don't like XSPs


> 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

+1

and ...
with the same concept we can implement validation in XMLForms if you need
access to your backend for this purpose because xml-schemes are not powerful
enough
(e.g. a customer wants to book a hotel room and you have to check before
confirming the reservation whether the room is still available)


Regards,
Reinhard


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