AJAX and Cocoon - Design Patterns

[Johannes Textor <jc...@gmx.de>]

Hi everybody,

I have some thoughts about Cocoon and AJAX that I want to share with
you. They are somehow related to the "Is cocoon obsolete?"-thread on the
dev list, but I think users also should express their opininons :) To
sum it up, it has come into my mind that AJAX strengthens the "classic"
Cocoon component approach, while somehow it does not fit up well with
the Flowscript - JX Template - Hibernate/Spring/OJB/whatever pattern.
Let me explain.

I have put into production quite a few Cocoon based websites and also a
more complex intranet knowledge base application, most of them used
Hibernate to complement Cocoon in the "M" part of "MVC", while relying
on Java Classes and Flowscript for the "C" part, JX Templates + XSLT for
the "V". Though it took me some time to get into it, I am now
comfortable with this way of building web apps. I also use CForms for
data manipuation, even though I frankly do not like it very much, it's a
little to bloated for my taste. And now the AJAX hype dropped in ...

I was absolutely excited about the whole AJAX stuff and decided to give
it a try and use it in my next cocoon based project. Now there was a
small dilemma: What I had started to like most about Cocoon, i.e. the
Flowscript/Java/CForms approach, now suddenly seemed a little obsolete
since all the user interaction was taking place on the client. No more
need for continuations - no more need for server-side validation - all
that stuff was done in the client, who would send CRUD - requests  to
the server side. Here, I only needed to make sure the user was
authenticated and the requested transaction was valid, and then execute
it. So no more multi-page transactions that were so fun and easy with
flowscript.

So I remembered the good old days of writing custom Generators and
Actions in Java - and a design pattern came into my mind that would fit
my needs quite well. Have a look at an example pipeline:

<map:match pattern="article-edit">
  <map:act type="article-edit">
    <map:generate type="article" label="xml" />
    <map:transform src="stylesheets/artikelxml2html.xsl">
    <map:serialize type="xhtml" />
  </map:act>
  <map:serialize type="xml" />
</map:match>

The action executes CRUD operations. The custom generator produces SAX
events from the DB. The view is an exit point for the AJAX client who
needs the XML representation of the data. The XHTML fragments are also
used by the AJAX client to render the view (no client-side XSL processing).

So, I get everything I need from one single pipeline:

- Handling CRUD operations
- XML Data representation
- XHTML Data view

However, application flow control has moved to the client, so there is
suddenly no more need for flowscript and friends. Everything gets
simpler (on the server side) and nicely fits into the "classic" cocoon
concepts (I remember some weeks ago there was a thread about if actions
were still recommended).

So I am curious: How are your experiences with Cocoon and AJAX ? Did you
try something familiar ? What is your pattern for designing
Cocoon/AJAX-Applications ? Do you also feel the new way of building web
apps is questioning some essential parts of Cocoon ? I would appreciate
any comments.

Regards,
Johannes







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

Re: AJAX and Cocoon - Design Patterns

[Ralph Goers <Ra...@dslextreme.com>]

Johannes Textor wrote:

>Hi Ralph,
>
>  
>
>>Johannes,
>>If you actually do this you will be creating a website with a big
>>security hole.  Anyone would be able to send fake requests to your
>>server with bogus data.  Client side validation is nice - it gives a
>>faster response to the user and does take a load off the server as
>>only valid requests SHOULD make it to the server.  However, the server
>>must still also perform data validation as someone could log in and
>>then start sending bogus requests to you.
>>    
>>
>
>I see your point, but the mentioned pipeline resides in a subdirectory
>which is protected via the authentication framework. Furthermore, all
>requests are checked for integrity and validity before execution (in the
>custom actions), to avoid data loss in case that something weird happens
>on the client side. So I think this is no less secure than CForms
>validation, for example.
>
>Regards,
>Johannes
>
>  
>
No, it certainly doesn't have to be CForms validation.  But it sure is 
nice when the validation on the client side and on the server side are 
done using a common set of definitions. By this I mean that you can 
define a single set of validation criteria that is used to generate 
whatever validation is performed both client side and server side.  So 
if you have to add a new parameter you can just add it in one place and 
there is no danger of the client and server getting out of sync.

I have found that Cocoon is most helpful in that kind of scenario as you 
can use a common generator with different transformers.

Ralph

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

Re: AJAX and Cocoon - Design Patterns

[Johannes Textor <jc...@gmx.de>]

Hi Ralph,

> Johannes,
> If you actually do this you will be creating a website with a big
> security hole.  Anyone would be able to send fake requests to your
> server with bogus data.  Client side validation is nice - it gives a
> faster response to the user and does take a load off the server as
> only valid requests SHOULD make it to the server.  However, the server
> must still also perform data validation as someone could log in and
> then start sending bogus requests to you.

I see your point, but the mentioned pipeline resides in a subdirectory
which is protected via the authentication framework. Furthermore, all
requests are checked for integrity and validity before execution (in the
custom actions), to avoid data loss in case that something weird happens
on the client side. So I think this is no less secure than CForms
validation, for example.

Regards,
Johannes


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

Re: AJAX and Cocoon - Design Patterns

[Ralph Goers <Ra...@dslextreme.com>]

Johannes Textor wrote:

>I was absolutely excited about the whole AJAX stuff and decided to give
>it a try and use it in my next cocoon based project. Now there was a
>small dilemma: What I had started to like most about Cocoon, i.e. the
>Flowscript/Java/CForms approach, now suddenly seemed a little obsolete
>since all the user interaction was taking place on the client. No more
>need for continuations - no more need for server-side validation - all
>that stuff was done in the client, who would send CRUD - requests  to
>the server side. Here, I only needed to make sure the user was
>authenticated and the requested transaction was valid, and then execute
>it. So no more multi-page transactions that were so fun and easy with
>flowscript.
>  
>
Johannes,
If you actually do this you will be creating a website with a big 
security hole.  Anyone would be able to send fake requests to your 
server with bogus data.  Client side validation is nice - it gives a 
faster response to the user and does take a load off the server as only 
valid requests SHOULD make it to the server.  However, the server must 
still also perform data validation as someone could log in and then 
start sending bogus requests to you. 

Ralph

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

Re: AJAX and Cocoon - Design Patterns

[Lars Huttar <la...@sil.org>]

Johannes Textor wrote:

>Hi everybody,
>
>I have some thoughts about Cocoon and AJAX that I want to share with
>you. They are somehow related to the "Is cocoon obsolete?"-thread on the
>dev list, but I think users also should express their opininons :) To
>sum it up, it has come into my mind that AJAX strengthens the "classic"
>Cocoon component approach, while somehow it does not fit up well with
>the Flowscript - JX Template - Hibernate/Spring/OJB/whatever pattern.
>Let me explain.
>
>I have put into production quite a few Cocoon based websites and also a
>more complex intranet knowledge base application, most of them used
>Hibernate to complement Cocoon in the "M" part of "MVC", while relying
>on Java Classes and Flowscript for the "C" part, JX Templates + XSLT for
>the "V". Though it took me some time to get into it, I am now
>comfortable with this way of building web apps. I also use CForms for
>data manipuation, even though I frankly do not like it very much, it's a
>little to bloated for my taste. And now the AJAX hype dropped in ...
>
>I was absolutely excited about the whole AJAX stuff and decided to give
>it a try and use it in my next cocoon based project. Now there was a
>small dilemma: What I had started to like most about Cocoon, i.e. the
>Flowscript/Java/CForms approach, now suddenly seemed a little obsolete
>since all the user interaction was taking place on the client. No more
>need for continuations - no more need for server-side validation - all
>that stuff was done in the client, who would send CRUD - requests  to
>the server side. Here, I only needed to make sure the user was
>authenticated and the requested transaction was valid, and then execute
>it. So no more multi-page transactions that were so fun and easy with
>flowscript.
>
>So I remembered the good old days of writing custom Generators and
>Actions in Java - and a design pattern came into my mind that would fit
>my needs quite well. Have a look at an example pipeline:
>
><map:match pattern="article-edit">
>  <map:act type="article-edit">
>    <map:generate type="article" label="xml" />
>    <map:transform src="stylesheets/artikelxml2html.xsl">
>    <map:serialize type="xhtml" />
>  </map:act>
>  <map:serialize type="xml" />
></map:match>
>
>The action executes CRUD operations. The custom generator produces SAX
>events from the DB. The view is an exit point for the AJAX client who
>needs the XML representation of the data. The XHTML fragments are also
>used by the AJAX client to render the view (no client-side XSL processing).
>
>So, I get everything I need from one single pipeline:
>
>- Handling CRUD operations
>- XML Data representation
>- XHTML Data view
>
>However, application flow control has moved to the client, so there is
>suddenly no more need for flowscript and friends. Everything gets
>simpler (on the server side) and nicely fits into the "classic" cocoon
>concepts (I remember some weeks ago there was a thread about if actions
>were still recommended).
>
>So I am curious: How are your experiences with Cocoon and AJAX ? Did you
>try something familiar ? What is your pattern for designing
>Cocoon/AJAX-Applications ? Do you also feel the new way of building web
>apps is questioning some essential parts of Cocoon ? I would appreciate
>any comments.
>
>  
>
We haven't tried anything as sophisticated as what you've done. We also 
haven't "moved up" to using Flow / CForms / JXTemplates.
We've been using good old traditional Cocoon components like XSP/ESQL, 
and we found it pretty easy to fit simple AJAX features (asynchronously 
fetching a list of choices for a dropdown) into that framework.

Lars




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