[Zope3-dev] Package organization quandry

[Shane Hathaway]

Jim Fulton wrote:
> Guido van Rossum wrote:
> 
>>>There's a tradeoff between moving things out of App to encourage
>>>their use outside of the Zope application server and keeping the
>>>dependencies between things outside of App to a minimum.
>>
>>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.

Here's an idea: we could put all the "dead chickens" in a single 
package, called Zope.App.Altar^H^H^H^H^HCommon.  It would consist of 
short scripts that connect multiple libraries together.  We could say 
that the scripts must be quite short (2 or 3 lines) because the scripts 
are meant to be copied and pasted if anyone wants to use the same 
functionality outside Zope.App.

Shane