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@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 ) > _______________________________________________ Zope-Dev maillist - Zope-Dev@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 )
