The description of this module looks great, nice step up from the weburl.module included with CCK. Thanks for contributing.

I was just wondering if you are aware of the API and infrastructure provided by the LInks Package (http://drupal.org/node/24719)? Did you (or would you) consider having this link field (at least optionally) use that API?

I would love to be able to use the Links Package to manage all of my Links, but one of the missing pieces is a CCK link field. I would be more than happy to help out in whatever way I can with such a feature.

Related issues filed here:
http://drupal.org/node/55208
http://drupal.org/node/55210

Comments

quicksketch’s picture

quicksketch
he/him
commented

Looks like you've been pitching pretty hard to get this integrated somewhere :-). I haven't looked at the links api at all and consequently not very familiar with it, but I am definately interested in the possibilities it presents. I don't really like the idea of having a big "if links.module" functionality inside a single module. It sounds like something that should have its own CCK field (ie a Link Field with Tracking), since the changes necessary might be too large to implement with a simple CCK widget. I'll look into the possibilities. Please post any suggestions or comments on an architecture for this.

RayZ’s picture

RayZ commented

You mean begging? ;-) Yeah, I'm trying to find a sort of "best practices" way of handling all my links and the infrastructure provided by the Links package looked like the way to go. I like the centralized link management with elimination of duplicates, potential for automated checking of broken links, optional link tracking, etc. The big missing piece for me was a corresponding CCK field, and I haven't been able to scrap together the time to learn everything I need to implement it myself ... hence the begging and trying to point everyone who might have a similar itch in that direction :-)

Anyway, you are probably right that it makes sense to implement it as a separate field type, since the storage for it would be different. Whether or not it is a separate module I suppose is primarily a matter of packaging preference. The date.module for example implements two types of date fields with a single module.

In terms of design, I think just having the field store a link id (lid) in the corresponding column of the {node_content_whatever} table should be fine. In order to have the Links API save the link with a unique entry for each field in the {links_node} table, it may be necessary to save it with a field-name specific value for the 'module'. Or maybe a patch is needed to add another column. I posted a few related thoughts in http://drupal.org/node/55208.

quicksketch’s picture

quicksketch
he/him
commented

Sorry I haven't forgotten you. I haven't had time to investigate the links package yet, but this task is still on the docket.

quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Closed (won't fix)

Well after an in-depth analysis of the links package it just doesn't look like this is the place for adding integration. I'd like to keep this module as streamlined as possible, no nasty hacks or conditionals. I believe that if integration is going to come from anywhere, the links.module folks are going to need to rework things a bit fit in with the CCK revolution. So I'm afraid the answer must be no. :(

RayZ’s picture

RayZ commented

Thanks, quicksketch, for taking the time to look into this. Do you have any specific suggestions for changes needed in the Links package to make it "fit in with the CCK revolution"? Were there specific limitations to the API, missing pieces, etc?