Raphael Ritz wrote:
Jim Fulton wrote:
I heard that there was some discussion about the relationship between Martijn Faassen's "Five" project and future versions of Zope.
I'd like to say, for the record, that I think Five is an important project. It is one of a number of projects to work out how to use features of Zope 3 in Zope 2. Most of the projects, such as the one here at Zope corp are not as public as Five. I can say, on our part, that this is not from a desire for secrecy, but from a lack of bandwidth to share what we have done. I applaud Martijn's effort to make this a broad and open effort. I view Five as an important step toward Zope 2.9 and encourage people to get involved with it. I certainly intend to be invlved as much as time allows.
Thanks for this clairification, Jim. Alan, does that address your concerns? Any reasons left, not to adopt the five approach to Zope 3?
Just understand that the Five approach is still being developed, so there's nothing to "adopt" yet. :) But I certainly encourage folks to participate and help Martijn figure out what the approach should be. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Alan, does that address your concerns?
Just understand that the Five approach is still being developed, so there's nothing to "adopt" yet. :) But I certainly encourage folks to participate and help Martijn figure out what the approach should be.
Raphael, I think its great that Jim responded. Now we (collectively) need to get some usage out of Five. Jim, Thanks for explaining ZC's position re: FrankenZope or backporting CA into Zope2. One of the big questions that I believe is open is how to use more of zope.app in Zope 2 - specifically Schema/Widgets. I heard that Zope Corp. is using this in some projects. So - I asked if people to do some CMF/Plone implementation of Views in certain aspects. I am up for creating a Supplement to Plone to bolts on some of the technologies and uses it. Maybe specifically using it for doing in-place versioning. I urge the communities to use Plone or maybe a fork of it (or the CMF) to be a playground. Like Idle forked to land some major features for Python. Then it can be integrated back into subsequent projects. -- Alan Runyan Enfold Systems, LLC. - Principal Plone/Zope Training, Products, and Consulting http://www.enfoldsystems.com/ p. +1.713.942.2377 f. +1.832.201.8856
alan runyan wrote:
Alan, does that address your concerns?
...
One of the big questions that I believe is open is how to use more of zope.app in Zope 2 - specifically Schema/Widgets. I heard that Zope Corp. is using this in some projects.
I think we should not be squeemish about using zope.app. Widgets are the main reason that we are using Zope 3 in Zope 2. I would like to see most of the widget code get lifted up out of zope.app. This is of general interest (not just z2).
So - I asked if people to do some CMF/Plone implementation of Views in certain aspects. I am up for creating a Supplement to Plone to bolts on some of the technologies and uses it. Maybe specifically using it for doing in-place versioning. I urge the communities to use Plone or maybe a fork of it (or the CMF) to be a playground. Like Idle forked to land some major features for Python. Then it can be integrated back into subsequent projects.
I'll note that there is an opportinuty for CMF-based systems that might not be interesting to Five. Specifically, the obvious fact that the mechanisms in the CMF are similar to those in Zope 3. It should be possible to create a new kind of CMF layer that does view lookup. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
alan runyan wrote:
Alan, does that address your concerns?
Just understand that the Five approach is still being developed, so there's nothing to "adopt" yet. :) But I certainly encourage folks to participate and help Martijn figure out what the approach should be.
Raphael, I think its great that Jim responded. Now we (collectively) need to get some usage out of Five.
Jim, Thanks for explaining ZC's position re: FrankenZope or backporting CA into Zope2. One of the big questions that I believe is open is how to use more of zope.app in Zope 2 - specifically Schema/Widgets. I heard that Zope Corp. is using this in some projects.
Note that FrankenZope is going to go for the new way of Interface integration last I heard (Five's way); the FrankenZope style setup to make interfaces work is not needed anymore since the changes to zope.interface that I did. This new approach works in straight 2.7. I also heard rumors that FrankenZope's use of schema/widgets is actually an evolved branch of an earlier version of Zope 3. Five's mission is to integrate Zope 3 into Zope 2 as much a possible without having to change either. Of course this is not always possible, but it's an important goal. That said, I'm sure we could learn more from FrankenZope's experiences in that area if someone would to speak up about this.
So - I asked if people to do some CMF/Plone implementation of Views in certain aspects. I am up for creating a Supplement to Plone to bolts on some of the technologies and uses it. Maybe specifically using it for doing in-place versioning. I urge the communities to use Plone or maybe a fork of it (or the CMF) to be a playground. Like Idle forked to land some major features for Python. Then it can be integrated back into subsequent projects.
Such experimentation is definitely very welcome, and I'd also like to see some in the context of Five. I'd very much like to avoid more dilution of efforts where Five is going one way and CMF/Plone is going somewhere else. That said, I'm certainly not going to be able to spend time on forking CMF and Plone and hacking on this myself. I do not know what a CMF version of Views would look like or even what its requirements could even be. It also sounds to me that forking Plone and/or CMF would be a far higher risk approach to integrating Zope 3 into Zope 2 than the approach Five is currently taking. Additionally of course I am not using CMF myself. :) I'd urge people against getting too ambitious with this; I know high risk strategies can have higher payoff, but the chance that they fail is also higher. Five's strategy is baby steps and using the technology *right now*. Regards, Martijn
Martijn Faassen wrote:
alan runyan wrote:
Alan, does that address your concerns?
Just understand that the Five approach is still being developed, so there's nothing to "adopt" yet. :) But I certainly encourage folks to participate and help Martijn figure out what the approach should be.
Raphael, I think its great that Jim responded. Now we (collectively) need to get some usage out of Five.
Jim, Thanks for explaining ZC's position re: FrankenZope or backporting CA into Zope2. One of the big questions that I believe is open is how to use more of zope.app in Zope 2 - specifically Schema/Widgets. I heard that Zope Corp. is using this in some projects.
Note that FrankenZope is going to go for the new way of Interface integration last I heard (Five's way); the FrankenZope style setup to make interfaces work is not needed anymore since the changes to zope.interface that I did. This new approach works in straight 2.7.
I also heard rumors that FrankenZope's use of schema/widgets is actually an evolved branch of an earlier version of Zope 3. Five's mission is to integrate Zope 3 into Zope 2 as much a possible without having to change either. Of course this is not always possible, but it's an important goal. That said, I'm sure we could learn more from FrankenZope's experiences in that area if someone would to speak up about this.
Can we please stop using this name in writing? It is funny, but not very reassuring to outsiders. :) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
Raphael Ritz wrote:
Thanks for this clairification, Jim. Alan, does that address your concerns? Any reasons left, not to adopt the five approach to Zope 3?
Just understand that the Five approach is still being developed, so there's nothing to "adopt" yet. :) But I certainly encourage folks to participate and help Martijn figure out what the approach should be.
There's the 'approach' and the implementation. The approach is fairly clear: a focus on baby steps to integrate into Zope 2.7. The aim is to introduce as much as possible as make sense of Zope 3 facilities into Zope 2. The implementation is still flux. Though that said, things like interfaces and adapters should be stable enough (as long as Zope 3 is stable in that regard), as there's really no difference between the way Five does them and the way Zope 3 does them. For views, we're moving along nicely following the Zope 3 pattern. At the post-Europython sprint Stuart Bishop and I, with help from Jim, came up with a way to integrate them the right way for Zope 2 objects. I'm now pretty happy with them, though some more possibilities and details are bound to change still. You can now even add views to existing Zope 2 objects, without the /edit/ hack, from ZCML. That this happens by way of "Structured Monkeypatching" shouldn't concern anybody. ;) While Five is in flux, I expect the main changes you'll have to make in your applications is slightly altering some ZCML statements and possibly changing an import here and there. It also depends on who contributes what, as always. :) Regards, Martijn
Martijn Faassen wrote:
There's the 'approach' and the implementation. The approach is fairly clear: a focus on baby steps to integrate into Zope 2.7. The aim is to introduce as much as possible as make sense of Zope 3 facilities into Zope 2.
Besides ourself also Christian Heimes has done a more product oriented adoption of the adapter and interfaces stuff. Will it be possible to use five in this way?
The implementation is still flux. Though that said, things like interfaces and adapters should be stable enough (as long as Zope 3 is stable in that regard), as there's really no difference between the way Five does them and the way Zope 3 does them.
For views, we're moving along nicely following the Zope 3 pattern. At the post-Europython sprint Stuart Bishop and I, with help from Jim, came up with a way to integrate them the right way for Zope 2 objects. I'm now pretty happy with them, though some more possibilities and details are bound to change still.
You can now even add views to existing Zope 2 objects, without the /edit/ hack, from ZCML. That this happens by way of "Structured Monkeypatching" shouldn't concern anybody. ;)
Will this monkeypatch be somewhat of a blessed way to include view adapters into zope2? Than we can replace our current approach of using view adapters in union.cms with this one. Or will this be integrated into Zope 2.8 at the end?
While Five is in flux, I expect the main changes you'll have to make in your applications is slightly altering some ZCML statements and possibly changing an import here and there. It also depends on who contributes what, as always. :)
On the conference you suggested to setup a mailinglist for the discussion of interface integration. Sure the main parts are done, but I think it would also be nice to see, how different projects are actually using the new possibilities. For example the usage of widgets can lead to something like a layout-manager or some other tools to really integrate them into Zope 2 applications. I think it would also drive some more testing and zope3 and further integration of other parts. (If one has views, adapters, schemas and widgets, events are looming in the corner :-) With regards, __Janko Hauser
Janko Hauser wrote:
Martijn Faassen wrote:
There's the 'approach' and the implementation. The approach is fairly clear: a focus on baby steps to integrate into Zope 2.7. The aim is to introduce as much as possible as make sense of Zope 3 facilities into Zope 2.
Besides ourself also Christian Heimes has done a more product oriented adoption of the adapter and interfaces stuff. Will it be possible to use five in this way?
I do not exactly know what you mean by 'Product oriented'? Install special Zope 2 products for adapters and interfaces? I don't see how that is easier than just having Zope 3 installed. Christian Heimes' ZopeThreeForTwo product will work with Five. It's just a way to more easily install Zope 3 into Zope 2. Five and ZopeThreeForTwo are complimentary. Anyway, the idea is to make interfaces and adapters useful for a Python product developer. I don't think we'll move towards supporting this stuff from the ZMI for scripter-level access any time soon, though of course people may surprise me. :)
The implementation is still flux. Though that said, things like interfaces and adapters should be stable enough (as long as Zope 3 is stable in that regard), as there's really no difference between the way Five does them and the way Zope 3 does them.
For views, we're moving along nicely following the Zope 3 pattern. At the post-Europython sprint Stuart Bishop and I, with help from Jim, came up with a way to integrate them the right way for Zope 2 objects. I'm now pretty happy with them, though some more possibilities and details are bound to change still.
You can now even add views to existing Zope 2 objects, without the /edit/ hack, from ZCML. That this happens by way of "Structured Monkeypatching" shouldn't concern anybody. ;)
Will this monkeypatch be somewhat of a blessed way to include view adapters into zope2? Than we can replace our current approach of using view adapters in union.cms with this one. Or will this be integrated into Zope 2.8 at the end?
The monkey patch only patches the objects you want to make viewable, not the Zope 2 core traversal machinery itself. There won't be anything of this in Zope 2.8, by the way, as matters currently stand. Zope 2.8 is *not* planned to do any Zope 3 integration, though parts of what it is doing (newer ZODB which allows new style objects, etc) are certainly helpful. Zope 2.9 is another story, but what will happen nobody knows quite yet, and in part I'd say it depends on us. :) Even if Zope 2.9 is going to do something quite different, the only thing you'd need to do is rewrite your ZCML page directives to the way Zope 2.9 prefers. Since Five page directives are extremely similar to Zope 3's, this should be a minor step.
While Five is in flux, I expect the main changes you'll have to make in your applications is slightly altering some ZCML statements and possibly changing an import here and there. It also depends on who contributes what, as always. :)
On the conference you suggested to setup a mailinglist for the discussion of interface integration. Sure the main parts are done, but I think it would also be nice to see, how different projects are actually using the new possibilities.
Philipp and I are actually busy setting up such a mailing list and moving the repository, and we'll announce it shortly.
For example the usage of widgets can lead to something like a layout-manager or some other tools to really integrate them into Zope 2 applications. I think it would also drive some more testing and zope3 and further integration of other parts.
(If one has views, adapters, schemas and widgets, events are looming in the corner :-)
Events I suspect are actually easier to integrate than the forms bit. Regards, Martijn
Janko Hauser wrote: ...
Will this monkeypatch be somewhat of a blessed way to include view adapters into zope2?
Yes, subject to my review. :) Perhaps the monkey patch can be integrated into 2.8.
Than we can replace our current approach of using view adapters in union.cms with this one. Or will this be integrated into Zope 2.8 at the end?
Hopefully, depending on timing. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (4)
-
alan runyan -
Janko Hauser -
Jim Fulton -
Martijn Faassen