cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: AJAX and Cocoon - Design Patterns
Date Tue, 04 Oct 2005 13:21:33 GMT
Johannes Textor wrote:

>>Doesn't this mean writing a full-blown App in Javascript? 
>>    
>>
> 
>Yes, an AJAX-Client (as I see it) is esentially a full-blown App in 
>JavaScript. Think about the classic examples, Google Mail and Google Maps. 
>They provide a stunning user experience - but they are written in 
>Cross-Browser JavaScript. This may sound worse than it actually is, but 
>it's still no way an "easy-and-fun" task.  
> 
>But given that AJAX is more than just a hype, we'll have to adapt to it. 
>There are already AJAX capabilities in Cocoon like the new "ajax=true" 
>thingy in CForms, but as I see it this does not go far enough. Cocoon is a 
>server-side framework. IMHO, a forms framework like CForms is obsolete in 
>an AJAX setting - AJAX forces us to *rethink the way we think about web 
>applications*. Does this sound familiar ? There is a popular web framework 
>which used that slogan some time ago ... 
>  
>

I disagree with the statement that Ajax makes CForms obsolete. Even with 
Ajax, you still need to input some data, validate it and relate it to 
back-end data.

Now the way we interact with forms will change, and rather than filling 
everything and submitting to see what is wrong, we will want validation 
to happen on the fly.

The current Ajax support in CForms provides a much better experience on 
complex forms (e.g. repeaters) than what we have with full-page reload. 
And we must go more far in this direction, by sending individually input 
to the server for validation each time it has changed. A prototypic 
Google-suggest like autocompletion is also available in the SVN since 
last week.

>>No more re-use of actions, transformations, pipelines, ...? 
>>No more Lego bricks to build an App? 
>>    
>>
>As Derek said, actions, transformations and pipelines, the basic 
>components of cocoon, would still play the same role in an AJAX setting. 
>But some parts, like CForms and Flowscript, will probably not, at least in 
>my opinion. If page flow control is moved to the client, why use 
>flowscript? If a "form", aka single HTML page with a "<form>"-tag in it, 
>is no longer the predominant way to receive info from the client, because 
>it happens by background HTTP requests pre-processed by the client, why 
>use CForms?
>  
>

Continuations still have an important role to play, as they track user 
interaction through a set of "screens" (let just not call them pages, as 
the interaction can occur in an area of the page). Now what will change 
with Ajax is that you may have several continuations running 
concurrently in a single page, possibly interacting.

>>Are there tools and libraries to support this task? 
>>    
>>
> 
>Yes there are - but they are out of Cocoon's scope, since Cocoon, as I see 
>it, is a *server side* framework, and AJAX is a *client side* technique. 
>There are initiatives popping out to make AJAX programming more 
>comfortable, like the drag & drop - libarary at 
>http://www.walterzorn.de/dragdrop/dragdrop.htm, or the OpenRico library at 
>http://openrico.org/rico/home.page but I'm getting OT.
>

For the record, Ajax support in CForms is now powered by Scriptaculous 
(http://script.aculo.us).

>For us as deveolopers, there is a downside about the AJAX thing - until 
>now, "Web application" basically meant "set of interacting HTML forms with 
>a client-server trip at each step". Now things have become much more 
>complicated - and fun - so it will be hard to come up with *the* framework 
>for building AJAX apps, like there isn't *the* framework for building X11 
>apps.  
> 
>My impression is that Cocoon fits in well, just maybe we will no longer be 
>doing *everything* with it (like page flow control), but put more weight 
>to the client in the client-server setting.
>  
>

Where Cocoon can shine IMO with Ajax apps is that a website (not 
necessarily a webapp) is often split into several subpipelines that are 
aggregated. With Ajax, each of the areas that are normally aggregated in 
a full-page rendering model live their lives separately. What that means 
is that those pipelines that use to be internal-only will now be used 
both by the full page rendering (for the first page display or non-Ajax 
browsers) and for individual Ajax updates.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message