Service Links 3.x, beyond the 2.x branch

A brief story about the 2.x

Fundamentally, the 2.x born to refresh the project which exists since Drupal 4.6 and from its first version had not many changes in features or number of services.

So after a consultation with the Drupal community about tastes, uses and wishes, Service Links got its path and became a little framework that can load dozen of services and sort them with a graphical interface and plus developers may expand the original equipment just implementing the hook_service_links() (don't need anymore overwrite the original module) which have to return an array of self-descriptive items (readable code) without care anymore about the admin section (declaring this little hook is enough to make them appear on the admin service page).

So, the 2.x was focused on the separation between the list of services and the main module with the minimum effort needed by a third part developer interested to extend the range of services, but also including features that a module like this should have: the ability to use short-url services, configure different icons, sort services on a visual UI, add blocks with indipendent styles appearing on not-node pages too, smoothing and optimizing for a best integration with important external modules.

The model of link considered was the static one, easy to integrate, using a standard XHTML anchor tag without any claim, afterwards when the widget mania exploded among the social networks, Service Links aimed to integrate the Twitter and Facebook widgets improving and modifying the core. However there are other modules which handle widgets older than Service Links, and i can understand how frustrating is, duplicate common features for each one: who want add a new widget creating his custom module, have to instantiate an admin page where configure all the settings needed and one or more hook to create blocks or page alteration, the result? Too much time to correct issues that someone fixed on another module, too much dispersion for one common target.

In this sense, Service Links 2.x give already a good point to start, the only needed things are the list of service settings and some callback module that introduce exotic tags (look at services/widget_services.module), and this part could be improved.

The new challenge

The work made on the 2.x branch is a lot, but honestly, Service Links 2.x is already obsolete compared to the Drupal 7 code.

Drupal 7 is build around the CCK module which is a great solution looking at what a CCK field does:

  • it can be configured for each content type;
  • can be shown or not for each view mode (full view, teaser, rss, search result, ...);
  • has options for each formatter, and external modules can define new formatters for each CCK type;
  • inherit an interface where configure the position among the other fields;
  • can specify different options for different content types;
  • can be used also on profiles.

... all this almost for free.

The third version should be developed around CCK, embrace its philosophy but taking advantage of the previous experience adding features like:

  • an interface that handle different group of links to stick on each CCK field;
  • a different interface could allow to modify the params (text, description, widget settings...) for each service on each group;
  • different formatters like HTML list, simple list, table, or some javascript implementation (which through external settings can build more complex formatting systems);
  • each formatter decide the style allowed: Image, Text, Image + Text, using sprites or not;
  • each Service Links field will have custom settings about short-url use, link opening, node title override, and a custom icon path... .

That should cover all the displaying needs, so it's important to focus on dynamic services instead of enlarge the list of static links (extra services are listed here and the code is generated automatically) improving the javascript side to handle settings for different groups.

Where there is a widget there is Service Links

First of all it's important gather knowledge about all the widgets already codified by external modules. Would be great if the owners of these modules will partecipate to the list of requests, asking for a particular tag or explaining why their widgets couldn't work on Service Links. But is also important discover new widgets not yet included on the long lisf of available modules, to be sure that all the resource needed can be coded like array items, where the level of difficult is too high either a work doesn't worth the efforce, we could always use the callback function.

There are also other widgets that are not strictly tied to the content sharing and could be added into a different module.
I am thinking to widgets like Skype and similar which announce the user's availability on one of those messenger systems. So the widjets user oriented will be another great add with a not big efforce since CCK fields work also on user profile, but need other kinds of data to be displayed!

I think i gave a first look on what i would achieve for the next Service Links branch, maybe i missed something so feel free to add a comment explaining wishes, suggestions and everything except spam, lol.

Comments

Yes, decoupling services descriptions from links visualization is the way to go. I like Service Links idea of concentrating descriptions external sharing services, but the default rendering of the links is not very pretty I have to say.

Thanks for the module BTW.