RE: [Zope-dev] Re: [Zope] Zope direction and 2.2 roadmap...
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:
Any plans to include the new "local" and "set" tags I submitted for perusal a month or two ago? Thanks.
The subject of DTML is a volatile one at the moment, as I'm sure you've seen from the list :) One of the big goals for 2.2 is to see how effective the integration of Python Methods is at reducing the necessity for complexity in DTML. The hope is that PMs will help reduce the need to introduce ever more constructs into DTML, so I plan to wait a while so that we can evaluate the results of the PM effort before adding anything more to the DTML core. I will definitely be interested in feedback from Zopistas on the effect of PMs on the sort of problems that tags like "local" and "set" propose to solve. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
I will definitely be interested in feedback from Zopistas on the effect of PMs on the sort of problems that tags like "local" and "set" propose to solve.
PythonMethods are wonderful! After wasting a week writing a workflow tool in DTML, we junked it, and started from scratch using python base classes and PythonMethods. A week's work on the part of two people was done instead in two days by one person. DTML is good for what it's meant for (generating HTML), but for programming python is the way to go. So I'm no longer troubled by DTML, since I was using it for something it wasn't meant for. OTOH, DTML is a bit too magical for me in some cases. I've had things not work for no good reason, and rewriting them in PythonMethods always seems to solve the problem. And why did you do the sequence-key / sequence-item thing using (('key', 'value'), ('key', 'value'))? What's wrong with dictionaries? And it should be sequence_item, please. I could live without DTML quite happily, but it's good to have it cause it discourages you from going down the PHP path of embedded code in HTML. -- Itamar S.T. itamars@ibm.net
On 12/9/99 4:27 PM, Itamar Shtull-Trauring at itamars@ibm.net wrote:
Brian Lloyd wrote:
I will definitely be interested in feedback from Zopistas on the effect of PMs on the sort of problems that tags like "local" and "set" propose to solve.
PythonMethods are wonderful!
We will be committing Evan's latest code (with some modifications) into CVS in the very near future, and then people can start working with it via that if they wish. He's going to continue working with us on it.
After wasting a week writing a workflow tool in DTML, we junked it, and started from scratch using python base classes and PythonMethods. A week's work on the part of two people was done instead in two days by one person. DTML is good for what it's meant for (generating HTML), but for programming python is the way to go. So I'm no longer troubled by DTML, since I was using it for something it wasn't meant for.
This is the difficulty in pushing a tool outside its problem domain.
I could live without DTML quite happily, but it's good to have it cause it discourages you from going down the PHP path of embedded code in HTML.
I think it's important that we iterate the placement of Python Methods v. DTML. They are not exclusive of each other, but rather very complementary. I think this will become more evident in the coming months. -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
participants (3)
-
Brian Lloyd -
Christopher Petrilli -
Itamar Shtull-Trauring