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. 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.
The tricky question is what to do with existing sites that are
expecting certain behavior in the 3.x series. 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.
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
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.
But I'm not sure whether the PLIP process allows me to make changes at
this point...
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; 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.
David Glick
Web Developer
ONE/Northwest
New tools and strategies for engaging people in protecting the
environment
http://www.onenw.org
davidgl...@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
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
