Henning I would use CSSContentRewriter, HTMLContentRewriter and RenderingContentRewriter in that order. You can add CajaContentRewriter if you want Caja support. I will be removing DefaultContentRewriter and some of the others and removing the now unused caja parser support.
-Louis On Mon, Dec 1, 2008 at 8:17 PM, Henning P. Schmiedehausen < [EMAIL PROTECTED]> wrote: > Hi, > > currently digging a bit deeper into the release-branch codebase: > > There are now a number of content rewriters implementing the > ContentRewriter interface: > > AppendingRewriter > CajaContentRewriter > CaptureRewriter > CSSContentRewriter > DefaultContentRewriter > HTMLContentRewriter > NoOpContentRewriter (sic!) > RenderingContentRewriter > > Of those, only CajaContentRewriter, DefaultContentRewriter, > HTMLContentRewriter and RenderingContentRewriter are actively used (in > DefaultGuiceModule and the ConcatProxyServlet) in the code (some > others are used in the tests but I don't really care about them). > > The DefaultContentRewriter in turn is closely tied to CssRewriter, > ProxyingLinkRewriter, HtmlRewriter, JavascriptTagMerger, > LinkingTagRewriter and StyleTagRewriter. All of this is tied into Caja > code. > > For the 0.7 Shindig integration I got away with mostly ignoring these > parts. :-) > > It seems that now I will have to put some work into that area of > Shindig. So my very basic question is: What of the content rewriting > is *needed* to implement the spec? As I can see, most of the > Css/HtmlRewriter code does sanity checking on the structure of the > HTML and CSS code. Or could I pull most of the code without losing > much of the functionality? > > Thanks. > > Ciao > Henning > > -- > Henning P. Schmiedehausen - Palo Alto, California, U.S.A. > [EMAIL PROTECTED] "We're Germans and we use Unix. > [EMAIL PROTECTED] That's a combination of two demographic groups > known to have no sense of humour whatsoever." > -- Hanno Mueller, de.comp.os.unix.programming >
