[Zope3-dev] Package organization quandry

[Guido van Rossum]

> > One possible strategy is to avoid hard-coded dependencies and instead
> > pass the necessary objects or classes in at construction time.  I
> > think TAL already uses this approach: there's a default execution
> > engine that's pretty simple and uses nothing except core Python; to
> > get the ZPT engine you instantiate and pass it explicitly.  Maybe this
> > idea can be extended?
> 
> This apporach doesn't work that well if there are a lot of clients of
> the constructor. For example, users of PageTemplateFiles should be able
> to:
> 
>    index = PageTemplateFile('index.zpt')
> 
> If people effectively always have to:
> 
>    index = PageTemplateFile('index.zpt', engine=ZopeEngine)
> 
> Then I think the extra argument is just a dead chicken 
> (meaningless sacrifice;).  I'd as soon provide a constructor that
> automated this. I could put this constructor in a separate package
> in App. This is basically the option I'm considering.

Yes, you can do app-specific customization in your own app, so you
don't have to use the standard constructor.

> The specialization involves more than just engine selection though.
> For example, I have a class that specialized page templates to be
> view methods, requiring changes in a number of methods and adding a 
> __get__.

Can that be a Zope-specific subclass?

I guess the point is that you have to separate out the parts that are
app-specific (such __get__) and the parts that can be shared.  Then
the latter can be distributed and used separately.

--Guido van Rossum (home page: http://www.python.org/~guido/)