cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: AJAX and Cocoon - Design Patterns
Date Mon, 10 Oct 2005 14:03:52 GMT
Johannes Textor wrote:

>(anybody else unable to post to users@ from certain accounts?)

Use to send from different 
accounts without receiving the list on these accounts.

>Sylvain Wallez schrieb:

>>>Let's consider an example. In a CMS application, you may have an
>>>htmlarea containing a document and some "dialogs" to add various
>>>things in the document. Among them you can have a dialog for adding an
>>>image. This is group of related fields, including the image path, an
>>>alternate text and some optional width and height information. Now
>>>this group impacts the document only when the group is valid. This
>>>mean that you can have a form for the image dialog, and have the image
>>>actually added to the document when the image form is fully validated.
>>>So the Ajax model means a different approach to form definitions.
>>>Rather than having large forms defining each and every possible imput
>>>on a page, you will have smaller forms, invoked only when the "page"
>>>needs them. That's what I meant with having several interaction flows
>>>running concurrently withing the same page.
>I think I got your point. Morevorer, In an AJAX application, many forms
>might be already preloaded in the background, without actually being
>used until the user "activates" them (e.g. by selecting a menu item). It
>would be certainly impractical to define all those "input areas" in one
>single CForms definition. Of course we could emulate such behaviour now
>by placing each form in a seperate IFrame ... but the more critical
>point is the "multi"-interaction tracking as you pointed out. It does
>not fit the classical, linear interaction model of flow script well.
>Users might type some input in one area, try to submit, get a validation
>error, but then switch to another area. We should be able to track each
>input area seperately ... but this is the kind of work I would now move
>to the client, for a lack of better ideas, and since it somehow feels
>like UI logic to me.

Flowscript doesn't imply linear interaction model. I did some cool 
things by using the fact that continuations are managed in a tree, and 
that flowscript variables are shared by all continuations that are 
created after the point where the variable is defined. This allows to 
define a shared state at the beginning of a non-linear interaction that 
all actions (continuation branches) can read and update when needed.

>But if there was a way to use CForms in a service-call-like fashion,
>(e.g. call form rendering service, which returns xhtml you can place in
>a div - call validation service - call data update service which implies
>validation service - and so on), as such somehow decoupling the form
>object form interaction flow, this would still seem nice to me ...

How is that different from what CForms currently provide, with the only 
changes that it is displayed in a div rather than the full page?


Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message