[Framework-Team] New PLIP

Sidnei da Silva sidnei at enfoldsystems.com
Thu Oct 13 19:44:03 UTC 2005


Sorry, maybe I wasn't clear enough on the PLIP, or maybe you didn't
understand the intent there. I will try to reply to your comments here.

On Thu, Oct 13, 2005 at 02:23:49PM -0500, whit wrote:
| this is a thorny one, since I think 99% of what needs to happen needs to 
| happen outside of plone.   But, it is the fundamental architectural 
| piece needed for groupware(and along with versioning, one of the two 
| last big things missing in plone).  So many hacks and products have been 
| spawned to handle this(Teamspaces, InnerPlone, SubPlone, GroupSpaces, 
| the Enfold staging suite, the BRC zpatterns/PloneFolder hack, etc etc).

You are talking about 'subsite functionality' here. The PLIP doesn't
deal with subsite implementation, instead it proposes ways to fix
Plone so that each subsite implementation outside Plone doesn't have
to override methods in Plone to make navigation cope with subsite
functionality.

The only goal of the proposal is to deal with navigation and catalog
search in the context of subsites, period. No implementation of
subsite in Plone itself.

| I think we should get this wheel right for the last time in this half 
| decade. Two points for discussion, consideration(sidnei, with your 
| permission, I will repost to plone-devel)
| 
| 1. Jim is the first to point out that the implementation of sites in z3 
| could be simpler.  Since this will eventually become not only the focus 
| for subsite, but for all non-global behavior, we might be feeling alot 
| more pain if we rush our personal
| subsite suite onto the current site implementation. 
| 
| I think it is worth investing time on this to make it as simple, clear 
| and solid as possible.
| 
| 2.  Everything that has to do with catalog, request, portal_url or 
| anything else not exclusively plone needs to go into CMF or zope.  I 
| would argue things like the nav tree and breadcrumbs fall in this 
| category too.  I would argue any feature that shows up in more than 2 
| CMF derivatives ought to be at least considered for CMFDefault.
|
| Componentizing is the best way to push down and to componentizing tools, 
| we need to change getToolByName at the CMF level so we can start 
| deprecating the portal root as a tool dumping ground.   To sanely 
| migrate to local utilities from tools, #1 has to be working sanely.

+1 for that. It doesn't mean we can't prototype in plone first though.

| Rather than introducing a subsite concept, it would make more sense to 
| decompose the site concept into something more malleable, decoupling the 
| CMFSite or PloneSite type from the siteish behavior.   The essence of 
| this is the local configuration of utilities and adapters and the 
| ability to delegate up the chain.

Again, and to make it clear for others, the proposal doesn't introduce
a subsite implementation. Rather, it deals with view-space and UI and
it's interactions with hipotetical third-party subsite implementations.

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com



More information about the Framework-Team mailing list