grok should provide a parents method

[Joachim Scmitz]

for easier navigation grok should provide a parents method on a view.

[Philipp von Weitershausen (philikon)]

Joachim Scmitz wrote:
> for easier navigation grok should provide a parents method on a view.

What should this parents method return?

[Joachim Scmitz (js-aixtraware)]

a reverse list of parent-objects to construct for example a breadcrumb-list.

[Philipp von Weitershausen (philikon)]

Joachim Scmitz wrote:
> a reverse list of parent-objects to construct for example a breadcrumb-
> list.

This can be easily obtained by zope.traversing.api.getParents(obj),
where obj probably is self.context.

I'm generally not opposed to adding convenience methods to grok.View,
but this doesn't seem exactly view-related.

[Jan Wijbrand Kolman (janwijbrand)]

This issue seems to be about missing functionality in Grok that Zope itself actually provides. Can this issue be closed?

[Philipp von Weitershausen (philikon)]

On 5 Nov 2007, at 11:16 , Jan Wijbrand Kolman wrote:
> This issue seems to be about missing functionality in Grok that Zope
> itself actually provides. Can this issue be closed?

Well, we *could* alias grok.getParents(obj) to
zope.traversing.api.getParents(obj)...

[Jan Wijbrand Kolman (janwijbrand)]

Yes we could alias is, but it might be better not to alias all kinds of functionality that Zope itself provides. Although it is hard to drwa the line between "useful to alias" and "not so useful to alias" I think in this case we shouldn't. Before we know it we're aliasing all of z.t.api...

[Martijn Faassen (faassen)]

I think this is an interesting issue - how much convenience functionality do we add to Grok that is already in Zope 3? If not, how do we make sure people can find the functionality in Zope 3 as well?

I think in this particular case we should let it be. It's not too difficult for people to use __parent__ manually to construct chains of parents.