[Zope-PTK] Portal content wherever you want it

[Kevin Dangoor]

----- Original Message -----
From: "Steve Alexander" <steve@cat-box.net>
To: "Chris Withers" <chrisw@nipltd.com>
Cc: <zope-ptk@zope.org>
Sent: Sunday, May 21, 2000 9:47 AM
Subject: Re: [Zope-PTK] Portal content wherever you want it


> For example, PTKBase/NewsItem.py has the methods
> PTKBase/dtml/newsEdit.dtml and PTKBase/dtml/newsView.dtml. The icons are
> also hard-coded into PTKBase.
>
> This scheme is wrong on three counts:
>
> 1: The four or five sample PortalContent types are part of PTKBase. You
> can't easily stop a Portal from offering Members the chance to create
> those types of content.

Yep.

> 2: The standard presentation and editing views of these PortalContent
> types cannot be customised from the Zope management interface, because
> they are defined in .dtml files, and added as attributes of
> PortalContent-derived instances. For example, NewsItem.py, line 35:
>
>   editForm=HTMLFile('dtml/newsEdit',globals())
>
> While we should be able to override this standard presentation by
> subclassing NewsItem, this is not good for clarity, flexibility or
> maintainability.

Yep. I've seen a couple common ways to get around this... instantiate a DTML
Method somewhere in the ZODB so that the Zope user can modify the appearance
(and provide a way to revert to the default). Or, provide hooks allowing
people to create a DTML Method (or whatnot) that will override the given
method. These are both easy to do and much nicer than subclassing NewsItem.

> 3: There is also messiness when you write your own PortalContent-derived
> classes, and want to use a particular icon. Here's a line from my own
> PTK extension product's __init__.py:
>
> from Products.PTKBase.register import registerPortalContent
> registerPortalContent(Accommodation,
>                       constructors=(addAccommodation,),
>                       action='Wizards/Accommodation',
>                       icon="../ZwopitPTK/accommodation.gif")

I wasn't aware of that one. Bleah.

> 3: Even if this presentation could be customised, we're left with one
> standard view and edit method for each class of portal. What if you want
> two DemoPortals instances on the same Zope server, each with its own
> style of NewsItem presentation?

Yep.

> My suggestion for a solution:
>
> The DTML methods for viewing and editing a PortalContent-derived
> instance, and the custom icon to use, should be acquired from its
> Portal.
>
> [Scary bit where I go out on a limb, and pretend I understand ZPatterns
> :-) ]

[Even scarier: I'm pretending to understand Python-based Products,
ZPatterns, *and* the PTK :) ]

> However, rather than tie these things to a Portal, we could use a
> Specialist that knows about presentation of PortalContent to look up the
> appropriate DTML methods and icons from a Rack, based on the name of the
> PortalContent class.

I would do this a little differently.

We make a Portal Specialist that will provide all sorts of nice Portal-y
features. It will accept PortalContent as plug-ins (much the same way that
LoginManager accepts UserSources as plug-ins). So, you just plug in any
types of Portal content you want to be available in that Portal. Within each
of these plug-ins, you'll be able to define the display methods for that
type of content. I'm not sure about the icons, because there might be some
other hooks for that. We can probably assume that that will be changeable as
well.

I believe ZPatterns 0.4.0 will allow RackMountables to show up anywhere you
want them, and will refer back to their DataManager for various things,
including Indexing. Based on Phillip's message from this morning, that means
you can put the PortalContent anywhere in your ZODB, and it will follow the
review policies that you have set up. These would be pluggable.

> We could probably take the same approach with Wizards, if this works out
> with presentation; although Wizards are nicely decoupled from
> PortalContent classes already.

Each Wizard could be tied to its PortalContent plug-in and be customizable
in the same way that the standard view/edit methods would be.

Since I started the thread as being keen on not having the Portal living in
its own little subset of the Zope world, I think having a Specialist
providing Portal features is a good thing. This prevents things like
SiteAccess-like features from creeping in to the PortalObject (which appears
to have happened).

Kevin