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

Re: [Zopexmlmethods-devel] Override variable definitions via query string?

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

Philipp von Weitershausen wrote:
>> kw.update(REQUEST.form)
> 
> 
> Please correct me if I'm wrong but I don't think REQUEST.form is quite 
> enough because it only contains form values. We'd need at least 
> REQUEST.other, but looking at the (quite ugly) code of HTTPRequest, I'd 
> say:
> form
> cookies
> environ
> other

I think that might be overkill.  Just because something appears in 
REQUEST doesn't make it an automatic candidate for stylesheet 
parameters.  There is a definite use case for REQUEST.form and I could 
probably make one for REQUEST.cookies.  But the others strike me as 
unnecessary and even unwanted, since neither the user nor the stylesheet 
creator has direct control over them.

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

Re: [Zopexmlmethods-devel] Override variable definitions via query string?

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

Brent Hendricks wrote:
> Philipp von Weitershausen wrote:
> 
>> As mentioned above, you'd really like to pass a parameters as a 
>> keyword argument to __call__, wouldn't you?
>> Why not make __call__ accept arbitrary keyword arguments (**kw)? Also,
> 
> 
> +1, as long as REQUEST parameters are still allowed to override them. My 
> suggestion to implement this would be to do:
> 
> kw.update(REQUEST.form)

Please correct me if I'm wrong but I don't think REQUEST.form is quite 
enough because it only contains form values. We'd need at least 
REQUEST.other, but looking at the (quite ugly) code of HTTPRequest, I'd say:
.form
.cookies
.environ
.other

Any objections?

Phil

Re: [Zopexmlmethods-devel] Override variable definitions via query string?

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

Craeg K Strong wrote:
> Hello:
> 
> I am using the latest and greatest ZopeXMLMethods from CVS, and I wanted
> to override an xsl:param dynamically.
> 
> My specific example is this:  I have a transformer that renders HTML for an
> arbitrary "article" doctype.  For most articles, you don't want a table 
> of contents.
> So I have the following at the top of article.xsl:
> 
> <xsl:param name="toc">no</xsl:param>
> 
> But for official project documents, we _do_ want a table of contents.
> Here, in my naivete, is that I tried to do inside my page template:
> 
>          <div tal:define="doc nocall:python:folder[docname]" >
>             <div tal:replace="structure doc/articlexsl?toc='yes'"/>
>          </div>

Unfortunately, the override support I added only works with REQUEST 
variables, which aren't set by TALES expressions.  So you could access 
doc/articlexsl?toc='yes' as a URL in your browser, but not within a page 
template.

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

Re: [Zopexmlmethods-devel] Override variable definitions via query string?

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

Philipp von Weitershausen wrote:
> As mentioned above, you'd really like to pass a parameters as a keyword 
> argument to __call__, wouldn't you?
> Why not make __call__ accept arbitrary keyword arguments (**kw)? Also,

+1, as long as REQUEST parameters are still allowed to override them. 
My suggestion to implement this would be to do:

kw.update(REQUEST.form)

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

Re: [Zopexmlmethods-devel] Override variable definitions via query string?

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

Craeg K Strong wrote:
> Philipp von Weitershausen wrote:
> 
>> Hi Craeg,
>>
>>> But for official project documents, we _do_ want a table of contents.
>>> Here, in my naivete, is that I tried to do inside my page template:
>>>
>>>          <div tal:define="doc nocall:python:folder[docname]" >
>>
>>
>> nocall:python: is overhead. Simply do
>>            <div tal:define="doc python:folder[docname]"> 
> 
> 
> So its only required if not using "python:" ?

It is necessary if you don't want the tales engine to call the result 
object. For example, if you want to define doc to be a Page Template 
called 'doc.html' in the current folder, here/doc.html will traverse to 
the Page Template *and* call it (which means it will be rendered). 
nocall:here/doc.html prohibits calling it and returns the object instead.

>>>             <div tal:replace="structure doc/articlexsl?toc='yes'"/>
>>
>> tales does not allow URL syntax. You will have to call it using a 
>> python expression:
>>         <div tal:replace="structure python:doc.articlexsl(toc='yes')">
>>
>> Now, that's the way you'd want it to work. It won't work 
>> unfortunately, because <snip/>
> 
> I agree. Let's work to make this happen. I always hated XSLparameters
>  as well. If you think you can get to it this week, great. If not, I
> will take a stab at it. I really need this functionality. Its not
> much work-- about the same amount of changes to tests as real code...

I will try to make the changes as quickly as possible. I would have to 
do them this week anyway because I'm leaving for Mexico on Friday.

Phil

Re: [Zopexmlmethods-devel] Override variable definitions via query string?

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

Philipp von Weitershausen wrote:

> Hi Craeg,
>
>> But for official project documents, we _do_ want a table of contents.
>> Here, in my naivete, is that I tried to do inside my page template:
>>
>>          <div tal:define="doc nocall:python:folder[docname]" >
>
> nocall:python: is overhead. Simply do
>            <div tal:define="doc python:folder[docname]"> 

So its only required if not using "python:" ?

>>             <div tal:replace="structure doc/articlexsl?toc='yes'"/>
>
> tales does not allow URL syntax. You will have to call it using a 
> python expression:
>         <div tal:replace="structure python:doc.articlexsl(toc='yes')">
>
> Now, that's the way you'd want it to work. It won't work 
> unfortunately, because <snip/>

I agree.  Let's work to make this happen.  I always hated XSLparameters 
as well.
If you think you can get to it this week, great.  If not, I will take a 
stab at it.  I
really need this functionality.  Its not much work-- about the same 
amount of changes
to tests as real code...

--Craeg

Re: [Zopexmlmethods-devel] Override variable definitions via query string?

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

Hi Craeg,

> But for official project documents, we _do_ want a table of contents.
> Here, in my naivete, is that I tried to do inside my page template:
> 
>          <div tal:define="doc nocall:python:folder[docname]" >
nocall:python: is overhead. Simply do
            <div tal:define="doc python:folder[docname]">

>             <div tal:replace="structure doc/articlexsl?toc='yes'"/>
tales does not allow URL syntax. You will have to call it using a python 
expression:
         <div tal:replace="structure python:doc.articlexsl(toc='yes')">

Now, that's the way you'd want it to work. It won't work unfortunately, 
because XSLTMethod.__call__ really wants a request (and so does the 
transform method) and does not accept keyword arguments. That is bad!

Looking at the code, XSL parameters really come from getXSLParameters() 
which simply acquires 'XSLparameters'. As it seems, there is no way of 
passing XSL parameters dynamically. Even worse!

As mentioned above, you'd really like to pass a parameters as a keyword 
argument to __call__, wouldn't you?
Why not make __call__ accept arbitrary keyword arguments (**kw)? Also, 
is there any good reason not to expose all request variables to the 
transformation? This way, you can have meaningful URLs like
    http://aXMLsource/aXSLTMethod?output=html
    http://aXMLsource/aXSLTMethod?output=text
where as the output variable will be available in the XSLT code as a 
parameter.

IMO, the change would be rather trivial and would not necessarily break 
backward compatability (though I would like to get rid of this icky 
'XSLparameters' acquisition).

Thoughts,
Phil

[Zopexmlmethods-devel] Override variable definitions via query string?

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

Hello:

I am using the latest and greatest ZopeXMLMethods from CVS, and I wanted
to override an xsl:param dynamically.

My specific example is this:  I have a transformer that renders HTML for an
arbitrary "article" doctype.  For most articles, you don't want a table 
of contents.
So I have the following at the top of article.xsl:

<xsl:param name="toc">no</xsl:param>

But for official project documents, we _do_ want a table of contents.
Here, in my naivete, is that I tried to do inside my page template:

          <div tal:define="doc nocall:python:folder[docname]" >
             <div tal:replace="structure doc/articlexsl?toc='yes'"/>
          </div>

    * Module Products.PageTemplates.TALES, line 217, in evaluate
      *URL: /maestro/dashboard/papers*
      *Line 40, Column 13*
      *Expression: standard:"doc/articlexsl?toc='yes'"*
      *Names:*

{'container': <Folder instance at 90c5f08>,
 'default': <Products.PageTemplates.TALES.Default instance at 0x867fb74>,
 'here': <Folder instance at 90c5f08>,
 'loop': <SafeMapping instance at 8671700>,
 'modules': <Products.PageTemplates.ZRPythonExpr._SecureModuleImporter instance at 0x868decc>,
 'nothing': None,
 'options': {'args': ()},
 'repeat': <SafeMapping instance at 8671700>,
 'request': <HTTPRequest, URL=http://localhost:8080/maestro/dashboard/papers>,
 'root': <Application instance at 8e78418>,
 'template': <ZopePageTemplate at /maestro/dashboard/papers>,
 'traverse_subpath': ['p-tech-proposal.xml'],
 'user': cstrong}

    * Module Products.PageTemplates.Expressions, line 206, in __call__
    * Module Products.PageTemplates.Expressions, line 194, in _eval
    * Module Products.PageTemplates.Expressions, line 150, in _eval
      __traceback_info__: doc
    * Module Products.PageTemplates.Expressions, line 360, in
      restrictedTraverse
      __traceback_info__: {'path': ["articlexsl?toc='yes'"],
      'TraversalRequestNameStack': []}

AttributeError


Hum.  What am I doing wrong?  
Thanks in advance,

--Craeg

Re: [Zopexmlmethods-devel] SchemaValidator? DTDValidator?

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

Brent M Hendricks wrote:
> Philipp von Weitershausen wrote:
> 
>> Hi Craeg,
>>
>> Instead of answering all your question one-by-one, let me sum it up:
>>
>> Pleeeeease do not make your validator dependent on Zope specific code. 
>> Instead, I would suggest writing a utility class (e.g. DTDValidator) 
>> that implemented the interface "IValidator".
> 
> I would agree with Philipp and add that I think generalizing here is not 
> premature.  I might be able to add a RelaxNG validator soon.  It goes 
> without saying that I think your idea is a good one :)

Way cool (both things). Can we use this code for Zope3?
So, I guess you guys sit down and work on out the interface then?

Phil

Re: [Zopexmlmethods-devel] SchemaValidator? DTDValidator?

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

Philipp von Weitershausen wrote:
> Hi Craeg,
> 
> Instead of answering all your question one-by-one, let me sum it up:
> 
> Pleeeeease do not make your validator dependent on Zope specific code. 
> Instead, I would suggest writing a utility class (e.g. DTDValidator) 
> that implemented the interface "IValidator".

I would agree with Philipp and add that I think generalizing here is not 
premature.  I might be able to add a RelaxNG validator soon.  It goes 
without saying that I think your idea is a good one :)

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

Re: [Zopexmlmethods-devel] SchemaValidator? DTDValidator?

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

Hi Craeg,

Instead of answering all your question one-by-one, let me sum it up:

Pleeeeease do not make your validator dependent on Zope specific code. 
Instead, I would suggest writing a utility class (e.g. DTDValidator) 
that implemented the interface "IValidator".

Hooking this specific utility up to a Zope object that contains XML data 
should be another part of the application. This way, we can reuse this 
utility much better in Zope3. Just think about how all XSLT processor 
modules are technically usable outside Zope2 already (or they should be 
in the future).

Phil

[Zopexmlmethods-devel] =?iso-8859-1?Q?SchemaValidator=3F__DTDValidator=3F?=

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

Hello:

I need to support DTD validation for a project I am on.

I am thinking about making a new class to support this.
It will leverage the same machinery as XSLTMethod; for
example, it can use an XML Catalog to find the DTD if the
particular XML library supports it (like 4suite).

How to proceed?  One idea is to create an object
called SchemaValidator.  It would point to a schema,
the same way XSLTMethod points to an XSLT transformer.
If I had a SchemaValidator instance called validate::

  http://foo/bar/myxmldoc/validate

Would dump out the results of the validation as text
in the browser window.

Of course, all I really need right now is DTD validation.
DTDs are special because they are mentioned directly
in the DOCTYPE.  So you don't necessarily need machinery to 
point to an alternate schema.

Do you, dear reader, think that I would be guilty of
"premature generalization" to call my class SchemaValidator?
After all, there are other things one might do with
schemas, right?  For example, one could generate an HTML
form from an XMLSchema a la formulator.  That is something
different.  Should I call my class DTDValidator, with
the understanding that we can change it later if/when
it gets more general?

Thoughts?

--Craeg

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_Re:_[Zopexmlmethods-devel]_ProcessorChooser.py_got_removed=3F?=

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

So sorry! My mistake.  The code is perfectly clean, it 
is a thing of beauty...
I must learn the difference between 'cvs up' and 'cvs co'
{:-\

--Craeg

> Craeg K Strong wrote:
> > Hello:
> > 
> > A fresh CVS update no longer seems to work.  ProcessorChooser.py
> > has been removed from the respository.  Does anyone know why?
> > ahem.  We should make sure that no checkins cause the code to break....
> 
> It should still be there, I just moved it to the new processors package. 
> All tests pass on my machine here, as well as functional tests (using it 
> with real XSLT and real XML in Zope). Maybe you're trying to import it 
> from somewhere else?
> 
> I wrote an email to the list. Did you not get it? I'm really sorry if I 
> caused any trouble. I thought we had agreed on my proposal...
> 
> Best regards,
> 
> Phil
> 
> 
> 
> -------------------------------------------------------
> 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] ProcessorChooser.py got removed?

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

Craeg K Strong wrote:
> Hello:
> 
> A fresh CVS update no longer seems to work.  ProcessorChooser.py
> has been removed from the respository.  Does anyone know why?
> ahem.  We should make sure that no checkins cause the code to break....

Did you do a '-d' update?  If not, the new processors dir won't get 
updated.

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

Re: [Zopexmlmethods-devel] ProcessorChooser.py got removed?

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

Craeg K Strong wrote:
> Hello:
> 
> A fresh CVS update no longer seems to work.  ProcessorChooser.py
> has been removed from the respository.  Does anyone know why?
> ahem.  We should make sure that no checkins cause the code to break....

It should still be there, I just moved it to the new processors package. 
All tests pass on my machine here, as well as functional tests (using it 
with real XSLT and real XML in Zope). Maybe you're trying to import it 
from somewhere else?

I wrote an email to the list. Did you not get it? I'm really sorry if I 
caused any trouble. I thought we had agreed on my proposal...

Best regards,

Phil

[Zopexmlmethods-devel] ProcessorChooser.py got removed?

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

Hello:

A fresh CVS update no longer seems to work.  ProcessorChooser.py
has been removed from the respository.  Does anyone know why?
ahem.  We should make sure that no checkins cause the code to break....

--Craeg

[Zopexmlmethods-devel] Big refactoring finished

[<MWa...@t-...>]

Hi,

I have just made three checkins this morning:

- fixed the bug with large File objects
- moved all interfaces to a central interfaces module
- moved all processors to the processors package

All tests pass on my machine except the URL one which hangs :(

Best regards,

Phil

Re: [Zopexmlmethods-devel] Re: Strange Behavior with XML files >= 64k

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

Craeg Strong wrote:
> I am cc-ing this to the development mailing list.
> I think you may have identified our first bug :)
> Zope clearly has different behavior for objects > 64K
> and we probably just need to do some buffering or 
> something.  

I already have code for this in RevisionManager. I'll check it in tomorrow.

Phil

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_[Zopexmlmethods-users]_Strange_Behavior_with_XML_files_>=3D_64k?=

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

Yikes.  This is bad news.  However, please see 
the following:

http://mail.zope.org/pipermail/zope-dev/2003-April/019341.html

I am cc-ing this to the development mailing list.
I think you may have identified our first bug :)
Zope clearly has different behavior for objects > 64K
and we probably just need to do some buffering or 
something.  

Thoughts?

--Craeg

> Ever since this wonderful product has been released, I have been playing with it, and have come to a bump in the road that I simply can't get over. Here is the basic problem, let's say I have a folder called "forest" and I am populating "Forest" with uploaded files (or Add --> File in the ZMI).  Works fine, so cool -- I can FTP these trees into my forest and each renders beautifully with the magic of a modular XML transformer. OK, so it works fine _if_ the XML files are under 64Kbytes.  If I try to process a freshly uploaded file, it hangs and eventually spits out "EOF reached" in the zope stupid log. As if this wasn't strange enough...  It continues -- so I 'modify' the OFS fileEdit.dtml page to allow me to directly edit the text of the XML file (it won't normally display if the text is >= 64K).  So I make absolutely NO changes whatsoever to the XML on the screen and click "Save Changes".  If I slap my modularxform at the end of the URL, the transform works. So, I am unsu!
 re of where the problem lies -- I have been trying different things in the Zope code (leaving the XML methods untouched).  Any thoughts?
> 

Re: [Zopexmlmethods-devel] Catalog/resolver support for libxml2

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

Craeg Strong wrote:
> Well, its always a bit of a challenge.  Hopefully the
> URN resolver implementations in the other XSLT processor
> modules will be helpful.    The main thing is to avoid
> going *outside* of the Zope context.  If you do that,
> you will lose authentication information and cookies,
> which means that many of the lookups will _fail_.  
> That is why having a Zope-aware resolver, that knows
> how to turn relative URLs into Zope objects directly,
> is so important.  I believe I have documented this
> fact in the code comments...

This will actually be great challenge for Zope3 implementations since 
Zope3 separates content objects from request-aware-code (i.e. views). 
Also, acquisition is only explicit.

When I get my laptop back from the repair shop (hopefully tomorrow) I 
will start trying to advance xml and xslt support in Zope3 and I am 
counting on you guys to give me some advice in this matter ;). I am 
fairly new to XML-related concepts like schemas anc catalogs so I might 
actually first spend some time on reading up some documentation.

I hope that both the Zope3 product called xslt and ZopeXMLMethods can 
profit from each other. We should try to abstract as much as possible in 
ZopeXMLMethods so things can be re-used later in Zope3. I will write 
something like a big (or small, depends) refactoring plan soon (repair 
shop...laptop...argh).

I will also try to get Martijn participate in this list. He has great 
insight into things like XPath.

Bye then,

Phil

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_[Zopexmlmethods-devel]_Catalog/resolver_support_for_libxml2?=

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

> I just sent in a patch to libxml2 that provides python bindings for
> local catalog support. 

Excellent!

 It seems to work in simple tests, but I'd like
> to test it with ZopeXMLMethods as well.  What's the best way to go about 
> testing?

There is already a catalog test: test_30 in TestXSLTMethods.
There should probably be more catalog tests.  The catalog
file for the test has a rewrite rule for URNs, which leaves
lots of things untested, like mapping one URL to another,
and all the other myriad things catalogs can do.
Feel free to clone test_30 and add some more variations.
Eventually if there are enough of these kinds of tests
we could always separate them out into a separate
TestCatalogs.py module...

> 
> Looking through the unit tests, it appears that XML catalog support is 
> tied into URN resolving.  Is this correct? 

Nah, I just used a URN for the test, and had to implement
extra code to make urns resolve to zope objects-- relative
urls already do i think.  Check out FourSuiteProcessor.py  It is using a CatalogInputSource
which will automagically do entity resolving/uri resolving
using the catalog.  To make it work I had to pass in
my URN-aware entity resolver as the resolver for the input
source.  The urn-aware resolver defaults back to the 
regular resolver in the case of non-urns.

The CatalogInputSource is quite a useful abstraction, but
absent from all the other XSLT implementations as of today...


 I know that libxml2 supports 
>     external resolvers and even has python bindings (eg. 
> libxml2.setEntityLoader(myResolver)), but ZopeXMLMethods doesn't seem to 
> use it.  Has this been tried before?  I presume we would just need to 
> write a resolver to map UR[LN]s into Zope objects.  Are there some 
> pitfalls to watch out for?

Well, its always a bit of a challenge.  Hopefully the
URN resolver implementations in the other XSLT processor
modules will be helpful.    The main thing is to avoid
going *outside* of the Zope context.  If you do that,
you will lose authentication information and cookies,
which means that many of the lookups will _fail_.  
That is why having a Zope-aware resolver, that knows
how to turn relative URLs into Zope objects directly,
is so important.  I believe I have documented this
fact in the code comments...

--Craeg

> 
> -- Brent

[Zopexmlmethods-devel] Catalog/resolver support for libxml2

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

I just sent in a patch to libxml2 that provides python bindings for
local catalog support.  It seems to work in simple tests, but I'd like
to test it with ZopeXMLMethods as well.  What's the best way to go about 
testing?

Looking through the unit tests, it appears that XML catalog support is 
tied into URN resolving.  Is this correct?  I know that libxml2 supports 
    external resolvers and even has python bindings (eg. 
libxml2.setEntityLoader(myResolver)), but ZopeXMLMethods doesn't seem to 
use it.  Has this been tried before?  I presume we would just need to 
write a resolver to map UR[LN]s into Zope objects.  Are there some 
pitfalls to watch out for?

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

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

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

Not just yet.  I hope to start working on a prototype this week, and then
I will float some ideas on the mailing list.

--Craeg

Brent Hendricks wrote:

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

Re: [Zopexmlmethods-devel] Privatizing XSLTProcessor.addParam

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

Brent Hendricks wrote:
 > 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!)

Please do so. Then somebody can clean up the "guts"... ;)

Phil

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

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

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?

My laptop is still in for repair so I'm still missing my XML/XSLT test
environment. Thus, I won't be able to contribute any code until some
time after Easter. So, if you'll allow us to refactor things later in
case we're not quite happy with it, please go ahead!

Phil