[Zope3-Users] Re: zalchemy integration

[Philipp von Weitershausen]

Roger Ineichen wrote:
> We really should use the Boston skin which offers much more
> flexibility for such customized ZMI's because of it's
> viewlet/manager concept and drop the Rotterdam skin.

Yeah, I'm not convinced. At least not by the current Boston skin. I find
its code over-structured (subpackages just for the sake of subpackages,
it seems). Also, it isn't as flexible as one would think it is. It
claims it uses viewlets but it has lots of stuff still hammered into a
huge template. I don't find it that much more flexible than Rotterdam.

For the second edition of my book I have implemented a new skin from
scratch, using a pure viewlet approach. It was surprisingly simple to do
and didn't take a lot of code. The result is very modular. I think a new
ZMI skin for Zope (e.g. Boston) should be more like that. All the bits
and pieces it has could come from individual viewlets. In the end, the
"main" template just decides where the bits and pieces are located.
Custom skins can then simply reuse all the viewlets and just move them
around in the template as they like.

Either way, being skeptical of content providers and viewlets at first,
I now think they're a great tool. And I've seen from practical
experience that they solve lots of skinning problems. I know the Plone
guys are rewriting their portlet machinery currently to take advantage
of content providers. Very nice.

I'm still not a big fan of the provider: expression type in TALES. I
think it's a misuse of TALES expression types. TALES expression types
aren't there to look up things. They are there to express different
kinds of expressions:

  - python: foo.bar
  - path: foo/bar
  - string: foobar

provider: doesn't fit into that category. In fact, I think it's the only
TALES expression that looks up things. Looking up things is the duty of
traversal. I really think we should have a provider namespace adapter:

  context/++provider++foo.Bar

instead of

  provider:foo.Bar

E.g. we we have

  context/++view++foo.html  or  context/@@foo.html

but not

  view:foo.html

Anyways, just a thought.

Philipp