[Zope3-dev] Re: How to add objects?

[Jeff Rush]

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