Philipp von Weitershausen wrote:
Florian Lindner wrote:

 >> Of course, I've a already defined a addform, but this is only for the

        label="Add CSEvent"

In Zope 2, "only for the ZMI" would be correct. In Zope 3, the line between the ZMI and a custom user interface has been blurred. Stuff that you define for the ZMI can largely be reused in a custom user interface. I other words, the ZMI in Zope 3 is just *one* user interface. Take it, customize it, and voila, you have your own user interface.

Coming from Zope 2 myself, where you always had to create parallel add/edit presentation forms if you wanted your objects to be both ZMI and non-ZMI manipulatable, I see his confusion. I'm wrestling with it now and still see gaps, perhaps to my newbie understanding of Zope 3.

I'm wondering if, in the Zope 3 world, it's going to become common to expose the ZMI, in a tightly-controlled, re-skinned way, to the non-technical end-user. Something we could never do in Zope 2.

My questions are:

a) How to I configure such a add form?

You already did so (the above addform directive). Your assumption that this only works in the "ZMI" is incorrect. It works in any user interface (=skin) that you create and that is based on the 'default' layer.

c) If the form needs a supporting view class, how do the class has to look like?

Most of the time you don't need a class that supports the view unless you want to do some very customized stuff.

I was hoping that but I'm not finding this to be true. It seems I need a view in common cases.

[1] If I want to redirect the user to an "operation completed" page, I must define a view with a nextURL() method. However if I want to reuse that same page for ZMI add operations, I must duplicate it so that it goes to @@contents.html and leave out my view. It seems I want a default nextURL() that just uses HTTP_REFERER, so that after an add/edit, you are returned to where you started, ZMI or not ZMI (although the original HTTP_REFERER would have to be passed thru a sequence of pages related to the view).

Perhaps I could do this with layers/skins, but it doesn't seem to be the case that ZMI and non-ZMI seamlessly use different skins in which I could factor such things.

So my solution is, for each object, to define a newblah.html and an addblah.html, where the former is used for non-ZMI and the latter is placed on the ZMI add-menu bar. And the only difference in those .html definitions is one has a class= view defined and the other doesn't. Seems kludgey.

[2] The other use-case that requires views is any filtering at all. Under Zope 2 it was common here to off-the-cuff (TTW) drop the following into the index_html of a folder to display a list of items of specific metatypes:

  <li tal:repeat="item container/objectValues">
    <span tal:condition="python:item.meta_type == 'Folder'">
      <a tal:attributes="href string:${item/getId}"
         tal:content="item/title_or_id"> Item Title or Id </a>

I saw the argument posted elsewhere that TAL should not be used for filtering, and I agree TAL has been abused for complex logic over the years. But requiring a view class just to perform something like "item.meta_type == 'Folder'" (eg. (IFolder.providedBy(item)) seems a bit burdensome.

I've tried doing something like the following but after several hours for something so simple its not working:

<li tal:define="IVentureSet modules/"
      tal:repeat="item context/values"
      tal:condition="python: IVentureSet.providedBy(item)">
        <a tal:attributes="href string:${item/@@absolute_url}"

So a view class it is.

But the main thing for me is object addition, in a flexible manner and discovering the new philosphy of ZMI versus non-ZMI.


Zope3-dev mailing list

Reply via email to