You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/07/15 16:12:43 UTC
[RT] Cocoon Integration Model
Something that has been bothering me regarding Cocoon's web app model is
how the webapp is supposed to be defined. Cocoon started as a content
publishing model. At this, it is better than anything else out there.
Using Cocoon for webapps has traditionally been troublesome. As a
result,
we have been trying to extend it and make it a better platform for web
applications.
The ways we extended it made it closer to an ideal, but never quite
there.
The J2EE blueprints, struts, and turbine all advocate an MVC approach.
We have been trying to make that happen in Cocoon as well. We have MVC
for the presentation of information--model=XML,
view=transformes/serializers,
and controller=sitemap/actions. However, that is not the proper
division
for a web Application.
* A proper model represents the application data. Whether you use
direct
SQL manipulation or an object model is up to you. XMLDBs attempt to
represent the data in XML--which seems the best way for Cocoon.
However,
XMLDBs are largely unproven in high transaction environments so
traditional
shops want to opt for more traditional models.
* Cocoon itself is the ultimate view. You can represent your
information
in so many different formats it isn't even funny. According to J2EE,
Servlets and JSPs are types of *views*. Essentially, this makes
Cocoon
as a whole just another view.
* Control is a more complex subject as different types of control work
together to represent a coherent application. The J2EE blueprints
have
Session EJBs handle the application logic, while the servlets handle
the presentation logic. It is important to separate them out because
handling which page of a form comes next is different from what
happens
when we approve something. Cocoon works well for presentation logic,
but admittedly does not do well for application logic.
As a result, what we have now to overcome the basic deficiencies in the
Cocoon integration picture is the inclusion of Transformers, Generators
(XSP esp.), and Actions that all perform application level logic. The
two biggest culprits are the Action and the Generator.
I have developed a few webapps using Cocoon, and have boiled down how
to come up with a Quick and Dirty (Q&D) setup rather quickly. However,
I have never been satisfied with what it takes to bring other developers
on board. By the shear quantity of information, component types, and
now pipeline types, the average newbie spends much longer trying to
understand Cocoon than they do actually using it.
When I wrote the first cut of the webapp tutorial, I had every intention
of making it as useful as the "Developing with Avalon" document I wrote.
Unfortunately, I ran out of time. My arguments about Cocoon apps being
easier to maintain and supporting simultaneous development went out the
window when people I was working with in my office spent six weeks
trying
to come to grips with everything.
I tried to tell them that if you use the markup I developed everything
would look like it belonged to the site. I still had one stubborn
developer
who insisted on directly writing broken HTML. I tried to tell them that
they didn't have to worry about the sitemap--it was my responsibility,
but still they tried to understand it.
It can be argued that the troubles I had were largely due to training
or management decisions. (Once I got a developer working with it
properly, she and I cranked out the application in about two weeks).
The problem is more fundamental than that. The problem is that there
is no proven or set way of creating web applications using Cocoon time
after time after time. That is what the J2EE blueprints are for. To
help developers not waste their time on harmful patterns, and
concentrate
on more useful aspects of J2EE. As a result, it is a platform that
works--maybe not the best, but it works.
Cocoon can definitely use its own blueprint. A Cocoon Application
Blueprint is an essential document that we need. There are two ways
of using Cocoon: integrated in with a traditional J2EE environment,
and standalone. The blueprint will define exactly what part of the
puzzle Cocoon supports. It will also define which patterns work well,
why they work well, and the antipatterns which suck all your time.
A side-affect, and general improvement will be that Cocoon will begin
to be shaped by the blueprint. The proposals that are given will be
there to enhance the model, or to overcome shortcomings. As we state
*how* Cocoon should be used, it's development effort will follow that
pattern. As of right now, the oppinions on how to get the best out
of Cocoon are as varied as the number of developers on the list.
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Integration Model
Posted by Steven Noels <st...@outerthought.org>.
Berin Loritsch wrote:
> As of right now, the oppinions on how to get the best out of Cocoon
> are as varied as the number of developers on the list.
Amen.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Integration Model
Posted by "Andrew C. Oliver" <ac...@apache.org>.
<snip content="increadibly relevant stuff I totally agree with"/>
>Cocoon can definitely use its own blueprint. A Cocoon Application
>Blueprint is an essential document that we need. There are two ways
>of using Cocoon: integrated in with a traditional J2EE environment,
>and standalone. The blueprint will define exactly what part of the
>puzzle Cocoon supports. It will also define which patterns work well,
>why they work well, and the antipatterns which suck all your time.
>
>
I'm doing my part.
http://www.superlinksoftware.com/cocoon/samples/bringmethis/index.html
is intended
to be a sample webapp. I don't want to do a total petshop as I think it
over does it in hopes of working
every technology into it.
Next I plan to do a write up.
Next, I hope you smart people will help refactor it into best practices.
Its about 3/4 finished. Nicola is writing a skin for it, I'm trying to
figure out how to pass a freaking request parameter
into an xml form from outside of the form, then I should be able to nail
the rest of it out.
All the code minus the branding will be donated to cocoon ASL of course.
Lastly, the site will actually go live so it will be a bit more than the
petshop.
>A side-affect, and general improvement will be that Cocoon will begin
>to be shaped by the blueprint. The proposals that are given will be
>there to enhance the model, or to overcome shortcomings. As we state
>*how* Cocoon should be used, it's development effort will follow that
>pattern. As of right now, the oppinions on how to get the best out
>of Cocoon are as varied as the number of developers on the list.
>
>
+1
>
>"They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Integration Model
Posted by Bert Van Kets <be...@vankets.com>.
At 15:44 16/07/2002 +0200, you wrote:
>Berin Loritsch wrote:
>
>>Cocoon can definitely use its own blueprint. A Cocoon Application
>>Blueprint is an essential document that we need. There are two ways
>>of using Cocoon: integrated in with a traditional J2EE environment,
>>and standalone. The blueprint will define exactly what part of the
>>puzzle Cocoon supports. It will also define which patterns work well,
>>why they work well, and the antipatterns which suck all your time.
>
>Quite some people and companies I know are currently building Cocoon-based
>CMS and webpublishing apps, often charging considerable amounts for this
>kind of 'product'. Wyona of course serves as some kind of reference
>example (while they do so in open source, which is good).
>
>But if you look at the basic use cases of a webbased CMS, those also cover
>general functions as authentication, form-based editing, some workflow,
>session management etc etc...
>
>I agree webshopping fits in most people's head as some blueprint
>application, but integrating what we've got (Cocoon, Slide, Lucene, forms
>processing, authentication and (portal) publishing building a CMS could
>also become an aggregation of best practices, IMHO.
Take away Slide (for the moment) and that's exactly what I'm doing in my
current project. Just a statement to back up Steven's.
- I'm having a member section on the site that uses a mySQL databse for
user authentication
- I'm using the portal as a CMS/logisitc tool with an XML file for user
authentication
- I have a form based menu.xml editor for menu editing
- I have a page editor from sourceforge, sadly enough using LGPL, to edit
the content of the pages
- I index the content using Lucene
- the logistical functions are to be created but there are enough form
processing things in cocoon to do this
- I'm using esql to dynamically generate forms with and from database
content. Add, delete, update and record navigation is provided. Still
need to add pagination.
- I will generate PDF documents to be used in mail merge applications
- I will use the sendMail logicsheet to do e-mailings
- lots of smaller stuff
This is a real life application that is easy to maintain, scalable and very
performing. The code is a bit of a mess right now due to several tests that
are still in there, but after cleanup I'm going to make it available in OSS
(apart from the editor which will remain LGPL of course).
Voices are rising in our company to set up a true document(ation)
management system for all the projects we are doing. Some of those are
really big and have lots of stuff. I'm trying to push Forrest, and thus
Cocoon, to get this done. This application will use all of the stuff
Steven mentioned. it will even use SVG to generate graphs and images for
personalized documents.
Cocoon is a big bag of goodies. We got to put them together to create a
candy factory.
Bert
></Steven>
>--
>Steven Noels http://outerthought.org/
>Outerthought - Open Source, Java & XML Competence Support Center
>stevenn@outerthought.org stevenn@apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Integration Model
Posted by Steven Noels <st...@outerthought.org>.
Berin Loritsch wrote:
> Cocoon can definitely use its own blueprint. A Cocoon Application
> Blueprint is an essential document that we need. There are two ways
> of using Cocoon: integrated in with a traditional J2EE environment,
> and standalone. The blueprint will define exactly what part of the
> puzzle Cocoon supports. It will also define which patterns work well,
> why they work well, and the antipatterns which suck all your time.
Quite some people and companies I know are currently building
Cocoon-based CMS and webpublishing apps, often charging considerable
amounts for this kind of 'product'. Wyona of course serves as some kind
of reference example (while they do so in open source, which is good).
But if you look at the basic use cases of a webbased CMS, those also
cover general functions as authentication, form-based editing, some
workflow, session management etc etc...
I agree webshopping fits in most people's head as some blueprint
application, but integrating what we've got (Cocoon, Slide, Lucene,
forms processing, authentication and (portal) publishing building a CMS
could also become an aggregation of best practices, IMHO.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Integration Model
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Artur Bialecki wrote:
>I think cocoon web application blueprints are a great idea.
>I had to get around many cocoon quirks to get it working
>in a J2EE environment. I've always seen cocoon advertised
>for web-publishing so I always thought that I'm not using
>it for what it was intended. To be fair J2EE has many quirks
>too which caused some of the problems.
>
>Now, let's not do another PetStore, maybe something
>more along the B to B model?
>
>
I just found the wafer project (http://www.waferproject.org/), whose aim
is to implement the same application using various serverside java
frameworks so that people can compare them more objectively.
And Cocoon is already listed as one of the competitors...
Anybody aware of this project ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Integration Model
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>Now, let's not do another PetStore, maybe something
>>more along the B to B model?
>>
>>
>
>We need something that does three basic things:
>
>1) Has complex application logic--i.e. one approval
> fires off several actions. That application logic
> should be encapsulated in application specific
> components.
>
>
+1
>2) Need for a non-trivial model. In other words, let's
> not talk directly to the database, and use an abstraction
> layer.
>
>
+/-1 -- make it only as complicated as it should be in a standard app
>3) Need for reports. Cocoon's integration with FOP is an
> excelent way to show off how reporting is integrated.
> We can show how to handle offline generated reports, and
> reports generated on demand.
>
>
+1 what I'm working on has it. But I'll probably do my part to Excel :-)
>As to the subject in question, we have some possibilities:
>
>* Manage the process of a Manufacturer submitting a new product
> to a retailer to have the product show up on the retailers
> stores. (I have worked on such a project myself).
>
>* Inventory management application that incorporates automatic
> re-ordering based on thresholds. An interface is necessary
> to input the current inventory, or at least the relationships
> between an order for a product and the number of parts used.
>
>* Insert your own idea here.
>
* Reverse auction website complete with live running site that
serves as an example. Its
likely others will adopt it as well. Its simple, but not too simple, so
you can get your mind around it
but its not so trivial that it doesn't require any complex logic. It
needs reports, it needs actions, it needs
database, I'm 3/4 of the way done with it. And plan to incorporate it
into my Cocoon presnetation with
Conrad D'Cruz in October. It also will demonstrate skinning, branding,
that kinda thing. Most importantly
everyone knows about auction sites, not everyone knows about inventory
management and Mfg sites.
-Andy
>
>Both of these concepts have use in the real world, which I find
>a more effective way of teaching how to use Cocoon.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Cocoon Integration Model
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>3) Need for reports. Cocoon's integration with FOP is an
>> excelent way to show off how reporting is integrated.
>> We can show how to handle offline generated reports, and
>> reports generated on demand.
>>
>>
>
>And something in rtf and excel.
>
>
+1
>J.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Cocoon Integration Model
Posted by John Morrison <jo...@ntlworld.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> > From: Artur Bialecki [mailto:artur@digitalfairway.com]
> >
> > I think cocoon web application blueprints are a great idea.
> > I had to get around many cocoon quirks to get it working
> > in a J2EE environment. I've always seen cocoon advertised
> > for web-publishing so I always thought that I'm not using
> > it for what it was intended. To be fair J2EE has many quirks
> > too which caused some of the problems.
> >
> > Now, let's not do another PetStore, maybe something
> > more along the B to B model?
>
> We need something that does three basic things:
>
> 1) Has complex application logic--i.e. one approval
> fires off several actions. That application logic
> should be encapsulated in application specific
> components.
>
> 2) Need for a non-trivial model. In other words, let's
> not talk directly to the database, and use an abstraction
> layer.
>
> 3) Need for reports. Cocoon's integration with FOP is an
> excelent way to show off how reporting is integrated.
> We can show how to handle offline generated reports, and
> reports generated on demand.
And something in rtf and excel.
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Cocoon Integration Model
Posted by Berin Loritsch <bl...@apache.org>.
> From: Artur Bialecki [mailto:artur@digitalfairway.com]
>
> I think cocoon web application blueprints are a great idea.
> I had to get around many cocoon quirks to get it working
> in a J2EE environment. I've always seen cocoon advertised
> for web-publishing so I always thought that I'm not using
> it for what it was intended. To be fair J2EE has many quirks
> too which caused some of the problems.
:) Yep.
>
> Now, let's not do another PetStore, maybe something
> more along the B to B model?
We need something that does three basic things:
1) Has complex application logic--i.e. one approval
fires off several actions. That application logic
should be encapsulated in application specific
components.
2) Need for a non-trivial model. In other words, let's
not talk directly to the database, and use an abstraction
layer.
3) Need for reports. Cocoon's integration with FOP is an
excelent way to show off how reporting is integrated.
We can show how to handle offline generated reports, and
reports generated on demand.
As to the subject in question, we have some possibilities:
* Manage the process of a Manufacturer submitting a new product
to a retailer to have the product show up on the retailers
stores. (I have worked on such a project myself).
* Inventory management application that incorporates automatic
re-ordering based on thresholds. An interface is necessary
to input the current inventory, or at least the relationships
between an order for a product and the number of parts used.
* Insert your own idea here.
Both of these concepts have use in the real world, which I find
a more effective way of teaching how to use Cocoon.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT] Cocoon Integration Model
Posted by Artur Bialecki <ar...@digitalfairway.com>.
I think cocoon web application blueprints are a great idea.
I had to get around many cocoon quirks to get it working
in a J2EE environment. I've always seen cocoon advertised
for web-publishing so I always thought that I'm not using
it for what it was intended. To be fair J2EE has many quirks
too which caused some of the problems.
Now, let's not do another PetStore, maybe something
more along the B to B model?
Artur...
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, July 15, 2002 10:13 AM
> To: cocoon-dev@xml.apache.org
> Subject: [RT] Cocoon Integration Model
>
>
> Something that has been bothering me regarding Cocoon's web app model is
> how the webapp is supposed to be defined. Cocoon started as a content
> publishing model. At this, it is better than anything else out there.
> Using Cocoon for webapps has traditionally been troublesome. As a
> result,
> we have been trying to extend it and make it a better platform for web
> applications.
>
> The ways we extended it made it closer to an ideal, but never quite
> there.
> The J2EE blueprints, struts, and turbine all advocate an MVC approach.
> We have been trying to make that happen in Cocoon as well. We have MVC
> for the presentation of information--model=XML,
> view=transformes/serializers,
> and controller=sitemap/actions. However, that is not the proper
> division
> for a web Application.
>
> * A proper model represents the application data. Whether you use
> direct
> SQL manipulation or an object model is up to you. XMLDBs attempt to
> represent the data in XML--which seems the best way for Cocoon.
> However,
> XMLDBs are largely unproven in high transaction environments so
> traditional
> shops want to opt for more traditional models.
>
> * Cocoon itself is the ultimate view. You can represent your
> information
> in so many different formats it isn't even funny. According to J2EE,
> Servlets and JSPs are types of *views*. Essentially, this makes
> Cocoon
> as a whole just another view.
>
> * Control is a more complex subject as different types of control work
> together to represent a coherent application. The J2EE blueprints
> have
> Session EJBs handle the application logic, while the servlets handle
> the presentation logic. It is important to separate them out because
> handling which page of a form comes next is different from what
> happens
> when we approve something. Cocoon works well for presentation logic,
> but admittedly does not do well for application logic.
>
> As a result, what we have now to overcome the basic deficiencies in the
> Cocoon integration picture is the inclusion of Transformers, Generators
> (XSP esp.), and Actions that all perform application level logic. The
> two biggest culprits are the Action and the Generator.
>
> I have developed a few webapps using Cocoon, and have boiled down how
> to come up with a Quick and Dirty (Q&D) setup rather quickly. However,
> I have never been satisfied with what it takes to bring other developers
> on board. By the shear quantity of information, component types, and
> now pipeline types, the average newbie spends much longer trying to
> understand Cocoon than they do actually using it.
>
> When I wrote the first cut of the webapp tutorial, I had every intention
> of making it as useful as the "Developing with Avalon" document I wrote.
> Unfortunately, I ran out of time. My arguments about Cocoon apps being
> easier to maintain and supporting simultaneous development went out the
> window when people I was working with in my office spent six weeks
> trying
> to come to grips with everything.
>
> I tried to tell them that if you use the markup I developed everything
> would look like it belonged to the site. I still had one stubborn
> developer
> who insisted on directly writing broken HTML. I tried to tell them that
> they didn't have to worry about the sitemap--it was my responsibility,
> but still they tried to understand it.
>
> It can be argued that the troubles I had were largely due to training
> or management decisions. (Once I got a developer working with it
> properly, she and I cranked out the application in about two weeks).
> The problem is more fundamental than that. The problem is that there
> is no proven or set way of creating web applications using Cocoon time
> after time after time. That is what the J2EE blueprints are for. To
> help developers not waste their time on harmful patterns, and
> concentrate
> on more useful aspects of J2EE. As a result, it is a platform that
> works--maybe not the best, but it works.
>
> Cocoon can definitely use its own blueprint. A Cocoon Application
> Blueprint is an essential document that we need. There are two ways
> of using Cocoon: integrated in with a traditional J2EE environment,
> and standalone. The blueprint will define exactly what part of the
> puzzle Cocoon supports. It will also define which patterns work well,
> why they work well, and the antipatterns which suck all your time.
>
> A side-affect, and general improvement will be that Cocoon will begin
> to be shaped by the blueprint. The proposals that are given will be
> there to enhance the model, or to overcome shortcomings. As we state
> *how* Cocoon should be used, it's development effort will follow that
> pattern. As of right now, the oppinions on how to get the best out
> of Cocoon are as varied as the number of developers on the list.
>
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org