Re: [Zope-dev] ZPatterns for Zope 2.3 convenience release
Steve, This release breaks access to the management screens of ZClasses stored on Racks. In Zpatterns-0.4.2a3, Specialist/item_id/manage returns the ZClass management screen. In your release it returns the Specialist Methods screen. Itai Steve Alexander wrote:
At the following URL, you can find the latest ZPatterns with my patches applied. This is what I'm using at the moment.
I'm providing this for convenience, so that folks don't have to patch stuff to use ZPatterns with Zope 2.3. Bear in mind that this is not an "official" release. The changes haven't been particularly reviewed or widely used. Only use this release if you absolutely can't wait until PJE and TS make an official release. (I expect there will be an official release within the next few days.)
http://www.cat-box.net/steve/ZPatterns-stevea-20010204.tar.gz
It untars as two directories: ZPatterns and PlugIns. Therefore, untar it in your lib/python/Products directory.
If you already have a DynPersist library compiled, you don't need to recompile it.
Note that this release only works with Zope 2.3.
Here's a summary of the changes in this release as compared to ZPatterns 0.4.3b2:
* Fix to _memento class so it works with Zope 2.3
* Alteration to GAPMixin so the the attributes it says it provides come from the union of the assignments and the defaults.
* Add style="width: 100%;" to SkinScript edit textarea, in line with other zope textareas.
* Add syntax to SkinScript "INVALIDATE FOR".
* Update PlugIns/www/main.dtml and PlugInGroup.dtml to look like the Zope 2.3 management screen
* Updated all classes in ZPatterns and PlugIns to use DTMLFile instead of HTMLFile, and removed some redundant imports of HTMLFile in the process. This makes cut/copy/paste work properly.
* Add history tab to SkinScriptMethods -- Itai Tavor -- "Je sautille, donc je suis." -- itai@optusnet.com.au -- - Kermit the Frog --
-- "Every day, once a day, give yourself a present" - Dale Cooper --
Itai Tavor wrote:
Steve,
This release breaks access to the management screens of ZClasses stored on Racks.
In Zpatterns-0.4.2a3, Specialist/item_id/manage returns the ZClass management screen. In your release it returns the Specialist Methods screen.
Thanks. I'll look into this. As a workaround, you can use Specialist/item_id/manage_workspace instead. What version of Zope have you seen the desired Specialist/item_id/manage behaviour with? This looks to me more like something in Zope has changed, (probably to do with how __bobo_traverse__ works) as I don't think any of my changes to ZPatterns would cause the change you're reporting. I'm definitely seeing what you describe on Zope 2.3 from CVS, with the ZPatterns convenience release. To check this, I'll try an unpatched ZPatterns-0.4.3b2 with Zope 2.3, and see if I can reproduce the bug with that. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Steve Alexander wrote:
Itai Tavor wrote:
Steve,
This release breaks access to the management screens of ZClasses stored on Racks.
In Zpatterns-0.4.2a3, Specialist/item_id/manage returns the ZClass management screen. In your release it returns the Specialist Methods screen.
Thanks. I'll look into this.
As a workaround, you can use Specialist/item_id/manage_workspace instead.
Yeah, that works. Thanks.
What version of Zope have you seen the desired Specialist/item_id/manage behaviour with?
2.3, release version. item_id/manage gets redirected to item_id/manage_main which shows the ZClass management screen. BTW, this might be a good time to mention a related problem in the stock ZPatterns - even there item_id/manage doesn't work as expected - it brings up the ZClass management tabs with the first one selected, but the page content is actually an empty Methods screen. So a click on the first tab is required to actually get to the ZClass info. item_id/manage_workspace gets around that. Perhaps you can investigate this while you're looking at the other problem?
This looks to me more like something in Zope has changed, (probably to do with how __bobo_traverse__ works) as I don't think any of my changes to ZPatterns would cause the change you're reporting.
It must be related to something you changed in your release because the behavior changes when I switch between the original ZPatterns and your release, on the same Zope.
I'm definitely seeing what you describe on Zope 2.3 from CVS, with the ZPatterns convenience release.
To check this, I'll try an unpatched ZPatterns-0.4.3b2 with Zope 2.3, and see if I can reproduce the bug with that.
-- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
-- Itai Tavor -- "Je sautille, donc je suis." -- itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every day, once a day, give yourself a present" - Dale Cooper --
Itai Tavor wrote:
Steve Alexander wrote:
Itai Tavor wrote:
Steve,
This release breaks access to the management screens of ZClasses stored on Racks.
In Zpatterns-0.4.2a3, Specialist/item_id/manage returns the ZClass management screen. In your release it returns the Specialist Methods screen.
Thanks. I'll look into this.
As a workaround, you can use Specialist/item_id/manage_workspace instead.
Yeah, that works. Thanks.
What version of Zope have you seen the desired Specialist/item_id/manage behaviour with?
2.3, release version. item_id/manage gets redirected to item_id/manage_main which shows the ZClass management screen.
BTW, this might be a good time to mention a related problem in the stock ZPatterns - even there item_id/manage doesn't work as expected - it brings up the ZClass management tabs with the first one selected, but the page content is actually an empty Methods screen. So a click on the first tab is required to actually get to the ZClass info. item_id/manage_workspace gets around that. Perhaps you can investigate this while you're looking at the other problem?
Changing PlugIns.py, line 145 from manage_main = DTMLFile('www/main', globals()) to manage_main = HTMLFile('www/main', globals()) (make sure you've imported HTMLFile too) restores the behaviour of ZPatterns-0-4-3b2. If you try adding any normal ZClass in a normal folder, you get the behaviour that you're reporting as a bug for ZPatterns-convenience. Therefore, I reckon the original behaviour with ZPatterns-0.4.3b2 is incorrect, and the behviour with ZPatterns-convenience-release is consistent with how ZClasses work in the rest of Zope. If you're not happy with the behaviour of a_zclass_instance/manage_main, then that will need changing for all Zope and not just ZPatterns. Stick a report in the Collector perhaps? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
Steve Alexander wrote:
Itai Tavor wrote:
Steve Alexander wrote:
Itai Tavor wrote:
Steve,
This release breaks access to the management screens of ZClasses stored on Racks.
In Zpatterns-0.4.2a3, Specialist/item_id/manage returns the ZClass management screen. In your release it returns the Specialist Methods screen.
Thanks. I'll look into this.
As a workaround, you can use Specialist/item_id/manage_workspace instead.
Yeah, that works. Thanks.
What version of Zope have you seen the desired Specialist/item_id/manage behaviour with?
2.3, release version. item_id/manage gets redirected to item_id/manage_main which shows the ZClass management screen.
BTW, this might be a good time to mention a related problem in the stock ZPatterns - even there item_id/manage doesn't work as expected - it brings up the ZClass management tabs with the first one selected, but the page content is actually an empty Methods screen. So a click on the first tab is required to actually get to the ZClass info. item_id/manage_workspace gets around that. Perhaps you can investigate this while you're looking at the other problem?
Changing PlugIns.py, line 145 from
manage_main = DTMLFile('www/main', globals())
to
manage_main = HTMLFile('www/main', globals())
(make sure you've imported HTMLFile too) restores the behaviour of ZPatterns-0-4-3b2.
Yep, it does. Thanks.
If you try adding any normal ZClass in a normal folder, you get the behaviour that you're reporting as a bug for ZPatterns-convenience.
Hmmm... you're right. Never noticed that before. Sorry for blaming your release.
Therefore, I reckon the original behaviour with ZPatterns-0.4.3b2 is incorrect, and the behviour with ZPatterns-convenience-release is consistent with how ZClasses work in the rest of Zope.
So it was a bug in ZPatterns, which resulted in useful behavior, but was then "fixed" by your release, so now the bug has to be put back in to return the erroneous but useful behavior :-)
If you're not happy with the behaviour of a_zclass_instance/manage_main, then that will need changing for all Zope and not just ZPatterns.
Stick a report in the Collector perhaps?
Done. Maybe it's not such a huge problem but I think it's reasonable to expect /manage to do the same thing no matter what type of object you're accessing. -- Itai Tavor -- "Je sautille, donc je suis." -- itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every day, once a day, give yourself a present" - Dale Cooper --
participants (2)
-
Itai Tavor -
Steve Alexander