We need per-instance XML setups
Document Actions
Submitted by
cbearden.
on 2006-06-12 17:11.
Having a single, global XML installation (including XSLT and CSS) per host is too limiting.
Doubtless there are some good reasons for the current way of doing per-host XML setups. The downside is that when you run more than one instance on a host, each instance is constrained to use the same XSLT files. This strikes me as a very artificial constraint. At the very least, an instance ought to be able to override the global XSLT (and CSS, for that matter!) with a local copy. At the very least.
Right now, my workstation hosts my dev instance and Max's. Max changes the XSLT quite a bit. I need to be able to do the same. However, any changes I would make would collide with Max's.
But even apart from this local, contingent issue, it just seems right that an instance should be able to override the global XML.
Re: We need per-instance XML setups
Posted by
jccooper
at
2006-06-13 17:14
Added to to-do list.
Re: We need per-instance XML setups
Posted by
jccooper
at
2006-06-13 17:20
CSS should be per-instance, since it lives in skins. The XSLT should be also per-instance, since it's a path relative to the RhaptosContent product. What exactly are you having problems with in these cases?
The XML stuff (mostly or entirely DTDs, I think) is global. Dunno how it could be made to work per-instance; ask Ross.
The XML stuff (mostly or entirely DTDs, I think) is global. Dunno how it could be made to work per-instance; ask Ross.
Re: Re: We need per-instance XML setups
Posted by
cbearden
at
2006-06-14 17:11
Perhaps I'm confused. Where is the template that renders a module as XHTML? I thought it would be CNXPloneSite/skins/cnx_overrides/cnxml_transform.py, but modifying that to point to a different set of XSLT doesn't work.
Re: Re: Re: We need per-instance XML setups
Posted by
jccooper
at
2006-06-14 18:53
That's 'module_render'. It's in two products, and I think the CNXPloneSite one is the operative one.
It works by first calling 'module_export_template', and then calls 'cnxml_transform' on that. This takes a 'stylesheet' parameter that is set to the value of RhaptosContent.MODULE_XSL. This points to the RhaptosContent/www/content_render.xsl file in the product.
What happens in cnxml_transform is that the specified XSL stylesheet is used (unless it's not specified, in which case the cnx.rice.edu unibrowser is used) in the xsltPipeline call, which is where I stop tracing.
So if you really have your own instance (with a separate RhaptosContent) it shouldn't be a problem.
It works by first calling 'module_export_template', and then calls 'cnxml_transform' on that. This takes a 'stylesheet' parameter that is set to the value of RhaptosContent.MODULE_XSL. This points to the RhaptosContent/www/content_render.xsl file in the product.
What happens in cnxml_transform is that the specified XSL stylesheet is used (unless it's not specified, in which case the cnx.rice.edu unibrowser is used) in the xsltPipeline call, which is where I stop tracing.
So if you really have your own instance (with a separate RhaptosContent) it shouldn't be a problem.
Re: Re: Re: Re: We need per-instance XML setups
Posted by
cbearden
at
2006-06-14 22:58
And RhaptosContent/www/content_render.xsl includes unibrowser.xsl from the default location to provide the bulk of the transform of CNXML elements. It looks then like it's in content_render.xsl that I need to adjust the path. I'll give that a try.
Re: Re: Re: Re: Re: We need per-instance XML setups
Posted by
cbearden
at
2006-06-14 23:09
Yes, that did the trick. I wonder if path information like this shouldn't be set in some central location and imported from there?
Re: Re: We need per-instance XML setups
Posted by
cbearden
at
2006-06-14 17:13
As for the XML validation stuff, that would be done by creating a different catalog file and getting the relevant products to start resolving paths to schemas from it rather than from the global default catalog. It's probably just a matter of finding the products that need to be adjusted and documenting it. Likewise with the XSLT, but ideally it should be doable through the management interface, IMO.
