cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: generator type value substitution
Date Wed, 28 Apr 2004 19:16:35 GMT
Leszek Gawron <ouzo@wlkp.org> writes:

> 
> On Wed, Apr 28, 2004 at 01:34:14PM -0500, Hunsberger, Peter wrote:
> > Tony Collen <colle006@umn.edu> writes:
> > > 
> > > Leszek Gawron wrote:
> > > > Why doesn't <map:generate type="{1}"/> work ? I cannot find the
> > > > explanation in the archives. I am currently porting all my xsp 
> > > > generators to Java based (compile time errors were a real 
> > > nightmare).
> > > > I am not able to use flow here - I need to use the pull model - 
> > > > the
> > > > generator gets data from database, applies non trivial 
> > > logic and then
> > > > outputs the sax events.
> > > > 
> > > > I use cocoon as a second tier which provides data for my
> > > C++ clients
> > > > (http protocol). The documents generated for offline
> > > synchronization
> > > > contains sometimes 10k+ nodes (files reach 2.5 MB )
> > > > 
> > > > I cannot use jxtg as I heavily mix iterative data retrieval from
> > > > database and data manipulation.
> > > > 
> > > > Previously (with xsps) I could do <map:generate 
> type="serverpages" 
> > > > src="{1}.xsp"/>. With java generators this turns into a
> > > sitemap nightmare.
> > > > 	lg
> > > > 
> > > 
> > > 
> > > Hmm, What about writing a selector to choose which 
> generator to use?
> > 
> > Missed the original e-mail, why not just push the problem down a 
> > level:
> > 
> > 	<map:generate type="superGenerator" src="{1}"/>
> > 
> > SuperGenerator can then figure out what to do by looking at the 
> > source...
> I have already thought of that but the problemis that here 
> the "source" is the generator name. Do you know how should I 
> lookup a generator, setup it properly (to support 
> map:parameter for example) and than invoke it? with 
> everything done not to break sitemap reloading (new 
> generators may come in place, old may be deleted), caching 
> and other stuff I cannot really comprehend :)

Umm, why is source another generator?  You really just need a mapping
from source to some Java class.  Since you've got a database adding that
mapping shouldn't be hard?  I guess the answer ATM is that you've
already got a bunch of generators hanging around and you don't want to
rewrite them.  So...
  
> AFAIU this is exactly a small part of a TreeProcessor 
> functionality and the TreeProcessor itself is really 
> complicated. I'am afraid I would have to rewrite/duplicate a 
> lot of code. 

Even if it is another generator superGenerator can just instantiate it
and call it; setup passes the parameters directly on to the new
generator.  Probably I'd insert a new proxyGenerator between
o.a.c.AbstractGenerator and your generators to do call backs to the
superGenerator to pick up things like xmlConsumer transparently so your
existing generators don't have to be rewritten.  Depending on your tool
set such a global search and replace might be a bit of a pain, but still
not hard?  The proxy would also handle the caching issues; implement
Cacheable, but leave it up to the sub generators to do anything real
with the generateKey and generateValidity....





Mime
View raw message