Re: [Zope-CMF] CMFActionIcons vs. new-style actions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 14, 2008, at 06:35 , Wichert Akkerman wrote: Previously Martin Aspeli wrote: Jens Vagelpohl wrote: Question: Wouldn't it make sense to enable the new action icons functionality in the various templates to show icons if an expression for an icon is provided, and completely retire the CMFActionIcons product? +1 - CMFActionIcons is a bit of a nuisance these days. I never understood why you'd need to separate the definition of the action (in the ZMI or GS) from its icon. Easier customization - no need to let people touch the action itself? Just at the high price of maintaining a full separate Zope product. That trade-off seems a bit lame. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjMyPMACgkQRAx5nvEhZLKmwgCfULE4/0dSmqPVdPo0NWRYypB4 Yx8AoJFGKJX7x6yImrRRsnSQFvHHZRMt =GceZ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] add view traversal
Hi! This mail has been lying around for a while because I'm not sure it's the right way to start the discussion. But now I'll give it a try. Maybe the sprinters find some time to discuss this: One result of the Add forms and menus[1] thread was that we'd like to get add views by portal type name. Some custom traversal should look up and return the right view for the specified portal type. I'm currently trying to figure out how to implement that correctly and am struggling with some details: 1.) What should URLs look like? --- Here are same possible URLs for adding a Message to a guest book: http://www.example.org/guestbook/+Message http://www.example.org/guestbook/@@+Message http://www.example.org/guestbook/addMessage.html http://www.example.org/guestbook/+/Message http://www.example.org/guestbook/@@+/Message http://www.example.org/guestbook/+/addMessage.html http://www.example.org/guestbook/+cmf/Message http://www.example.org/guestbook/@@+cmf/Message http://www.example.org/guestbook/+cmf/addMessage.html http://www.example.org/guestbook/add/Message http://www.example.org/guestbook/@@add/Message http://www.example.org/guestbook/add/addMessage.html 2.) Which hook should be used for custom traversal? --- a) for URLs like http://www.example.org/guestbook/+Message In this case we use a special prefix '+' followed by the portal type name. CMF containers don't implement IPublishTraverse, so we can register an IPublishTraverse adapter. If we don't find an add view, we can fall back to DefaultPublishTraverse behavior. Unfortunately the IPublishTraverse hook only works with one adapter. If other packages like plone.app.imaging[2] try to use the same hook, we get a problem. b) for URLs like http://www.example.org/guestbook/+/Message The '+' view already implements IPublishTraverse, so we can't change traversal using an adapter. The only solution I can see is to replace the '+' view by a customized version. c) for URLs like http://www.example.org/guestbook/add/Message If we use our own adding view, we can implement IPublishTraverse inside the view or as adapter. 3.) For which context should we register the add views? --- The add views will depend on special portal type handling done by the traverser. So we register the add views for traverser? Or should all views have a default portal type that is used if we access add views directly? In that case we would register the add view for the container. plone.dexterity[3] uses an @@add-dexterity-content traverser, but I don't think product names like dexterity or cmf should be visible in URLs. Those are implementation details that should be transparent for users. Any feedback is welcome. Cheers, Yuppie [1] http://mail.zope.org/pipermail/zope-cmf/2008-July/027500.html [2] http://dev.plone.org/plone/browser/plone.app.imaging/trunk/plone/app/imaging/traverse.py [3] http://dev.plone.org/plone/browser/plone.dexterity/trunk/plone/dexterity/browser/add.py ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] add view traversal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 14, 2008, at 12:26 , yuppie wrote: This mail has been lying around for a while because I'm not sure it's the right way to start the discussion. But now I'll give it a try. Maybe the sprinters find some time to discuss this: We're down to 2 at this point and I need to take off very soon, so here's a very quick assessment from Tres and me: b) for URLs like http://www.example.org/guestbook/+/Message The '+' view already implements IPublishTraverse, so we can't change traversal using an adapter. The only solution I can see is to replace the '+' view by a customized version. This looks like a good solution. I believe Zope 3 uses the same or a similar style. 3.) For which context should we register the add views? --- The add views will depend on special portal type handling done by the traverser. So we register the add views for traverser? Or should all views have a default portal type that is used if we access add views directly? In that case we would register the add view for the container. I'm not sure, hoping for comments from others. plone.dexterity[3] uses an @@add-dexterity-content traverser, but I don't think product names like dexterity or cmf should be visible in URLs. Those are implementation details that should be transparent for users. I agree. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjM7HQACgkQRAx5nvEhZLKPOACgpWQjPFL9o0Fng8WtLMSPRfSZ 3ZEAoJoWo0XGe00MXNwI2+aLmsYRxm6L =Scef -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] add view traversal
Jens Vagelpohl wrote: b) for URLs like http://www.example.org/guestbook/+/Message The '+' view already implements IPublishTraverse, so we can't change traversal using an adapter. The only solution I can see is to replace the '+' view by a customized version. This looks like a good solution. I believe Zope 3 uses the same or a similar style. I don't think we can do this. The + view implements IAdding which has special semantics. Existing types are likely to rely on + being an IAdding view. Zope 3 does use IAdding for zope.app.form/zope.formlib based add views; With z3c.form, IAdding support is optional, but the preference is to just use views like @@add-foo.html (note: I hate the .html convention; it is superfluous and looks weird, IMHO). I think it's better to use a different name. For plone.dexterity, I've done this: http://dev.plone.org/plone/browser/plone.dexterity/trunk/plone/dexterity/browser/add.py The add view traverser is called @@add-dexterity-content. It's deliberately framework-specific since I want particular semantics (a default add view based on FTI information only if no type-specific add view is registered). That's all fine, though, since we look up the exact URL for add view in an action anyway. We don't need a one-size-fits all traverser (which the + view had to be). I'm monkey patching the TypesTool to backport the changes Yuppie already made to CMF trunk to support folder/add actions. For CMF, how about a simple @@add or maybe @@add-content? 3.) For which context should we register the add views? --- The add views will depend on special portal type handling done by the traverser. So we register the add views for traverser? No. That's how IAdding works, and it's basically what we're trying to avoid. If the context of the view is the IAdding view, then self.context is not a content item, which makes for all kinds of self.context.context type lookups, messes with vocabulary factories, makes security tricky in some cases, and generally is confusing. (If you *do* want this, then we should just use CMFAdding form Products.Five, by the way). The add view should be registered for IContainerish, unless it's a type addable only in one particular type of container. The add view needs to do some checking that adding is allowed, too; see the pasted file above. Or should all views have a default portal type that is used if we access add views directly? In that case we would register the add view for the container. I think if you access @@add directly, you get an error. I can't see there being a use case for a default type. plone.dexterity[3] uses an @@add-dexterity-content traverser, but I don't think product names like dexterity or cmf should be visible in URLs. Those are implementation details that should be transparent for users. I agree. I agree with that sentiment, but it doesn't really matter, I don't think. Users never type add view URLs anyway, do they - they come from actions :) My preference is actually @@add. However, that's very generic. Like I said, Dexterity needs its own version to have its own semantics, which means it needs its own name. I didn't want to do an @@add override or anything like that, since not all content is going to be Dexterity-managed. So, in summary: +1 for http://site.com/folder/@@add/PortalType -1 for anything with .html ...and + is probably not going to work. One last thing to note: You need to put the portal type in the URL, but portal types can have spaces and the like in the name. That's probably not a problem, but there may be a case for some kind of normalisation. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMFActionIcons vs. new-style actions
Wichert Akkerman wrote: Easier customization - no need to let people touch the action itself? You can change a property of an action easily enough with GS or in the ZMI. So, a separate registry is more isolated, but it's also harder to guess which portal_actionicons thing you need to add/modify to modify a particular action. Looking in two places doesn't necessarily make it easier. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] add view traversal
Am 14.09.2008 um 12:26 schrieb yuppie: This mail has been lying around for a while because I'm not sure it's the right way to start the discussion. But now I'll give it a try. Maybe the sprinters find some time to discuss this: I had to leave yesterday evening... it would have been great if we'd have been able to arrange a CMF sprint in advance even if meant just discussing these kind of things. One result of the Add forms and menus[1] thread was that we'd like to get add views by portal type name. Some custom traversal should look up and return the right view for the specified portal type. I'm currently trying to figure out how to implement that correctly and am struggling with some details: 1.) What should URLs look like? --- Here are same possible URLs for adding a Message to a guest book: http://www.example.org/guestbook/+Message http://www.example.org/guestbook/@@+Message http://www.example.org/guestbook/addMessage.html http://www.example.org/guestbook/+/Message http://www.example.org/guestbook/@@+/Message http://www.example.org/guestbook/+/addMessage.html http://www.example.org/guestbook/+cmf/Message http://www.example.org/guestbook/@@+cmf/Message http://www.example.org/guestbook/+cmf/addMessage.html http://www.example.org/guestbook/add/Message http://www.example.org/guestbook/@@add/Message http://www.example.org/guestbook/add/addMessage.html 2.) Which hook should be used for custom traversal? --- a) for URLs like http://www.example.org/guestbook/+Message In this case we use a special prefix '+' followed by the portal type name. CMF containers don't implement IPublishTraverse, so we can register an IPublishTraverse adapter. If we don't find an add view, we can fall back to DefaultPublishTraverse behavior. Unfortunately the IPublishTraverse hook only works with one adapter. If other packages like plone.app.imaging[2] try to use the same hook, we get a problem. b) for URLs like http://www.example.org/guestbook/+/Message The '+' view already implements IPublishTraverse, so we can't change traversal using an adapter. The only solution I can see is to replace the '+' view by a customized version. c) for URLs like http://www.example.org/guestbook/add/Message If we use our own adding view, we can implement IPublishTraverse inside the view or as adapter. I could live with either b) or c). I guess we need to weigh up the desirability of being as close to Zope 3 style without unwanted side effects. c) would to be the cleanest implementation. Would it be possible to implement b) as a sort of alias for this if desired? 3.) For which context should we register the add views? --- The add views will depend on special portal type handling done by the traverser. So we register the add views for traverser? Or should all views have a default portal type that is used if we access add views directly? In that case we would register the add view for the container. I guess the circle we're trying to square here would be what's the best way to be able to add objects to a particular container. Our particular experience has been to rely on the need to register views for a particular container object but, of course, you still need type information. As the type information (allowed content types for a container object) is always required it probably makes sense to use this rather than an implicit allowability through a registered view. I think this means +1 for registering for the traverser. plone.dexterity[3] uses an @@add-dexterity-content traverser, but I don't think product names like dexterity or cmf should be visible in URLs. Those are implementation details that should be transparent for users. Absolutely. We've found the add forms to be extremely useful but the dependence on knowing the name of the view is a pain even if you can enforce a naming convention. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Formlib based view of folder contents
Am 13.09.2008 um 16:49 schrieb yuppie: I never used it. But one major function of CMFDefault is to showcase CMF features. And I'm not aware of any other code that demonstrates how to use filtering. Good point. If so is it okay to drop the use of the cookie and either use hidden variables as the sorting options do already or possibly dump this information in the session? One of the problems with the current implementation is that the cookie is hard-coded to live until 2020 and will persist from one folder to the next but it's debatable whether the filters you want for one folder you would want for another but not the sort options. Our preference would be to put the filter information in hidden variables. I don't think CMFDefault should rely on sessions. Using hidden variables sounds fine to me. This was our consensus yesterday. I hope it's possible to unpick the folder_filter_form.pt Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] add view traversal
Am 14.09.2008 um 13:30 schrieb Martin Aspeli: Zope 3 does use IAdding for zope.app.form/zope.formlib based add views; With z3c.form, IAdding support is optional, but the preference is to just use views like @@add-foo.html (note: I hate the .html convention; it is superfluous and looks weird, IMHO). I used to think this but then I thought about the possibility of any non-Zope upstream handling such as caching which might be very grateful for this kind of convention. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] add view traversal
Charlie Clark wrote: Am 14.09.2008 um 13:30 schrieb Martin Aspeli: Zope 3 does use IAdding for zope.app.form/zope.formlib based add views; With z3c.form, IAdding support is optional, but the preference is to just use views like @@add-foo.html (note: I hate the .html convention; it is superfluous and looks weird, IMHO). I used to think this but then I thought about the possibility of any non-Zope upstream handling such as caching which might be very grateful for this kind of convention. We don't have .html extensions on content items or views in Plone, and setting up Caching has never been a problem. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] add view traversal
Charlie Clark wrote: b) for URLs like http://www.example.org/guestbook/+/Message The '+' view already implements IPublishTraverse, so we can't change traversal using an adapter. The only solution I can see is to replace the '+' view by a customized version. c) for URLs like http://www.example.org/guestbook/add/Message If we use our own adding view, we can implement IPublishTraverse inside the view or as adapter. I could live with either b) or c). I guess we need to weigh up the desirability of being as close to Zope 3 style without unwanted side effects. c) would to be the cleanest implementation. Would it be possible to implement b) as a sort of alias for this if desired? As I outlined in the other response: - Using '+' is not being close to Zope 3. In Five, we already have an IAdding view called +, which is close to Zope 3, but which has different semantics. It'd a great mistake, I think, to make something that *looked* like IAdding and wasn't. It'd also conflict with Plone, which *does* use IAdding in some cases, and I suspect other CMF users too. I guess the circle we're trying to square here would be what's the best way to be able to add objects to a particular container. Our particular experience has been to rely on the need to register views for a particular container object but, of course, you still need type information. As the type information (allowed content types for a container object) is always required it probably makes sense to use this rather than an implicit allowability through a registered view. I think this means +1 for registering for the traverser. Again at the risk of repeating myself, I don't think this really works. It's important that the context of the view is the container object and not another view (the traverser). Otherwise, we should go back to IAdding and use what's in Five already :) Absolutely. We've found the add forms to be extremely useful but the dependence on knowing the name of the view is a pain even if you can enforce a naming convention. That's a bit like any view, though, surely? :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] add view traversal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi! This mail has been lying around for a while because I'm not sure it's the right way to start the discussion. But now I'll give it a try. Maybe the sprinters find some time to discuss this: One result of the Add forms and menus[1] thread was that we'd like to get add views by portal type name. Some custom traversal should look up and return the right view for the specified portal type. I'm currently trying to figure out how to implement that correctly and am struggling with some details: 1.) What should URLs look like? --- Here are same possible URLs for adding a Message to a guest book: http://www.example.org/guestbook/+Message http://www.example.org/guestbook/@@+Message http://www.example.org/guestbook/addMessage.html http://www.example.org/guestbook/+/Message http://www.example.org/guestbook/@@+/Message http://www.example.org/guestbook/+/addMessage.html http://www.example.org/guestbook/+cmf/Message http://www.example.org/guestbook/@@+cmf/Message http://www.example.org/guestbook/+cmf/addMessage.html http://www.example.org/guestbook/add/Message http://www.example.org/guestbook/@@add/Message http://www.example.org/guestbook/add/addMessage.html 2.) Which hook should be used for custom traversal? --- a) for URLs like http://www.example.org/guestbook/+Message In this case we use a special prefix '+' followed by the portal type name. CMF containers don't implement IPublishTraverse, so we can register an IPublishTraverse adapter. If we don't find an add view, we can fall back to DefaultPublishTraverse behavior. Unfortunately the IPublishTraverse hook only works with one adapter. If other packages like plone.app.imaging[2] try to use the same hook, we get a problem. b) for URLs like http://www.example.org/guestbook/+/Message The '+' view already implements IPublishTraverse, so we can't change traversal using an adapter. The only solution I can see is to replace the '+' view by a customized version. c) for URLs like http://www.example.org/guestbook/add/Message If we use our own adding view, we can implement IPublishTraverse inside the view or as adapter. 3.) For which context should we register the add views? --- The add views will depend on special portal type handling done by the traverser. So we register the add views for traverser? Or should all views have a default portal type that is used if we access add views directly? In that case we would register the add view for the container. plone.dexterity[3] uses an @@add-dexterity-content traverser, but I don't think product names like dexterity or cmf should be visible in URLs. Those are implementation details that should be transparent for users. Any feedback is welcome. Here's my take: o -1 to using IAdding at all. If we use a URL like /container/+/typename, then the traverser could just use the next name after '+' to look up the adding view directly and return it. o +0 on 'container/+/typename'. o +1 on 'container/@@add/typename' o -1 on 'container/add/typname', or any URL token could conflict with real object IDs. o -0 on the '.html' suffic. o +0 on 'container/+typename': I don't think this will clash with anything in Z3: we just have to supply a traverser which does what I outlined above for 'container/+/typename'. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIzQiQ+gerLs4ltQ4RAo4WAKCcVH2ceg4yvs8FmAwWbCsrhBHTmwCgi7eO fGNT58nb9hZNn4RPJjiEPMQ= =rZJY -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] add view traversal
Hi, o +1 on 'container/@@add/typename' this is my suggestion as well regards, robert ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
