Zope direction and 2.2 roadmap...
Hi all. Now that Zope 2.1.0 is out the door, we at DC want to let the community know our direction and the "roadmap" leading to 2.2. In a nutshell, our direction and focus will be on usability. Making it easier to get things done with Zope has been a recurring theme on the lists lately, and we will be working to make progress on this front. For 2.2, here is the short list of we will be working on: o Online Help System - Amos has been doing great work on a real honest-to-goodness online help system for Zope that will make its debut in 2.2. o Python Methods - work will be done to include Evan Simpson's Python Methods in the Zope core. This should help a lot in avoiding the headaches of convoluted DTML logic. o Site Objects - will make it easier to deploy "virtual sites" in the same Zope with far less effort than is required now. o The ability to associate ZClasses as "brains" for relational database data instead of having to write Python classes. o And of course, fixes for bugs and issues in the Collector. We are expecting to have these things available in at least a pre-release by the time of the Zope track at the Python Conference. There are other usability initiatives underway as well. Rob and Amos have been doing a _lot_ of work coming up with a much better and much more scalable approach to documentation that should have a big impact on the quality and breadth of documentation. Work will also continue on making Zope.org a better resource with things like ZTopics (Yahoo-style directory views). And there are some other projects percolating (which I can't talk about yet :) that will have a big impact on usability. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
On Wed, Dec 08, 1999 at 02:55:34PM -0500, Brian Lloyd wrote:
o Site Objects - will make it easier to deploy "virtual sites" in the same Zope with far less effort than is required now.
I was munching on this for a week at least, but didn't post due to other, more pressing issues. But... I would really like to be able to ``isolate'' a ZClass. I mean, develop it for one customer and not make it available for the others. It's not as much a commercial problem, as it is a problem of having the ``Add'' select box popping up 2 or 3 pages of stuff that is completely useless for most customers. Right now I'm considering radical approaches like deleting the factories and building the objects using specialized methods instead of the management interface. But it would be great if Zope 2.2 allowed ``constrained'' ZClasses (or factories, at least). (Yes, I could just tweak the permissions, but that would be a kludge. What I really want is to give each customer ``manager'' role on her folder and not think about it again.) []s, |alo +---- -- I am Lalo of deB-org. You will be freed. Resistance is futile. http://www.webcom.com/lalo mailto:lalo@webcom.com pgp key in the web page Debian GNU/Linux -- http://www.debian.org
Hi, I take that you mean allowing ZClass "implementations" (not instances) to reside within the main ZODB and hence be able to use permissions etc. If this is the case check out VisualZope for some ideas. The *new* address (with content still coming but I can email you the tgz if ur in a hurry) is: http://visualzope.linuxbox.com/ Other Zopeisters - linuxbox offers free hosting of your Zope projects with *full* access to Zope source (ie Products directory). VisualZope provides a Widget. A widget is like a Zclass (ie can inherit from other widgets and widget types) and contains dtml, python methods etc. A number of "renderable" methods are also provided. To *use* them, just place a VZ editor in the acquisition chain somewhere. If one is found, the Zope Management system is modified to use this instead. Every editor can display a list of all widgets in the acqusition path. Needless to say, if you don't have permissions on that widget you just don't see it and it is never activated. Editors proivde a document type specific way of editing a document. Remember, the document type can be changed on the fly and can have a number of types at one time. Ignore the name, VisualZope, it is much more than that. Basically, it is my version of the Multiple document format ideas that were floating about. Closest description is that of the XSL renderer. However, you can apply different renderers to different parts of the document (ie one part can be a dtml document, another a word file etc) Cheers, Anthony Pfrunder
participants (3)
-
Anthony Pfrunder -
Brian Lloyd -
Lalo Martins