Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 67444 invoked by uid 500); 16 Jun 2002 20:23:17 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 67433 invoked from network); 16 Jun 2002 20:23:17 -0000 Message-ID: <3D0CF240.7070606@apache.org> Date: Sun, 16 Jun 2002 15:17:04 -0500 From: Ivelin Ivanov User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT] Flowmaps References: <3D0CB445.6D832A1C@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > c) the sitemap executes the "getNumberA.xsp", which is given by > > language="java" > xmlns:xsp="http://apache.org/xsp" > xmlns:jpath="http://apache.org/xsp/jpath/1.0" > > > > > > > > > What if this is represented by: Enter Value For A number A Enter 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: > > > > > > 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