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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
