On Sun, 9 Dec 2001 17:06:44 +0100 (CET), Torsten Curdt <[EMAIL PROTECTED]> wrote:
> On Sun, 9 Dec 2001, Steven Noels wrote: > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > Sent: zondag 9 december 2001 1:07 > > > To: Berin Loritsch > > > Cc: [EMAIL PROTECTED]; Michael Hartle > > > Subject: Re: [RT] Managing Flow and Resources > > > > > Regarding the XML syntax of the sitemap, I actually believe it's a lot > > > easier if we just have the sitemap written in Scheme, instead of > > > XML. We can add new stuff much more easily than trying to invent a > > > syntax in XML. Here's how a sample sitemap would look like in the > > > Scheme syntax: > > > > > > (sitemap > > > (define-pipeline docbook-html (dir filename) > > > (generate (concat dir filename)) > > > (xslt "docbook-html.xsl")) > > > > > > (match "/myapp/*/*.xml" > > > (pipeline docbook-html)) > > > > > > (match "/app2/*/*.pdf" > > > (pipeline > > > (generate (concat dir filename)) > > > (xslt "docbook-html.xsl"))) > > > ) > > > > > > "sitemap" above is just a Scheme function that reads its arguments and > > > generates another function to match a request against the specified > > > patterns. Another side-effect of executing "sitemap" is that all the > > > "pipeline" functions will setup in the Java space the transformers > > > objects according to the description. The serialization process could > > > be added automatically by the "match" functions, if no serializer has > > > been defined. Similarly one can think of lots of possible semantics > > > associated with the above description. > > > > uh oh... > > > > One of the great features of the current Cocoon2 distribution *is* the > > XML-syntax of the sitemap, even at its DTD/Schema-less state. Although I like > > the usage of Rules-based engines to drive dynamic execution paths, I do not > > see why we need YAS (Yet Another Syntax) to configure Cocoon. > > +10 > > Let's stay with the XML syntax! Otherwise would be a step backwards! > Maybe we can work out a different way to combine the current sitemap > with the new flow managing. 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. > 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. 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. 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}); } 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. 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. Best regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://orion.nsr.hp.com/ (inside HP's firewall only) http://sourceforge.net/users/ovidiu/ (my SourceForge page) http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
