let _link() return structured link info [#636]

[from the mailing list, making it a feature request to not forget about it]

i recently run into some problems with the way <module>_link() functions currently work, i.e. returning an array of "link /strings/" ('<a href="bla">blub</a>"). specifically, i had the problem working on

a) a "link admin" (admin.php?mod=system&op=links), which would allow links to be dynamically admin'ed (similar to modules and themes) and grouped (suitable for hierarchical menus) (and would solve the problem of the proliferating link_page() links and the poor workaround of $custom_links in conf.php), and on

b) a theme_invoke()d version of user_block() which would group "create", "view", and other links into drop-down menus to save screen estate.

for both these things, i need the results of <module>_link() not in the form of a "<a href...>...</a>", but as the arguments as which they are passed to l() (text, args, script, ...) to generate these "link strings". because, for

a), i need to construct a table "link_name", "link_url", "link_module", and for

b), i need to construct a form select something like

  <select name="type">
    <option value="blog">text1</option>
    <option value="book">text2</option>
    <option value="image">text2</option>
  </select>

with value and text being parts of <module>_link() results.

with the way things work currently, i call <module>_link() (which calls l(text, args, script, ...)), get an "<a href=...>...</a>", and have to (re)parse this to get back the text, args, script, ... i need. /and had before/. this does not look really cleaver to me (actually, i refuse to do this ;))

the much cleaner approach would be to let <module>_link() functions to return an array of links /arrays/ with the same parameters as l(), e.g.

  $links[] = array("text" => $page->link, "args" => array("id" =>
$page->nid), "script" => "node", ...);
  return $links ? $links : array();

instead of

  $links[] = l($page->link, array("id" => $page->nid), "node", "",
array("title" => $page->title));
  return $links ? $links : array();

and to do the link rendering (l()) in the function that calls <module>_link().

comments?

Comments

Comment #1

ax commented 11 October 2002 at 00:34

[adding Kjartan's reply]

+1. It will make the link system more flexible for themes as well. I don't think we will get any extra overhead, all that is being done is moving the l() call to a later stage.

Have to think about the other scripts that use $theme->link() though. Can they be changed as well without any problems?

Comment #2

(not verified) commented 11 October 2002 at 01:27

+1 from me too. lets keep giving theme designers the data they need to make spectacular user interfaces.

Comment #3

moshe weitzman commented 11 October 2002 at 11:10

ive always een bothered about the usability of the list of links at the top of the admn pages. i'd much prefer them to be in alphabetical order. so my request, along with the proposed work, is the add a param to the links() function called 'sort'. if present, the caller will receive his output sorted alphabetically by output text (i.e. the first param in the l() call). Perhaps this should be made a it more generic, so that the caller could sort upon any of the l() parameters.

after link sorting is in place, please do change admin.php so it uses this feature.

Comment #4

ax commented 11 October 2002 at 16:08

my suggestion for making link lists, both the one users see (generated by links(link_page(), a collection of <module>_link($type = "page") links), and the admin list (a collection of <module>_link($type = "admin") links) (and possibly lists for other link types such as "node" and "menu" ...) more usable is a "link admin" as mentioned in my initial post.

the idea is to admin links dynamically, similar to the way modules and themes are handled already. i imagine a new db table "links" with the fields lid, module, type, text, url, parent, weight, attributes, status (and possibly more). this table can be admin'ed in "site configuration" > "links". it would initially be filled by querying all modules' link functions (with all the link types to be admin'ed dynamically). then, admins can

create new links (module = NULL)
enable / disable links (status)
group links, suitable for (DHTML) hierarchical menus. for instance, one could create a root link "drupal module links" with lid x, and put all "automatic" drupal links below that one (parent = x). or order all page.module links under a level 0 "site pages" link. etc etc
reorder links for each level / link group (weight)
add / edit / delete link texts and attributes (e.g. title)

links would be rendered then by querying this table and rendering it appropriately.

how does this sound?

Comment #5

moshe weitzman commented 11 October 2002 at 17:19

+10 now that you describe it that way.

Comment #6

kika commented 11 October 2002 at 17:47

+100 from me

What about admin links?

Currenty only top-level links in admin are generated by link() hook, others are hard-coded on module_admin() page.

Second- and third-level admin links must take advantage of link() hook as well, but how to preserve sturcture of links?

Example - "internal referrers | external referrers | help" must be automatically grouped under "statistics" link.

See my experimental admin.menu linktype

Comment #7

ax commented 11 October 2002 at 19:13

Title:

let <module>_link() functions return structured link info

» dynamically admin'ing links

i gave this a first try. see screenshots here:

http://axel.kollmorgen.net/images/link_admin.png
http://axel.kollmorgen.net/images/link_links.png

Comment #8

moshe weitzman commented 11 October 2002 at 19:28

looking good. i don't know what the rightmost two columns mean, but i'm sure your help will explain it :)

you might want to assume that new links that are added by admins are owned by the links.module. this parallells how page.module works

also, do check out kika's sandbox. his idea of admin links was pretty interesting, IIRC. Are you just managing navigation links for now?

Comment #9

ax commented 12 October 2002 at 02:19

looking good. i don't know what the rightmost two columns mean, but i'm sure your help will explain it :)

"d" means "default" (you see in the real app when you hover over it), i.e. resetting the values of module links to it's defaults (from <module>_link()). "op" is "operation" and could be "delete" for non-module links (and i don't what else. it's not just "del(ete)" because i used to have an "add" here, which i replaced with the 5 empty "add" lines at the bottom. maybe this could become a checkbox to select links for an operation on multiple links (delete / enable / disable / defaults / up / down / ...) ...)

you might want to assume that new links that are added by admins are owned by the links.module. this parallells how page.module works

not sure about this. why would i make an extra links.module? i think about these links as much similar to themes and modules, which don't have extra modules. ... on the other hand, making this a module would allow for links to be admin'ed / access controlled separately, for importing / exporting links, for ... what else?

also, do check out kika's sandbox. his idea of admin links was pretty interesting, IIRC. Are you just managing navigation links for now?

for now only page links, right. but its the same principle for admin links. gotta check kika's sandbox.

Comment #10

(not verified) commented 15 October 2002 at 09:52

Priority:

Major

» Normal

Looks good to me.

Usability nag: we really must try to make our admin interfaces the same. Look at the block admin page to see how it handles adding new custom blocks and settings. It might not be the right/best way, but it is what is currently in use. Someone who has some usability experience should make a document on how all these things should work and then we just force anything that goes into the Drupal core to follow these requirements.

Comment #11

ax commented 14 December 2003 at 19:02

Title:	dynamically admin'ing links	» let _link() return structured link info
Component:	Other	» base system
Assigned:	Unassigned	» ax

changing title (and issue) back to the original one (see first comment). while "dynamically admin'ing links" is still a feature i'd like to see, this must be rethought with the new menu system.

Comment #12

ax commented 9 January 2004 at 15:14

"dynamically admin'ing links" should be discussed in the A link management module feature request.

Comment #13

ax commented 19 January 2004 at 17:13

beside returning link values unexpanded, module_link() should also key-index the returned link array. this makes it much easier to customize links in themes. the indexes should be [modulename][linkname], eg.

$links["node"][t("read more")] = l(t("read more"), "node/view/$node->nid", array("title" => t("Read the rest of this posting."), "class" => "read-more"));

instead of

$links[] = l(t("read more"), "node/view/$node->nid", array("title" => t("Read the rest of this posting."), "class" => "read-more"));

now if i wanted to change the "read more" behavior/link, i could easily access and change that link. with the current mechanism, i have to search through all link values to find that special one.