[Zope3-dev] Re: Zope 3 Newsletter: Issue 10

[Paul Winkler]

On Wed, Sep 10, 2003 at 10:30:43AM +0100, seb bacon wrote:
> Perhaps a better question is, how can we make it easy to refactor?

I think I said much the same thing a few dozen posts back :-)

For consideration, here are two suggestions based on things that
have bitten me when refactoring in zope 2.

* It should be very difficult to abuse templating languages
for purely logic purposes. I.e. please kill <dtml-return>.

* Namespaces, bindings, and idioms should be as consistent 
as possible. NEVER add a convenience in one place without
considering its impact on refactorability. If you want the feature,
consider yourself morally obligated to implement it everywhere that
it might be useful :-)

Expansion of the second point:
There are a lot of places you can write bits of python for zope 2:
<dtml-var "foo()">,  TALES expressions, Script (Python), External Methods,
not to mention Products.
Each one *requires* you to write things that cannot be cut/pasted
into the others. Each of these little differences alone is no big deal,
but together they conspire to make refactoring really annoying.
In order to refactor in zope 2, you have to keep a lot in mind.
Some examples off the top of my head; this is not an exhaustive list:

 refactoring from TALES expressions to Script (python) is not too bad:

   here     -> context
   request  -> context.REQUEST or container.REQUEST (does it matter?)
   template -> maybe context, maybe script, depending on what you expect.
               This last one is inevitable ... fine.

 refactoring from a Script (python) to External Method, maybe to get
 access to restricted modules or whatever:

   context         -> self (which is a bit magical in External Methods)
   container       -> self.aq_parent, maybe. But does that give me the
                      container of the External Method instance, or the
		      container of the calling context? I don't 
		      know offhand.
   script          -> No equivalent concept. (don't think i've ever used
                      "script", though.)
   context.REQUEST -> REQUEST must be explicitly passed, which means
                      all callers must be changed too! Ugh.
   print           -> must be replaced with something that builds a string


 refactoring from DTML to anything else:

   sucks!
    

> Actually, I Shane's comments about persistent modules seem right on target:
> 
> > we should provide a simple UI for site developers to write persistent 
> > modules.  Then we should provide an easy way to call persistent
> > modules from templates; the new prefix stuff should be pretty
> > effective for that.
> 
> Wouldn't this provide the best of both worlds?

I always assumed that was going to be a feature... but i haven't
paid very close attention to persistent modules and their intended
useage. How were they originally meant to be used?

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's THE STUPENDOUS BULLET!
(random hero from isometric.spaceninja.com)