[Grok-dev] Re: guidance for incorporating XSLT as alternative templating mechanism?

[Martijn Faassen]

Hello,

Craeg Strong wrote:
[snip]
>>> Maybe we need toXML() and fromXML() methods. It gets complex because 
>>> you are often dealing with big graphs of objects. 

>> Yes, I am not sure there is a general solution to this. I can see 
>> there being a bunch of utility functions that can help translate 
>> object graphs (especially simple dictionaries and lists and so on) to 
>> XML. There's also the schema2xml package I wrote about, which can take 
>> a schema-defined content object and transform it to XML (or back). 
>> This works quite nicely.

> Can you re-send the links to the schema2xml package?  Alas, my google-fu 
> is apparently not up to the task of finding it.
> Code, examples, blogs, docs, anything you have would be most appreciated!

The package wasn't published yet; I only used it internally in a 
project. I've just put it into svn.zope.org though, here:

http://svn.zope.org/z3c.schema2xml/

The README.txt is a doctest that contains some more information about 
it. Unfortunately all the code that actually uses it is still internal, 
but the API isn't too obscure. JW Kolman and myself wrote it originally, 
and I'm the current maintainer.

[snip]
>> If you use schema2xml you don't really need an XML schema, you can 
>> just define zope.schema schemas.

> The zope.schema seems like extra work for me, since I don't use it to 
> generate any screens, but I will look into it. I was just using Amara to 
> generate XML.  I have not (yet) bothered to create a relaxng schema for 
> the XML since XSLT does not require it.

Right, if you don't use it to generate screens it's indeed some extra 
work. The way I'm using schema2xml is to also be able to present forms 
for this same content. Another way I use it is to turn an object into 
its XML representation just to get its text nodes, which can then be 
fulltext indexed using the catalog.

> The most important parts of my object model are not the primitive 
> attributes (where zope.schema shines),
> but rather the complex way the domain objects are inter-related.
> I have lots of collection classes, maps, and the like. It will be 
> interesting trying to grok-ify all these relationships so that they are 
> exposed on the web.

One area I'm currently exploring is a way to use the infrastructure of 
the zc.relation index to define relations between objects. In my case 
that would be defined again using a zope.schema field.

> I have the same problem others have mentioned in recent threads,
> where my objects have a canonical URL (e.g. 
> myproject/features/processtrade)
> but are also tagged or classified in multiple ways to allow many 
> different navigations
> (e.g. myproject/businessactivities/dealcapture/features/processtrade). 
> The alternative navigations are just aliases to the same view on the 
> object.

That can be modeled using catalog search and traversers fairly nicely, I 
think. It depends a bit on the user interface requirements - in some 
cases you might need to virtually re-root the objects. I know Zope 3 has 
some infrastructure for that in some extension, but I can't recall which 
and I haven't used it yet. :)

>> I think we should start with a simple view infrastructure. The XSLT 
>> templating solution would call the xml() method on the view to get the 
>> XML representation for whatever content object is being displayed.
>>
>> The developer can implement these xml() methods themselves for each 
>> view. Most likely he will do this using some helper functions as I 
>> described above.
>>
>> Now we can build things on top of this infrastructure. Instead of 
>> creating a new xml() method each time, we can have a special kind of 
>> view that implements xml() already, and uses the adaptation 
>> infrastructure as you describe, or something like schema2xml.

> Sounds like the right approach.  I will hopefully have some time over 
> the next two weeks to work on this.

Very cool! I hope eventually we'll end up with a package that provides 
XSLT support much like this package provides Genshi support for Grok:

http://svn.zope.org/megrok.genshi/trunk/

I hope we can follow that model. If we run into limitations of the 
template pluggability, I hope will be able to extend Grok to lift them.

Regards,

Martijn