zopexmlmethods-devel — List for developers interested in maintaining and extending ZopeXMLMethods

[Zopexmlmethods-devel] =?iso-8859-1?Q?RE:_Overriding_parameters_with_REQUEST_variables?=

[Craeg S. <cs...@ar...>]

I like your proposal!  

Please send your patch to the list; I am 
eager to take a look at it.  

Would you be willing to add a test or two for this
new behavior to the unit test suite?  It should 
be a piece of cake, and will guard against any
regressions.  So far, I have been extremely rigorous
in my testing, and have added a new test case for every
new feature and against every bug I found.
The test suite and the documentation are two of the
biggest differentiators for ZopeXmlMethods, IMHO.

--Craeg

[Zopexmlmethods-devel] Overriding parameters with REQUEST variables

[Brent M H. <br...@ec...>]

As I mentioned in my previous email, I need the behavior of allowing 
REQUEST variables to override stylesheet parameters.  This allows 
individual users to see customized behaviors based on session data, 
cookies, or form data.

Primarily this involves editing getXSLParameters() to query the REQUEST 
object for each parameter.  However, this means that getXSLParameters() 
needs to receive REQUEST, so I modified the .transform() method to pass 
it along.

I've made the changes for LibXsltProcessor.py, and it should be trivial 
to do it for the other processors as well[1].  It seems to work as 
intended, although I can't claim to have do extensive testing.  I can 
post the patch if you are interested.

--Brent

[1]  While looking at this, I noticed that the exact same 
getXSLParameters() code is replicated in every processor implementation. 
  Would it perhaps be better to move this code into the XSLTMethod class 
and then pass the parameters as a dictionary to processor.transform()?



-------------------------------------------------------------------------

"The programmer, like the poet, works only slightly removed from pure
  thought-stuff.  He builds his castles in the air, from air, creating
  by exertion of the imagination.  Few media of creation are so
  flexible, so easy to polish and rework, so readily capable of
  realizing grand conceptual structures."
                         -- Frederick Brooks, Jr., The Mythical Man Month

[Zopexmlmethods-devel] Re: [xml] python binding for xmlCatalogAddLocal() ?

[Brent M H. <br...@ec...>]

Craeg K Strong wrote:
>> I agree, that sounds like the right way to do it.  But does libxslt use
>> the XML catalog for import/include resolution?  I was under the
>> impression that it only happened for DTD lookups. 
> 
> 
> Not sure.  That would be unfortunate and unusual.  Most other products I 
> have seen use it for all.

I'll try to look into it.

>>> I will also be looking for interested parties to become committers 
>>> (hint, hint :)
>>
>>
>> Sure, I'd be happy to help out.  My SF ID is 'bmh' 
> 
> 
> That is great news!  I am a bit new to the protocol of all this.   
> Philipp is the other committer on this
> project so far.   I believe the next steps would be to provide a bit of 
> information in the way of
> background and particular areas/ideas where you would like to move the 
> project forward,
> and, of course, code speaks ;-)

OK let's see, background.  I'm the systems architect for the Connexions 
project at Rice University (http://cnx.rice.edu).  We have a repository 
of educational content modules in XML that we serve through Zope. 
Currently we use a home brewed XSLT Product for transformations, but I 
would like to use a more general tool.  Hence my interest in 
XMLTransform, and now ZopeXMLMethods.

As far as ideas/goals, my main goal is to make sure it works for our 
project :)  OK, I admit it's somewhat self-serving, but I expect others 
have similar needs to ours.

The first thing I needed was for ZopeXMLMethods to allow REQUEST 
variables to override stylesheet parameters.  I have a patch that seems 
to work pretty well (although it hasn't undergone extensive testing). 
I'll send another email describing it.

-- Brent

-------------------------------------------------------------------------

"The programmer, like the poet, works only slightly removed from pure
  thought-stuff.  He builds his castles in the air, from air, creating
  by exertion of the imagination.  Few media of creation are so
  flexible, so easy to polish and rework, so readily capable of
  realizing grand conceptual structures."
                         -- Frederick Brooks, Jr., The Mythical Man Month

[Zopexmlmethods-devel] Re: [xml] python binding for xmlCatalogAddLocal() ?

[Craeg K S. <cs...@ar...>]

I would like to move this discussion over to ZopeXMLMethods-devel
That way we have archiving, searching, etc...

Brent Hendricks wrote:

> Craeg K Strong wrote:
>
>> The local Catalog support might be the path of least resistance.  
>> With catalogs you can use rewriteURI
>> rules to effectively turn any URN into a URL.  This is in some ways 
>> even better than my URN resolver
>> algorithm because it is not hardcoded-- the "algorithm" is contained 
>> in the catalog file.  In practice,
>> I have never needed a more complicated algorithm than what Catalogs 
>> provide with rewriteURI.
>
> I agree, that sounds like the right way to do it.  But does libxslt use
> the XML catalog for import/include resolution?  I was under the
> impression that it only happened for DTD lookups. 

Not sure.  That would be unfortunate and unusual.  Most other products I 
have seen use it for all.

>> It would be nice to have both, but I would love to see local catalogs 
>> (i.e. thread safe catalogs)
>> implemented first.
>> Other news: I have changed the name of the project from XMLTransform 
>> to ZopeXMLMethods.
>> It is now a sourceforge project.  I am in the middle of registering 
>> it and populating the CVS repository.
>> There will be a 1.0 release shortly, and I will put a link from the 
>> zope.org place to the sourceforge
>> site.
>
> Thanks, I downloaded it and poked around for a bit.  Looks nice!  I 
> like the direct application as a method.  As you observed, much more 
> Zopish :) 

Philipp deserves much credit for this

>> I will also be looking for interested parties to become committers 
>> (hint, hint :)
>
> Sure, I'd be happy to help out.  My SF ID is 'bmh' 

That is great news!  I am a bit new to the protocol of all this.   
Philipp is the other committer on this
project so far.   I believe the next steps would be to provide a bit of 
information in the way of
background and particular areas/ideas where you would like to move the 
project forward,
and, of course, code speaks ;-)

Regards,

--Craeg