You are here: Home Articles Disclaimer: We do not hate TTW
Navigation
OpenID Log in

 

Disclaimer: We do not hate TTW

by Martin Aspeli last modified Oct 19, 2007 07:57 PM

So please stop hating us

Now that Plone 3 is reaching a wider audience, it's only natural to some we get more feedback - positive and negative. Thankfully, most of it is positive, and it's a release that the whole community is very proud of.

Now, In the past few days, there have been multiple blog posts about how some things that used to be easy to do through-the-web got harder. That's understandable, of course. First of all, anything "new" is an additional overhead, and thus by definition harder. Secondly, we've done quite a lot to the underlying Plone 3 architecture. That has made many things easier, but also some things harder.

However, I'm a bit fed up witih the undertone that this has something to do with the core developers losing touch with (or not caring about) the needs of everyday integrators. An incredible amount of work went into Plone 3 (with five.customerize, plone.app.viewletmanager and plone.theme) to ensure that TTW-customisers and theme authors had a sensible story that didn't involve becoming on par with a core developer. The issue of how something could make life harder for basic integrators/customisers came up in discussions again and again. It was not as if we didn't care.

For the record, some template customisation is now done in the portal_view_customizations tool, because it relates to templates on views and viewlets and portlets which are implemented differently to plain old page templates in skin layers. You can change the header and footer here just as you could in the custom folder before. Using viewlets actually gives us some TTW tools we didn't have before - to easily hide and re-order elements of the UI (just go to http://localhost:8080/myplonesite/@@manage-viewlets to see what I mean). Most of the basic templates, stylesheets and images are still in portal_skins, of course, and work as before.

Why did we do this? Well, some of the old ways of doing things were becoming difficult to manage, impairing our productivity. Some of the things we wanted to do in Plone 3 would have gotten so tangled up in templates and persistent tools and pyscripts in a flat namespace that we probably wouldn't have been able to do it (at least not as well). Views and viewlets and new-style portlets give us the power to make a more robust Plone. For the amount of stuff that went in, Plone 3 has had incredibly few serious bugs post release. That's not accidental.

I'm not saying we're perfect. We got some things wrong, we made some stuff harder. But we certainly didn't do that out of arrogance or ignorance of how most people use Plone, and we tried damned hard not to make things more difficult whenever we could.

So, if you're frustrated, we'd like to hear about your troubles. Post to the mailing lists and tell us what you're struggling with. Maybe there's an easy way that you just haven't found yet, or maybe there's something we need to work on. Chances are we'll try and fix it. If you're lucky, we'll even be able to fix it before the next major release, because some of the pluggability we built into Plone gives us more flexibility to do that kind of thing. For an example of that, you need look no further than plone.browserlayer, which plugs an integrator/third-party product developer gap we hadn't anticipated. Go figure.

Document Actions

our concern

Posted by Anonymous User at Oct 19, 2007 08:29 PM
Hello

As members of the community we're very excited and we totally agree when people say this is the best plone release ever. We also think that having a great book like yours is a very good thing for people that is getting started with Plone development.

On the other hand, we're a little bit concerned because of the increasing amount of knowledge needed to dive into Plone 3 Development. This may sound a little bit off topic, but with previous plone releases, it was fairly easy to develop a skin product following the plone way for a person with css, html and zpt skills. That doesn't seem to be the case of Plone 3 since you have to know many zope3 concepts, like viewlets, to follow Plone 3 good practices.

It seems that the only way to reduce the amount of knowledge required to do a theme in plone3 would be not following the new recommended way and doing things.

Do you think this is part of the transition process or shall the theme developers get used to viewlets and zope3 stuff? :D

Kind Regards
r0ver and emanuel

Commentary is aimed lower in the stack

Posted by Anonymous User at Oct 20, 2007 09:40 AM
There has been an undercurrent in the stack for some time that says "TTW is Invalid", and people should be transitioned to the CA for doing customizations. I guess you're saying here that Plone's official policy is that TTW is valid and will be the right way for casual integrators to engage minor customizations?

In general, I don't think the "hating" is aimed at the Plone team. Instead, the people in the stack seem intent on saying "All changes should be done with component software and shell access to the server with restart privileges". That viewpoint *is* out there and that is the viewpoint which leaves a lot of people abandoned.

--Paul
Plone Book
Professional Plone 4 Development

I am the author of a book called Professional Plone Development. You can read more about it here.

About this site

This Plone site is kindly hosted by: 

Six Feet Up