[Zope-PTK] Do we *need* a Portal object?

Phillip J. Eby pje@telecommunity.com
Wed, 10 May 2000 19:39:26 -0500


At 05:22 PM 5/10/00 -0400, Kevin Dangoor wrote:
>
>    How about a "Preferences" Specialist? This would be able to store prefs
>for objects that can live all over the Zope hierarchy. For example, imagine
>a KM|net News where the KMArticles can go anywhere. The prefs for KMArticles
>could tell the article posting method where to drop the article (in the
>Member's folder? in a central location?). Additionally, you could have
>Preferences that specify how a Link is formatted (so that you don't have to
>change a part of the product that can get overwritten on the next update).

There isn't enough commonality in a "preferences" concept to make this work
as a Specialist, IMHO.  Each of the things you describe is pretty doable by
*using* Specialists, but in different ways.  For example, I'm not familiar
with the KMArticles system, but I do know that if you have an Articles
Specialist, that would be an ideal place for that kind of configuration to
go - in the form of your constructor wizard for making that kind of object.
 For Link objects, you would actually need to use the variant of Specialist
that I'm working on for the next ZPatterns.  If you look on the Interfaces
Wiki under "CatalogManager" there are some notes I put there about how to
make objects outside of Racks act like they're in one, sort of.  The new
"DataManager" facility will let you select on a meta-type by meta-type (and
hierarchically stored) basis what objects will be managed by what
DataManagers.  If Links delegated their formatting methods to their
DataManager, then what you describe above would be easy to accomplish.
(Perhaps we should call them ConfigManagers or just Managers?)



>    How about a "Content Review" Specialist? This can provide a flexible way
>to determine how new content is reviewed.

This would make the most sense if ContentReviews were objects unto
themselves, but I can see handling it virtually as well.  (Reviewable
object asks the Review specialist to register it as needing review, etc.)


>    It seems to me like it would be nicer to drop in a set of components
>that provide the features you want than to have to move an entire site
>within a Portal when you want to take advantage of a new widget that is
>designed as PortalContent.

Indeed.  During the early development of the PlugIns pattern for ZPatterns,
Mike P. mentioned that it (the PlugIns system) sounded very useful for what
PTK does.  Ty and I promoted the idea of treating other parts besides
LoginManager as Specialists, but then as now we're not familiar enough with
PTK to know exactly what aspects should be factored thus.  We also
suggest(ed) that a LoginManager be used as a general Member object
specialist, and placing such things as the registration process there.


>    Is there some giant Portal feature that I'm missing that requires things
>to be factored out the way they are?

I'm not aware of anything per se, although it certainly seems to me that
the Portal object itself is useful, at least if you're building a portal.