Portlet settings from a GS profile?

Martin Aspeli optilude at gmx.net
Tue Oct 2 15:19:46 UTC 2007

Raphael Ritz wrote:
> Obviously, this is going to be somewhat involved but
> we better come up with a solution to (at least parts of)
> GS support for portlet configuration rather soon or we
> are making a fool of ourselves.

Well... if you have any time to put into this, that'd be great. I can
happily provide support in understanding the portlets infrastructure and
there's already a GS handler for portlets.xml that we can extend, but I'm
famously short of time these days.

> So in general there is the assignment as handled by the portlet
> manager(s) as well as the configuration of the individual portlets.

Right. Basically, the "assignment" is a persistent object of a particular
type. The type is specified by an interface, which specifies a number of

> Lets compare this to the way the more complex CMF tools like the
> types tool or the workflow tool are handled. There you have a
> configuration of the tool itself (types.xml, workflows.xml) as well
> as folders (types, workflows) which hold the configuration of the
> individual objects managed by the tool (the FTIs or the individual
> workflows respectively). Now whether you introduce a folder hierarchy
> or not is not the point (GS can do either way; for the parsers and
> renderes of the bibliography tool in CMFBib I've chosen to use
> just one file) but the situation here is at least similar in as
> much as we have (configuration) managing objects (the portlet managers)
> as well as configurable objects (the portlets).
> Providing an xml representation for those settings and having handlers
> dealing with that shouldn't be too hard (BTW: is there any build-in
> support for zope 3 schemata in GS like there is for the classical
> Zope 2 object and property manager functionality? that could make
> life *much* easier).

I'm not sure, but schemata are pretty easy to introspect, so I don't think
it'd be hard to write something generic or specific for this.

> Except for one thing (as Martin points out correctly):
> location-dependent assignments (and I think Martin is also right
> in pointing out that GS doesn't provide support for this when it
> comes to plain Zope properties on portal content objects either
> - I simply don't know at the moment).

To many of the portlet functions, the fact that it's a location-specific
portlet is neither here nor there. They work on a portlet manager name
(plone.leftcolumn), a category (e.g. group portlets), and a key (e.g.
Administrators) and then have a list of assignments under that key. For
contextual portlets, the "key" is the /-separated path. So we could use that
in the GS syntax.

> This is a tricky issue as this mixes site configuration and content
> (structure) which we are generally trying to keep as separate as
> possible. It reminds me in some way of the problem that Archetypes
> - or more generally the content handlers - has/have when it comes
> to supporting references between content objects on import/export.
> Maybe there are some lessons to be learned (or code to be "stolen"?)
> from XMLForrest or gsxml???

Perhaps - and you're right. User, group and content type portlets are more
configuration-like in that they're "global" to the portal. Contextual
portlets are more content-like in that they are "local" (and stored in
annotations on content objects rather than site-local utilities).

I could imagine a syntax like:

  <property name="review_state" type="lines">
  <property name="limit" type="integer">5</property>

Here, I've deliverately re-used the property syntax from e.g. the
propertiestool.xml config, although the implementation would be different.
Upon reading one of these, we'd need to (losely):

 - get the portlet manager name, category and key and use a method in
plone.portlets.utils which is able to load the assignment mapping (the
ordered container of assignments) from that info.

 - use the portlet name to look up the IPortletType

 - use the portlet type to look up the addview (maybe via traversal, or by
instantiating the object directly)

 - pick out properties and build a data dict

 - use the addview (in a slightly hacky way, since we'd have to fake a
request ... ) to create an object

Basically, this would re-use the create() method from the addviews that know
how to turn a dict of values (normally coming from form input) into an
object of the appropriate type and call "add" on their context (which is
normally the + view, but we could have a different context here if need be)
in order to save the object in the appropriate place.

For export, we'd iterate over all portlet managers, categories and keys and
output a structure like the above, inspecting the schemata to pull out data
and saving as properties. That may not be 100% perfect (you're not guranteed
that all properties are defined as zope.schema properties) but it should
work for all current types. We'd use an adapter to perform the property
extraction, thus allowing other implementations if necessary.

The problem also is whether we traverse the whole site looking for local
portlets, or only export assignments at the portal root.

There's one more thing we'd need to export: the portlet assignment blockings
which you can do on a folder-by-folder basis. These are stored in
annotations and are pretty simple properties (a tri-state
block/unblock/inherit for each of the portlet categories). Again, there's a
traverse-the-whole-site dillema here, though.

View this message in context: http://www.nabble.com/Portlet-settings-from-a-GS-profile--tf4547266s20094.html#a13000900
Sent from the Product Developers mailing list archive at Nabble.com.

More information about the Product-Developers mailing list