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

Martin Aspeli optilude at gmx.net
Mon May 19 20:09:10 UTC 2008


Hi Michael,

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)

Yes.

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

Yes.

> 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.)

Yes.  I certainly prefer this myself, since I find it invaluable to have 
a natural place to put "view logic". You don't *have* to use views for 
AT content type views, but IMHO this is best.

> 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... :-(

I don't quite see why this is so confusing. First of all, you are free 
to organise your code however makes most sense to you. I prefer and 
promote separating content types, themes and overall customisation/site 
policies into separate packages. Not everyone does that, of course.

If you're building a look-and-feel for your site, I'd use a theme 
product. If you're performing customisations or changing settings that 
are not theme specific, then do them in a customisation policy product. 
If you are building content types, put them in a separate product and 
try to ensure they work reasonably without depending too much on your theme.

Of course, if that doesn't make any sense (i.e. you have no need for 
re-use without your specific theme) then make different choices.

>> 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.

I think that's why my book is trying to do. That's my contribution, at 
least.

>>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.

:-)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book





More information about the Product-Developers mailing list