[silva-dev] public rendering flexibility

[Paul Everitt]

Speaking of Cocoon, they are having a mini-conference in Belgium Oct 
7-8.  I know some of those guys, and we've been looking for ways to 
establish communications between camps, so they invited me to the 
conference.  Alas, I have a prior commitment.

It would be interesting to visit and find out, in depth, how their 
rendering model works.  They've accumulated some valuable insights, I'm 
sure.

--Paul

On Wednesday, Sep 24, 2003, at 09:57 Europe/Paris, Korosec, Wolfgang 
wrote:

> 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
>>
> _______________________________________________
> silva-dev mailing list
> silva-dev at lists.infrae.com
> http://lists.infrae.com/mailman/listinfo/silva-dev