Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4391EA1E.8060404@apache.org>
Date: Sat, 03 Dec 2005 19:55:26 +0100
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Thunderbird 1.5 (Macintosh/20051025)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT][long] Cocoon 3.0: the necessary mutation
References: <43908B84.7070909@apache.org> <4391DD5B.9080703@apache.org>
In-Reply-To: <4391DD5B.9080703@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
> [snip]
>
>> Tell me your thoughts. Am I completely off-track, or do you also want 
>> to build this great new thing?
>
> Well, I've always been against dynamic pipelines and content-aware 
> selection. But yes, I've changed my mind.
>
> scripted sitemap, pull-driven events, dynamic pipelines, yes, it's 
> time for those.

Great :-)

> Not sure I understand what you mean by flow.sendMultiple() though. can 
> you explain in more detail what you mean there?

This is useful in Ajax apps when a user action requires several 
different pages to be updated. Right after I sent the RT, I found a blog 
entry about the exact same use case I outlined[1].

In many use cases, there are several semi-independent areas in a page. 
By semi-independent, I mean that a user action in an area can, but not 
always, have an impact on what should be displayed in another area.

In the shopping cart example, there's the catalogue area and the cart 
area. When you browse the catalogue, no need to redisplay the cart. But 
when you click "add to cart", you need to update both areas: the cart 
because its content has changed, and the catalogue to outline the chosen 
item and update the available stock.

The knowledge of what areas are to be redisplayed is at the controler 
level, e.g. in the "addToCart" flowscript function. So the idea is to 
send back to the client a kind of multi-part response, each part being 
used to update an area of the browser page.

Technically, this can be implemented by a generator that spits out a 
list of <xi:include src="cocoon:/blah"/> to an XInclude transformer, 
that will then call the individual pipelines for each of the updated 
parts. But that is really overly complicated, hence the idea to allow 
the controller to define this multipart response, and this 
flow.sendMultiple() method.

The content of this response will actually be the same as what comed 
back to the browser with CForms in Ajax mode: a list of <bu:replace 
id="foo"> instructions, that the client-side JS places in the 
appropriate locations.

Hope this is clearer.

Sylvain

[1] 
http://scottraymond.net/articles/2005/12/01/real-world-rails-rjs-templates

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director