Chris Withers wrote:
Hi Benji,

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, and it shouldn't.  It should be undocumented.

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.

I'm all for reverting that change when either:

Documenting something is a promise of a feature. Reverting the docs is equivalent to withdrawing a feature. Testbrowser is going to be released in 3.2, we don't need to make promises we don't intend on keeping.

- mechanize is replaced with something else

That's not how "implementation details" work.

- 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. With that you can use Beautiful Soup, libxml2, ElementTree, or whatever. We don't know enough to make the decision, so we're not forcing a decision.

The other change I made is due to he fact that to meaningfully do file uploading with testbrowser, you currently _have_ to reach inside and use the underlying mechanize functionality, for the reasons I explained...

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

So, in short, yes I agree with you but please don't back anything out until something better is available!

You don't compensate for a broken/missing feature by documenting a hack. Please remove the offending text.
Benji York
Senior Software Engineer
Zope Corporation
Zope3-dev mailing list

Reply via email to