[Informa-developer] Modifying Informa to allow subclassing (For adding "custom" tags)

[Miles G. <mgo...@gm...>]

Hi All,
	I have a need to parse/rewrite some RSS feeds with enclosures into a  
very similar form that requires some "non-standard" tags in the items  
(It's an automated processing system I have no chance of modifying  
the end-consumer of).
	I've been bouncing ideas off Mats Lindh over the past couple of days  
and I think I've found an appropriate and workable solution. The good  
thing is the change to Informa code is fairly minor (Basically moving  
come code out of an iterator-loop into a seperate method call for the  
ChannelExporterIF interface and its implementers). The modified code  
works identically as-is, but can now be extended through subclassing  
to allow using and writing items that contain "special" tags without  
having to modify the Informa source code directly.
	Here's the relevant bits from Mats' blog (Note - I wasn't sure that  
modifying the interface was the right way to go at the time I wrote  
this, but I now feel that the benefits outweigh the uglinesses):

---8<---
Each of the existing ChannelExporterIF implementers should call-out  
to a "protected" (or at least not "private") method to generate each  
"item" JDOM Element. I implemented this for the RSS 2.0 exporter  
simply by taking the entire block of code inside the write() method's  
item-terator loop and putting it into the new method:

  protected Element getItemElement( ItemIF item )

(Plus minor tweaks for instantiation/return of the resultant ItemIF  
object).

Anyway, having made this change, the Informa library behaves  
identically to the way it did before. However now, I can subclass the  
Item class to allow further parameter parsing. I could already  
subclass the ChannelBuilder class to allow reading/recognition of the  
relevant JDom tags to produce the new Item sublass instances. The new  
functionality is that now I can subclass the RSS 2.0 Exporter to  
produce a "customised" JDOM "item" Element from the new Item subclass  
instances sent to it.

It was tempting to put the RSS 2.0 Exporter change into the  
ChannelExporterIF interface definition (so all implementers must  
implement the new method), but that would mandate the new method be  
public, which I'm not sure is sensible: There's no _need_ for an  
external entity to be able to render an ItemIF object into a JDom  
"item" Element within the context of a particular ChannelExporterIF  
instance. Nevertheless the extensibility benefits may outweigh this  
slight inelegance (I'll leave it up to "the mailing list" to decide).
--->8---

	Anyway, as these small changes are essentially moving blocks of code  
(Changin indenting), the diffs are still 191 lines long. So I don't  
think I'll spam the entire list - I'll just foist them upon Niko.

Thanks,

M0les.