Torsten Curdt wrote:
>>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 :-\
I think this has much to do with terminology. Web administrators
and designers do not think in terms of finite state machines. If
they have any concept of programatic logic, it is expressed in terms
of XSLT or CFML, or something similar. Really simple. One way of
restating the above example in XML is:
<functions>
<function name="addNumbers">
<send-response page="first-page.xml" pipeline="my-pipeline"/>
<call-action name="getFirst"/>
<send-response page="second-page.xml" pipeline="my-pipeline">
<parameter name="first" value="{first}"/>
</send-response>
<call-action name="getSecondResult"/>
<send-response page="third-page.xml" pipeline="my-pipeline">
<parameter name="result" value="{result}"/>
</send-response>
</function>
</functions>
Note the same feel as the other text, but we are using actions as
they are meant to be used, as will as passing variables in the
sitemap centric way.
Notice though in this case all the <send-response> tags use the
same pipeline?
This is typical of the majority of the cases, therefore it can
be simplified even more:
<functions>
<function name="addNumbers" pipeline="my-pipeline">
<send-response page="first-page.xml"/>
<call-action name="getFirst"/>
<send-response page="second-page.xml">
<parameter name="first" value="{first}"/>
</send-response>
<call-action name="getSecondResult"/>
<send-response page="third-page.xml">
<parameter name="result" value="{result}"/>
</send-response>
</function>
</functions>
That way, if any particular <send-response> wanted to override
the default, they would include a "pipeline" attribute on that
instance. However, this does bring up a valid point about the
pipelines as they stand:
It would be great to have valid pipelines that do not specify
the source document in the generator. In other words, the valid
pipeline would say use a "FileGenerator" through an "XSLTTransformer"
with stylesheet X through an "HTMLSerializer".
Notice that the "FileGenerator" does not have a source property.
In the concept outlined here, we specify the source or page in
the <send-response/> tag. This is an important distinction so that
we can have re-usable pipelines.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
