[Zope3-dev] zope.testbrowser and mechanize

[Chris Withers]

Benji York wrote:
>>> I actually don't want to support any exposure of mechanize 
>>> functionality in zope.testbrowser.  Mechanize is an implementation 
>>> detail (although a very important one) and may change in the future.
>>
>> I think the documentation I added makes this clear.
> 
> It doesn't, 

"""
testbrowser currently doesn't help much unless you already know the
controls you will be looking for, however, you can do some
introspection by utilizing the underlying mechanize functionality.
"""

"""
     Unfortunately, testbrowser doesn't really support what you need,
     so you have to use the underlying mechanize control:
"""

Both of those are pretty clear to me in explaining that you have to use 
the "implementation detail" to get stuff done.

> and it shouldn't.  It should be undocumented.

Great, so you advocate forcing people to dig through the code and find 
their own way blindly to do something as simple us uploading a file. Nice.

I put that stuff in there to give other people in my position a clue, I 
was happy to get an off-list email saying thanks from Gary Poster. I'm a 
bit perplexed to now have you bitching at me...

>>> We will probably be adding support for using XPath to do this type of 
>>> inspection of the HTML in the future, but until then this change 
>>> should be reverted.
>>
>>
>> How will XPath help me with that specific example?
> 
> By allowing you to easily find the controls you're interested in.

So how, specifically, would I use XPath to find all checkbox controls in 
a form?

>> I'm all for reverting that change when either:
> 
> Documenting something is a promise of a feature. 

I'm more than happy to make it explicit in the stuff I added that these 
aren't features and will go away as soon as something better is 
abailable in testbrowser.

> Reverting the docs is 
> equivalent to withdrawing a feature. 

I think the two things I've added are _required_ and so it would be 
replacing with something better rather than withdrawing.

> Testbrowser is going to be 
> released in 3.2, we don't need to make promises we don't intend on keeping.

Well, you've already promised to support file uploads...

>> - mechanize is replaced with something else
> 
> That's not how "implementation details" work.

huh?

>> - testbrowser itself provides a way for doing decent introspection.
> 
> We don't know what the right way is.  This is why it provides the 
> .contents attribute. 

...which doesn't help ;-)

> With that you can use Beautiful Soup, libxml2, 
> ElementTree, or whatever. 

What? instead of mechanize?

> We don't know enough to make the decision, so 

who is "we" here?

> This is true, so as above, either the feature should be fixed or 
> reference to it removed from the docs.

great, so now you want to withdraw file upload support from testbrowser?

> You don't compensate for a broken/missing feature by documenting a hack. 
>  Please remove the offending text.

I won't. If you do, I'll take that as a clear sign that participation in 
testbrowser's development isn't welcome and go and develop something 
else or just plain fork it.

Please, don't make such a mountain out of adding a couple of useful 
pieces of documentation...

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk