> OK, we'll stay with the XML syntax for the sitemap.
>
> > I'd also like to see the flowmap to have XML syntax. I'm still dreaming
> > of developing some visual tools for editing this stuff. This would
> > be WAY easier when everything is XML based!!
>
> The flowmap is actually nothing more than a program that drives the
> navigation between pages. Because of that a programming language is
> much more natural to express the logic, than XML.
But isn't the sitemap (at least in some parts) programming, too?
"programming in XML" - does it really taste so bad?
IMHO it depends on the level of abstraction.
Question is: do we want to express the logic in a component based
approach like the sitemap does or do we want a full blown scripting
language where we can do everything we want?
If we have a set of well defined components to express the flow
we could stay with XML. If not XML wouldn't make much sense
here. So _this_ is the question that really relates to the question
of XML syntax.
How much freedom in terms of program logic do we really need
to give inside the flow? That's what we should decide first.
Is it really necessary to have this way of scripting if we also
have actions? What about calling actions from the flow? Can't
_they_ do the dirty work where programming is really needed?
In cocoon everything is XML to the bone. Do we really want to give
this up? There is already a sitemap editor at sourceforge. We could
have flowmap editor then, too. If we say flow is completely scripting
this will not happen.
And don't get me wrong I don't want to be the stopper saying "no,
that's new" - but I'm trying to ask some (maybe) unpleasant questions
just to make sure we are going the right direction.
Although I often wished to have scripting for exactly what seems
to became reality now - I am a bit reserved.
> > Ovidiu, could you give a more complete example how these implicit
> > flow definition could look like for a more complex multipage form?!
> > (I'm still sceptic about this approach - still like the turing machine)
>
> Here's a simple example adapted from one of the papers I pointed
> to. I'm using a syntax more familiar, not actual Scheme.
When really talking about scripting I guess I'd prefer to
see JavaScript as scripting language. I bet this would be quite pleasing
for webapp/website builders...
> In this example you have three pages. The first page prints some text
> and asks for the first number. The second page prints out the first
> number obtained from the first page, and asks for the second
> number. The third page displays the two numbers and the result.
>
> The text for each page is written in three different XML files. Each
> file is processed through a pipeline that takes the XML doc and
> generates the output. The send-response() function is responsible for
> doing this processing. It takes the page to process, the pipeline name
> that processes the page, and an optional data structure that contains
> data which could be used to generate the pages.
>
> The send-response function is special. After it sends the response to
> the client, it suspends the execution of the thread serving the
> request. Before doing this, it stores the continuation of the
> procedure in an internal hash table. This hash table contains as keys
> URLs, and as values continuation objects. When a particular URL is
> invoked, the Scheme engine obtains from the hash table the
> continuation object and executes it. The net effect is that the
> suspended function continues the execution right were it was.
This is again one thing that scares me ... how will this thing
scale!? A whole thread for a person - waiting for the next one?!
> To be able to correctly specify in the generated HTML pages what is
> URL to invoke next, send-response() makes available to the pipeline
> the continuation URL. During the processing of the file, various
> transformers can make use of this URL to embed it in the generated
> result page.
>
> To be able to incorporate URLs to older points in the processing, the
> send-response() function could return as value an object that contains
> the URL to its continuation. You can pass this URL in the optional
> dictionary, as an additional argument, if you wish so.
>
> function addNumbers(HttpRequest request)
> {
> send-response("first-page.xml", "my-pipeline");
> first = request.getIntParameter("first");
> send-response("second-page.xml", "my-pipeline", {"first" = first});
> second = request.getIntParameter("second");
> result = first + second;
> send-response("third-page.xml", "my-pipeline", {"result" = result});
> }
Hmm... ok let's try with XML:
<flow starts-with-state="first">
<states>
<state id="first" uri="first-page.xml"/>
<state id="second" uri="second-page.xml"/>
<state id="third" uri="third-page.xml"/>
</states>
<transitions>
<transition id="goToSecond">
<action type="RequestParameter">
<parameter name="first"/>
</action>
<next-state id="second">
<parameter name="first" value="{first}"/>
</next-state>
</transition>
<transition id="goToThird">
<action type="RequestNumbers">
<parameter name="first"/>
<parameter name="second"/>
</action>
<action type="addNumbers">
<parameter name="first" value="{first}"/>
<parameter name="second" value="{second}"/>
</action>
<next-state id="third"/>
<parameter name="result" value="{result}"/>
</next-state>
</transition>
</transitions>
</flow>
Hm.. I have to admit your example feels much more natural :-\
> In this example each send-response has its own URL. The default URL
> which selects the addNumbers() function is specified in the
> sitemap. The newly generated URLs for each send-response() function
> have unique URLs, which possibly are derived from the initial URL
> (still need to decide on the format).
>
> If the user uses the back button in the browser, he/she will select a
> page that has URL pointers to old continuations. When the "submit"
> button is pressed, the user effectively selects an old continuation
> object, at a point in the program that was executed in the past.
But you don't want to have a thread per continuation object, don't you?
I wonder if it would be possible to see a continuation as a little VM
that has an evirionment (registers etc.) and a programm pointer.
If we could only safe those information (the environment and the
position inside the continuation). I bet this would be more scaleable...
(or did you take this approach for granted ;)
> You can control for how long the continuations are kept around, aka
> for how long you allow the user to go back in the processing, by
> simply modifying the continuation object. We can specify a default
> timeout for all the continuation objects which are created, and have a
> function that modifies this default.
>
> Here's an example of how one can change the expiration time of a
> continuation:
>
> set-default-expiration (60m); // Set expiration time to 60 minutes
> continuation = send-response("some-page.xml", "some-pipeline");
> continuation.setExpire(0); // Expire it now!
>
> The above example was a very simple, and doesn't justify why one would
> use continuations instead of describing the flow in a FSM, or even
> spreading the logic across multiple pages.
>
> However the language you implement the page flow into is complete: it
> has loops, conditionals etc. You can implement as complex of a logic
> you want, depending either on the values of parameters present in the
> request, or on values obtained from your low-level logic. The language
> also allows you to call arbitrary Java objects, which implement the
> logic of your application.
>
> I hope this example makes you understand why this approach is much
> easier to implement Web applications. I'm sure many of the things I've
> described above may change over time, as we implement things, expose
> it to users, and get more feedback on useful things to have. So don't
> take things too literaly, I've just tried to give you a taste of the
> idea.
You are for sure tempting me :)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
