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
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 )
Scavenging the mail folder uncovered Stefan Kuzminski's letter:
">" == 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 have to say that <aol>i agree too.</aol> i had a discussion some days ago with some co-workers using zope about the "why they did put in dtml instead of using plain python?" some people expressed the desire to have access to full python in zope, others said that learning dtml is easier and faster than learning a full programming language. so the question is: do you developers think that adding python support (maybe into a dtml tag, as a product) is feasible? ciao, federico -- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Don't dream it. Be it. -- Dr. Frank'n'further
I agree that we have lots of work to do on making Zope more understandable and faster to "get a grip on". We're struggling right now with what it means to do that, whether it means concentrating on documentation, building a simpler interface, ripping stuff out or what-have-you. Examples of the community and DC trying to address these problems are evident in the Zope Mozilla Initiative, the soon(really!)-to-be-released Portal Toolkit, and the shiny new help system that Amos has been working hard on. Unfortunately, all of it takes time. My opinion, for what its worth, is that DTML is valuable because it lets non-Python programmers have a crack at building simple dynamic pages in an environment that they're familiar with (ie. in the context and style of HTML). But I do think that we've possibly allowed DTML to overstep its bounds as a reporting language, and now we've got people trying to make it do things that could be infinitely better handled in Python. But we've also got external methods and Evan Simpson has contributed Python Methods. So I think we're slowly reaching a point where Zope is an ideal environment for Python programmers and a less ideal but still very usable environment for non-Python programmers. I would suggest giving both tools a workout. I also would suggest that if you've got the time, we could definitely use your help simplifying Zope in other ways. For example, both the Zope Mozilla Initiative and the Zope Documentation Project could use reliable expert help. Both projects are extremely interesting too. Federico Di Gregorio wrote:
Scavenging the mail folder uncovered Stefan Kuzminski's letter:
> ">" == 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 have to say that <aol>i agree too.</aol> i had a discussion some days ago with some co-workers using zope about the "why they did put in dtml instead of using plain python?" some people expressed the desire to have access to full python in zope, others said that learning dtml is easier and faster than learning a full programming language.
so the question is: do you developers think that adding python support (maybe into a dtml tag, as a product) is feasible?
ciao, federico
-- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Don't dream it. Be it. -- Dr. Frank'n'further
_______________________________________________ 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 )
-- Chris McDonough - Digital Creations, Inc. Publishers of Zope - http://www.zope.org
Scavenging the mail folder uncovered Chris McDonough's letter:
My opinion, for what its worth, is that DTML is valuable because it lets non-Python programmers have a crack at building simple dynamic pages in an environment that they're familiar with (ie. in the context and style of HTML). But I do think that we've possibly allowed DTML to overstep its bounds as a reporting language, and now we've got people trying to make it do things that could be infinitely better handled in Python.
I completely agree.
But we've also got external methods and Evan Simpson has contributed ^^^^^^^^^^^^^^^^ Talking about external methods I have a little problem with them: every time a method outputs to stdout zope bombs and you have to restart it. So we have to put try/except clauses around anything when an exception logged somewere would be much better in debugging the method. It is a problem of my installation, a known one or a feature?
Python Methods. So I think we're slowly reaching a point where Zope is an ideal environment for Python programmers and a less ideal but still very usable environment for non-Python programmers. I would suggest giving both tools a workout.
i'll investigate Python Methods. and, from *my* point of view a more python-programmer oriented zope is better than a simplier but less powerfull one. IMHO; off course.
I also would suggest that if you've got the time, we could definitely use your help simplifying Zope in other ways. For example, both the Zope Mozilla Initiative and the Zope Documentation Project could use reliable expert help. Both projects are extremely interesting too.
apart from my involvement in debian, i work for a company commited to free software. we use zope extensively and we'll surely give back to the community any patch/improvment/documentation we produce. ciao and thank you again, federico -- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Try the Joy of TeX [http://www.tug.org] -- brought to you by One Line Spam
Federico Di Gregorio wrote:
But we've also got external methods and Evan Simpson has contributed ^^^^^^^^^^^^^^^^ Talking about external methods I have a little problem with them: every time a method outputs to stdout zope bombs and you have to restart it. So we have to put try/except clauses around anything when an exception logged somewere would be much better in debugging the method. It is a problem of my installation, a known one or a feature?
I don't think it's a known issue (at least by me)... can you reliably reproduce it?
apart from my involvement in debian, i work for a company commited to free software. we use zope extensively and we'll surely give back to the community any patch/improvment/documentation we produce.
Thanks! -- Chris McDonough - Digital Creations, Inc. Publishers of Zope - http://www.zope.org
Chris McDonough wrote:
Federico Di Gregorio wrote:
Talking about external methods I have a little problem with them: every time a method outputs to stdout zope bombs and you have to restart it. So we have to put try/except clauses around anything when an exception logged somewere would be much better in debugging the method. It is a problem of my installation, a known one or a feature?
I don't think it's a known issue (at least by me)... can you reliably reproduce it?
If Federico is talking about the same problem that ZPyGreSQL users encountered, then it only happens when Zope is run as a daemon. As long as it is started with a pty to talk to, it's fine. Start it using the sysvinit script, and it goes down *hard* every time something prints (in the ZPyGreSQL case, whenever Zope propagated an error message from PostgreSQL). Cheers, Evan @ 4-am
Scavenging the mail folder uncovered Evan Simpson's letter:
Chris McDonough wrote:
Federico Di Gregorio wrote:
Talking about external methods I have a little problem with them: every time a method outputs to stdout zope bombs and you have to restart it. So we have to put try/except clauses around anything when an exception logged somewere would be much better in debugging the method. It is a problem of my installation, a known one or a feature?
I don't think it's a known issue (at least by me)... can you reliably reproduce it?
If Federico is talking about the same problem that ZPyGreSQL users encountered, then it only happens when Zope is run as a daemon. As long as it is started with a pty to talk to, it's fine. Start it using the sysvinit script, and it goes down *hard* every time something prints (in the ZPyGreSQL case, whenever Zope propagated an error message from PostgreSQL).
that is. we start zope as a daemon, without a pty. -- Federico Di Gregorio MIXAD LIVE System Programmer fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Don't dream it. Be it. -- Dr. Frank'n'further
Federico Di Gregorio wrote:
i'll investigate Python Methods. and, from *my* point of view a more python-programmer oriented zope is better than a simplier but less powerfull one. IMHO; off course.
(Egads, I've become a lurker!) Here's an interesting datapoint from the Zope Track this week. I asked a show of hands on two questions: 1) Who here didn't know Python before Zope? 2) Who found Zope within the last three months? On both cases, almost half the hands went up. IMO, Zope has an opportunity to be meaningful to non-programmers, and more importantly, has an opportunity for programmers to turn meaning (read: Zope Products) over to non-programmers. --Paul
On Sat, 29 Jan 2000, Paul Everitt wrote:
Here's an interesting datapoint from the Zope Track this week. I asked a show of hands on two questions:
1) Who here didn't know Python before Zope?
2) Who found Zope within the last three months?
On both cases, almost half the hands went up. IMO, Zope has an opportunity to be meaningful to non-programmers, and more importantly, has an opportunity for programmers to turn meaning (read: Zope Products) over to non-programmers.
It would have been even more interesting if you had also asked 'Who didn't know CGI, PHP, Java or ASP programming before Zope'. The gut feel *I* have about Zope is it caters mainly for people who got sick of PHP, CGI, Java or ASP (don't know about CF or Notes), or felt that it all could be done better. It would also be interesting to find out who prefers: a) Getting a document template from a designer and adding in the dynamic information b) Creating an object for a designer to use I suppose it depends on how clueful your designers are... its not fun doing b when your first have to quiz the designer on what they want, implement it, show them how to use it, fix their bugs, and then starting over again when it turns out the first step was a total balls up :-( Maybe I've worked in a University for too long... -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
">" == Chris McDonough <chrism@digicool.com> writes:
I agree that we have lots of work to do on making Zope more understandable and faster to "get a grip on". We're struggling right now with what it means to do that, whether it means concentrating on documentation, building a simpler interface, ripping stuff out or what-have-you. Examples of the community and DC trying to address these problems are evident in the Zope Mozilla Initiative, the soon(really!)-to-be-released Portal Toolkit, and the shiny new help system that Amos has been working hard on. Unfortunately, all of it takes time.
Just a thought.. addressing the split in the user demographic between people from the HTML world and from the programming world. Perhaps the HTML people could be gently introduced by exporting the the string substitution syntax which is so nice in python. i.e. <htmlcode> %s <morehtml> % <more_html> More powerful programming constructs, variables, iteration, etc.. could be introduced as the user learns and needs them. It's an observation on how to teach a HTML writer programming, give them something at first that relates to what they know and is powerful but not so powerful as they would get into trouble by pushing it too far.. ( since the string substitution contains no state machine )..
My opinion, for what its worth, is that DTML is valuable because it lets non-Python programmers have a crack at building simple dynamic pages in an environment that they're familiar with (ie. in the context and style of HTML). But I do think that we've possibly allowed DTML to overstep its bounds as a reporting language, and now we've got people trying to make it do things that could be infinitely better handled in Python.
But we've also got external methods and Evan Simpson has contributed Python Methods. So I think we're slowly reaching a point where Zope is an ideal environment for Python programmers and a less ideal but still very usable environment for non-Python programmers. I would suggest giving both tools a workout.
I also would suggest that if you've got the time, we could definitely use your help simplifying Zope in other ways. For example, both the Zope Mozilla Initiative and the Zope Documentation Project could use reliable expert help. Both projects are extremely interesting too.
participants (10)
-
Brian Lloyd -
Chris McDonough -
Dan L. Pierson -
Evan Simpson -
Federico Di Gregorio -
Michael Bernstein -
Paul Everitt -
Ross Boylan -
Stefan Kuzminski -
Stuart 'Zen' Bishop