Re: [Zope3-Users] Found a (perhaps obvious) page template speedup
Stephan Richter wrote: The point is that I am not interesting in supporting the ZMI at all. I have no use for users or developers to ever use the ZMI. In fact, basing my skin on the ZMI is bad because it provides all those URLs I (a) do not have control over -- thus being a security risk, and (b) are not needed and make the system slower. This is stupid. One of the big wins for Zope 3 was that you were supposed to be able to re-use UI code without having to write it all from scratch. The ZMI has a lot of widgets that people should want to re-use (generically: tree controls, file widgets, directory listings, etc, specifically: forms and configuration for the generic parts of zope) It sounds like you're advocating writing every bit of UI from scratch, as you have to in Zope 2 due to the hard-coded nature of the ZMI, but I'm hoping I'm mistaken... Am I? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Found a (perhaps obvious) page template speedup
Chris Withers wrote: The ZMI has a lot of widgets that people should want to re-use (generically: tree controls, file widgets, directory listings, etc, specifically: forms and configuration for the generic parts of zope) It sounds like you're advocating writing every bit of UI from scratch, as you have to in Zope 2 due to the hard-coded nature of the ZMI, but I'm hoping I'm mistaken... Am I? Widgets are in zope.app.form.browser, and those can be use independently of ZMI Forms are in zope.formlib (or zope.app.form), again independent of ZMI Want menus? Again, they are *used* by ZMI but you can define your own with the same machinery.. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Found a (perhaps obvious) page template speedup
On Friday 02 June 2006 03:57, Jeff Rush wrote: I would always write a skin from scratch. That's a lot of work, to fully cover all the needs of the ZMI, error pages etc. Besides, I thought one benefit of the layers facility is that you can keep most of a skin and only implement what you want different, similar to the idea of subclassing. If you're going to write your skin from scratch, you might as well keep it in one layer, it seems. Or am I missing the purpose of layers? The point is that I am not interesting in supporting the ZMI at all. I have no use for users or developers to ever use the ZMI. In fact, basing my skin on the ZMI is bad because it provides all those URLs I (a) do not have control over -- thus being a security risk, and (b) are not needed and make the system slower. What I was aiming for was to keep the ZMI look/feel the way it is now, so I don't have to grok all the intricacies, and then to provide a non-ZMI skin for the customer. It doesn't seem to work that way though. Right, making the ZMI skin flexible and pluggable enough is much more work then developing a skin from scratch. And then there is always the benefit that you know what's available and what permissions are required for thise available pages, which was something that was really important in my last project. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Found a (perhaps obvious) page template speedup
On Sunday 16 April 2006 15:17, Jeff Rush wrote: Perhaps most of you already know this but it bit me this week. For my project I've noticed some sluggish presentation of pages, and a lot of container queries flying around for very simple pages. It turns out to be Javascript code (singleBranchTree.xml) that is walking one-level of parents, siblings and children for each of my pages, even though I don't have a nav tree widget in my skin. I thought I was doing things the preferred way, by using the existing @@standard_macros/page and filling in slots to change out selected portions. It turns out that while there is a slot to disable the -display- of the nav tree, there isn't one for the page header to disable the -computation- of the nav tree, which is triggered from within the browser via navigation_tree.js upon the body load event. I would always write a skin from scratch. Roger Ineichen has developed a set of minimal registrations (like error pages, etc) for a new skin. He should probably release that code, if he has not already. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
