[Zope-dev] Re: Subpath traversal interface (was RE: ANN: Pyth on Methods 0.1.7 up and over to DC) and over to DC)

[Michel Pelletier]

> -----Original Message-----
> From: Evan Simpson [mailto:evan@4-am.com]
> Sent: Monday, December 20, 1999 7:34 PM
> To: Michel Pelletier
> Cc: 'Phillip J. Eby'; zope-dev@zope.org
> Subject: Re: [Zope-dev] Re: Subpath traversal interface (was RE: ANN:
> Python Methods 0.1.7 up and over to DC) and over to DC)
> 
> 
> Michel Pelletier wrote:
> 
> > I, personally, prefer the folderish approach.  If a site root is a
> > definitive folder, then 'portal' like methods can be placed in it,
> 
> I'm not sure I understand what 'portal' methods are.  Are we 
> talking about
> methods which, for example, should only be used in a 
> SiteObject, and not in
> an ordinary folder?  Or are they something else?

I guess they're shaping up to be top level methods of a portal object.
What methods get to be 'portal methods' is still not a concrete concept.
 

> That's pretty nifty.  I believe we want that, what we need 
> to figure out
> > is the best way to do manipulations like that.  You're using a Rule
> > object now, probably makes sense at the application level 
> to not change
> > that and have identical Rule objects in interface, but 
> investigate how
> > it's to be done.  If there is a discrete folder object like 
> we have now,
> > is the before hook needed at Rule time?
> 
> Well, yes, unless you add Rule-aware machinery to the 
> standard Folder class
> (or ObjectManager?).  I'd hate to have to replace a Folder with a
> RuleFolder (or whatever) just because I wanted a Rule in it.  
> Note that
> there isn't technically such a thing as a Rule object (in the 
> sense of a
> distinct class).  Any DTML Method or Document, External 
> Method, or Python
> Method can be a Rule.  Also, a Rule can manipulate the 
> traversal path more
> simply than a __bobo_traverse__ could, since it only concerns 
> itself with
> Ids, not actual objects.

I think what we are going to end up doing is releasing a small, general
purpose object to do the virtualhosting.  It will be a mixin class that
hooks __b_t__ and absolute_url().

As a 'Product' we will be developing a simple object based on Folder and
this new class, SiteObject.  Further, the SiteObject class will be used
for our 'PortalObjects'.

So, you can use the stock object which is simple, folderish; or you can
use the portal object which will be more complex, or you can roll your
own by inheriting SiteObject and whatever, ZClass or Python, etc.

Now the path manipulation thing sounds like it should be some seperate
genetic material that is subclassable and realizable by a simple 'Rule'
object.  I think that this object's elaboration, while related to the
genetic material that forms virtualhosting, should be developed without
mixing them together too much.  Sorta the same thing we did with Virtual
hosting, we folded your functionality into the core; it might be useful
to fold path manipulation logic into the core and realize it the same
way, subclassable, simple object (not, I would imagine, unlike your Rule
object) a snip of genetic material that can be mixed in at any time.

I suspect I'm beginning to see your side of the argument, A 'Rule' mixin
would conflict with the SiteObject mixin if they both wanted to hook
__b_t__, so your __before__ hook was a way to chain calls like this?

-Michel