[Zope3-dev] directory hierarchy proposal

[Martijn Faassen]

Gary Poster wrote:
> All in all I like it a lot as a general direction.  Certainly the 
> shorter names will be a blessing, as long as they do not become too 
> obscure.  Here are a few niggles.
> 
> ---
> 
> "Don't shy away from using acronyms in package/module names."
> 
> This makes me nervous.  That seems an invitation to excessive obscurity. 
>  Certainly "zpt" and "dtml" are ok, but what are some unreasonable 
> acronyms according to this naming convention?  I think acronyms such as 
> zpt will arise of their own accord, while I noticed the proposal itself 
> didn't choose "ca" but "component" for ComponentArchitecture...

> -1 on this one, or at least elaborate.

What about 'don't shy away from using well-known acronyms'? I've tried
to follow this.

> I did not like seeing zope/app/services/event.py and so on.  I think an 
> important elaboration of this is that packages that cannot have 
> arbitrary parts added in and removed are ok to compress as the quoted 
> recommendation describes, but that "services", and to a lesser degree 
> "content", should be allowed to have smaller distinct packages for the 
> convenience of being able to drop things in and pull things out.

Like plugins? I'm not sure about how it would work for zope.app.service;
perhaps someone else who knows more about this can answer. As for
zope.app.content I don't think that many 'drop in' pieces can exist,
especially as views are also supposed to be moving away.

> Discussion points:
> 
>   * reading the code, I'm willing to go to one interfaces.py for a 
> given subsystem (i.e. service), but I don't want to go to a service 
> interfaces.py to muck through *all* the service interfaces in there. 
> These are completely different components!

That's a good point. We discussed the ability to create ifoo.py files
for separate interface files for this purpose.

>   * a number of the service packages contain a decent amount of code 
> and/or interfaces, and the majority of them have no "global" counterpart 
> in which to store extra interfaces (as event does).  Being able to group 
> them in a directory is good.

Sure, I don't think this proposal forces you to use a module; just encourages
to stick to modules to try to keep the tree from deepening rapidly.

>   * I feel particularly strongly about this for the two services with 
> which I am most familiar, the object hub and the event service.  I'll 
> elaborate if requested.

Please do; what is the kind of stuff you'd like to be able to drop
in that you can't drop into a module file?

> Can we agree on that distinction, or is there a similar compromise that 
> might work?

> what is zope.app.software?  The replacement for ZopeProducts?  That's 
> fine, but it wasn't crystal clear to me.

No, its intent is to contain stuff that is going to be in the services,
but is software, not the service itself. Things like TTW page templates,
TTW modules, etc.

> ---
> 
> I guess the whole magical zcml ending "." thing that duplicates the last 
> name until it resolves into a class can now go the way of the dinosaur? 
>  I didn't describe that very well: I'm trying to describe 
> "Zope.Events.GlobalEventService." resolving to 
> "Zope.Events.GlobalEventService.GlobalEventService" and so on.  We can 
> get rid of that now?  Or is that still useful somehow?

Not useful anymore; it was battling a symptom and we're trying to 
tackle the root cause now. :)

Regards,

Martijn