cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Variations on a theme by Cocoon
Date Tue, 15 Feb 2000 16:46:10 GMT
Pierpaolo Fumagalli wrote:
> 
> Stefano Mazzocchi wrote:
> >
> > [...] a worth reading piece of email that I won't quote since it's
> > too long :) [...]
> 
> Let me see if I got that correctly: You're talking about the two
> different kinds of producers:
> 
> 1) The first kind of producer is the "well known" file producer, relying
> on a parameter to operate: I give it a filename and it "produces" the
> XML data contained in that file.

yes
 
> 2) The second kind of producer is something "different", since it
> doesn't rely on anything (any parameter and/or external resource) to
> produce XML data. It can be a class I write by hand, or a compiled XSP,
> or whatever...

well, the line between them is thinner: we're not talking about
parameter-free producers, but producers that contain some information
that was generated from another source that can change independently.

In case of DummyProducer, we have no parameters and no external original
file... everything was done by hand and there is nothing that can change
externally to trigger a "regeneration" of this producer.

Both FileProducer and DummyProducer are immutable in such sense.

But if you take hello.xml and compile it into a producer, the code you
end-up with is _exactly_ like dummyproducer, but it's behavior is very
different: if hello.xml is updated, the system _must_ trigger the
regeneration of the producer, before executing it again.

Extending this into the most complex case, "generated producers" are
linked to their generation process. 

At the end, FileProducer is a very special case of a "generated
producer" where the generator is a human being and it recompiles the
thing by hand if something changes.

Eventually, all producers can be seen as "generated producers", and for
this reason they expose _two_ ergodic periods:

1) the period of their logic generation
2) the period of their generated data

which are totally incorrelated.
 
> In this envision, we could think about taking a static XML file used by
> the common "FileProducer", compiling it somehow into java bytecode, and
> making it become a "second type" producer.

yes
 
> In the same way, we can think about having a "ClassLoaderProducer", wich
> loads the class of the "second type" producer specified in its
> parameters (mostly like how "FileProducer" parses the static XML file)
> and tells to its instance to generate XML data.

hmmm, not quite. Instead of treating "generated producers" as special
cases (with their own classloaderproducer) I'd treat fileProducer as a
special case of a externally generated producer which cannot change
during execution.
 
> IMVHO, those two are two completely different things: if we call 1
> "Producer" and 2 "Generator" things come easier:
> 
> The XSPProducer takes a parameter, the XSP page, or XML source file
> (depending how we consider XSP: a full standard or a "taglib" for XSLT),
> parses the file, does the appropriate transformations and writes a .java
> source file. The generated .java source file will not implement
> "Producer", but it will implement "Generator". After this one is
> compiled, it is instantiated by the XSPProducer and executed, to
> generate XML.

Hmmmm... what if all producers are supposed to be "generated" and only
special ones are not? something like they have a null instead a
Modificable chain? just thinking out loud.
 
> At the same way, the FileProducer receives a source file parameter, and
> tells the "Parser+new InputSource(sourceFile)" union (in our case is,
> again, another Generator) to generate XML.

See what you're doing? your producer is now a single one that does
almost the same thing for all "generators".... IMO this is the engine
itself.
 
> The ClassLoader producer is the easier of the three: it receives a
> source file name (the name of the class implementing Generator), loads,
> instatiates, and executes it.

Again, this should be included in the engine. What's the point of
creating an interface for plugins where the only useful one is a
classloaderproducer that spawns generators depending on sitemap
parameters?
 
> So, IMVHO, we have to deal with one more "element" in our processing
> chain, this "Generator": and the chain itself changes: from
> 
> producer -> filter* -> serializer
> 
> it becomes
> 
> generator -> filter* -> serializer
> 
> and it's the task of the producer to retrieve the appropriate generator
> from the request parameter.

I like this name change: in fact producer is something more than the
general "producer/consumer" pattern. I like "generator" a lot better.
But it should take the producer's place, not requiring another
processing step...

> Also, this makes things easier since only the Producer is "driven" by
> the request parameters (meaning that "it changes its behaviour depending
> on the request data").

Hmmm, bad naming. Call it Producer or Generator, I don't want _both_ to
coexist. We need a pattern to define "an entity able to produce XML
content and able to reflect the changes to all the other entities
involved in the production".

These other entities are request/session parameters as well as data
repositories such as files, DBMS, directory servers, whatever...

In fact, even FileProducer could save the parsed DOM internally and
behave as a "collection of compiled static pages". I think there is no
real difference between a producer and a generator, but we _have_ to
take into account the possibility of "generated producers" and consider
those who are not special cases, not the other way around.

> The producer is asked if a particular request matches a Generator, and,
> when this is obtained, the processing chain is set up...

I think this is unfortunately more complex than this :(
 
> I just hope it makes sense...

It really does. I'm happy we are still tuned even if we have half a
planet in between :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------


Mime
View raw message