Generator How-To

[Geoff Howard <gh...@crosswalk.com>]

After giving a long winded response to a question about writing your own
generator, I've started working on a "How-To Write A Custom Generator" based
on my experience of doing two or three over the last few months.  Before I
get too far into it:
- is anyone else working on this already
- are there any abandoned drafts lying around
- has anything drastic been happening to the docs structure that I should
take into account (I have made a few references to the Extending Cocoon docs
and Performance Tips, and Avalon primer so far)
- do you share my view that this is a need?

Geoff Howard

Re: Generator How-To

[Diana Shannon <sh...@apache.org>]

On Thursday, August 1, 2002, at 03:10  AM, Bertrand Delacretaz wrote:

> Note that there is a "Writing a Cocoon 2 generator" article
> at
> http://xml.apache.org/cocoon/tutorial/tutorial-rmi-generator.html

Please also note that John Austin (john@integerservices.no-ip.com) had 
expressed an intent to edit the above. You may want to check with him on 
its status/plans.

Diana

Re: Generator How-To

[Bertrand Delacretaz <bd...@codeconsult.ch>]

On Wednesday 31 July 2002 23:23, Geoff Howard wrote:
> After giving a long winded response to a question about writing your own
> generator, I've started working on a "How-To Write A Custom Generator"
> based on my experience of doing two or three over the last few months. 

Note that there is a "Writing a Cocoon 2 generator" article
at
http://xml.apache.org/cocoon/tutorial/tutorial-rmi-generator.html

-Bertrand

RE: Generator How-To

[Conal Tuohy <co...@paradise.net.nz>]

Sorry the "Source vs Generator" thread is:
http://marc.theaimsgroup.com/?t=102571404500001&r=1&w=2

RE: Generator How-To

[Conal Tuohy <co...@paradise.net.nz>]

Hi Jeff

I think there is a definite need for this documentation. I wrote a Generator
for the first time a few days ago and it took me quite a while to research
it, though the code was minimal in the end.

It seems to me though that because of the recent changes to the
SourceResolver, there's an opportunity now to write Sources and XMLizers for
many of the cases that would have required Generators in the past. I am
converting my Generator into an XMLizer right now. At the end of it, I was
planning to write a document summarising my experience, and explaining about
writing Generators vs Sources and XMLizers, and why to choose which option.

There was actually a useful thread about this recently (which I missed the
first time through sheer inattention, though I did come to the same
conclusion as Carsten, in the end). Here's that thread:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=source+vs+generator
&q=t

What follows is a quote from me in an off-list discussion with Justin
Fagnani-Bell on the subject of developing a JavaMail Generator or a JavaMail
Source + an email XMLizer:

Cheers

Con

> -----Original Message-----
> From: Conal Tuohy [mailto:conalt@paradise.net.nz]
> Sent: Tuesday, 30 July 2002 10:18
> To: 'Justin Fagnani-Bell'
> Subject: RE: HELP! Advice needed for JavaMail generator
>
>
> Hi Justin
>
> >    I'm a little confused about Sources as well. It seems like the
> > Generator is going to have to do a lot of work to setup the
> JavaMail
> > Store and Folder and once is does that is can get a stream
> > directly from
> > a message. So I'm wondering why a source would even be necessary.
>
> Yes confusion reigns alright. But my thinking has progressed
> a little, to where I wonder if a "Generator" is necessary; I
> think a "Source" is actually what's needed:
>
> A "Source" is appropriate for reading data from a particular
> resource of some generic type (i.e. specified by a URL),
> whereas a "Generator" is appropriate for other sources of
> data (i.e. generating xml from the http request itself). It
> seems that this distinction has developed over time. For
> instance, there's an old XMLDB generator which is now
> deprecated in favour of an XMLDB source, which means you use:
>
> <map:generate src="xmldb:blah"/>
>
> rather than
>
> <map:generate type="xmldb" xmldb-specific-parameter="blah"/>
>
> So the preferred approach is to use the FileGenerator, which
> reads from an XMLDB Source.
>
> I think it's worth taking the same approach with JavaMail. My
> current MIMEMessageGenerator basically reads a message/rfc822
> from a Source, as a stream, and parses it to generate SAX
> events. And I think the rfc822 parser SHOULD be decoupled
> from the JavaMail infrastructure, because rfc822 data can
> come from files, not necessarily from a JavaMail provider
> such as POP or IMAP.
>
> But it seems to me that there's yet another way of assembling
> it, which is what I'm investigating now: using "XMLizer". In
> this approach, the MIMEMessageGenerator would be deprecated,
> and the rfc822-parsing would be done by an "RFC822Parser"
> which would fit somehow into the XMLizer component of Avalon
> Excalibur. In this pattern, the JavaMailSource would provide
> RFC822 data to an RFC822Parser which would produce SAX events
> for the FileGenerator. This pattern looks like a good way to
> decompose the whole email access, IMHO. In particular it
> provides email-parsing to other Excalibur components that may
> not have to deal with JavaMail themselves.
>
> But first I have to find out about XMLizer! The Avalon
> website is a mess, and the code-base is being refactored ...
> it's quite frustrating but I think it's worth getting a good
> handle on the architecture we're dealing with.
>
> > I've found a lot of source out there that I'm going to try to glue
> > together into a generator, probably not using sources, and
> > I'll see how
> > that turns out. Unfortunately most of what I found is GLP'ed,
> > so I don't
> > quite know what to do about that.
>
> Well ... I hope I can convince you to take a look at Sources
> instead of Generators (I don't think we need one). Basically
> a Source has to be able to take a url which refers to an
> email on some kind of mail server, and return an OutputStream
> of the bytes of that email. And the actual parsing to XML can
> be done separately.