[Grok-dev] Re: issue #226555: viewlet.url() and how to solve it

[Kevin Smith]

Martijn Faassen wrote:
> Hi there,
>
> Jan-Wijbrand Kolman wrote:
>> See https://bugs.launchpad.net/grok/+bug/226555
>
>> The current url() methods on viewlets and viewletmanagers are broken. 
>> They apparently returns incorrect URLs, the code is duplicated all 
>> over the place, and on the trunk these methods have not been updated 
>> according the updates the view.url() got during the Grokkerdam sprint 
>> and there're no tests.
>
> A correct summary of what's wrong. :)
>
>> I assigned myself to the issue and I've been working on a fix for a 
>> bit, but I need your help.
>>
>> Let me try to summarize my thinking:
>>
>> The url() methods for viewletmanagers and viewlets should return 
>> basically *identical* URLs to what the url() method on a regular view 
>> for the same object would return.
>>
>> * Question: is this interpretation of the issue correct?
>
> That is my interpretation. I'd like someone more experienced about 
> viewlets to chip in on this, though.
That would be my interpretation as well. Zope3 viewlets inherit 
BrowserView not BrowserPage, so a zope.viewlet does not have it's own 
url. So any urls referenced should point to the parent view.

Without a view.url method, one has to type...

<a tal:attributes="href python:view.__parent__.__parent__.url(obj): />

With a view.url method....

<a tal:attributes="href python:view.url(obj)" />

Just like we always do in grok. When I started using viewlets alot, I 
found for myself needing access to all the great power tools that are in 
grok.View. AFAIK Darryl Cousin's in his own work, extracted these out 
into a base class for inclusion in his version of viewlets. So one 
possibility is to put all of the power methods in ViewBase (is that 
being used for anything) as a mixin.

Thinking out loud, it may be possible in a viewlet to map the 'view' 
namespace directly to the parent view and then supply a 'viewlet' 
namespace that maps directly to the viewlet.

>
>> * Related question: during the sprint someone expressed the desire 
>> for a way to construct URLs to individual viewlets. How does that 
>> relate to this issue? Or should we ignore this for now?
>
> Ignore this for now; viewlets don't really have URLs (yet) in Grok 
> anyway.
+1, this is muddying up the issue and it is really a separate case. I 
propose implementing a new type of viewlet to signify such extended 
functionality, like ViewletPage or something.

>
>
>> In order to re-implement the url() methods on viewlet(manager), the 
>> viewlet(manager) instance needs a reference to the view it was 
>> adapted to (together with the context object and request). Looking at 
>> the viewlet(manager) interfaces in zope.viewlet and 
>> zope.contentprovider, this relationship is expressed through the 
>> __parent__ attribute on the viewlet(manager).
>>
>> * Question: allthough I see the necessity for calling this attribute 
>> '__parent__', I can imagine having it assigned to an attribute called 
>> 'view' as well would make it slightly more obvious how to use it for 
>> the developer using viewlets. Would that be an idea?
>
> The confusion here is that 'view' in the context of a viewlet template 
> is actually the viewlet. I think...
>
> I'd say go with the __parent__ thing for the time being. I don't know 
> what the Zope 3 story is.
>
> [snip]
>> * Question: is it then actually a good thing that Grok extends the 
>> viewlet (and contentprovider) interfaces? Or in other words, isn't 
>> the bug really that there *is* a url method and should it thus be 
>> removed?
>
> I think it's fine to extend these. viewletmanagers are frequently 
> extended; it's their design. Since we extend views as well (for 
> convenience reasons), I think we should extend viewlets as well, also 
> for convenience. It think it would be good if viewlets acted like 
> views a lot in the API they provide. Makes them easier to explain, and 
> hopefully allows a lot of code sharing.
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>

Kevin Smith