[Zope-PTK] Portal content wherever you want it

[Steve Alexander]

Chris Withers wrote:
> 
> "Dan L. Pierson" wrote:
> >
> > One example the the current structure that I don't like, is that the
> > basic layout for all types of Portal Content is defined in dtml
> > methods hidden in PTKBase.  It seems to me that this is the sort of
> > things lots of people will want to change, so it needs to be much more
> > visible.
> 
> My sentiments exactly :-)

I've been thinking about this issue.

PortalContent classes typically have two dtml methods: a view method and
an edit method.

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.

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.

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")

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?


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
:-) ]

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.

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

Any comments? 

--
Steve Alexander
Software Engineer
Cat-Box limited