who wants to maintain the Zope 3 ZMI?
Hi there, In the whole discussion about Zope 3 I saw very few people speak up for the Zope 3 ZMI. So, who finds the Zope 3 ZMI useful? What parts of it do you find useful? Are you interested in helping maintain it? Note that I'm talking about the concrete Zope 3 ZMI here, not the general concept of the ZMI. I think there are quite a few useful concepts surrounding the ZMI, but the Zope 3 ZMI isn't that good at making any of these concepts work right now, in my opinion. If we get a consensus that the ZMI in Zope 3 isn't actually used a lot, we could take a lot more drastic action in removing it from our codebase than we've done before. If people are using it, we shouldn't do that of course. Regards, Martijn
Hello there, * 2009-04-14 18:35, Martijn Faassen wrote:
So, who finds the Zope 3 ZMI useful? What parts of it do you find useful? Are you interested in helping maintain it?
We use the ZMI to manage applications, where applications are instances of a content object stored in the ZODB. All in all, we manage applications in a similar way we manage plone sites in zope2.x. If this specific feature is going to be removed, I'm willing to support and maintain it. Best regards. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _____________________________________________________________________ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
Hey Fabio, Fabio Tranchitella wrote:
* 2009-04-14 18:35, Martijn Faassen wrote:
So, who finds the Zope 3 ZMI useful? What parts of it do you find useful? Are you interested in helping maintain it?
We use the ZMI to manage applications, where applications are instances of a content object stored in the ZODB. All in all, we manage applications in a similar way we manage plone sites in zope2.x.
If this specific feature is going to be removed, I'm willing to support and maintain it.
Cool! That's a quite limited use of the ZMI if I understand you correctly. I use it that way as well too in pure Zope 3 settings. Grok has a UI that *only* does that (well, besides introspection). It might be an easier way to maintain this concept is to write a simple UI for Zope 3 that only cares about installation of applications? It'd be much less involved than all the ZMI code we currently have to worry about. Regards, Martijn
Hello, * 2009-04-14 19:35, Martijn Faassen wrote:
It might be an easier way to maintain this concept is to write a simple UI for Zope 3 that only cares about installation of applications? It'd be much less involved than all the ZMI code we currently have to worry about.
I'd be curious to know if anybody else is using ZMI for anything other than this; if this is the typical usage scenario, than reducing it to a simple UI is a good idea. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _____________________________________________________________________ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
Hi Fabio, Martijn
Betreff: Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
Hello,
* 2009-04-14 19:35, Martijn Faassen wrote:
It might be an easier way to maintain this concept is to write a simple UI for Zope 3 that only cares about installation of applications? It'd be much less involved than all the ZMI code we currently have to worry about.
I'd be curious to know if anybody else is using ZMI for anything other than this; if this is the typical usage scenario, than reducing it to a simple UI is a good idea.
As far as I understand, it should also be optional. This would allow Grok or other frameworks to plugin their own management UI. Regards Roger Ineichen
-- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _____________________________________________________________________ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 _______________________________________________ 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 )
Roger Ineichen wrote:
Hi Fabio, Martijn
Betreff: Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
Hello,
* 2009-04-14 19:35, Martijn Faassen wrote:
It might be an easier way to maintain this concept is to write a simple UI for Zope 3 that only cares about installation of applications? It'd be much less involved than all the ZMI code we currently have to worry about. I'd be curious to know if anybody else is using ZMI for anything other than this; if this is the typical usage scenario, than reducing it to a simple UI is a good idea.
As far as I understand, it should also be optional. This would allow Grok or other frameworks to plugin their own management UI.
Yes, I think one of the important lessons is not to integrate any UI with the main code anymore. This makes the UI optional and allows some room for alternatives. Regards, Martijn
Am Dienstag 14 April 2009 19:31:32 schrieb Martijn Faassen:
Hey Fabio,
Fabio Tranchitella wrote:
* 2009-04-14 18:35, Martijn Faassen wrote:
So, who finds the Zope 3 ZMI useful? What parts of it do you find useful? Are you interested in helping maintain it?
We use the ZMI to manage applications, where applications are instances of a content object stored in the ZODB. All in all, we manage applications in a similar way we manage plone sites in zope2.x.
If this specific feature is going to be removed, I'm willing to support and maintain it.
Cool!
That's a quite limited use of the ZMI if I understand you correctly. I use it that way as well too in pure Zope 3 settings.
Grok has a UI that *only* does that (well, besides introspection).
It might be an easier way to maintain this concept is to write a simple UI for Zope 3 that only cares about installation of applications? It'd be much less involved than all the ZMI code we currently have to worry about.
Well, that's basically what I personally use the ZMI for and would need... Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
I use zmi as a basic ui for viewing objects bacause we get basic views for some default content, navigating the object store, and configuring local security settings on objects, and configuring per instance tools. And this is mainly because in the early stages of our projects we haven't built the UI. Oh and we probably wouldn't integrate some the tool management in our UI like pluggable auth components. T On Wed, Apr 15, 2009 at 12:34 AM, Martijn Faassen <faassen@startifact.com> wrote:
Hi there,
In the whole discussion about Zope 3 I saw very few people speak up for the Zope 3 ZMI.
So, who finds the Zope 3 ZMI useful? What parts of it do you find useful? Are you interested in helping maintain it?
Note that I'm talking about the concrete Zope 3 ZMI here, not the general concept of the ZMI. I think there are quite a few useful concepts surrounding the ZMI, but the Zope 3 ZMI isn't that good at making any of these concepts work right now, in my opinion.
If we get a consensus that the ZMI in Zope 3 isn't actually used a lot, we could take a lot more drastic action in removing it from our codebase than we've done before. If people are using it, we shouldn't do that of course.
Regards,
Martijn
_______________________________________________ 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 )
Hi, On Tue, 14 Apr 2009 18:34:47 +0200 Martijn Faassen <faassen@startifact.com> wrote:
So, who finds the Zope 3 ZMI useful? What parts of it do you find useful? Are you interested in helping maintain it?
For me, the ZMI is useful to managing local components, security settings, making views for ad hoc changes etc. I think it could be an optional package like grokui.admin. I'm interested in maintenance it. Best regards, -- Yusei TAHARA <yusei@domen.cx>
Hey, Yusei TAHARA wrote:
On Tue, 14 Apr 2009 18:34:47 +0200 Martijn Faassen <faassen@startifact.com> wrote:
So, who finds the Zope 3 ZMI useful? What parts of it do you find useful? Are you interested in helping maintain it?
For me, the ZMI is useful to managing local components, security settings, making views for ad hoc changes etc. I think it could be an optional package like grokui.admin. I'm interested in maintenance it.
Great! Perhaps one way to make the ZMI and optional package is to aggregate the relevant ZMI code into a smaller amount of packages (or a single package), for instance zmi.core. The benefit of doing that is that it should be possible to evolve the code slowly. You could still support the zope.app.* packages compatibility by putting imports from zope.app.something.browser to zmi.core. Alternatively someone could write something from scratch, but that might need longer waiting. Regards, Martijn
Hi, On Wed, 15 Apr 2009 09:37:33 +0200 Martijn Faassen <faassen@startifact.com> wrote:
Perhaps one way to make the ZMI and optional package is to aggregate the relevant ZMI code into a smaller amount of packages (or a single package), for instance zmi.core. The benefit of doing that is that it should be possible to evolve the code slowly. You could still support the zope.app.* packages compatibility by putting imports from zope.app.something.browser to zmi.core.
Then I'll take this way for now. Maybe z3c.zmi.core would be good? Best regards, -- Yusei TAHARA <yusei@domen.cx>
Yusei TAHARA wrote:
Hi,
On Wed, 15 Apr 2009 09:37:33 +0200 Martijn Faassen <faassen@startifact.com> wrote:
Perhaps one way to make the ZMI and optional package is to aggregate the relevant ZMI code into a smaller amount of packages (or a single package), for instance zmi.core. The benefit of doing that is that it should be possible to evolve the code slowly. You could still support the zope.app.* packages compatibility by putting imports from zope.app.something.browser to zmi.core.
Then I'll take this way for now. Maybe z3c.zmi.core would be good?
Flat is better than nested (see the Zen of Python). I'd say go for "zmi.core"; z3c isn't necessary. Regards, Martijn
On Wed, 15 Apr 2009 14:10:44 +0200 Martijn Faassen <faassen@startifact.com> wrote:
Then I'll take this way for now. Maybe z3c.zmi.core would be good?
Flat is better than nested (see the Zen of Python). I'd say go for "zmi.core"; z3c isn't necessary.
Thanks. I will use the name "zmi.core" and will commit initial draft this weekend. Best regards, -- Yusei TAHARA <yusei@domen.cx>
Yusei TAHARA wrote:
On Wed, 15 Apr 2009 14:10:44 +0200 Martijn Faassen <faassen@startifact.com> wrote:
Then I'll take this way for now. Maybe z3c.zmi.core would be good? Flat is better than nested (see the Zen of Python). I'd say go for "zmi.core"; z3c isn't necessary.
Thanks. I will use the name "zmi.core" and will commit initial draft this weekend.
That's great to hear! If you want to move code from existing zope.app.* packages, you need to make sure you keep track of where you move things from. Once you're happy with zmi.core, you can change the zope.app.* packages that you took code from to depend on zmi.core by placing backwards compatibility imports in those packages (and modifying their setup.py to depend on zmi.core). That's only for backwards compatibility though - zmi.core should be installable without having to rely on a lot of zope.app.* packages (zope.app.publication and zope.app.form excepted, I mean those packages that actually provide the ZMI). You should try to limit the amount of packages that zmi.core itself depends on - it shouldn't be depending on zope.app.* packages for instance, otherwise we will get hard-to-understand circular dependencies. Regards, Martijn
participants (6)
-
Fabio Tranchitella -
Hermann Himmelbauer -
Martijn Faassen -
Roger Ineichen -
Tim Hoffman -
Yusei TAHARA