Chris Withers wrote:
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.
Senior Software Engineer
Zope3-dev mailing list