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

[Craeg Strong]

Martijn Faassen wrote:
> Hello,
>
> Craeg Strong wrote:
> [snip]
>
> Do you mean that your browser is sending XML to the server?
yes
>> 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!
>
>> That is why I sometimes make the business objects themselves know how to
>> transform themselves to and from XML as a first step (self-adapters ?) 
> > and then later on on in the process I can
> > always decouple that via a simple refactoring if needed or desired.
> > As a matter of taste, I liken that to keeping unit tests inside the
> > code, as a way to simplify maintenance.
>
> They don't have to know themselves, right? You can just define normal 
> adapters to do this. Some other code will then use these adapters. Oh, 
> perhaps you mean this: if your object implements the interface you 
> want to adapt to, any adaptation request to that interface will return 
> the object itself. That way you can start out putting the knowledge in 
> the objects and factor it out later. Sure, that is a reasonable 
> approach as well. Note that in Grok it's so easy to create adapters 
> it's almost as simple to write them right away.
Agreed.  I have a pre-existing bunch of Amara code that transforms my 
pure Python code (no Zope) to and from XML, and my lazy first step was 
to make the objects themselves implement the XmlAdapter interface, but I 
will likely refactor soon.
> 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.

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.
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.
> 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.

--Craeg
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev