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

Re: [Zopexmlmethods-devel] Starting to work on XPathMethod, comments?

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

Do you have a planned interface yet?

--Brent

Craeg K Strong wrote:
> I will probably be implementing XPathMethod this weekend, at least a first
> cut at an implementation, based on the old one on zope.org.  I wanted to 
> check it in as soon as it passes all of its
> tests, to get all of your comments as quickly as possible.
> I need it for a customer job, so will probably move quickly.
> Hope that won't derail anyone's efforts?
> 
> --Craeg
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ZopeXMLMethods-devel mailing list
> Zop...@li...
> https://lists.sourceforge.net/lists/listinfo/zopexmlmethods-devel

Re: [Zopexmlmethods-devel] Privatizing XSLTProcessor.addParam

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

+1

> Having received a thumbs up from the other developers on the list, all 
> 2 of you :), I went ahead and modified my patch to do this.  You can 
> find it at 
> http://thehendricks.org/zxmlmethods/zxmlmethods-request-patch-v3.    
> This includes the updated unit tests and CHANGES.txt file.  If there 
> are no last objections, I will commit it, since I see that I have CVS 
> access now (thanks!)
>
> --Brent

[Zopexmlmethods-devel] Starting to work on XPathMethod, comments?

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

I will probably be implementing XPathMethod this weekend, at least a first
cut at an implementation, based on the old one on zope.org.  
I wanted to check it in as soon as it passes all of its
tests, to get all of your comments as quickly as possible.
I need it for a customer job, so will probably move quickly.
Hope that won't derail anyone's efforts?

--Craeg

Re: [Zopexmlmethods-devel] Privatizing XSLTProcessor.addParam

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

Philipp von Weitershausen wrote:
> +1

[snip]

> Craeg Strong wrote:
> 
>> +1
>>
>> --Craeg
>>
>>
>>> How would you guys feel about moving the calls to addParam() inside 
>>> transformGuts() so that what gets passed to the XSL Processor is just 
>>> a dictionary of parameters?  Then each processor can do whatever 
>>> manipulations are necessary to get the parameters into a digestible 
>>> format.  There doesn't seem to me to be a need to expose that 
>>> implementation detail to XSLTMethod (or the rest of the world).

Having received a thumbs up from the other developers on the list, all 2 
of you :), I went ahead and modified my patch to do this.  You can find 
it at http://thehendricks.org/zxmlmethods/zxmlmethods-request-patch-v3. 
    This includes the updated unit tests and CHANGES.txt file.  If there 
are no last objections, I will commit it, since I see that I have CVS 
access now (thanks!)

--Brent

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_Refactor_transformGuts_(was:_Privatizing_XSLTProcessor.addParam)?=

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

That is a good question.  It might be a  historical detail.
I can't think of a good reason, so it probably is better
to be more standard.  I guess its quite analogous to
the situation when your Page Template doesn't compile.
It throws an exception as soon as it is accessed.

OK, let's simplify and eliminate the guts :)

--Craeg


> 
> Pretending to be the devil's advocate: why would you _not_ want 
> transform to raise an exception? If transformation fails, there is most 
> likely an error in your configuration or in your XSLT script. Also, Zope 
> provides a facility to customize the display of error messages 
> (standard_error_messages). Why should XSLTMethod try to go around that 
> and display the error message in plain text, or even worse, display 
> nothing. This makes debugging very hard.
> 
> > Perhaps transformGuts() should instead be called 
> > transformOrRaiseException() or something?  It might be 
> > simply a case of poor naming...
> 
> Looks like it...
> 
> > Is there a Zope3 convention that might be helpful here?
> 
> Well, yeah. Exceptions are defined in the interface modules and are 
> being raised when appropriate. This is the convention ;)
> 
> Philipp

[Zopexmlmethods-devel] Refactor transformGuts (was: Privatizing XSLTProcessor.addParam)

[Philipp v. W. <ph...@we...>]

Craeg Strong wrote:
> Here is the theory behind the "guts" :)
> 
> transform()
>    Never throws an exception.  Success/error messages
>    are returned as a string
> 
> transformGuts() 
>    Throws an exception in the case of error.  Returns
>    a string only in the success case
> 
> Making transformGuts part of the interface makes it possible
> for someone to call this from another Zope Product that
> wants to capture exceptions.  For example: ZOODocument :-)
> Alternatively, you might capture exceptions in a 
> PythonScript and display them in some other way (?)
> 
> Removing the method results in a loss of information
> b/c there is no way to programmatically tell if an
> error has happened.

Pretending to be the devil's advocate: why would you _not_ want 
transform to raise an exception? If transformation fails, there is most 
likely an error in your configuration or in your XSLT script. Also, Zope 
provides a facility to customize the display of error messages 
(standard_error_messages). Why should XSLTMethod try to go around that 
and display the error message in plain text, or even worse, display 
nothing. This makes debugging very hard.

> Perhaps transformGuts() should instead be called 
> transformOrRaiseException() or something?  It might be 
> simply a case of poor naming...

Looks like it...

> Is there a Zope3 convention that might be helpful here?

Well, yeah. Exceptions are defined in the interface modules and are 
being raised when appropriate. This is the convention ;)

Philipp

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_Re:_Privatizing_XSLTProcessor.addParam?=

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

Here is the theory behind the "guts" :)

transform()
   Never throws an exception.  Success/error messages
   are returned as a string

transformGuts() 
   Throws an exception in the case of error.  Returns
   a string only in the success case

Making transformGuts part of the interface makes it possible
for someone to call this from another Zope Product that
wants to capture exceptions.  For example: ZOODocument :-)
Alternatively, you might capture exceptions in a 
PythonScript and display them in some other way (?)

Removing the method results in a loss of information
b/c there is no way to programmatically tell if an
error has happened.

Perhaps transformGuts() should instead be called 
transformOrRaiseException() or something?  It might be 
simply a case of poor naming...

Is there a Zope3 convention that might be helpful here?

--Craeg 

> +1
> 
> Also, I think this transformGuts method is very ugly, especially because 
> it's mentioned in the interface. Processors should only have a transform 
> method. What they define beyond that internally should not be part of 
> the API documentation. Or is there a use case where you would actually 
> call transformGuts from outside a processor?
> 
> Craeg Strong wrote:
> > +1
> > 
> > --Craeg
> > 
> > 
> >>How would you guys feel about moving the calls to addParam() inside 
> >>transformGuts() so that what gets passed to the XSL Processor is just a 
> >>dictionary of parameters?  Then each processor can do whatever 
> >>manipulations are necessary to get the parameters into a digestible 
> >>format.  There doesn't seem to me to be a need to expose that 
> >>implementation detail to XSLTMethod (or the rest of the world).
> >>
> >>--Brent
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > ZopeXMLMethods-devel mailing list
> > Zop...@li...
> > https://lists.sourceforge.net/lists/listinfo/zopexmlmethods-devel
> > 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ZopeXMLMethods-devel mailing list
> Zop...@li...
> https://lists.sourceforge.net/lists/listinfo/zopexmlmethods-devel
> 

Re: [Zopexmlmethods-devel] Privatizing XSLTProcessor.addParam

[Philipp v. W. <ph...@we...>]

+1

Also, I think this transformGuts method is very ugly, especially because 
it's mentioned in the interface. Processors should only have a transform 
method. What they define beyond that internally should not be part of 
the API documentation. Or is there a use case where you would actually 
call transformGuts from outside a processor?

Craeg Strong wrote:
> +1
> 
> --Craeg
> 
> 
>>How would you guys feel about moving the calls to addParam() inside 
>>transformGuts() so that what gets passed to the XSL Processor is just a 
>>dictionary of parameters?  Then each processor can do whatever 
>>manipulations are necessary to get the parameters into a digestible 
>>format.  There doesn't seem to me to be a need to expose that 
>>implementation detail to XSLTMethod (or the rest of the world).
>>
>>--Brent
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ZopeXMLMethods-devel mailing list
> Zop...@li...
> https://lists.sourceforge.net/lists/listinfo/zopexmlmethods-devel
> 

Re: [Zopexmlmethods-devel] Re: Zope3 XML sprint

[Philipp v. W. <ph...@we...>]

Hi Brent, hi all,

good news, Martijn checked in our xslt and xslt_examples products. Check 
them out at
   http://cvs.zope.org/zopeproducts/xslt
and
   http://cvs.zope.org/zopeproducts/xslt_examples
respectively

> I'm thrilled to hear that Zope 3 is including XML support.  I am a 
> little concerned by the references to XML Schema, though.  Is there 
> support for other schema languages, like DTDs, RelaxNG, etc?  Or just 
> the W3C XML Schema?  Many in the document markup world (as opposed to 
> data markup) have objections to XML Schemas.  I would hate to see Z3 
> tied solely to that technology for its XML support.

Don't worry. Zope3 wouldn't be Zope3 if tied you to a certain standard. 
That's actually the beauty of the Component Architecture. You can 
replace components with your own ones as long as they fulfill the interface.

Also, don't think that we already have full support for W3C Schemas. The 
_only_ thing our implementation does is read the schemaLocation 
attribute from the document element and try to find the interface object 
for that. Zope3 has currently no "idea" what a W3C schema is. It just 
deals with unique identifiers.

So, if you provide an XSLT style sheet that transforms to HTML, you need 
to provide a unique identifier for an "HTML schema". Obviously, there is 
no such thing, but Zope needs something there.

If you look at the configuration directives of our xslt_examples product 
(http://cvs.zope.org/zopeproducts/xslt_examples/configure.zcml?rev=HEAD), 
it needs to declare a schema for HTML just by giving some (fake) unique 
identifier. Whether that is actually a DTD, a W3C Schema, a RELAX NG or 
nothing doesn't matter in the moment.

 > Also, part of the
> beauty of XML is that in many instances you don't *need* a schema. 
> Well-formedness is enough.  Z3 should be able to accomodate those 
> use-cases as well.

Yes, it already does. If you don't want to provide a schema, then don't 
do it. If you still would like to be able to hook adapters and views to 
certain XML documents, then you need to provide a unique identifier. As 
already mentioned, this is just an identifier for the moment. Zope3 will 
probably support fetching schemas from their URI and parsing them, but 
this will totally optional and, of course, pluggable so that you can 
plug-in your own schema engine.

Philipp

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_[Zopexmlmethods-devel]_Privatizing_XSLTProcessor.addParam?=

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

+1

--Craeg

> How would you guys feel about moving the calls to addParam() inside 
> transformGuts() so that what gets passed to the XSL Processor is just a 
> dictionary of parameters?  Then each processor can do whatever 
> manipulations are necessary to get the parameters into a digestible 
> format.  There doesn't seem to me to be a need to expose that 
> implementation detail to XSLTMethod (or the rest of the world).
> 
> --Brent

[Zopexmlmethods-devel] Privatizing XSLTProcessor.addParam

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

How would you guys feel about moving the calls to addParam() inside 
transformGuts() so that what gets passed to the XSL Processor is just a 
dictionary of parameters?  Then each processor can do whatever 
manipulations are necessary to get the parameters into a digestible 
format.  There doesn't seem to me to be a need to expose that 
implementation detail to XSLTMethod (or the rest of the world).

--Brent

Re: [Zopexmlmethods-devel] Re: Zope3 XML sprint

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

Philipp von Weitershausen wrote:
> We also implemented very simple XSLT support (in a separate product, however).
> XSLT sheets in the Zope3 sense are adapters that adapt from one schema to
> another. We first implemented a XSLT processor utility based on the 4Suite
> library (can be replaced by a different utility implementing the same interface).
> 
> The unit test actually declares an adapter from one XML schema to another and
> uses an XSLT sheet for it and it works. We just didn't get it to work in reality

I'm thrilled to hear that Zope 3 is including XML support.  I am a 
little concerned by the references to XML Schema, though.  Is there 
support for other schema languages, like DTDs, RelaxNG, etc?  Or just 
the W3C XML Schema?  Many in the document markup world (as opposed to 
data markup) have objections to XML Schemas.  I would hate to see Z3 
tied solely to that technology for its XML support.  Also, part of the 
beauty of XML is that in many instances you don't *need* a schema. 
Well-formedness is enough.  Z3 should be able to accomodate those 
use-cases as well.

--Brent

[Zopexmlmethods-devel] Re: Zope3 XML sprint

[Philipp v. W. <ph...@we...>]

Hi,

> > You should look what we did for XML in Zope3 just these past days during
> > the sprint. It's amazing and will make things like XSLT really easy...
> 
> I am sorry I missed that!  What did you
> guys do?  Where can I get more information?

We basically hooked up XML to Zope3's Component Architecture. Like Zope3
schemas, XML Schemas can be used to describe a certain content type (in this
case an XML content type). They can be used in exchange for normal Python
interfaces almost everywhere.

We implemented a very simple XML Document content object which parses the XML
and looks for schema declarations. If it finds any, it will automatically change
its __implements__ so it will implement it. You can then for example define a
special view for that XML Schema and you will be able to use that view on the
content object.

You'll find a little more information in zope/app/xml/README.txt
(http://cvs.zope.org/Zope3/src/zope/app/xml/README.txt?rev=HEAD) and examples in
zopeproducts/xml_examples (http://cvs.zope.org/zopeproducts/xml_examples/).

We also implemented very simple XSLT support (in a separate product, however).
XSLT sheets in the Zope3 sense are adapters that adapt from one schema to
another. We first implemented a XSLT processor utility based on the 4Suite
library (can be replaced by a different utility implementing the same interface).

The unit test actually declares an adapter from one XML schema to another and
uses an XSLT sheet for it and it works. We just didn't get it to work in reality
(outside the unit test). Must be a very small problem, but we ran out of time
yesterday evening.
I am sure the XLST product including examples will be checked in the next days
or so...

Philipp

[Zopexmlmethods-devel] Interfaces package (was: Creating a separate processors package)

[Philipp v. W. <ph...@we...>]

Hi,

> OK, I will handle that.
 
> OK, consistency with Zope3 is good, however, if the
> processors package is to really be a separable, reusable
> component, it should probably also own its interface, no?

Yes

> So I vote for the IXSLTProcessor interface to be
> moved to the processor package.

Yes, to processors/interfaces.py

Philipp

[Zopexmlmethods-devel] =?iso-8859-1?Q?Zope3_XML_sprint?=

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

> You should look what we did for XML in Zope3 just these past days during
> the sprint. It's amazing and will make things like XSLT really easy...

I am sorry I missed that!  What did you 
guys do?  Where can I get more information?

--Craeg

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_[Zopexmlmethods-devel]_Re:_Creating_a_separate_=?=

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

> Unfortunately, my laptop just broke and I don't have a good testing environment
> etc. Either someone else will have to do the change or we'll have to wait until
> my laptop works again ;(

OK, I will handle that.

> Also, I would like to move all interfaces to an interfaces.py module. Zope3
> separates interfaces from implementation that way very cleanly. Currently we
> have modules for each interface except for GeneratorRegistry and Generators.
> This is over-kill and inconsistent.

OK, consistency with Zope3 is good, however, if the
processors package is to really be a separable, reusable
component, it should probably also own its interface, no?

So I vote for the IXSLTProcessor interface to be
moved to the processor package.

--Craeg  

[Zopexmlmethods-devel] Re: Creating a separate "processors" package (was: cvs administration)

[Philipp v. W. <ph...@we...>]

Hi all,

somehow I wasn't getting messages from the list, that's why I always start a new
thread. I went and changed some settings of my SF.net account and I hope they
did it...

>  Let me see if I understand your reasons.  Putting the processor specific 
>  code
>  in a separate Python package will emphasize the separation of concerns and
>  enhance reusability for other projects.   In effect, we are creating the 
>  beginnings
>  of a separately distributable abstraction layer along the lines of JAXP.
>  
>  Separating them in this way also makes it more clear that they can evolve
>  independently from the rest of ZopeXmlMethods, as long as the interface 
>  does not change.

Yes...

Unfortunately, my laptop just broke and I don't have a good testing environment
etc. Either someone else will have to do the change or we'll have to wait until
my laptop works again ;(

Also, I would like to move all interfaces to an interfaces.py module. Zope3
separates interfaces from implementation that way very cleanly. Currently we
have modules for each interface except for GeneratorRegistry and Generators.
This is over-kill and inconsistent.

Philipp

Re: [Zopexmlmethods-devel] Re: Re: [Zopexmlmethods-devel] RE: Overriding parameters with REQUEST

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

Brent Hendricks wrote:

> Craeg Strong wrote:
>
>>> Did you have any thoughts about my suggestion to move
>>> getXSLParameters() into XSLTMethod? 
>>
>   The patch implementing this a little larger, so I put it at
> http://thehendricks.org/zxmlmethods/zxmlmethods-request-patch-v2 

Yes, it looks as I expected it to.   Philipp is about to refactor the 
processor
stuff into a separate package, so we should coordinate this change.  
(Philipp
are you already in process?  If so, you should probably just add this to 
your
list since you will be in that code.  If not, I can do it Saturday)

> After looking at it for a bit, it definitely looks like it will make
> testing Zope Products pretty straightforward. 

yep.  I can't imagine testing without it.  You have a full REQUEST object,
folders, permissions,  and a running ZPublisher instance, so you can do
virtually anything you could do in the ZMI.

In fact, to a certain extent it even affects the design of 
ZopeXMLMethods, because
I like to design for testability.

> I have a question about tests 7 and 8 now that I'm moving
> getXSLParameters() into XSLTMethod:  wouldn't it be better to test the
> getXSLParamaters() method by itself to verify that it was grabbing
> parameters correctly without actually doing a transformation?  Then we
> could have a separate test for passing parameters to the XSLTProcessor.
>  It just just seems more in the unit test spirit of "test one thing". 

Yes.  In fact, you should check out the code in TestXSLTProcessor.py
where I do a loop through all available processors and test the output 
of each one.
Your test should probably do the same thing to ensure that parameters
work for each and every one.  I don't have *every* processor installed 
on *every*
operating system, but between windows 2000 and Linux I have at least one
installation of each one.  So I am happy to help out with testing.

My next project is going to be recompiling Zope  with Python 2.2 and 
trying that
out.  Apparently, the Python XML libraries behave significantly better 
under 2.2
there were some changes under the hood that dramatically decrease memory
usage and such.  For example: docbook  is virtually unusable under 
python 2.1.x
and apparently runs ok under python 2.2 

What OS/Zope(s) are you using, out of curiousity?

--Craeg

Re: [Zopexmlmethods-devel] Re: Re: [Zopexmlmethods-devel] RE: Overriding parameters with REQUEST

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

Craeg Strong wrote:
>>Did you have any thoughts about my suggestion to move
>>getXSLParameters() into XSLTMethod?  I'd be happy to put together a
>>patch for that as well.
> 
> 
> Yes, I think its the right thing to do.  There is nothing
> processor-specific about grabbing the params, so
> why should the method be in a processor specific class?

Agreed.  The patch implementing this a little larger, so I put it at
http://thehendricks.org/zxmlmethods/zxmlmethods-request-patch-v2

> I think you will be amazed how easy it is to add
> a test-- ZopeTestCase rocks!  

After looking at it for a bit, it definitely looks like it will make
testing Zope Products pretty straightforward.

I have a question about tests 7 and 8 now that I'm moving
getXSLParameters() into XSLTMethod:  wouldn't it be better to test the
getXSLParamaters() method by itself to verify that it was grabbing
parameters correctly without actually doing a transformation?  Then we
could have a separate test for passing parameters to the XSLTProcessor.
  It just just seems more in the unit test spirit of "test one thing".

--Brent

[Zopexmlmethods-devel] Creating a separate "processors" package (was: cvs administration)

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

Philipp von Weitershausen wrote:

>>I assume you mean refactoring, yes?
>>    
>>
>Yes, I would like to move all processor packages to a "processors" package, for
>instance. Feedback?
>
Let me see if I understand your reasons.  Putting the processor specific 
code
in a separate Python package will emphasize the separation of concerns and
enhance reusability for other projects.   In effect, we are creating the 
beginnings
of a separately distributable abstraction layer along the lines of JAXP.

Separating them in this way also makes it more clear that they can evolve
independently from the rest of ZopeXmlMethods, as long as the interface 
does not
change.

Sounds like a fine idea!

--Craeg

[Zopexmlmethods-devel] Re: cvs administration

[Philipp v. W. <phi...@ph...>]

Hi,

> When you create a branch,
> - it is harder for others to see what you are doing
> - the eventual merge gets more difficult over time
> - you lose the intangible benefits of collaboration

Agreed. But sometimes you may also create conflicts... However, I guess the
mailinglist is a good way to coordinate development then.

> Having said that, there may well be reason to create a branch,
> but why don't you try first giving your ideas an airing on the mailing list,
> and see if we can't implement some or all of them on the mainline?

We can. I have no problem with that.

> Personally, I am a big fan of merciless refactoring, as long as it is
> backed by a strong suite of tests.  When you say "purely structural"
> I assume you mean refactoring, yes?

Yes, I would like to move all processor packages to a "processors" package, for
instance. Feedback?

Philipp

Re: [Zopexmlmethods-devel] cvs administration

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

I like the naming conventions, they look fine...

..but urge caution as far as creating CVS branches goes.

When you create a branch,
- it is harder for others to see what you are doing
- the eventual merge gets more difficult over time
- you lose the intangible benefits of collaboration

Having said that, there may well be reason to create a branch,
but why don't you try first giving your ideas an airing on the mailing list,
and see if we can't implement some or all of them on the mainline?

Personally, I am a big fan of merciless refactoring, as long as it is
backed by a strong suite of tests.  When you say "purely structural"
I assume you mean refactoring, yes?

--Craeg

Philipp von Weitershausen wrote:

>Hi all(?),
>
>I just got my CVS checkout. I have some plans and ideas, one of them are purely
>structural. I propose that I will make my own branch which I would call
>'philikon-branch'. How shall we name branches and tags? Upper case, lower case,
>camel case?
>
>I propose:
>
>- tags uppercase and underscores, e.g. RELEASE_1_0
>
>- branches lowercase and hyphens, e.g. philikon-branch
>
>- merge tags on the branch mixed, e.g. philikon-RENAMING_MERGE
>
>Comments?
>
>Philipp
>  
>

[Zopexmlmethods-devel] cvs administration

[Philipp v. W. <ph...@we...>]

Hi all(?),

I just got my CVS checkout. I have some plans and ideas, one of them are purely
structural. I propose that I will make my own branch which I would call
'philikon-branch'. How shall we name branches and tags? Upper case, lower case,
camel case?

I propose:

- tags uppercase and underscores, e.g. RELEASE_1_0

- branches lowercase and hyphens, e.g. philikon-branch

- merge tags on the branch mixed, e.g. philikon-RENAMING_MERGE

Comments?

Philipp

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_Re:_[Zopexmlmethods-devel]_RE:_Overriding_parameters_with_REQUEST?=

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

> Did you have any thoughts about my suggestion to move
> getXSLParameters() into XSLTMethod?  I'd be happy to put together a
> patch for that as well.

Yes, I think its the right thing to do.  There is nothing
processor-specific about grabbing the params, so
why should the method be in a processor specific class?

> > Would you be willing to add a test or two for this
> > new behavior to the unit test suite?  It should 
> 
> OK, I'll take a look at it.  Any suggestions for examples to follow?

Why don't you take a look at TestXSLTMethod.py, 
test_07 tests scalar parameters and test_08
tests object parameters.  All you need to do
is create (at least) two more tests (test_31 and test_32)
that are a duplicate of these except that they
override the parameters via self.app.REQUEST, 
and then use self.assertEquals() to ensure
they get the properly overridden results. 
 
Another good test would be to override the value
with the *same* value, to make sure that doesn't
somehow mess something up.    

I think you will be amazed how easy it is to add
a test-- ZopeTestCase rocks!  

BTW, the reason the test methods are numbered that way is
so they execute in order.  Otherwise I have a 
hard time matching the results to the test...

--Craeg

Re: [Zopexmlmethods-devel] RE: Overriding parameters with REQUEST variables

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

Craeg Strong wrote:
> I like your proposal!  
> 
> Please send your patch to the list; I am 
> eager to take a look at it. 

OK.  Here is the first stab.  As I mentioned before, it's currently
libxslt only.  Did you have any thoughts about my suggestion to more
getXSLParameters() into XSLTMethod?  I'd be happy to put together a
patch for that as well.

> Would you be willing to add a test or two for this
> new behavior to the unit test suite?  It should 

OK, I'll take a look at it.  Any suggestions for examples to follow?

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