Re: TR: How to develop a web application with Cocoon

[Bertrand Delacretaz]

On Friday 08 November 2002 15:51, [EMAIL PROTECTED] wrote:
>. . .
> Is this scenario completely crazy and out of reality or not??
>. . .

That's how I would do it, but I haven't had the opportunity to test this 
concept IRL yet. Does anyone have a firsthand experience?

-Bertrand

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: TR: How to develop a web application with Cocoon

[Sylvain.Thevoz]

Yes, the concept is very interesting.

It appears very clean and simple but the difficulty is now to translate it in 
pipelines and Cocoon concepts.

So imagine that I would use Cocoon as front-end (FE) and java classes with database 
mapping tool as backend (BE) instead of Cocoon
If I have understood (and from the Cocoon point of view):

1. user submits an HTML form (newCustomer.html) to FE with request parameters 
firstname, lastname and operation. This HTML form is produced by a Cocoon pipeline 
when the user request it. When the submit is done... 

2. ...a second Cocoon pipeline is called to collect the data and to relays it to BE 
(using WebServiceProxyGenerator or another): a java class that store the data in 
database is called.

3. this java class carry out some operations to store data or other things and returns 
some feedback.

4. the second pipeline (FE) receives the feedback (using WebServiceProxyGenerator or 
another) and finally convert it to HTML to display the result of the action.

Is this scenario completely crazy and out of reality or not??
Are there another solutions?
What do you think about?

Thank you
Sylvain

-Message d'origine-
De: Bertrand Delacretaz [mailto:bdelacretaz@;codeconsult.ch]
Date: vendredi, 8. novembre 2002 14:21
À: [EMAIL PROTECTED]; Thévoz Sylvain, IT-DCS-CPS-CLI-DAR
Objet: Re: TR: How to develop a web application with Cocoon


(note: please use reply-to instead of creating new messages when replying, to 
avoid breaking the message threads if possible)

>. . .
> HOW separate layers in Cocoon?? I have not enough experience
> in Cocoon to see the solution of the separation.
>. . .

Let me try to give a simple scenario where you want to insert data in your 
database, as an example. FE is the front-end (Cocoon for sure), BE is the 
backend (Cocoon maybe):

1. user submits an HTML form to FE:/newCustomer.html, with request parameters 
"firstname=Joe, lastname=Kool, operation=insert"

2. FE, probably using WebServiceProxyGenerator, relays the request in HTTP to 
BE:/insert/customer.xml, probably unmodified in such a simple case

3. BE process the request, inserts data in the database and returns an XML 
representation of the inserted data (or error message if it didn't work out).

This BE HTTP/XML interface is fully testable, will most probably not change 
often, even if the backend itself changes.

4. FE converts the XML data (received through WebServiceProxyGenerator) to 
the desired (probably HTML) format, adds navigation features and returns the 
generated HTML page to the user.

Does this help?
-Bertrand

-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: TR: How to develop a web application with Cocoon

[Bertrand Delacretaz]

(note: please use reply-to instead of creating new messages when replying, to 
avoid breaking the message threads if possible)

>. . .
> HOW separate layers in Cocoon?? I have not enough experience
> in Cocoon to see the solution of the separation.
>. . .

Let me try to give a simple scenario where you want to insert data in your 
database, as an example. FE is the front-end (Cocoon for sure), BE is the 
backend (Cocoon maybe):

1. user submits an HTML form to FE:/newCustomer.html, with request parameters 
"firstname=Joe, lastname=Kool, operation=insert"

2. FE, probably using WebServiceProxyGenerator, relays the request in HTTP to 
BE:/insert/customer.xml, probably unmodified in such a simple case

3. BE process the request, inserts data in the database and returns an XML 
representation of the inserted data (or error message if it didn't work out).

This BE HTTP/XML interface is fully testable, will most probably not change 
often, even if the backend itself changes.

4. FE converts the XML data (received through WebServiceProxyGenerator) to 
the desired (probably HTML) format, adds navigation features and returns the 
generated HTML page to the user.

Does this help?
-Bertrand

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

TR: How to develop a web application with Cocoon

[Sylvain.Thevoz]

Thank you Bertrand for your help.

I think that a cleanly separation between different layers is great. This was my first 
idea and Cocoon should be the user interface layer. But HOW doing that??
HOW separate layers in Cocoon?? I have not enough experience in Cocoon to see the 
solution of the separation.

Anyone of you can help me?
Thank you
Sylvain

-Message d'origine-
De: Bertrand Delacretaz [mailto:bdelacretaz@;codeconsult.ch]
Date: vendredi, 8. novembre 2002 08:30
À: [EMAIL PROTECTED]
Cc: Thévoz Sylvain, IT-DCS-CPS-CLI-DAR
Objet: Re: How to develop a web application with Cocoon


Hi Sylvain,

> ...can I do all I want in my web application
> with Cocoon

Looks like there's not a rush to reply to this one...

Quite frankly I don't know the precise status of the current implementations 
of forms handling and flow. These would help you a lot in filling the blanks 
in your concept, so you might want to ask more specific questions about them 
here.

Let me reply on what I know...

> 2) Search data: form to enter the query => select data in database =>
> display result

If you're reading directly from the database (but read below about this), 
ESQL seems to be the most flexible option here, followed by XSLT 
transforms for HTML or PDF generation.

I don't think you need a form handling module for this, you can start with a 
(static or XSLT-generated) HTML form and use the request parameters to build 
the SQL query.

> 4) Generate file: choose the file to generate (from a result or a form) =>
> select data in database => generate the file

What kind of file? XML? HTML? PDF? RTF?
In any case I think XSLT transforms followed by the appropriate serializers 
will do the job. This is something that is definitely mature in Cocoon today 
(with some limitations in PDF output and some more in RTF output).

The forms handling module might also be overkill here IMO if you're just 
selecting 2-3 options on a form to trigger file generation.

*** OK,BUT - do you want a monolithic system? ***

So I don't have all the answers, but even if Cocoon allows you to build your 
complete app today, I would by all means avoid creating a big monolithic 
thing. 

Cleanly separated application layers are a must in my book, with at least a 
(stable and testable) backend to handle database transactions and a (more 
subject to change and harder to test) frontend for the user interface.

It's great that Cocoon offers (or will soon offer) all components required to 
build a complete webapp, but this might cause a tendency of using too much of 
it at the same time.

IMHO the WebServicesProxyGenerator [1] is a great step towards cleanly 
modularized applications, by allowing a clean separation of application 
layers. It doesn't mean you won't use Cocoon for the backend as well, but if 
you do you might be better off using *another instance* of Cocoon for the 
backend, separate process, maybe separate server.

Of course modularizing usually means some loss of performance compared to 
more tightly integrated systems. For most applications this is irrelevant I 
think, or more precisely the benefits far outweigh the disadvantages.

Hope this helps!
-Bertrand

[1] http://xml.apache.org/cocoon/userdocs/generators/wsproxy-generator.html





-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>