[Product-Developers] Re: Where does it hurt?

Michael Hierweck team at edv-serviceteam.net
Mon May 19 08:05:14 UTC 2008

Hi Wichert,

Wichert Akkerman wrote:
> Right now we have one solution: skin layers. Until the new stuff is used
> that is what people should be using. Consistent, flexible, and well
> documented. 

Skin layers are those "traditional" things in the subdirecotries of the
skins directory, configured by skins.xml. (Zope 2)

DIY makes use of browser resources configured by zcml and GS using
resource registries.

Also (Browser)Views for AT based content make use of classes and page
templates stored in the browser package, even portal type icons, too.
(At least that's what Martin suggests in his book what is "the"
introduction for new developers/customizers at this time.)

I would call DIY and the related Chapters from "Professional Plone
Development" the "main" resources on this topic. Now I'm confused.

I'm even more confused: Martin tells us to use a policy and and theme
package. On the other hand BrowserViews for portal types are defined in
the browser package the content type belongs to. But BrowserViews are
related to skinning in some ways, as a special skin/theme might require
a modified BrowserView. Maybe this could be done using override.zcml,
but... :-(

> Do not be distracted by all the shiny new stuff - most of it is not
> quite ready for real widespread usage for various reasons. Some of us
> are adventerous and will use it anyway and run into problems, hopefully
> fixing them along the way. For normal Plone developers my advise is to
> just stick with that works well.

That's a big point concerning documentation: I have to clearly point
out, what newbie/average developers should use in productive
environments and what is only nice, experimental stuff to play around
with for study or recreation.

>From this point of view it dangerous for website developers to subscribe
to the core development mailinglist. On the other hand I think I need
watch those discussions since it's the best place get informed about
planning/roadmap and future development. And of course highly
experimental stuff will be discussed there.


More information about the Product-Developers mailing list