Zope Futures discussion: your input
Hi all, I will be giving a talk at the Zope Track at IPC8 on the future directions of Zope. The format will be about half me babbling about our broad future plans and half Q & A. I would like to make sure that I cover the things that the zopista community cares about in the first part, so I'm putting out a call for you to chime in and let me know what topics are important to you. I can't promise to cover them all, but I do hope to be able to address the ones that are most common among your responses. Please cc the list on your feedback! Thanks! Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
One of the issues I think are important for web application development are link or pointers to arbitrary objects (ie. not contained within the object) of a certain type, so that it is easier to create many-to-many relationships. An example: Authors write many books, books can have more than one author. It does not make sense to create 'book' objects within the 'author' objects, nor does it make sense to do the reverse. instead, author objects and book objects should each be contained in their own heirarchies, and an external repository (probably based on ZCatalog) would contain bi-directional link objects. If an object subclasses a 'linking' class, it would get a tab that shows all the objects that it links to, and new objects added through that tab are added to the link repository automatically. Further, it would be nice if it were possible to traverse into the linked-to object to access its properties, ie: <dtml-var Author.Name> from within the 'book' object. Michael Bernstein.
Please include any plans you have for making upgrading of Zope installations easier. Right now it's somewhat of a pain. More importantly there are lots of chances for cockpit errors. Dan Pierson
Scavenging the mail folder uncovered Dan L. Pierson's letter:
Please include any plans you have for making upgrading of Zope installations easier. Right now it's somewhat of a pain. More importantly there are lots of chances for cockpit errors.
can I humbly suggest you to install a distribution that contains Zope, like... err... emm... well... maybe Debian GNU/Linux? (ops, sorry for this spam.) ciao, federico -- Federico Di Gregorio [http://www.bolinando.com/fog] {Friend of Penguins} Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Best friends are often failed lovers. -- Me
Federico Di Gregorio writes:
Scavenging the mail folder uncovered Dan L. Pierson's letter:
Please include any plans you have for making upgrading of Zope installations easier. Right now it's somewhat of a pain. More importantly there are lots of chances for cockpit errors.
can I humbly suggest you to install a distribution that contains Zope, like... err... emm... well... maybe Debian GNU/Linux? (ops, sorry for this spam.)
Guilty as charged :-) We're using RedHat for all of the external Zope stuff here. I also plead guilty to using NT for an internal site... Does Debian's Zope package support updating an existing Zope site to a new version of Zope without disturbing the contents and products in the site?
I think the key issues are 1) Documentation and 2) Simplification of the actual system and 3) Documentation Though 2) is more ambitious, it would obviously make 1) easier. For example, there are ZClasses, python classes, other objects created in the Zope tree. There's also dtml. Want to add a variable? It could go in a ZClass, python class, or be "property" (if I have the right lingo) thrown into an existing object which obeys the management interface. There's more than one way to do it (tm) is someone else's slogan! I, and I think others, have struggled with exactly how information and calls on the browser/dtml side map to and from stuff happening in python space.
">" == Ross Boylan <rboylan@mindspring.com> writes:
Simplification.. I couldn't agree more with this assessment, Zope is beautiful and powerful but just finding the right level to code at can be a challenge. The relationship between browser/dtml and the python space is especially difficult to decypher, especially from the dtml side. I'm not convinced of the value of dtml since Python is so easy to learn and using a markup language for programming tasks leaves something to be desired..
I think the key issues are 1) Documentation and 2) Simplification of the actual system and 3) Documentation
Though 2) is more ambitious, it would obviously make 1) easier.
For example, there are ZClasses, python classes, other objects created in the Zope tree. There's also dtml.
Want to add a variable? It could go in a ZClass, python class, or be "property" (if I have the right lingo) thrown into an existing object which obeys the management interface.
There's more than one way to do it (tm) is someone else's slogan!
I, and I think others, have struggled with exactly how information and calls on the browser/dtml side map to and from stuff happening in python space.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
participants (6)
-
Brian Lloyd -
Dan L. Pierson -
Federico Di Gregorio -
Michael Bernstein -
Ross Boylan -
Stefan Kuzminski