cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: XML-Based Reporting Application, Design?
Date Wed, 20 Aug 2003 19:30:02 GMT
Jeff Sexton wrote:
> On Tue, 19 Aug 2003, Geoff Howard wrote:
> 
>>Jeff Sexton wrote:
>>
>>>We'd like to built an application that uses data from a database to create
>>>XML, which can be transformed to various forms.  A significant amount of
>>>coding will be required to create the XML (otherwise I'd just place SQL in
>>>an xsp), so I think a separate servlet will make more sense.  My thought
>>>is to create a servlet that outputs type text/xml, call the servlet from a
>>>sitemap, transform and serialize as needed.
>>
>>I don't quite get why you came to the conclusion that a servlet is
>>better for serious coding than the Cocoon environment.  IMHO you should
>>back up and reconsider that.
> 
> 
> Ok, I will.  And I'll take a look at your tutorial.
> 
> There are two reasons that I lean toward a servlet (but I don't feel real
> sure about it, which is why I posted the question).  One is that in
> several of the cases we have to build there will be a fair amount of
> business logic actually coded out.  Others are simpler - just dump the
> data from the database.  But some are going to need plain ol'programming.
> These will be replacing some moderatly complicated C++ programs that
> contain calculations and a lot of condition logic that is not reflected in
> the data source.
> 
> The other reason it that if it's all coded in a servlet (or other stand
> alone chunk of java), then it could potentially have a life outside of
> cocoon.  Don't get me wrong, I love Cocoon and plan to use it, but by
> not commiting the XML data source to a cocoon world we might gain some
> handy flexibility, and allow any old java programmer to work on it with
> learning a thing about Cocoon.  Or allowing the code to run in an agent or
> grid environment, as a web service, or as a setand-alone application.
> 
> Again I don't feel really strongly about either of these reasons, and
> nothing is cast in stone yet.

Gotcha.  Ok, then my advice stands: I'd suggest writing some supporting 
classes which contain most of your heavy lifting, and call those from a 
Generator which handles the mandatory Cocoon-specific methods.  Cocoon 
generators are very simple if you already know java and SAX, especially 
if you have the critical logic factored out into your supporting classes.

Geoff



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


Mime
View raw message