[Product-Developers] Re: Where does it hurt?
veda at onenw.org
Mon May 19 02:54:37 UTC 2008
We're plotting a theming sprint at the conference, and I really would love
to rope some developers in there to work on some of these items David
mentions. I don't want to spend all of our valuable time simply producing
themes; I want to think about what the future will bring for us
I believe we need to uber-simplify how themes are built, and David's ideas
touch on exactly what I'm thinking. I think we still need to allow TTW
modifications, but I still would like to lean more towards filesystem-based
development as the primary path.
I'd also like to look at finding a better way of registering viewlets, or at
the very least improving how @@manage-viewlets works. It's hard, with a
complex theme, to read this view and make sense of it.
Would love to hear more on gloworm, subskins, CSS Manager, and how we could
potentially tie some of these tools together more tightly.
> I think the following efforts would take us 80% of the way in regard
> to staunching some of the pain that new techniques have brought for
> skinners (probably targetting plone 4?):
> - Add browser layer support to z3c.jbot and promote it as the
> recommended way to do filesystem customization of resources registered
> through ZCML (for those not familiar with jbot, this may sound like
> yet another technology, but really it's a simplification. It allows
> customization of things like viewlet and portlet templates just by
> placing a ZPT in the correct filesystem directory, so that it feels
> more like a skin layer.)
> - Devise a UI for through-the-web customization that unifies the skin
> layer (portal_skins) and customerize (portal_view_customizations)
> approaches. (An entry-level skinner should not need to know *how* the
> template they are customizing is registered; just where to find it.)
> Ideally I think this would appear in the Plone control panel as
> opposed to the ZMI, to be more approachable (I'm thinking of
> Wordpress' theme editor.) It's probably also a good idea to provide
> in-context links to customize, (the proverbial Introspector, which I
> think Eric Steele has modeled nicely in his branch of viewletmanager),
> but I think a centralized place to see what customizations are active
> fulfills a separate but important need.
> - Make it easier to export TTW customizations to the filesystem.
View this message in context: http://www.nabble.com/-Product-Developers--Where-does-it-hurt--tp17301616s20094p17310479.html
Sent from the Product Developers mailing list archive at Nabble.com.
More information about the Product-Developers