[Framework-Team] PLIP #126 ready for review

Tue Jan 27 21:46:48 UTC 2009

On 27 jan 2009, at 21:07, David Glick wrote:

>
> On Jan 27, 2009, at 11:19 AM, Danny Bloemendaal wrote:
>
>> notes and observations
>> ----------------------
>> I reviewed this plip from a UI perspective of course. So I started
>> by creating a folder as
>> admin with a Link in there. Published both items. In another browser
>> I visited as an anonymous
>> user and opened the folder. Both the navtree and the link redirected
>> me to the target url.
>> As admin I also visited the folder and the navtree links me to the
>> Link object while the folder listing
>> redirects me to the target url.
>> I checked what the default setting is for this redirecting and
>> "Redirect immediately to link target"
>> was not checked. Then how is it possible that it does redirect for
>> anonymous and for admin in the folder
>> listing? In my opinion, if you offer this option then it should not
>> redirect when unchecked.
>> Checking the option doesn't seem to change anything for anonymous
>> and logged-in users without edit permissions.
>> It keeps redirecting. The only change I notice when checking this
>> option is the portal-like info message in the landing page
>> for the Link object. So it looks as if this feature is not working
>> at all or I am missing the entire point
>> (which is also bad because I'm doing what I actually do best: being
>> a dumb user)
>
> This behavior is due to the decision that I made and noted in the PLIP
> readme:
>
>  * I experimented with, but ultimately deferred removing the
> conditional code in many
>    listing views that handles Links as a special case in order to
> link to the target URL.
>    This becomes unnecessary if redirect_links is true, because you
> can go to the Link like
>    any other content type and its default view will take care of
> redirecting to the target.
>    However, setting redirect_links to True seemed like too big of a
> behavior change for the
>    3.x series, so I have instead added a draft PLIP suggesting this
> change for 4.x:
>    http://dev.plone.org/plone/ticket/8867
>
> So, as the PLIP is currently implemented, the "Redirect immediately to
> link target" setting does not affect the behavior when Links appear in
> navigation.  Danny, you're right that this is confusing and it's bad
> that the control panel setting doesn't seem to have an effect.

Well, it was all about expectation (and probably not having read the  
readme correctly although having read the plip twice and I didn't see  
that it was just for redirecting when you access the url directly and  
not through the various navigation tools.

>  The
> desired behavior we'd like to have is that links redirect, or don't
> redirect, based on the setting in the control panel, regardless of how
> someone accessed the link.

Indeed. You need to make the behaviour predictable for the editors/ 
administrators.

> The tricky question is what to do with existing sites that are
> expecting certain behavior in the 3.x series.

That behaviour was 'broken' to begin with. But ok...

>  If we make everything
> be controlled by the "Redirect immediately to link target" setting,
> then we cannot set it to True without changing the behavior when links
> are accessed via a direct URL.  But we cannot set it to False without
> changing the behavior when links appear in navigation.  However, at
> the moment it seems to me that the former would have been a better
> option, since Links are more often accessed via navigation than via a
> direct URL.  So I probably made a bad decision when implementing this
> PLIP.

I'd say that when the switch is off, it behaves as <3.3. So,  
redirect=off, no redirect occures at all.
When redirect=on everything redirects: direct urls, navigation  
elements, lists etc. At least that makes it predictable.

>
>
> At this point I would like to change the PLIP implementation to:
> 1. re-add the changes I made to listings so that Links aren't handled
> specially, and the redirect behavior is handled by the link view
> rather than by the navigation generating logic

This makes it way much easier to customize the entire Link behaviour.

>
> 2. change the default value of the "Redirect immediately to link
> target" setting to True, so that the behavior as viewed by the end
> user of clicking on a link in navigation remains the same
> 3. add documentation of how to restore the existing pre-3.3 behavior
> (links in navigation redirect, but Links when accessed via a direct
> URL do not) by changing the default view for Links back to link_view
> instead of the new link_redirect_view which contains the logic that
> checks the configlet setting.

Sounds ok with me.

>
>
> But I'm not sure whether the PLIP process allows me to make changes at
> this point...

You have my vote.

/me looks at the others

>
>
>> Seeing this and at least thinking about the intentions I begin to
>> wonder why this isn't implemented as the comments option. There you
>> have a site setting for the type if you want to allow commenting or
>> not. If allowed you can still overrule this for each instance (you
>> can either user the site's default or control locally).
>
> I didn't do it this way because it seemed like more overhead than it
> was worth to have this setting for each content type and for each
> instance.  The use case of needing to have some links redirect and
> some not seemed advanced enough that requiring some simple
> customizations of the view to make it happen didn't seem like a big
> problem.  Anyway, this seems like the sort of question that should
> have been raised when the PLIP concept was approved;

You are right. That question just popped into my mind ;-)

> it's not really a
> problem with the implementation of the proposed change per se.
>
>> I also am not in favor of the Info message. I'd leave it out. If the
>> site admin or the site designer decided to do automatic linking,
>> then you don't need to show this decision in every view page. I'd
>> put in the edit form instead where it belongs. It's a setting after
>> all.
>
> The info message is intended to prevent confusion when someone has the
> "Redirect immediately to link target" setting on, but the view doesn't
> actually redirect because they have permission to edit the link.
>

Ok, agreed. But then I'd probably expect that the message tells me  
that this is due to the control panel setting. In this particular  
situation the normal behaviour is indeed that nobody sees the Link's  
view page except for the editor. But I agree with Andy that the use of  
a portal message styling is not appropriate. I think I would use a  
dimmed/discreet comment below or near the comment like

Note: you see this page because you can edit this link. Others will be  
redirected to the target link because of the setting blabla.

Something like that. I know it comes down to the proper wording here.  
Brief and informative. Perhaps with link to the setting itself if the  
user has permission to change it (but i'm not entirely sure for this  
one).

>
> David Glick
> Web Developer
> ONE/Northwest
>
> New tools and strategies for engaging people in protecting the
> environment
>
> http://www.onenw.org
> davidglick at onenw.org
> work: (206) 286-1235 x32
> mobile: (206) 679-3833
>
> Subscribe to ONEList, our email newsletter!
> Practical advice for effective online engagement
> http://www.onenw.org/full_signup
>
>
>
>