Add support for regular vocabularies

I'm not going to commit anything like this until core taxonomy gets refactored

Understood. Is there a relevant patch in the queue?

Here for the record, and potentially for future reference or reworking, is a completed patch.

Changes since the last iteration:

1. Includes javascript for regular taxonomies.
2. Fixed errors in previous patch that broke free tagging.

I've also included support for tagging on node teasers. This required some reworking of the data model, which was previously limited to a single node's data. Is this of interest? If so, I could factor it out into a separate patch.

Some issues with the patch:

1. Reliance on hook_footer() to output JS settings. This assumes the hook is called after content is generated but before JS is generated, which is true for PHPTemplate themes but potentially not for regular PHP themes.

2. Need an image, add.png, equivalent to the existing delete.png.

3. The Javascript implementation could use some further design work. I've implemented it as two rows of tags, the ones available and the ones already applied. Available tags are labeled 'add to tagname', while already applied ones are labelled 'remove from tagname', where tag name is the term name.

4. In the Javascript, I'm explicitly passing around references in some places, e.g., nid and elt in

var addHandler = function (nid, elt)

Likely the code could be improved to avoid needing this explicit passing.

Because I need this functionality for a current project, I'll probably implement this as a separate module that extends community_tags if feasible.

Old version had a debugging line left in.

I've rewritten the patch as a new module, community_tagsrv, Community Tags Regular Vocabularies, and committed to Drupal CVS, http://cvs.drupal.org/viewcvs/drupal/contributions/modules/community_tag.... I'm hoping this can be merged back in with Community Tags and have written it to avoid any conflicts and facilitate merging in.

I'm considering whether I should release community_tagsrv as a module, with a note saying it's intended to be merged into Community Tags when possible. Any red flags or concerns or reasons not to?

Attached is an updated patch with some small bug fixes from the previous patch.

Thanks for taking the time to look at this more.

At the moment, there isn't enough functional code re-use (e.g. in the JS) to justify this patch IMO.

Agreed particularly for the JS that the code reuse could be improved. I could have a go at writing a single set of methods that could process both regular and freetagging vocabularies. This would probably mean moving to a model where data are stored client side in a form that meets both needs, i.e., has both the tid and the term name. Of course, for freetagging vocabularies this requires server interaction when adding tags.

I'm also worried about the UI concerns, because the module uses the word "tags" everywhere, yet some things apply to terms too (e.g. "edit own tags" permission).

Agreed that this is a challenge. Another case is "'You have already tagged this post. Your tags: ". Possible approaches would be (a) move to more generic wording that applies to all, like "categorize content" instead of "tag content"; (b) have parallel wordings for each, (c) leave it as it is, assuming that in this particular case both types of categorizing can be called "tagging".

I can't think of anything for (a) that isn't awkward. A full (b) approach would mean e.g. introducing superfluous permissions. So I'm not sure what's best. I guess my inclination is (c).

I also don't see why you added a static cache mechanism for the drupal_add_js().

It's the recursive merging that's the issue. Initially, when I had the function called once for each node on the page, I ended up with multiple values for keys, one for each time the function was called, e.g. add: ['add to', 'add to', 'add to']. This shouldn't be a big concern in hook_footer(), as it's unlikely this will be called twice, but I left it in just in case.

Here's an improved patch.

I've completely rewritten the Javascript to integrate as much as possible the regular and freetagging vocabulary handling, introducing a single set of methods that apply to both.

Other changes include:

1. Merging in new freetagging tags is now done on the client rather than on the server. This enables a single post method.

2. Regular vocabulary tags are in one ul element rather than separating them out into two.

3. Removed use of hook_footer(). Instead, an initial array is declared using a static variable for the settings, then individual node data are added in a way that will merge.

I'm feeling (I guess taking the time to rewrite the patch suggests so!) that this does make sense as a single module. We have these two types of vocabularies in Drupal. Yes, they require distinct server and client side treatment. But they are both forms of tagging. The data storage needed is identical.

On the PHP side, most of the complexity of the current module is to handle the freetagging. In comparison, the code for regular vocabularies is relatively straightforward. Adding regular vocabulary support increases the .module file by under 10% is size.

Just finished this redraft, it seems to basically work but could use some more testing.

Minor fixes from previous version. Fixed parse error, removed some code no longer needed in the JS callback.

Minor changes to JS to fix IE errors. IE didn't like a variable being named class or an extra comma at the end of an object list.

Thanks for the review!

I expected a dropdown menu where you can select the term you want to apply.

Turn off Javascript and that's just what you'll see ;) I based the JS interface on what's already there for freetagging.

We could consider, though, keeping the select, or making that optional, or dependent on the number of tags. Where there are only a few tags having them directly clickable seems to make sense, but I see that having many would clutter up the page.

That said, I'm not planning to work further on the patch unless its status is changed from postponed. If and when core taxonomy is rewritten (probably at least many months from now) enough changes will have occurred in the module that the patch will no doubt require rewriting from scratch.

Steven is right to hesitate to apply this patch. Community tags is complex, and, whatever my efforts to minimize additional complexity, this patch would make the module more difficult to maintain, expecially as I've completely rewritten the JS. I wanted to do what I could to address issues, but I still completely accept the 'postponed' status.

I did try writing this as a separate module, see http://drupal.org/node/140964#comment-241308. I didn't like the result, for some of the same reasons. If doing this in the same module adds complexity, doing it in a different module that builds on community_tags is positively messy.

So, it seems, the idea can wait until if and when community tags settles out and is ready for significant additions.

(Meantime, for the project I intended this for, I'm going to write a small custom solution instead.)

Steven's recent patch to add AJAX to views_bookmark, http://drupal.org/node/141017, means that pretty much the same functionality can be achieved through that module.