CCK/Views integration

Views support was contributed by someone else for the Drupal 5 version, and remains in the production distribution (if I recall correctly...I don't remember having removed it). For the Drupal 6 port, I decided the changes in Views itself were sufficiently large that it would be easier to re-implement from scratch.

As of now, the D6 development snapshot of Links has a pre-release version of Views support. What's there is pretty solid (though you are not hearing me say "production ready"!), but I still need to add more tables and relationships. What I'm saying is that the journey from today's D6 dev snapshot to the production release of Views support for Links in D6 is likely to be a superset of what's there today, rather than significantly changing what I've done so far.

I will not be back-porting the D6 Views support to D5. What's there in D5 already will stay there, but the D6 Views implementation for Links is a clean break. Not that there is anything wrong with the D5 Views support -- I appreciate the contrib very much, and it works well. But the Views API itself changed enough that I felt a recoding was easier than a forward port. :-)

CCK is still a work in flux, particularly since the Drupal core team has put CCK-like field support into core for Drupal 7. I am very much looking ahead to D7 and trying to design the D6 implementation so that forward compatibility and migration will be easier.

Your question about converting Link to Links to CCK is a good one. I can answer it conceptually, but I need you to clarify *which* Link field you mean in the question. There is the existing links_weblink field for the primary link, there are the links_related link fields, and there are other modules such as Link (q.v.) which implement a URL-type field but don't use the Links API from my package. And there is the URL field type in existing CCK. And these are just the ones of which I'm aware. :-)

Here are my current migration plans -- but note that these are *not* cast in stone:

* I will definitely, absolutely be adding support for a Drupal 7 links field type that presents a D7 fields-in-core interface at the top of the stack, but uses Links API for physical storage and centralized link management at the bottom of the stack. My goal is to have this functionality available on Day One of D7's production release, but remember I'm a volunteer and can't absolutely promise any specific delivery date.

* I am very much wanting to create a D6 CCK integration that works like the upcoming D7 implementation. If I do so, I will absolutely provide a way to migrate from this to the Drupal 7 fields-in-core implementation.

* I would like to provide a way to *optionally* migrate the existing CCK URL field to my new D7 Links API fields-in-core implementation. However, this will be an *optional* migration because not everyone who used CCK (under D6) or uses FIC (under D7) will want to use my Links API modules. I'm not arrogant enough to think I've got the right answer for everyone. :-)

* The links_weblink module was *always* intended as an interim solution until Drupal had FIC. Quite honestly, I anticipated long ago that eventually CCK or something like it would end up in core. So *probably* links_weblink will go away in D7. But if it does, I am absolutely committed to providing a smooth migration path to FIC and a "weblink" node type.

* The case for maintaining links_related as standalone, or migrating it to FIC, is not so clear-cut, in my opinion. Whereas links_weblink creates a special-purpose node type, links_related does not, but rather modifies the behavior of arbitrary nodes of any type. I am still thinking about this, but it is possible links_related will be maintained through D7 and then migrated into FIC for D8. Or I may migrate the field-management part of links_related to FIC in D7 but maintain it through D8 and beyond as a module which provides the separate links display (tab and block). But that overlaps some of Views. Again, this is a complex question and the answer isn't clear at this time.

Regardless any of the above, I absolutely commit that any of the Links modules that I retire because of new Drupal core functionality will provide an automated (possibly automatic, possibly optional, but definitely scripted) migration path to whatever core functionality replaces the applicable Links package module. This is not just a commitment to the Open Source ethos, but also enlightened self interest. I "eat my own dog food" with the Links Package by using it extensively on my own production sites. One of my sites has over 12,000 links in the Links package's tables. I *have* to be able to migrate those.

This "eat own dog food" situation also will guide architectural planning for Links. I of course want to migrate to Drupal core any functionality that is redundant. But like most Open Source volunteers, I originally created the Links Package to "scratch my own itch." That is still the case, and I won't migrate to core if that migration means giving up the functionality that is unique to the Links Package modules.

I hope this helps clarify where things are. Please feel free to post here with further questions, comments, and suggestions.

Kind regards,

Scott

Scott- thanks so much for the great work on this module. I am also looking forward to Views support and grabbed links_views.inc from the dev snapshot to try it out and see if there is anything I can do to help, but wasn't able to get anything to show up in views- does that file need to be included from somewhere else to work?

Thanks again,
Christopher

Same question here.

thanks.

Subscribing.

subscribing

Any updates on this?

Subscribing