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