On Aug 13, 2008, at 2:31 PM, Malthe Borch wrote:
2008/8/13 David Glick <[EMAIL PROTECTED]>:
I'm writing seeking your opinion on some recent work I've done on
making
Collage views easier to customize. Malthe and Paul, you know that
I tried
to do this once earlier, but didn't come up with a workable solution.
Gilles, this may be new to you, but it looks like you've been doing
some
good work on maintaining Collage lately, so I wanted to make sure
you're
part of this conversation.
Yes, we definitely want to keep everybody in the loop; thanks for
this, David.
In the interests of this I'm adding plone-developers to the cc here.
My changes are in the davisagli-layer-overrides branch in svn
(https://svn.plone.org/svn/collective/Collage/branches/davisagli-layer-overrides
).
Basically what I did is make sure that Collage *adds*
ICollageBrowserLayer
to the request, instead of replacing any other marker interfaces.
This
makes it possible to register Collage views on other browser
layers. But
how do we tell which views are meant for Collage then? I added an
ICollageView interface which the custom view classes can
implement. I've
also written the view lookup so as to maintain backwards
compatibility --
e.g. views registered to the ICollageBrowserLayer but not
implementing
ICollageView will still be found.
I think I've written earlier, that we should try and look at what
Plone is contemplating on this matter; I seem to recall that there's a
general notion of an ``ITile`` interface which describes a view or
viewlet that renders a content item in a "tile".
Perhaps it would make sense to register collage tiles like so:
<browser:viewlet
name="default"
for="ATDocument"
template="document_tile.pt"
permission="zope2.View"
manager="ICollage" />
Of course, Collage would be a strange viewlet manager, but the concept
is a bit familiar; we would manually look up these viewlets.
This looks like a fairly decent suggestion. It takes care of the
customization problem, and I like that it re-uses a concept (viewlets)
that is already quite familiar to plone 3 themers.
The downside over my branch is that my branch adds some measure of
customizability without breaking any backwards compatibility. I
should probably have clarified that the goal of my branch was not to
come up with the final, long-term solution for this problem, but to
make it possible for us to use Collage with themed sites for clients
in the short term. (We tend to run ~15 sites per zope instance, so
registering things to a particular layer is essential.)
The only downside is that collage views registered on a layer other
than
ICollageBrowserLayer may be traversed to directly, not just within
the
Collage (because these layers are probably applied globally by
plone.theme
or plone.browserlayer). I don't think this is a huge problem
though as long
as you take care to pick a view name which doesn't conflict with
something
else. Paul, this was an issue for you with my last attempt, but I
think the
backwards compatibility discussed above will allow you to keep
doing what
you're doing.
I think this is problematic. These views should require a special
request, not a browser layer request. Of course, if they're viewlets,
as sketched out above, then this problem goes away entirely.
Thoughts? I'd be happy to merge this to trunk.
I think we should issue Collage 1.2 (I've tried a couple of times, but
was let down by plone.org) and then move to these more drastic changes
(e.g. 2.0).
I think my vote for 1) releasing Collage 1.2 as it stands, and 2)
switching to viewlets on trunk, and pushing out an alpha or beta
release of this fairly quickly.
Separate topic: Are there plans to turn Collage into an egg? This
should be
pretty simple, and I'm willing to take care of it if there are no
objections. I would do it in the Products namespace as seems to be
the
custom, so that it's still possible to release an old-style tarball.
+10.
I'll do this as soon as you tag the 1.2 release.
\malthe
peace,
David Glick
Project Associate
ONE/Northwest
New tools and strategies for engaging people in protecting the
environment
http://www.onenw.org
[EMAIL PROTECTED]
(206) 286-1235 x32
Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
