So here's a little review on current status of z3c.form. Mostly based on items from CHANGES.txt for 2.0 release :) I may forget something, so I'll reply to myself if something suddenly comes in my mind. And sorry for my English, i'm quite in hurry now. :-) FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box. TextLinesWidget - Works. I've fixed a case when a field has tuple in its _type, so it hopefully will work in any case now. MultiWidget - Probably needs some review as it does the updateWidgets thing on "value" property setting, which seems fishy to me. It works however. I've added the check for min_length and max_length and conditional buttons in the browser version. One thing I'd like to see is that it generate a default number of input rows based on field's minimal length if there's any. Also, another thing that would be nice is to have a way to reorder values for orderable fields. However this can wait for next release. I've added that to the TODOS.txt. ObjectWidget/ObjectMultiWidget - ??? I didn't checked that out, so it would be nice if its author reviewied it and wrote here about its status. Source support - Seems to work fine. I've checked that out in my sandbox instance with zc.sourcefactory's context-less and context-based sources. However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility. z3c.pt support - ??? I don't use the z3c.pt myself, so I didn't really checked that out. As I said before, the benchmarking suite is borked. Also, there's a strange bug with macros (see below). Also, we need to migrate to z3c.ptcompat instead of z3c.pt.compat (UPDATE: the merge was done while I was writing this). Tests - All are passing. However there was a failure with z3c.pt, I've described before. I don't know what's wrong there, but found a little workaround. See my comment in the tests/simple_groupedit.pt file. (UPDATE: tests are now borked again as a result of merging z3c.ptcompat branch while I was writing this). Translations - I've updated the template and the russian translation to be complete. I don't expect any msgid changes, so I think translators should review their translations and commit them right now :) Also, I wanted to add browser widget attributes like "klass" or "onclick" to adaptable values. This will require some work to make browser widgets automatically add their adaptable values to _adapterValueAttributes before calling parent's "update" method. I'm not sure that I'll be doing that very soon as it isn't very important. So this is definetely not a reason to wait with the release. One more thing I'd like to do is to add "klass" and "id" to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though. -- WBR, Dan Korostelev
On Monday 09 February 2009, Dan Korostelev wrote:
FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box.
Since this feature has not been there before, I can live without it for the 2.0 release.
MultiWidget - Probably needs some review as it does the updateWidgets thing on "value" property setting, which seems fishy to me.
Me too. :-) Roger, could you comment on this? Or Adam?
It works however. I've added the check for min_length and max_length and conditional buttons in the browser version. One thing I'd like to see is that it generate a default number of input rows based on field's minimal length if there's any. Also, another thing that would be nice is to have a way to reorder values for orderable fields. However this can wait for next release. I've added that to the TODOS.txt.
Nice to have, but not necessary. ;-)
ObjectWidget/ObjectMultiWidget - ??? I didn't checked that out, so it would be nice if its author reviewied it and wrote here about its status.
Adam? I'll note that we use that code heavily at Keas, so at least for that limited exposure it seems fine.
Source support - Seems to work fine. I've checked that out in my sandbox instance with zc.sourcefactory's context-less and context-based sources.
That's great to hear.
However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility.
Yeah, let's fix that.
z3c.pt support - ??? I don't use the z3c.pt myself, so I didn't really checked that out. As I said before, the benchmarking suite is borked. Also, there's a strange bug with macros (see below). Also, we need to migrate to z3c.ptcompat instead of z3c.pt.compat (UPDATE: the merge was done while I was writing this).
Malthe, do you have some time to look into this?
Tests - All are passing.
Clearly, all testsshould be passing. In addition, I would really like to see 100% test coverage after taking the false positives into consideration.
Translations - I've updated the template and the russian translation to be complete. I don't expect any msgid changes, so I think translators should review their translations and commit them right now
If translations are not updated until the next release, 2.1.0 or 2.0.1, that's fine with me.
Also, I wanted to add browser widget attributes like "klass" or "onclick" to adaptable values. This will require some work to make browser widgets automatically add their adaptable values to _adapterValueAttributes before calling parent's "update" method. I'm not sure that I'll be doing that very soon as it isn't very important. So this is definetely not a reason to wait with the release.
One more thing I'd like to do is to add "klass" and "id" to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though.
All nice to have. :-) I would not block the release because of it. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
2009/2/10 Stephan Richter <srichter@cosmos.phy.tufts.edu>:
On Monday 09 February 2009, Dan Korostelev wrote:
FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box.
Since this feature has not been there before, I can live without it for the 2.0 release.
Well, if that will be the only issue left, I'm personally also fine with releasing without it :))
However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility.
Yeah, let's fix that.
I'll check that.
Tests - All are passing.
Clearly, all testsshould be passing. In addition, I would really like to see 100% test coverage after taking the false positives into consideration.
Ok, the fix for the "z3c.ptcompat merge break" was to provide a zope.testing.doctest as a doctest module for testing.OutputChecker, so all tests pass again. They are also mostly 100% covered. Most uncovered bits are in the ObjectWidget, MultiWidget and its combination. So those modules defenitely need a review. :-)
If translations are not updated until the next release, 2.1.0 or 2.0.1, that's fine with me.
Well, that's actually fine with me as well (as I've already updated my translation :-P), so that was a call for people who wants to get their translations ready for 2.0.0.
One more thing I'd like to do is to add "klass" and "id" to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though.
All nice to have. :-) I would not block the release because of it.
That's fine with me to do that for the next release. BTW, I just discovered that forms have the "id" attribute, but it really points to the "name" which is a read-only property based on prefix, so they are not customizable at all. Was that done on purpose? I'd just set those attributes in the `update` method of the form. What do you think? -- WBR, Dan Korostelev
Hello, Tuesday, February 10, 2009, 2:19:48 AM, you wrote:
ObjectWidget/ObjectMultiWidget - ??? I didn't checked that out, so it would be nice if its author reviewied it and wrote here about its status.
SR> Adam? I'll note that we use that code heavily at Keas, so at least for that SR> limited exposure it seems fine. ummm, yeah it's quite heavily used. Caveats still apply as described in the docs. Anyway I'll check the coverage soon. -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: This line from Shakespeare has delusions of grandeur. - Douglas R Hofstadter
Hi, With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-( In fact, zope.site require zope.container requiring ZODB3 :-( I can't find any solutions to solve this problem. It is really damage to lose the possibility of using z3c.form with zope2/plone ... sagblmi Dan Korostelev wrote:
So here's a little review on current status of z3c.form. Mostly based on items from CHANGES.txt for 2.0 release :) I may forget something, so I'll reply to myself if something suddenly comes in my mind. And sorry for my English, i'm quite in hurry now. :-)
FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box.
TextLinesWidget - Works. I've fixed a case when a field has tuple in its _type, so it hopefully will work in any case now.
MultiWidget - Probably needs some review as it does the updateWidgets thing on "value" property setting, which seems fishy to me. It works however. I've added the check for min_length and max_length and conditional buttons in the browser version. One thing I'd like to see is that it generate a default number of input rows based on field's minimal length if there's any. Also, another thing that would be nice is to have a way to reorder values for orderable fields. However this can wait for next release. I've added that to the TODOS.txt.
ObjectWidget/ObjectMultiWidget - ??? I didn't checked that out, so it would be nice if its author reviewied it and wrote here about its status.
Source support - Seems to work fine. I've checked that out in my sandbox instance with zc.sourcefactory's context-less and context-based sources. However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility.
z3c.pt support - ??? I don't use the z3c.pt myself, so I didn't really checked that out. As I said before, the benchmarking suite is borked. Also, there's a strange bug with macros (see below). Also, we need to migrate to z3c.ptcompat instead of z3c.pt.compat (UPDATE: the merge was done while I was writing this).
Tests - All are passing. However there was a failure with z3c.pt, I've described before. I don't know what's wrong there, but found a little workaround. See my comment in the tests/simple_groupedit.pt file. (UPDATE: tests are now borked again as a result of merging z3c.ptcompat branch while I was writing this).
Translations - I've updated the template and the russian translation to be complete. I don't expect any msgid changes, so I think translators should review their translations and commit them right now :)
Also, I wanted to add browser widget attributes like "klass" or "onclick" to adaptable values. This will require some work to make browser widgets automatically add their adaptable values to _adapterValueAttributes before calling parent's "update" method. I'm not sure that I'll be doing that very soon as it isn't very important. So this is definetely not a reason to wait with the release.
One more thing I'd like to do is to add "klass" and "id" to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though.
Laurent Mignon wrote:
Hi,
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-(
In fact, zope.site require zope.container requiring ZODB3 :-(
Why can't you put these eggs into your Plone buildout? Are there version conflicts?
I can't find any solutions to solve this problem. It is really damage to lose the possibility of using z3c.form with zope2/plone ...
Yes. This would be a pretty big problem indeed, and one I hope we can avoid. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Laurent Mignon wrote:
Hi,
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-(
In fact, zope.site require zope.container requiring ZODB3 :-(
Why can't you put these eggs into your Plone buildout? Are there version conflicts?
I can't find any solutions to solve this problem. It is really damage to lose the possibility of using z3c.form with zope2/plone ...
Yes. This would be a pretty big problem indeed, and one I hope we can avoid.
Martin
Hi Martin, As specified in a response to my own post, I've found a solution. The problem is probably due to a inappropriate dependency declaration in the zope.container module. In fact zope.container use ZODB3 for their tests but ZODB3 is declared in the install_requires list in place of extras_require into setup.py. Everything works fine after modifying the setup.py file. BUT I wonder if the way that z3c.form compute resource url stay compatible with zope2 from zope.site import hooks class ImageButtonAction(image.ImageWidget, ButtonAction): zope.component.adapts(interfaces.IFormLayer, interfaces.IImageButton) def __init__(self, request, field): action.Action.__init__(self, request, field.title) submit.SubmitWidget.__init__(self, request) self.field = field @property def src(self): site = hooks.getSite() src = zope.traversing.api.traverse( site, '++resource++' + self.field.image, request=self.request)() return src
On Tuesday 10 February 2009, Laurent Mignon wrote:
BUT I wonder if the way that z3c.form compute resource url stay compatible with zope2
from zope.site import hooks class ImageButtonAction(image.ImageWidget, ButtonAction): zope.component.adapts(interfaces.IFormLayer, interfaces.IImageButton)
def __init__(self, request, field): action.Action.__init__(self, request, field.title) submit.SubmitWidget.__init__(self, request) self.field = field
@property def src(self): site = hooks.getSite() src = zope.traversing.api.traverse( site, '++resource++' + self.field.image, request=self.request)() return src
Zope 2 guys, is that a problem for you? If so, how can we make this work? Also a 2.0 show stopper. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Tuesday 10 February 2009, Laurent Mignon wrote:
BUT I wonder if the way that z3c.form compute resource url stay compatible with zope2
from zope.site import hooks class ImageButtonAction(image.ImageWidget, ButtonAction): zope.component.adapts(interfaces.IFormLayer, interfaces.IImageButton)
def __init__(self, request, field): action.Action.__init__(self, request, field.title) submit.SubmitWidget.__init__(self, request) self.field = field
@property def src(self): site = hooks.getSite() src = zope.traversing.api.traverse( site, '++resource++' + self.field.image, request=self.request)() return src
Zope 2 guys, is that a problem for you? If so, how can we make this work? Also a 2.0 show stopper.
Regards, Stephan
I don't use ImageButton so I don't kow if it's a real problem. For my part, I thing it's not a 2.0 show stopper since we already have the possibility to override the widget if it don't work... Regards Laurent
Laurent Mignon wrote:
Hi,
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-(
In fact, zope.site require zope.container requiring ZODB3 :-(
I can't find any solutions to solve this problem. It is really damage to lose the possibility of using z3c.form with zope2/plone ...
sagblmi
Hi The problem encountered is that zope.container specify ZODB3 as a main dependency. After checking the code, it seems that ZODB is only required for tests. If I modify zope.container.setup.py to specify ZODB3 as an extra dependency for test target, everything works fine. I suspect that I'll probably have side effects by using modules using zope.container into zope2.... sagblmi
Dan Korostelev wrote:
So here's a little review on current status of z3c.form. Mostly based on items from CHANGES.txt for 2.0 release :) I may forget something, so I'll reply to myself if something suddenly comes in my mind. And sorry for my English, i'm quite in hurry now. :-)
FileWidget - It doesn't clear the bytes value if no new file is uploaded now, which is nice. But there's also should be a way to clear current value if the field is not required. I've added that to the TODOS.txt. I think that should be done before release to make the widget actually functional out of box.
TextLinesWidget - Works. I've fixed a case when a field has tuple in its _type, so it hopefully will work in any case now.
MultiWidget - Probably needs some review as it does the updateWidgets thing on "value" property setting, which seems fishy to me. It works however. I've added the check for min_length and max_length and conditional buttons in the browser version. One thing I'd like to see is that it generate a default number of input rows based on field's minimal length if there's any. Also, another thing that would be nice is to have a way to reorder values for orderable fields. However this can wait for next release. I've added that to the TODOS.txt.
ObjectWidget/ObjectMultiWidget - ??? I didn't checked that out, so it would be nice if its author reviewied it and wrote here about its status.
Source support - Seems to work fine. I've checked that out in my sandbox instance with zc.sourcefactory's context-less and context-based sources. However, there was some backward-incompatible refactorings (class renames) done to sequence data converters that breaks the z3c.pt benchmarking suite. This may also break end-users' code so we probably want to fix the compatibility.
z3c.pt support - ??? I don't use the z3c.pt myself, so I didn't really checked that out. As I said before, the benchmarking suite is borked. Also, there's a strange bug with macros (see below). Also, we need to migrate to z3c.ptcompat instead of z3c.pt.compat (UPDATE: the merge was done while I was writing this).
Tests - All are passing. However there was a failure with z3c.pt, I've described before. I don't know what's wrong there, but found a little workaround. See my comment in the tests/simple_groupedit.pt file. (UPDATE: tests are now borked again as a result of merging z3c.ptcompat branch while I was writing this).
Translations - I've updated the template and the russian translation to be complete. I don't expect any msgid changes, so I think translators should review their translations and commit them right now :)
Also, I wanted to add browser widget attributes like "klass" or "onclick" to adaptable values. This will require some work to make browser widgets automatically add their adaptable values to _adapterValueAttributes before calling parent's "update" method. I'm not sure that I'll be doing that very soon as it isn't very important. So this is definetely not a reason to wait with the release.
One more thing I'd like to do is to add "klass" and "id" to the forms themselves so one could easily customize the visual appeal of the forms. But it's probably should be done in z3c.formui's subclasses and not in z3c.form's base classes. I'd like to hear the community opinion on that though.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
2009/2/10 Laurent Mignon <laurent.mignon@softwareag.com>:
The problem encountered is that zope.container specify ZODB3 as a main dependency. After checking the code, it seems that ZODB is only required for tests. If I modify zope.container.setup.py to specify ZODB3 as an extra dependency for test target, everything works fine.
Hmm.. zope.container actually uses BTrees from the ZODB3 egg module for implementing BTreeContainer. -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/2/10 Laurent Mignon <laurent.mignon@softwareag.com>:
The problem encountered is that zope.container specify ZODB3 as a main dependency. After checking the code, it seems that ZODB is only required for tests. If I modify zope.container.setup.py to specify ZODB3 as an extra dependency for test target, everything works fine.
Hmm.. zope.container actually uses BTrees from the ZODB3 egg module for implementing BTreeContainer.
And BTrees is also available into Zope2 but I agree that therefore ZODB3 seems to be a normal dependency.. I'm really not an expert and I don't know how it's possible to fix such kind of problem...
2009/2/10 Laurent Mignon <laurent.mignon@softwareag.com>:
Dan Korostelev wrote:
2009/2/10 Laurent Mignon <laurent.mignon@softwareag.com>:
The problem encountered is that zope.container specify ZODB3 as a main dependency. After checking the code, it seems that ZODB is only required for tests. If I modify zope.container.setup.py to specify ZODB3 as an extra dependency for test target, everything works fine.
Hmm.. zope.container actually uses BTrees from the ZODB3 egg module for implementing BTreeContainer.
And BTrees is also available into Zope2 but I agree that therefore ZODB3 seems to be a normal dependency.. I'm really not an expert and I don't know how it's possible to fix such kind of problem...
Well, I'm no Zope2 expert at all, but isn't there some "fake eggs" support in recent Zope2/Plone buildouts created for handling problems like that? -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/2/10 Laurent Mignon <laurent.mignon@softwareag.com>:
Dan Korostelev wrote:
2009/2/10 Laurent Mignon <laurent.mignon@softwareag.com>:
The problem encountered is that zope.container specify ZODB3 as a main dependency. After checking the code, it seems that ZODB is only required for tests. If I modify zope.container.setup.py to specify ZODB3 as an extra dependency for test target, everything works fine. Hmm.. zope.container actually uses BTrees from the ZODB3 egg module for implementing BTreeContainer.
And BTrees is also available into Zope2 but I agree that therefore ZODB3 seems to be a normal dependency.. I'm really not an expert and I don't know how it's possible to fix such kind of problem...
Well, I'm no Zope2 expert at all, but isn't there some "fake eggs" support in recent Zope2/Plone buildouts created for handling problems like that?
OK, Sorry for the disturb, Everything is my fault... You're right, thanks for your suggestion. Everything works simply by specifying ZODB3 = 3.8 as additional-fake-eggs Thanks again, sagblmi
On Tuesday 10 February 2009, Laurent Mignon wrote:
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-(
Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that: try: import zope.site except ImportError: import zope.container or something like that. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Tuesday 10 February 2009, Laurent Mignon wrote:
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-(
Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that:
try: import zope.site except ImportError: import zope.container
or something like that.
Regards, Stephan Thanks also for your attention, the problem was in my buildout configuration as suggested by 'Dan Korostelev'
Adding the following lines to my buildout solves the problem: additional-fake-eggs = zope.schema = 3.4.0 zope.location = 3.4.0 ZODB3 = 3.8.1 Regards, Laurent
Laurent Mignon <laurent.mignon@softwareag.com> writes:
Stephan Richter wrote:
On Tuesday 10 February 2009, Laurent Mignon wrote:
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-(
Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that:
try: import zope.site except ImportError: import zope.container
or something like that.
Regards, Stephan Thanks also for your attention, the problem was in my buildout configuration as suggested by 'Dan Korostelev'
Adding the following lines to my buildout solves the problem:
additional-fake-eggs = zope.schema = 3.4.0 zope.location = 3.4.0 ZODB3 = 3.8.1
It would be nice if we could move these to an extends= file, so that people don't have to maintain this list in their own buildouts. -- http://danielnouri.org
Daniel Nouri wrote:
Laurent Mignon <laurent.mignon@softwareag.com> writes:
Stephan Richter wrote:
On Tuesday 10 February 2009, Laurent Mignon wrote:
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-( Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that:
try: import zope.site except ImportError: import zope.container
or something like that.
Regards, Stephan Thanks also for your attention, the problem was in my buildout configuration as suggested by 'Dan Korostelev'
Adding the following lines to my buildout solves the problem:
additional-fake-eggs = zope.schema = 3.4.0 zope.location = 3.4.0 ZODB3 = 3.8.1
It would be nice if we could move these to an extends= file, so that people don't have to maintain this list in their own buildouts.
More generically, I think it would be nice if the plone.recipe.zope2instance use the KGS used to build the zope2 distrib to directly specify the good version during the fake-zope-eggs process.
2009/2/10 Stephan Richter <srichter@cosmos.phy.tufts.edu>:
On Tuesday 10 February 2009, Laurent Mignon wrote:
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-(
Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that:
Is the problem in that zope2 still contains zope.* modules in itself and not in the eggs, so if it contain old zope.app.component and the new z3c.form depends on zope.site egg, we get two independent local site implementation that will conflict? If so, I guess we have the similar problem with ITerms that was moved to zope.browser. So, the "creative solution" could be to prepare a "compatibility" packages that could be used for zope 2 instead of real zope.site and zope.browser and contain reverse imports of things that were moved from their places in zope2 zope.* packages. However, this should be done by someone who works with Zope2 and that's not me, unfortunately. I hope that new zope2 will just use zope3 modules as eggs and won't maintain a copy of them. -- WBR, Dan Korostelev
On Wednesday 11 February 2009, Dan Korostelev wrote:
Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that:
Is the problem in that zope2 still contains zope.* modules in itself and not in the eggs, so if it contain old zope.app.component and the new z3c.form depends on zope.site egg, we get two independent local site implementation that will conflict? If so, I guess we have the similar problem with ITerms that was moved to zope.browser.
I think they later reported this problem as fixed and they got it working in Zope 2. Right? Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Wednesday 11 February 2009, Dan Korostelev wrote:
Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that: Is the problem in that zope2 still contains zope.* modules in itself and not in the eggs, so if it contain old zope.app.component and the new z3c.form depends on zope.site egg, we get two independent local site implementation that will conflict? If so, I guess we have the similar problem with ITerms that was moved to zope.browser.
Yes zope2 still contains zope.* modules BUT the plone.recipe.zope2install has an option 'fake-zope-eggs' to add fake egg links to Zope 3 libraries, so that setuptools can see and use them for dependencies lookup... zope2 (for my part I use zope-2.11.2) still contain and relay on zope.app.component. It's true that we have two independent local sites implementation since z3c.form depends of zope.site. I think that the only issue is when a call is made to the 'getSite' function provided by zope.site to request the site root. The function is only used 2 times in the code (ImageButtonAction and ImageFieldWidget) to compute the resource url. Since these two classes are registered as adapters, we can provide an override for zope2. (maybe into plone.z3cform...) I don't have a similar problem with ITerms since I've updated my code to use the ITerms provided by zope.browser. But, when I execute a 'grep' on the plone code itself, I found four potential issues: plone/app/form/widgets/uberselectionwidget.py plone/app/vocabularies/catalog.py plone/app/vocabularies/groups.py plone/app/vocabularies/users.py
I think they later reported this problem as fixed and they got it working in Zope 2. Right?
Regards, Stephan
2009/2/11 Laurent Mignon <laurent.mignon@softwareag.com>:
Stephan Richter wrote:
On Wednesday 11 February 2009, Dan Korostelev wrote:
Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that: Is the problem in that zope2 still contains zope.* modules in itself and not in the eggs, so if it contain old zope.app.component and the new z3c.form depends on zope.site egg, we get two independent local site implementation that will conflict? If so, I guess we have the similar problem with ITerms that was moved to zope.browser.
Yes zope2 still contains zope.* modules BUT the plone.recipe.zope2install has an option 'fake-zope-eggs' to add fake egg links to Zope 3 libraries, so that setuptools can see and use them for dependencies lookup... zope2 (for my part I use zope-2.11.2) still contain and relay on zope.app.component. It's true that we have two independent local sites implementation since z3c.form depends of zope.site. I think that the only issue is when a call is made to the 'getSite' function provided by zope.site to request the site root. The function is only used 2 times in the code (ImageButtonAction and ImageFieldWidget) to compute the resource url. Since these two classes are registered as adapters, we can provide an override for zope2. (maybe into plone.z3cform...) I don't have a similar problem with ITerms since I've updated my code to use the ITerms provided by zope.browser. But, when I execute a 'grep' on the plone code itself, I found four potential issues: plone/app/form/widgets/uberselectionwidget.py plone/app/vocabularies/catalog.py plone/app/vocabularies/groups.py plone/app/vocabularies/users.py
Yeah. So one solution, as I said before is to release zope.sitecompat egg that provides a "zope.site" module, but doesn't implement a site implementation, but instead imports things from old zope.app.component (as does the new zope.app.component reversely). The same thing could be done for zope.browser. However, this is an ugly solution, so I hope Zope2 will move to eggs completely soon, so we won't have to deal with problems like that. -- WBR, Dan Korostelev
On Wednesday 11 February 2009, Dan Korostelev wrote:
Yeah. So one solution, as I said before is to release zope.sitecompat egg that provides a "zope.site" module, but doesn't implement a site implementation, but instead imports things from old zope.app.component (as does the new zope.app.component reversely). The same thing could be done for zope.browser. However, this is an ugly solution, so I hope Zope2 will move to eggs completely soon, so we won't have to deal with problems like that.
If that works, +1. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
2009/2/11 Stephan Richter <srichter@cosmos.phy.tufts.edu>:
On Wednesday 11 February 2009, Dan Korostelev wrote:
Yeah. So one solution, as I said before is to release zope.sitecompat egg that provides a "zope.site" module, but doesn't implement a site implementation, but instead imports things from old zope.app.component (as does the new zope.app.component reversely). The same thing could be done for zope.browser. However, this is an ugly solution, so I hope Zope2 will move to eggs completely soon, so we won't have to deal with problems like that.
If that works, +1.
Yeah, and so we're able not to deal with that in z3c.form itself and not to delay the release. Though I'd like this things to be done by someone who actually works with Zope2/Plone + z3c.form. Anyone? -- WBR, Dan Korostelev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Korostelev wrote:
2009/2/10 Stephan Richter <srichter@cosmos.phy.tufts.edu>:
On Tuesday 10 February 2009, Laurent Mignon wrote:
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-( Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that:
Is the problem in that zope2 still contains zope.* modules in itself and not in the eggs, so if it contain old zope.app.component and the new z3c.form depends on zope.site egg, we get two independent local site implementation that will conflict?
The 2.11 released versions do contain those packages, yes. The 2.12 release will be purely egg-based.
If so, I guess we have the similar problem with ITerms that was moved to zope.browser.
So, the "creative solution" could be to prepare a "compatibility" packages that could be used for zope 2 instead of real zope.site and zope.browser and contain reverse imports of things that were moved from their places in zope2 zope.* packages. However, this should be done by someone who works with Zope2 and that's not me, unfortunately.
Anybody still using Zope 2.11.x should probably just stck with the versions of z3c.form which were known to work with that Zope2 version, knowing that they will be able to upgrade z3c.form at the same time as they upgrade Zope2 (and the underlying eggs).
I hope that new zope2 will just use zope3 modules as eggs and won't maintain a copy of them.
The time machine has already been here. :) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJkzNH+gerLs4ltQ4RAtZPAKCDSPnQMcH6Mz6+x10U9qWy2F09DACgyXTN hkCYLr4SSY0l2EheiC887NA= =/5jl -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dan Korostelev wrote:
2009/2/10 Stephan Richter <srichter@cosmos.phy.tufts.edu>:
On Tuesday 10 February 2009, Laurent Mignon wrote:
With the replacement of zope.app.component import with zope.site, it's no more possible to use z3c.form with Zope2 / Plone :-( Thanks for getting our attention on this. I consider this a show-stopper for 2.0. Dan, let's think about something creative that allows us to use the new and old way, maybe through a special import statement like that: Is the problem in that zope2 still contains zope.* modules in itself and not in the eggs, so if it contain old zope.app.component and the new z3c.form depends on zope.site egg, we get two independent local site implementation that will conflict?
The 2.11 released versions do contain those packages, yes. The 2.12 release will be purely egg-based.
If so, I guess we have the similar problem with ITerms that was moved to zope.browser.
So, the "creative solution" could be to prepare a "compatibility" packages that could be used for zope 2 instead of real zope.site and zope.browser and contain reverse imports of things that were moved from their places in zope2 zope.* packages. However, this should be done by someone who works with Zope2 and that's not me, unfortunately.
Anybody still using Zope 2.11.x should probably just stck with the versions of z3c.form which were known to work with that Zope2 version, knowing that they will be able to upgrade z3c.form at the same time as they upgrade Zope2 (and the underlying eggs).
For my part I can leave in my project with these know issues... Tres, are you saying that if I want to continue to use the next release of z3c.form with Zope2 / Plone, it would be necessary to upgrade to zope-2.12??? Is-it realistic? Actually zope-2.12 is not officially released and I don't know which are the potential problems to use it with plone3 ... The 'creative solution' seems better to me. If I need it, I'll probably develop it.
I hope that new zope2 will just use zope3 modules as eggs and won't maintain a copy of them.
The time machine has already been here. :)
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJkzNH+gerLs4ltQ4RAtZPAKCDSPnQMcH6Mz6+x10U9qWy2F09DACgyXTN hkCYLr4SSY0l2EheiC887NA= =/5jl -----END PGP SIGNATURE-----
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Laurent Mignon wrote:
Tres Seaver wrote:
Anybody still using Zope 2.11.x should probably just stck with the versions of z3c.form which were known to work with that Zope2 version, knowing that they will be able to upgrade z3c.form at the same time as they upgrade Zope2 (and the underlying eggs).
For my part I can leave in my project with these know issues... Tres, are you saying that if I want to continue to use the next release of z3c.form with Zope2 / Plone, it would be necessary to upgrade to zope-2.12??? Is-it realistic? Actually zope-2.12 is not officially released and I don't know which are the potential problems to use it with plone3 ... The 'creative solution' seems better to me. If I need it, I'll probably develop it.
There is no general promise that an already-released package, such as Zope2, will be able to work with a more recently-released add-on package than the version which was tested with it. In this case, the updated dependencies of the latest zc3.form version are *incompatible* with Zope 2.11, period: you can work around it, maybe, but you are in uncharted territory. This is exactly the same problem as if you tried to run Plone 3.2 atop Zope 2.8, actually. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJlKis+gerLs4ltQ4RAlCFAJ9ojWNJUAG1Juok7GJzPf2oOsDSswCfcLkB SoirgCz0Xq1s+yfzoRdPfHU= =UJj4 -----END PGP SIGNATURE-----
participants (7)
-
Adam GROSZER -
Dan Korostelev -
Daniel Nouri -
Laurent Mignon -
Martin Aspeli -
Stephan Richter -
Tres Seaver