cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Hoegg <rho...@isisnetworks.net>
Subject Re: XML-Based Reporting Application, Design?
Date Wed, 20 Aug 2003 19:57:00 GMT
Jeff,

You might consider writing an avalon component and wrapping it in a 
Generator.  An avalon component is really "plain ol' programming" with 
some restraints, and can be used outside of cocoon.  You could decide 
exactly what functionality you want to be reusable and what you want to 
put in Cocoon, and draw the line there.  For example, your component 
could generate SAX events and the generator could be a thin delegation 
layer.  Or, your component could expose data classes and the Generator 
could do the translation to SAX. (I suggest jakarta commons betwixt for 
that).

I recently did this on a small scale for my first flowscript 
application, and could give more details in response to some specific 
questions :)

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

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.
>
>Thanks for the helpful feedback!
>
>  
>


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


Mime
View raw message