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

Dylan Jay gmane at dylanjay.com
Mon May 19 12:35:44 UTC 2008


Michael Hierweck wrote:
> 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.

And whats more, if it gets used in the core or popular plugin products 
then inevitably we have to understand how it works to customise it. 
Browser resources are in the core and are used. So not using them 
ourselves doesn't reduce the learning curve at all :(






More information about the Product-Developers mailing list