Mailing List Archive: Zope: CMF

[dev] add view traversal

Index | Next | Previous | View Threaded

y.2008 at wcm-solutions

Sep 14, 2008, 3:26 AM

Post #1 of 15 (1012 views)
Permalink

[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[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

jens at dataflake

Sep 14, 2008, 3:50 AM

Post #2 of 15 (960 views)
Permalink

Re: [dev] add view traversal [In reply to]

-----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[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude at gmx

Sep 14, 2008, 4:30 AM

Post #3 of 15 (958 views)
Permalink

Re: [dev] add view traversal [In reply to]

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[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

charlie at begeistert

Sep 14, 2008, 4:38 AM

Post #4 of 15 (962 views)
Permalink

Re: [dev] add view traversal [In reply to]

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[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

charlie at begeistert

Sep 14, 2008, 4:44 AM

Post #5 of 15 (951 views)
Permalink

Re: [dev] add view traversal [In reply to]

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[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude at gmx

Sep 14, 2008, 4:47 AM

Post #6 of 15 (958 views)
Permalink

Re: [dev] add view traversal [In reply to]

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[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude at gmx

Sep 14, 2008, 4:53 AM

Post #7 of 15 (961 views)
Permalink

Re: [dev] add view traversal [In reply to]

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[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

tseaver at palladion

Sep 14, 2008, 5:50 AM

Post #8 of 15 (957 views)
Permalink

Re: [dev] add view traversal [In reply to]

-----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 tseaver[at]palladion.com
Palladion Software "Excellence by Design" http://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[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

rnix at squarewave

Sep 14, 2008, 6:11 AM

Post #9 of 15 (957 views)
Permalink

Re: [dev] add view traversal [In reply to]

Hi,

>
> o +1 on 'container/@@add/typename'
>

this is my suggestion as well

regards, robert

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2008 at wcm-solutions

Sep 15, 2008, 4:00 AM

Post #10 of 15 (931 views)
Permalink

Re: [dev] add view traversal [In reply to]

Hi Martin!

Martin Aspeli wrote:
> 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).

Maybe it's not the best solution, but we *can* implement CMF specific
behavior for portal_type names and fall back to the default behavior for
the rest. Either by overriding Five's ContentAdding view completely or
by traversal hacking.

>>> 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.

You mean for IFolderish?

I had already forgotten all the IAdding issues because I don't use it
anymore. But you are right.

> The add view needs to do some checking that adding is allowed, too; see
> the pasted file above.

It always has to check container constraints. isConstructionAllowed is
redundant if the view is guarded by the same permission as the factory.
But we can't be sure that's the case for a default view, so thanks for
the hint.

> 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.

CMFDefault has the 'News Item' type, I'll make sure things work with spaces.

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2008 at wcm-solutions

Sep 15, 2008, 4:04 AM

Post #11 of 15 (937 views)
Permalink

Re: [dev] add view traversal [In reply to]

Martin Aspeli wrote:
> 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.

Exports to a file system are the problem because the content type gets
lost. But I can't see a need to save add views to a file system, so
regarding add views I agree.

Cheers, Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2008 at wcm-solutions

Sep 15, 2008, 4:05 AM

Post #12 of 15 (933 views)
Permalink

Re: [dev] add view traversal [In reply to]

Charlie Clark wrote:
> Am 14.09.2008 um 12:26 schrieb yuppie:
>> 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?

Could you live with a) as well if we use a different hook than
IPublishTraverse?

Cheers, Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude at gmx

Sep 15, 2008, 6:31 AM

Post #13 of 15 (934 views)
Permalink

Re: [dev] add view traversal [In reply to]

yuppie-4 wrote:
>
> Charlie Clark wrote:
>> Am 14.09.2008 um 12:26 schrieb yuppie:
>>> 2.) Which hook should be used for custom traversal?
>>> ---------------------------------------------------
>>>
>>> a) for URLs like http://www.example.org/guestbook/+Message
>
> Could you live with a) as well if we use a different hook than
> IPublishTraverse?
>

I really think it would be a very big mistake to have a view called + that
was not an IAdding view. Plone, at least, would have to forcibly disable
such a thing, and it'd be very confusing to people who come from Zope 3 and
expect certain semantics from IAdding.

Martin
--
View this message in context: http://www.nabble.com/-dev--add-view-traversal-tp19479053p19493029.html
Sent from the Zope - CMF list2 mailing list archive at Nabble.com.

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

y.2008 at wcm-solutions

Sep 15, 2008, 9:21 AM

Post #14 of 15 (933 views)
Permalink

Re: [dev] add view traversal [In reply to]

Martin Aspeli wrote:
> yuppie-4 wrote:
>> Charlie Clark wrote:
>>> Am 14.09.2008 um 12:26 schrieb yuppie:
>>>> 2.) Which hook should be used for custom traversal?
>>>> ---------------------------------------------------
>>>>
>>>> a) for URLs like http://www.example.org/guestbook/+Message
>> Could you live with a) as well if we use a different hook than
>> IPublishTraverse?
>>
>
> I really think it would be a very big mistake to have a view called + that
> was not an IAdding view. Plone, at least, would have to forcibly disable
> such a thing, and it'd be very confusing to people who come from Zope 3 and
> expect certain semantics from IAdding.

I think it is consensus that we don't want a solution that is based on
IAdding or an other view called '+'.

The example http://www.example.org/guestbook/+Message has nothing to do
with that. It means to reserve names *starting* with '@@+' or '+' for
CMF add view names. Similar to the 'add' prefix convention encouraged by
z3c.form. Right now I prefer this solution, but I have to think a bit
more about the pros and cons.

The other possible solution (and the one with most spontaneous +1 votes)
is a CMF specific add view with the generic name 'add'.

Cheers, Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

optilude at gmx

Sep 15, 2008, 11:08 AM

Post #15 of 15 (941 views)
Permalink

Re: [dev] add view traversal [In reply to]

yuppie-4 wrote:
>
> Martin Aspeli wrote:
>> yuppie-4 wrote:
>>> Charlie Clark wrote:
>>>> Am 14.09.2008 um 12:26 schrieb yuppie:
>>>>> 2.) Which hook should be used for custom traversal?
>>>>> ---------------------------------------------------
>>>>>
>>>>> a) for URLs like http://www.example.org/guestbook/+Message
>>> Could you live with a) as well if we use a different hook than
>>> IPublishTraverse?
>>>
>>
>> I really think it would be a very big mistake to have a view called +
>> that
>> was not an IAdding view. Plone, at least, would have to forcibly disable
>> such a thing, and it'd be very confusing to people who come from Zope 3
>> and
>> expect certain semantics from IAdding.
>
> I think it is consensus that we don't want a solution that is based on
> IAdding or an other view called '+'.
>
> The example http://www.example.org/guestbook/+Message has nothing to do
> with that
>

Ah! Sorry, I saw a / that wasn't there. :)

It means to reserve names *starting* with '@@+' or '+' for
CMF add view names.
</quote.

The problem with this is that you won't use a traverser at all; each add
view has to subclass from something to get the right semantics. That's not
necessarily a problem, of course. For something like Dexterity we'll always
want a traverser because of the special defaults handling. For CMF types you
may not need them. The action in the FTI will decide the URL anyway, so I
think it's easy enough.

> The other possible solution (and the one with most spontaneous +1 votes)
> is a CMF specific add view with the generic name 'add'.
>

That'd be my preference, but I'm not religious about it.

Martin
--
View this message in context: http://www.nabble.com/-dev--add-view-traversal-tp19479053p19498119.html
Sent from the Zope - CMF list2 mailing list archive at Nabble.com.

_______________________________________________
Zope-CMF maillist - Zope-CMF[at]lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com