Re: [Zope-dev] Zope 4 ZMI sprint report
Thank you for the sprint report. I think it is great that you are working on upgrading the ZMI. I am also turning my attention to this problem. Clearly ZMI needs an upgrade. I need an upgraded ZMI. Today I fired up my old version of ZAM. I can give you a password and url if you want to see what it looks like. My understanding is that it is a well thought out upgrade for the ZMI. Properly done with page templates, not dtml, and pluggable. It certainly looks nice. Of course it has copy, cut, delete, rename, but no create. I also did a reinstall of the ZAM demo, but it broke. Am I doing the wrong thing working on ZAM? Is that consistent with the direction others are taking on upgrading the ZMI, or should I be putting my energy elsewhere? If I am doing the right thing working on ZAM, perhaps the first thing I should do is get the install working again correctly. For that I have to get svn access from the Zope foundation. I presume Larry Rowe is the release manager for Zope 4, so he is the person who signs off on the upgrades to ZAM? Do I understand the process correctly? Is ZAM part of Zope 4? Is it the basis of the new ZMI, or is something else the new ZMI? -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org
On 26 January 2012 04:29, Christopher Lozinski <lozinski@freerecruiting.com> wrote:
Thank you for the sprint report.
I think it is great that you are working on upgrading the ZMI.
I am also turning my attention to this problem. Clearly ZMI needs an upgrade. I need an upgraded ZMI.
Today I fired up my old version of ZAM. I can give you a password and url if you want to see what it looks like. My understanding is that it is a well thought out upgrade for the ZMI. Properly done with page templates, not dtml, and pluggable. It certainly looks nice.
Of course it has copy, cut, delete, rename, but no create.
I also did a reinstall of the ZAM demo, but it broke.
Am I doing the wrong thing working on ZAM? Is that consistent with the direction others are taking on upgrading the ZMI, or should I be putting my energy elsewhere?
If I am doing the right thing working on ZAM, perhaps the first thing I should do is get the install working again correctly. For that I have to get svn access from the Zope foundation. I presume Larry Rowe is the release manager for Zope 4, so he is the person who signs off on the upgrades to ZAM?
Do I understand the process correctly? Is ZAM part of Zope 4? Is it the basis of the new ZMI, or is something else the new ZMI?
I think building a better ZMI will be important in the long run though I'm not sure it should land in Zope 4 itself as I think it could be too big a step for that release. I wasn't able to get zam.demo (svn trunk) to run, so I don't have an opinion on ZAM itself at the moment. Note that Zope 4 is based on Zope 2 rather than BlueBream so I don't know how much of the existing work would still be applicable. I can volunteer some time towards guiding the Zope 4 release process, though it may be appropriate to find someone more comfortable with the existing svn/email/launchpad toolchain to be release manager if the consensus is to stay with that. Laurence
On 2/1/12 10:39 AM, Laurence Rowe wrote:
I wasn't able to get zam.demo (svn trunk) to run, so I don't have an opinion on ZAM itself at the moment. Note that Zope 4 is based on Zope 2 rather than BlueBream so I don't know how much of the existing work would still be applicable. Not being able to fire up the demo is a problem. Since people are talking about upgrading the ZMI, they should take a look at ZAM, but it does not currently install correctly. So you can take at an older install here:
http://ejr0.x.rootbsd.net:8080/ Login:Manager Password:password I will leave it up for a few days. If anyone wants to see it in the future, and it is down, just ask me to fire it up. It has Copy, Cut, Rename, Delete. No Add. So I am going back to the ugly ZMI. Hope this helps the people who are thinking of working on the ZMI. Also it is interesting to look at ice.control. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org
Hi Christopher
-----Ursprüngliche Nachricht----- Von: zope-dev-bounces@zope.org [mailto:zope-dev-bounces@zope.org] Im Auftrag von Christopher Lozinski Gesendet: Samstag, 4. Februar 2012 12:35 An: Laurence Rowe Cc: ct@gocept.com; zope-dev@zope.org Betreff: [Zope-dev] ZAM/ZMI Demo
On 2/1/12 10:39 AM, Laurence Rowe wrote:
I wasn't able to get zam.demo (svn trunk) to run, so I don't have an opinion on ZAM itself at the moment. Note that Zope 4 is based on Zope 2 rather than BlueBream so I don't know how much of the existing work would still be applicable. Not being able to fire up the demo is a problem. Since people are talking about upgrading the ZMI, they should take a look at ZAM, but it does not currently install correctly. So you can take at an older install here:
http://ejr0.x.rootbsd.net:8080/
Login:Manager Password:password
I will leave it up for a few days. If anyone wants to see it in the future, and it is down, just ask me to fire it up.
It has Copy, Cut, Rename, Delete. No Add. So I am going back to the ugly ZMI.
It has an Add menu, but there is nothing to add by default. You can see the Add menu left from the Context Menu. It will open if you hover on the "+". The important part in ZAM is, that it is cusomizable by ist plugins. This concept was used because not every project is using the full zope.* package stack. ZAM allows you to install a package include the configure.zcml and the UI get enhanced. but this makes ZAM a little bit complex because of it's layer interfaces. Probably ZAM should get improved and just use one layer or something like that. Regards Roger Ineichen
Hope this helps the people who are thinking of working on the ZMI. Also it is interesting to look at ice.control.
--
Regards Christopher Lozinski
Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com
Expect a paradigm shift. http://MyHDL.org
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
On Sun, Feb 5, 2012 at 04:49, Roger <dev@projekt01.ch> wrote:
It has an Add menu, but there is nothing to add by default. You can see the Add menu left from the Context Menu. It will open if you hover on the "+".
The important part in ZAM is, that it is cusomizable by ist plugins. This concept was used because not every project is using the full zope.* package stack.
This is at least an important attitude. I think also a future admin interface to a large extent should lose many of the ZMI concepts. For example, we need several management tools, like what is in the control panel at the moment. But that should be separate from the browsing of objects. That browsing should instead be a rather low-level ZODB browser, IMO. //Lennart
Hello, Op 6 feb 2012, om 10:26 heeft Lennart Regebro het volgende geschreven:
This is at least an important attitude. I think also a future admin interface to a large extent should lose many of the ZMI concepts. For example, we need several management tools, like what is in the control panel at the moment. But that should be separate from the browsing of objects. That browsing should instead be a rather low-level ZODB browser, IMO.
That would be great, for my part to be able to have the management tools (packing and such) in a separate package than the object browsing (and even the object actions, if you want to keep them, I don't want them). For some projects, I don't wish people to be able to browser the ZODB objects and fucked up things by copying, renaming objects and things like that, but I still want them to able to access the packing screen and such tools. And for this same reason, those two package should not depend on each others, so I say +1. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
Very good point about different user types. Maybe we could have different permissions on the different roles, and people only get to see their version. Right now there is just a single ZMI permission. At least in Zope 2 that was the case. So I suggest we have 3 new roles. System Administrator, Zope Administrator, Zope Developer. System administrator could view the database size, pack it, and start and stop zope. That is about it. Zope administrator could also move things around and delete things. Maybe add a few types of objects, such as cache objects. Zope developer could add arbitrary objects. I think this distinction would go a long way towards resolving the conflicts I have seen over the years about the ZMI. What do you think? Regards Chris On 2/6/12 7:07 AM, Sylvain Viollon wrote:
Hello,
Op 6 feb 2012, om 10:26 heeft Lennart Regebro het volgende geschreven:
This is at least an important attitude. I think also a future admin interface to a large extent should lose many of the ZMI concepts. For example, we need several management tools, like what is in the control panel at the moment. But that should be separate from the browsing of objects. That browsing should instead be a rather low-level ZODB browser, IMO.
That would be great, for my part to be able to have the management tools (packing and such) in a separate package than the object browsing (and even the object actions, if you want to keep them, I don't want them).
For some projects, I don't wish people to be able to browser the ZODB objects and fucked up things by copying, renaming objects and things like that, but I still want them to able to access the packing screen and such tools.
And for this same reason, those two package should not depend on each others, so I say +1.
Regards,
Sylvain,
-- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org
Hello, Op 6 feb 2012, om 17:06 heeft Christopher Lozinski het volgende geschreven:
Very good point about different user types. Maybe we could have different permissions on the different roles, and people only get to see their version. Right now there is just a single ZMI permission. At least in Zope 2 that was the case.
So I suggest we have 3 new roles.
System Administrator, Zope Administrator, Zope Developer.
System administrator could view the database size, pack it, and start and stop zope. That is about it. Zope administrator could also move things around and delete things. Maybe add a few types of objects, such as cache objects. Zope developer could add arbitrary objects.
I think this distinction would go a long way towards resolving the conflicts I have seen over the years about the ZMI.
Having different roles will help greatly yes, and even if we end up with multiple packages that would still be a great idea to have, but again, if I don't expect (want) my users to use this browsing interface at all, why should I load all its code when the server start ? That just increase the application footprint for nothing, and designing the new ZMI in two or three packages (not 50) would solve it. And I am against 50 packages too, as setuptools get exponentially slower when you load entry_points, as it check that all dependencies of your packages are installed. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
Having different roles will help greatly yes, and even if we end up with multiple packages that would still be a great idea to have, but again, if I don't expect (want) my users to use this browsing interface at all, why should I load all its code when the server start ?
That just increase the application footprint for nothing, and designing the new ZMI in two or three packages (not 50) would solve it.
Makes sense to me. Two or three roles, and two or three packages. One role per package. In any case it should be possible to split ZAM out into different pieces. I am really glad to see that multiple people are interested in building on ZAM and working with it. That motivates me to work on it. Thank you so much Roger for pointing out the + sign for adding objects in the ZAM interface. Now I just need to figure out how to get it to work! Regards Chris
There are a number of people interested in ZAM, and a lot of discussion about a new ZMI, even an upcoming sprint so I am trying to do my part to get zam.demo installing correctly. Of course the error message was completely incomprehensible, I did not have the context. So step 1 is to figure out how ZAM works. I went to read the source code. Very nicely documented. Thanks to the authors. But there is no high level documentation, so I wrote this user level document. Writing this helped me understand ZAM better. And in general I think a great way for new developers to work with Zope is to write documentation, because then it helps us understand what we are doing, makes it easier to get feedback, and smooths the path for those coming after us. So here is where I left off six months ago. https://mail.zope.org/pipermail/zope-dev/2011-June/043089.html What follows is the updated version. ZAM User Documentation. ZAM is a browser based interface to BlueBream. It allows us to interact with the running BlueBream server. It provides three types of services. Administration services tell you about the Unix processes, and the ZODB databases. Error services tell you about server errors which have occurred. Hierarchy services allow one to interact with the ZODB hierarchy of objects. ADMINISTRATION SERVICES (zamplugin.control) This wepage has links to runtime information, ZODB information, Generations, and Registration. To access it you go to http://localhost/++skin++ZAM/++etc++ApplicationController/index.html The runtime information includes the following: Uptime, System platform, Zope version, Python version, Command line used to start the server, Preferred encoding, Process id, Developer mode on or off, and the Python path ZODB control includes a list of ZODB databases, their file system name, current size, and the ability to pack them, keeping up to X number of days of version. Generations describes the versions of ZODB schemas, and is a way of updating the objects as the schema changes. Impressive! Registrations allow objects to be registered as adaptors or user interfaces. This is a complex topic which requires an understanding of the Zope Component Architecture. In general beginners do not need to worry about this. ERROR SERVICES (zamplugin.error) You can see the error logs here. http://localhost/++skin++ZAM/++etc++site/default/RootErrorReportingUtility Looks very nice, much like the Zope 2 error reports. You get Time, User,and exception. You can click on the exception for more details, the Request URL, Traceback, user permissions, and the full REQUEST object. HIERARCHY SERVICES (zamplugin.sitemanager, zamplugin.navigation) Bluebream stores objects in the Zope Object Database. Objects are stored in a tree. The allows one to navigate the tree, browse objects, cut, copy, paste, and rename those objects. In the current version, when enabled, it is possible to add objects to the tree. In future versions this may also require developer permisssion. I am not sure which part of the interface is handled by the site manager, and which part is handled by navigation. zamplugin.sampledata From pypi: "A sample data generator is a pluggable tool to create data needed for tests." Not really sure what this does either. If you want to learn more about ZAM, go into the source code. Go into the eggs directory and type more zam*/zam*/*/README.txt That gets you all of the source code docs. There are several different sections. There is zam.api which provides the core functionality. There is the best README.txt in this section. It explains the ZAM plugin framework. You can add or remove a plugin, but obviously only once. It talks about a base registry plugin. They talk about the layers model. Layers are all about the stuff in the skin, described below. zam.skin contains all the "HTML, JS, CSS and image components" The other directories correspond to the user interfaces described above. QUESTION: So where should i put this documentation? My next step is to try to run zam.demo again, and see if the error message makes any more sense to me than it did this morning. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org
Am 06.02.2012 um 21:35 schrieb Christopher Lozinski: [...]
ZAM User Documentation.
Nice text. [...]
QUESTION: So where should i put this documentation?
I think you should put it into the README of zam.skin this is the zam top-level package. The read-me of zam.api and zam.demo might reference it using its PyPI page. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations
On Mon, Feb 6, 2012 at 13:07, Sylvain Viollon <sylvain@infrae.com> wrote:
That would be great, for my part to be able to have the management tools (packing and such) in a separate package than the object browsing
Excellent point.
(and even the object actions, if you want to keep them, I don't want them).
We need two packages for the object browser: One with the interfaces and layers to enable registration of the object actions and views, and one with the actual object browser views, that makes use of these registered actions and views. And we need one package that contain the "New ZMI" which is basically just a Zope Control panel, where the object browser is just one plugin to that control panel. //Lennart
participants (6)
-
Christopher Lozinski -
Laurence Rowe -
Lennart Regebro -
Michael Howitz -
Roger -
Sylvain Viollon