A lot of the problems in Zope2 and Plone are, IMHO, due to an overconsideration of Average Joes, who at one time were going to build their own applications with ZClasses (since what Average Joe fears above all else are text editors — textareas are A-OK!). It has added many layers of useless complexity. I’m all for enabling Average Joes, but I think that is better accomplished through quality documentation than code contortions that attempt to hide rather than reduce complexity.

That said, what I’ve seen of Grok rocks!

kotisivu…

What would be helpful is if @@manage-viewlets had an [edit] button for each viewlet that took you to a TTP (through-the-plone) page that let you edit a given template instead of needing to hunt around the scary ol’ ZMI for ‘portal_view_customizations’. This would probably be quite easy to do as well. It would also rock if you could move viewlets from one container to another in @@manage-viewlets, although that would be a harder UI to support – although perhaps with some of that fancy new KSS it wouldn’t be too hard to implement.

This only addresses “template-only” customizations though. If you want to create a viewlet backed by a custom Python class you are going to hit that much larger learning curve.

I also like the constructive and well-researched criticism and your goal to simplify. So forgive me the recruitement attempt: please join the grok-dev mailing list if you haven’t already and make sure that when we get to viewlets, we do it right?

What does it mean to do it right? The Grok approach is this: we keep the essential flexibility but don’t let it get in your way, by providing sensible defaults and minimizing repetition.

There is a tension there with explicit configuration and the complexity that results in, but there’s also a lot of synergy. In fact I think Grok is a much better framework thanks to it being based on Zope 3, a framework with a strong attitude towards explicit configuration. When we developed Grok we didn’t need to rebuild Zope 3, we just needed to add automation on top of it. Zope 3′s explicitness pointed out what we could automate and how. Similarly I hope the complexity of configuration of viewlets today can be a great help in identifying what Grok should be doing by default and what flexibility points it should be providing.

The templating system needs to be easy to understand for front-end developers. It’s NOT (only) about whether everything can be customized through the web or not.

Now if all these steps give me a headache already, how am I supposed to explain this to my fellow HTML/designer person, who really wants to use a version control system?

I think that the vague benefit of “can track changes easier” (anyone heard of diff?) is in no relation to the downsides.

I’m seeing UI people that are confused today with how Plone 2.5 is put together, and we’re just adding to the complexity…

Your answer reflect much of a developer attidude and I think you miss the point of the blog: I don’t want technical answers, I want to point out that viewlet system is too complex for non-pro developers and how it could be improved. You understand ZCML and such stuff when you typed your answer out of your head – normal people don’t know these things. And why should they?

- The template has nothing to do with where something is placed

Only in the engineer world which is full of rectangles and 90 degree corners. Look at this layout: http://www.amnesty.ch/en See word Contact. It has a special border. Thus, the template rendering the word has a lot of do where it is placed.

- You can just register a template in your zcml, no need for python files.

Why do I have to do this? Why my templates aren’t picked automatically like in plone_skins?

- The template has nothing to do with where something is placed, just how it looks.

Only in the ideal world. Templates need data. Data comes from viewlet classes. Often you need to transform this data suitable for templates. To change the data, even a tiny bit, you need to subclass/recreate the viewlet class. This is cumbersome.

- Register your viewlet under the original name, just with the new layer.

New layer = WTF says Average Joe.

Register viewlet = WTF says Average Joe.

- And subclassing is way better than the old way where you had to copy the whole python script and template and customize them.

This is true, as I told the post. It makes possible to extend Plone cleanly. But it’s also a cumbersome way to make small changes. Skin/template developers must be aware of a lot of things which they shouldn’t (ZCML, Python, ZCA and so on).