[silva-dev] public rendering flexibility

[Korosec, Wolfgang]

Hello,
this sounds really VERY good !

Some nice things you could do with this system much easier than now:

Take the Silva-XML send it through the "magic pipe" and get PDF for a
nice printout. 
Silva-XML -> Plain Text for Email 
Silva-XML -> OpenOffice XML (or even M$-Office XML) 
Silva-XML -> RSS

It would be very important, that the "dynamic" parts (database queries
for example) of the page are generated before sending resulting the XML
through the pipe.

Another point: dynamic generation of the XSLT code - would that be a
good idea or not ?

Cocoon uses a similar approach, maybe one can borrow some ideas  ;-) 

Best regards
Wolfgang

> 
> Hi there,
> 
> An idea dump about a possible way to make Silva extensible
> and more flexible in a new direction: view rendering pipelines.
> 
> The current setup of Silva concerning public views uses particular
> widgets which are in the 'widgets' tree to do the public 
> rendering. Each widget is in effect a view for an XML node. 
> When publically rendering, a widget is looked up for an XML 
> node by element name (tag name), and this widget has a 
> 'render' method which gets called. This then is a page 
> template and/or python script that does the rendering of the 
> widget to HTML. Public widget take care of the public rendering.
> 
> Frequently a particular Silva site manager wants particular
> elements to render differently. Often enough CSS is powerful 
> enough to allow this. This already works for Silva; Silva 
> spits out simple HTML for documents and it's easy to 
> associate a stylesheet to that.
> 
> Sometimes it's not enough; perhaps a local site manager wants
> the TOC to really render in a different way. In this case it 
> would be useful to override a particular element with new 
> rendering code.
> 
> This is currently hard. It will take some re-engineering of
> the widget and view architecture to accomplish this.
> 
> What is easier to accomplish is a simpler approach. This will
> introduce more maintenance burden on the site maintainer but 
> it is very flexible.
> 
> Imagine there's a service_xml_rendering or something like
> that. In it, the site manager can control which rendering 
> pipeline transforms the XML coming from the Silva Document 
> (or other objects) into HTML.
> 
> The default uses the current widget tree to do it. It should
> also be easy to plug in different widget registries which may 
> use different widget trees. Applying the page template in the 
> end here remains the same; only the public content rendering changes.
> 
> This would require maintaining a near-copy of the public
> widget tree so it'd be a maintenance burden, but it'd at 
> least be possible.
> 
> More powerful flexibility is also possible. Each Silva object
> knows how to represent itself as XML. It should be possible 
> to plug in XSLT transformation sheets to transform this XML 
> into HTML as well, or basically any mechanism to do this 
> transformation you like.
> 
> With XSLT it may be nice to actually disable the whole page
> template system (just plug in a minimal macro for public 
> layout perhaps) and let all the HTML rendering, including 
> navigation, be the responsibility of the 
> XSTL template. The requirements for the various sources of 
> XML data would increase though; the XSLT would also need 
> access to an XML representation of the folder tree, for 
> instance, in order to render navigation elements.
> 
> What do people think?
> 
> Regards,
> 
> Martijn
> 
> _______________________________________________
> silva-dev mailing list
> silva-dev at lists.infrae.com
> http://lists.infrae.com/mailman/listinfo/silva-> dev
>