Philipp von Weitershausen wrote:
Florian Lindner wrote:
>> Of course, I've a already defined a addform, but this is only for the
ZMI:
<addform
label="Add CSEvent"
name="AddCSEvent.html"
schema="..interfaces.IEvent"
content_factory="..event.Event"
permission="zope.ManageContent"
/>
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>
</span>
</li>
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/webaccountant.ventures.interfaces/IVentureSet"
tal:repeat="item context/values"
tal:condition="python: IVentureSet.providedBy(item)">
<a tal:attributes="href string:${item/@@absolute_url}"
tal:content="python: item.name"></a>
</li>
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.
-Jeff
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
