Been busy but caught up now, thanks for taking this further (and everyone else I will get to the end soon).

In an earlier email I mentioned "tools" for making doing ZCML easier for not technical types e.g. a site administrator that was mainly a content creator (we have a lot of these as clients). the Use case I was thinking of was one of the above people wanted to install a new component to add some functionality to their site. e.g. add a shopping cart/checkout component . I think it would be great if the site administrator could add this component to their site without having to contact a developer. After all the component isn't changing and its a component they just work right. The type of tool I was meaning could be something like a TTW way to do this, or some kind of desktop application. It has some specific use cases like add this component, customise this particular template to be one named XYZ instead of ABC. The site administrator doesn't need to know ZCML to do this but understand the concept. This tool knows how to do all things in ZCML but nothing in python as python is the developers domain. We therefore need to make sure that everything a site admin might want to do is possible in ZCML.

Anyway it might not be a realistic idea but the use case is something that really will happen.

Someone also said:

For example, has anyone had people, who don't know or can't handle
Python AT ALL, hook up page templates?

We have this all the time in the plone sites we are currently doing so I imagine it will continue as we move to zope 3 way of doing things. I guess there are other ways for the designers to change the template that gets used by a particular piece of content (e.g. just change the contents of the template) but in reality they do find going into portal_types and changing the template on an action useful. Am I understanding correctly that the way you do that type of thing in zope 3 is via the ZCML at the moment?


Lennart Regebro wrote:

On 2/19/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
Ah, ok. Well, I'm not 100% sure myself, but I would tend to say we
should define things in Python first and then register it (Jim seems to
think so too).

I agree. I just see naming it as a part of the registration. You can
change the name withouth changing the implementation. Not always, but
most of the time the name of a page is completely independent from
everything else except the menu item definition.

For example, has anyone had people, who don't know or can't handle
Python AT ALL, hook up page templates?

Nope. Although I would definitely like easy overrides. But then again,
I could do that by using the class that already is there and just
override the "something.html" template, I guess.

So, all in all, the boiler-plate isn't useless. It's just declarative,
and I don't think it's overly wordy.

Right. As with much, is a matter of where to draw lines, maybe thats
the right place to draw it

As a sidenote on the MVC discussion:

I have discussed MVC with a friend an how it maps onto Zope3, and I
have looked more closely as MVC lately, and to be honest, I think it's
bunk and can be happily ignored, at least when it comes to normal
HTML/HTTP stuff (maybe, just maybe, it can have applications for Ajax.
Maybe). But if you should map it into Zope3, then I'd say that the
view is the method you call that returns HTML, and the controller is
the "update" method. It's mainly bunk becase you have to call the
controller method for every request to see if anything happened...

And although I think MVC is bunk, I'd like a better way of calling the
"update" method than tal:define="dummy view/update" or making small
python wrapper methods for every template. Any ideas?

Lennart Regebro, Nuxeo
CPS Content Management
Zope3-dev mailing list

Zope3-dev mailing list

Reply via email to