[Zope-dev] RFC: Site -> Locus

[Roger Ineichen]

Hi Martjin

> Betreff: Re: [Zope-dev] RFC: Site -> Locus
> 
> Hey,
> 
> Roger Ineichen wrote:
> [snip]
> >> What do people think about:
> >>
> >> * the idea of renaming Site to Locus
> > 
> > Oh my god, many -1
> 
> Motivations beyond "oh my god"?

My first motivation was the same as Jens had.
"Lokus" is such a unique word in german that you 
defently think this is a typo if you read "Locus"

But I think right now we have:

- a well known pattern with the ISite

- the concept is not bad or wrong

- the site is not a page (in web terms)

- the site is a kind of root (in web terms)

- the site map is an overview of what a site includes (in web terms)

I can't think there could be a better name for what the
site pattern does right now. There is absolutly no reason
why we should use another name for the same concept we use
the last 5 years.

Probably I missed something in your proposal, but as
far as I can see you don't propose to change something 
in the concept of the site pattern? right?

> One reason Locus might be a bad word is because it's easily 
> confused with "Location", a concept we already have.
> 
> > What I like to see is that we remove the default Folder 
> container and 
> > simplify the hole implementation.
> 
> I'm proposing we separate the folder implementation from the 
> basic site functionality. It will then become easier for 
> people to ignore the folder implementation and not use it, 
> while we retain backwards compatibility for those who do need it.

Probably a good idea

> [snip]
> > I think a dependency cleanup and split the same old bad 
> concept into 
> > different packages is not usefull right now.
> 
> What is the "same old bad concept"? Details?
> 
> > Are you aware of all the overhead we have in zope.site right now?
> 
> Since I actually assembled these things into zope.site, I 
> have some awareness of what is in there.
> 
> Could you actually point to specific points in the zope.site 
> code? It's not a lot of code, after all. I'm proposing we 
> move some of this code into zope.component, and the rest into 
> zope.container (or we could leave it in zope.site for now). 
> Where is the overhead we can safely remove?

The site offers a SiteManagementFolder, SiteManagerContainer
and a LocalSiteManager.

The SiteManagementFolder by default installed as ['default']
is absolutly useless and obsolate since the last refactoring.
It's just a container, earlier it was a kind of namespace.

Also the lookup concept for this default container should
get reviewed. I also think since we do not offer a Zope 3
application server the hole default setup which is not
needed for a working local component registry shuld probably
go to a own package.

I think the hard part of refactoring the ISite and local utility
concept is to moe the right concept how this pakage get used
into diefferent packags and not the components.

My first step whould be to write down the differen usecase
of zope.site, global and local utilities, location, component
and the registry which brings everything together.

Just refactoring zope.site and move the same packages arround 
because of dependencies is in my point of view the wrong
thing. We need to define wich package will offer which parts
of the hole site concept. otherwise it could be useless
if at the end all packages get used together in 99% of all
Zope projects.

What do you like to use independently from each other
which is now assembled as a unit in zope.site?

Regards
Roger Ineichen

> Regards,
> 
> Martijn
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  ** (Related lists -  
> http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
>