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
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
