You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by ov...@apache.org on 2002/02/28 02:33:09 UTC
cvs commit: xml-cocoon2/src/scratchpad/schecoon/webapp/docs index.xml
ovidiu 02/02/27 17:33:09
Modified: src/scratchpad/schecoon/webapp/docs index.xml
Log:
Added short description on continuations.
Revision Changes Path
1.2 +82 -13 xml-cocoon2/src/scratchpad/schecoon/webapp/docs/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/src/scratchpad/schecoon/webapp/docs/index.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.xml 10 Jan 2002 05:21:25 -0000 1.1
+++ index.xml 28 Feb 2002 01:33:09 -0000 1.2
@@ -3,20 +3,89 @@
<document>
<body>
- <s1 title="A new Cocoon sitemap implementation">
- <p>This page describes a new implementation of Cocoon's sitemap
- which dramatically increases Cocoon's start-up speed and the
- turnaround development time when writing applications using
- Cocoon.</p>
-
- <p>The new sitemap implementation reads the sitemap at runtime
- and translates its XML format into a program written in the
- algorithmic language <link
- href="http://www.schemers.org/">Scheme</link>. Each time you
- make a new request to Cocoon, the Scheme program representation
- of the sitemap will be executed.</p>
+ <s1 title="Schecoon - Cocoon with control flow">
+ <p>Schecoon is an attempt to add advanced control flow
+ capabilities to Cocoon. Control flow is usually referred to as
+ the ability to describe the order of Web pages that have to be
+ sent to the client, at any given point in time in an
+ application.</p>
+
+ <p>Traditional Web applications try to model the control flow of
+ a Web application by imagining the application as a finite state
+ machine (FSM). For a client, the application can be only in one
+ state at a time. Any request the client sends to the application
+ makes it transition in a different state. As a side-effect of
+ this transition, the application may update internal data,
+ either in memory or in the database. The response to this
+ transition is a Web page that's sent back to the client.</p>
+
+ <p>For simple Web applications, this model works fine. However,
+ as the application grows, the number of states and transitions
+ between them grows as well, and it becomes hard to visualize
+ what's happening in the application.</p>
+
+ <p>Moreover, the interactions in some applications are more
+ complex than a simple finite state machine. In such cases it's
+ much easier to think and implement the application as a program,
+ rather than a FSM.</p>
+
+ <p>By using a high level programming concept called
+ <em>continuations</em>, Schecoon tries to solve this problem,
+ and promises to allow the control flow in Web applications to be
+ modeled as a normal program.</p>
+
+ <s2 title="What are continuations?">
+
+ <p>A continuation is a way to represent what is the processing
+ that still needs to happen. Think of a continuation as an
+ object that, for a given point in your program, contains a
+ snapshot of the stack trace, including all the local
+ variables, and the program counter. You can not only store
+ these things in the continuation object, but also restore the
+ execution of the program from a continuation object. This
+ means that the stack trace and the program counter of the
+ running program become the ones stored in a continuation.</p>
+
+ <p>By resuming the processing stored by a continuation object,
+ you essentially resume the program from the point it was
+ stopped. This allows you to write programs that do something
+ like this:</p>
+
+ <source><![CDATA[
+ // some processing going here
+ ...
+-> send-page("response.xml");
+ ...
+ // some other processing here
+ ...
+]]></source>
+
+ <p>With continuations in the language, you can essentially
+ store the continuation of <code>send-page</code> (think of all
+ the stack trace, and the program counter), put it in a global
+ hash table associated with an id. The id is then encoded in
+ the <code>response.xml</code> page as an URL. When the user
+ clicks on that URL, on the server side the associated
+ continuation is resumed. Resuming the processing happens as if
+ nothing was stopped, you get all the stack trace back, and all
+ the local variables.</p>
+
+ <p>So instead of using beans to store things in session, you
+ use normal variables in a program. Since each user has its own
+ version of the program, all the local variables in the program
+ are separate between users.</p>
+
+ <p>With this approach clicking the <em>Back</em> button in the
+ browser is no longer a hassle to deal with for you as a
+ server-side programmer. They will simply refer to past
+ continuations objects, which have their own state of the local
+ variables.</p>
+
+ <p>Since continuations are objects, you can also store them in
+ a database, for really long-lived session, just like you do
+ with session beans.</p>
+ </s2>
- <p>More to come...</p>
</s1>
</body>
</document>
----------------------------------------------------------------------
In case of troubles, e-mail: webmaster@xml.apache.org
To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org