Personal tools
You are here: Home Products Plone Roadmap #126: Link type improvements
Document Actions

#126: Link type improvements

Contents
  1. Motivation
  2. Assumptions
  3. Proposal
  4. Progress log
by Alexander Limi last modified August 22, 2006 - 06:29
Links should be capable of doing automatic redirection and to serve as favorites - we don't need two separate types for this!
Proposed by
Alexander Limi
Proposal type
Architecture
State
being-discussed

Motivation

Currently, the Plone standard "link" content type is dumb as rocks. Favorites is another content type that is unnecessary with if we expand the coverage of a link a little bit.

Assumptions

  • Opening a link in a new window should only be applied when used as Favorite, so that it affects your own habits - I believe that it is fundamentally evil to put this in the hands of the individual user for normal links.
  • For the intranet use case it makes sense, though - so it should respect a site-wide setting to open all links in new windows (or tabs in more sane browsers). This requires a configuration toggle in the external link markup script (the code was there earlier, I believe it was deactivated).
  • There should be a separate proposal to clean up the Favorites mess, this proposal is mainly about the Link type. If we don't replace favorites with this type, the rest of the PLIP is still a valid PLIP.

Proposal

The link type should be extended with the following abilities:

  • Automatic redirection - when you can edit the object, it doesn't do this, though - like with File/Link objects in the current listings, it goes/acts directly on the object if you don't have the permissions to edit it, and goes to the view page if you have editing permissions
    • This should work in the navtree too
  • Ability to open link in new window (see Assumptions)

Two things that we should consider:

  • Use links as favorites - we don't need two types for this!
  • Have a checkbox that says "index linked page" that uses wget/lynx to get a copy of the page you link to and indexes the words it contains in the local Link object. This way, if you search for something that is contained in a page that is linked to, you will get search result hits.

Progress log

Half of this is already in Plone 2.5 (link objects act as redirection in content listings + navtree), and if possible I'd like to see this be a "sleeper PLIP" for 3.0. If the rest isn't done, no big deal, it doesn't go into 3.0 - but if somebody has a day or so to fix this before the betas, I'd hate to see it be excluded just because there isn't a bundle as such. :)

What about when a site has both public & intranet functions?

Posted by Jon Stahl at April 7, 2006 - 04:25
Alexander-

While I agree that forcing new windows is *mostly* evil, most of the time, and that it might be less evil in an intranet situation, a lot of smaller sites will have both public & private/intranet spaces on the same server. So, I'm not sure as site-wide setting is the best way to go.

I think that maybe, just maybe, there should be per-object control over whether a link opens in a new window.

Maybe some strong words of warning against new window links in the UI?

/me ducks ;-)

Symlinking within a site?

Posted by Jon Stahl at April 7, 2006 - 04:29
One common request I get from our site admins is "how can I put a link in the navigation that points to another place on our site?"

I think I've seen this referred to as "symlinking."

It would be really nice if the Link type could also support this. It would make it easier to build very flexible navigation schemes.

Linking to an internal object by browsing

Posted by Sleepy Jackson at June 20, 2006 - 03:19

I have just this second had a user describe their frustration at having to type in a full URL to create a link to a document somewhere else in the system. For this reason I can see it would be really useful for the link type to have a facility - much like the internal link feature in Kupu - that enables users to browse to the object they wish to link to.

I'm also suprised that in Plone (2.5) you can create an external link with an address which omits the http:// prefix without receiving a warning message, only to find after the link is created it doesn't work.

Because the link type was originally for external links

Posted by Alexander Limi at June 20, 2006 - 04:24
That's what this PLIP is about; making the link type better. :)

because the link type was originally for external links

Posted by Sleepy Jackson at June 20, 2006 - 04:37

I have outlined clearly two limitations of the current link type that as a user I would hope will be addressed by this Improvement. If that's not in the spirit of making the link type better then please enlighten me.

I think Alex actually agrees with you. ;-)

Posted by Jon Stahl at January 4, 2007 - 03:54
He's just explaining the backstory to *why* Plone behaves in this (now obviously suboptimal) way. Your suggestion is most definitely in keeping with the spirit of this PLIP.

In fact, I think it's a great suggestion -- I ran into this frustration with a client just today.

My only question is about the feasibility of having two widgets (string field for external URLs + reference browser for internal links) that both feed a single field. There's probably some clever way around this though.

For any issues with the web site functionality, please file a ticket.

Please consult the policy on plone.org content if you want your content published on this site.

Servers and hosting by