Closed (won't fix)
Project:
Tagging
Version:
6.x-1.x-dev
Component:
Backend
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
15 Jan 2010 at 11:07 UTC
Updated:
18 Oct 2010 at 20:59 UTC
Hello,
i was asking myself if you would like to join efforts with the module tagging. I think both modules seem to have the same goal. Tagging adds a suggestion and a theme API and uses a jquery-plugin architecture.
So my question is if you like to merge into the tagging module, bring in your ideas and features, helping to maintain it and over all create a even more stable and featurerich plugin.
Let me know if you are interested or have any other ideas
best regards
Eugen
Comments
Comment #1
arhak commentedjust downloaded your module (I'll review it)
Join forces? yes, why not
Merge? don't think so (details after reviewing your module)
Comment #2
eugenmayer commentedGreat you investigate, thanks for the time
Comment #3
arhak commentednice piece of module you have there
how would you like me to help you?
some functionality / bug hunting / patch testing ?
BTW, in fact it doesn't relates to taxonomy_single_tag, so a merge is discarded, this module just enables autocompletion for non-multi tagging vocabs, it doesn't needs UI or nothing like it, neither API to support it, since it delegates to core functions
Comment #4
arhak commentedtesting your module I can see some flaws where I could help you
but it would be much better if you join the vanguard on this front http://drupal.org/project/active_tags
OTOH, I think you might help them a lot, and your module shouldn't be growing by its own while it actually reproduce an existing functionality
an they might use a lot of your insight on their module, ask them to become a co-maintainer
Comment #5
eugenmayer commentedThe functionality of taxonomies (not tagging) will be included.. just look into the issues. http://drupal.org/node/685008
And thats exactly were you could help out, making the module more complete and more widely useable. Goal is to cover the different taxonomy types with different UI`s for the different usecases
I allready asked the active_tags maintainer if he wants to join efforts but dont have an answer yet.
Comment #6
arhak commented@#5
I really don't get it. There are modules already specialized on different ways of clasification.
The ones I recall:
- active_tags: looks pretty much like what you have now, but has the advantage of being older and having more than a thousand users (your ideas could enrich it though)
- tagtool: similar approach to active_tags, but different UI
- tag_editor: ditto
- hierarchical_select: great UI for hierarchical vocabularies
- taxiselect: a different approach for hierarchical vocabularies
- community_tags: great concept, implementation got too complex at some point and last time I checked was buggy
- content_taxonomy: manage taxonomy via CCK and optionally keeps synch
- taxonomy_image: images for terms or sub-trees
- taxonomy_list: a lot of different ways to display term pages
- taxonomy_manager: enhanced admin
- taxonomy_menu: creating menus through vocabularies
- taxonomycloud: clouds
- tagorder: sorting terms
My advise, you shouldn't attempt to bundle all possibilities into one big module (chances are that bugs will never stop)
There are currently 4 modules doing basically the same thing: tagging, active_tags, tagtool, tag_editor.
And at least 2 modules for any approach with a minimal common sense.
taxonomy_single_tag is just autocompletion for what could be a non-hierarchical vocab with many terms, to avoid using a huge dropdown list. From that, I don't get why did you ask for a possible merge.
Nevertheless, I can help you sorting some things regarding "module development", but I not a fan of fancy UI development (because there are a lot of developers with plenty of time to take over).
I can review your module, test, patch, take over of some bug or missing functionality (like validators, schema, etc), but I'd feel better if you spend some time to contact the maintainers of the modules mentioned above (via IRC, issues, contact form, etc) until you find one team who welcome you, and maybe some of them might advise you regarding the roadmap or approach to follow.
Comment #7
eugenmayer commentedIam not trying to bunlde it all into one module, but create pluggable module. As you stated, there are several modules doing the same, and EVERY of them reeimplementing the wheel once again.
Every of them works with the taxonomy backend, creating some kind of UI and trying to hook into drupal generally.
And they really differ a lot in the way they do and in the quality, espicially on the Javascript side.
So my idea is providing a base, on that base you have different plugins:
- Handle freetagging
- Handle term selection (also huge amounts)
- Handle term exploration and selection)
- Handle hierarchical selections
- Handle suggestions / semantic
Actually you need 3 kinds of UI`s:
- The one we have in Tagging, so selecting from autocompletion and visualize the selection. Make selected items manageable (deletion). This UI can also used for "taxonomy_single_tag" without changes, just one check needed "only allready created terms are accepted". So there is not much to change and THATS the idea of implementing that UI. Thats why its a Jquery plugin, thats why you can overload it.
- the second ui must handle hierarchies. Thats where i really like taxiselect.
- the third must handle all, but give the user a better way of exploring. So actually you first see the tree (with a max) and have a textfield to finter. While you type, the tree (also flat) shrinks, while still reflecting the hierarchy (if any). This way a use can search for terms / tags, without knowing to much about that.
So there is a sense sharing the work, a lot of sense actually. And thats why i ask the module devs. The problem with nearly every implementation you mention is, that they have no API and are not pluggable at all. They have never designed to be so.
Comment #8
arhak commented@#7 makes more sense
- the pluggable API makes totally sense
- the kinds of UI being provided via this same module: not so clear why (to bring a themeable start point?)
- will those pluggable items be sub-mods? will they be a migrated version of existing mods? will you draft and suggests their maintainer to migrate to rely on your API?
- are you aware of taxonomy_override_selector? and the issues related to it? (active_tags states "Does not currently work with the Heirarchial Select module, Community Tags module, or any other module that uses the "taxonomy_override_selector" variable. More information")
- where do you want me to start helping you?
Comment #9
eugenmayer commentedIt depends on the "weight" of the module, if it should become a submodule or a module. it also depends on if we have maintainers for it.
Iam not using the taxonomy_override_selector at all. Tagging defines a new form element type and that one simply renders differently. So every vocabulary defined to be displayed by tagging will be affected, every other vocabs are not touched at all.
So taggin does work with hierarchical_select, community_tags and even with active_tags. Of course you cant use active_tags and taggin on one taxonomy, but this would not make any sense at all. also using hierarchical_select with tagging on one and the same vocab while editting a node would not make sense.
So yes, you can use tagging while hierarchical_select or others are install and activated. But you can use them on the same vocabulary at the same type while editing.
Well in your case its all about the case supporting non-free-tagging, flat vocabularies. So UI 2 in that matter.
All there is to do is only letting people selecting existin terms, this shoudl become an option to the jquery_plugin. Or even more presize, tagging is using the autocomplete feature of drupal core, so you need actually to exchange that one.
In addition, you can bring in any ideas you ever like to, critize the module or the way its written. help well you really want to :)
Thanks taking part in this discussion!
Comment #10
arhak commentedactually, free-tagging, but a single tag, which might also include commas/quotes, since it doesn't requires a list of tags
other similar use cases:
- non-free-tagging autocompletion: taxiselect (which works for hierarchical and flat as well)
- dropdown list with option for new terms: taxonomy_other
so I preferred to avoid overlapping functionalities, taxonomy_single_tag was also developed for a specific site, which requires selecting a single category/clasification which might come from a huge set of existing terms or a new one might be created as well
Comment #11
arhak commentedregarding contributions I might come up with:
- would be nice if you open a meta-issue to follow up the ongoing development (what is being working, buggy, missing, etc)
- I can provide you patches against the 6.x-1.x-dev tarball, so I might be outdated some times
Comment #12
Crell commentedEugene also opened a similar issue for my module, Suggested Terms. To be honest, I have to ask, if you're so interested in modules merging together why did you release yet-another-taxonomy-module before talking to any of the existing maintainers, and then ask them to fold their modules into yours? That seems like a rather backward and presumptuous approach to take.
Also, come Drupal 7 taxonomy is a field so all of these modules become different taxonomy widgets rather than form_alter implementations. That would be the time to massively rethink the approach we all take toward taxonomy (as I discussed in a recent blog post).
Comment #13
arhak commentedmmm... a roadmap is actually required, also other developers' thoughts regarding this proposal
most likely a discussion at g.d.o.
and I'd suggest discussing D7 first (with probable D6 backport later)
@#12 +1
Comment #14
dragonwize commentedEugene also originally posted (#650968: Forked / Reimplemented active_tags) over at the active tags queue when he created the tagging module. Only after my responses was he even remotely interesting in working together and started posting to everyones queue.
Comment #15
sevanden commentedSounds all complicated if you're not really in on it from the beginning, especially if you're not an active developer. However, if D7 will effectively change the way things are done and make all those modules change to different taxonomy widgets allowing different ways to display information, I must agree that it would be better to focus on working together on D7 development. A thing I am still missing in all those modules is to have the ability to inject tags based on external services (Calais, Amplify, or other services), maybe that should be taken into consideration as well for future developments.
Comment #16
eugenmayer commentedTagging can inject terms, thats called "suggestions api here".
Its yet implemented with the extractor module as an example, which does a semantic analyze of the content you have and sugges terms on that.
Its pretty easy to use opencalais for that to, should be a module of < 30 lines. All you need to is call the opencalais service on the node-body you got from the hook, then pass the returned terms as sugesstions. Your done. You need to implement one method for that ( hook_tagging_suggestions ). Same goes for Amplify.
@crell: Well its pretty plain, why i did not start to argue about mergin before: First i want to provide a "in my eyes better" module, which can handle most of the functionality.
Neither suggested_terms, community_tags, active_tags, taxonomy_single_term provide any API to extend. Rebuilding a extensible, stable plugin of most of them would have been resulted in a complete rewrite (well thats what tagging is).
@arhak: Please dont close issues of tagging.
@dragonwize: yes, i have contacted a bunch of "taxonomy widget authors". Is that bad? And no, your response was not the reason for my interest of working together. Its the release of the first stable where i started to contact people. I dont think any authors are interested in working on a "new proof of concept". The module shuld have been release, stable and ready to use before that. Thats what i did. But as i appologized before, i understand your bitter feelings.
Comment #17
arhak commented@Crell, @dragonwize: could you please review/criticize the proposed API and check whether your modules would be able to rely on it?
I know you didn't liked the first contact attempted by EugenMayer, but he has a point (and already apologized)
would you support his ideas? (this shouldn't go too far without developers' support)
@EugenMayer: you're right about providing a "working" proof of concept rather than just ideas, and I'd love to see other maintainers jumping in at least to state what would be the "issues" regarding their modules getting related to tagging
Comment #18
arhak commented@#15
http://groups.drupal.org/node/38290
Comment #19
Crell commented@EugeneMayer: Are you sure of that? Did you ask any other maintainers? I certainly didn't hear a peep from you until after you'd duplicated my module's functionality and then had the gall to ask *me* to fold my module into yours. Really, check my issue queues. I'm usually desperate for co-maintainers, and I like extensible APIs. Had you contacted me before about adding pluggable suggestion algorithms to Suggested Terms, I'd have been quite open to the idea. Now, we have even more duplicate code and you're trying to fold everyone else's modules into the youngest, with the least traction among users, but the one that you're the maintainer on.
Under these circumstances, no, I am not interested in reviewing the API for this module because I am not discontinuing Suggested Terms for Drupal 6.
If you really want to collaborate, rather than just replicate, then let's focus on Drupal 7 and what it would take to have a common approach there that would deprecate *all* of these modules, including tagging.module.
There's really 2 parts that such a system would need:
1) Configurable suggestion list algorithm that can pull from OpenCalais, or from existing tags a la Suggested Terms, or from whatever other source.
2) Swappable widget logic that can leverage that suggestion list. Tagging and Suggested Terms, for instance, use a different UI display. There are cases where you'd want to use one or the other; neither is going to be The Widget for all sites to use.
So we would need a generic suggestion system and then a generic way for different widgets to easily leverage that suggestion system, both in configuration and in source data.
Comment #20
eugenmayer commented@Crell: Iam totally fine with it. I was not going to co-maintain Suggested terms, so iam fine with it. It was an offer nothing more. You see it once sided, you see that "i" (or tagging) profit from merging with suggest_terms. I dont think its that one-sided at all.
btw. 1) is already solved in tagging and 2) is nearly done, as iam using a form element as a widget which is completely customizeable. Also the JQuery plugin is completely generic.
Your points are exactly the reason why tagging was created (beside the lack of usability). Anyway, as activet_tags, suggest_tags and taxonomy_single_terms are going to keep themselfs, iam closing this issue.
Thanks for the informations and the discussion.
Comment #21
eugenmayer commentedComment #22
Crell commented... So you're not going to discuss D7 approaches with the rest of us since we're not interested in folding into your module right now? Am I reading that correctly?
Comment #23
eugenmayer commentedWell were did you read this?!
This topic is about mergin those modules. As this not gonna happen, this issues is closed i guess.
D7 are a different topic and should get an extra issue and iam ofcourse interested in discussing it, while for me this is a long term goal. I dont see me switching to D7 in less then a year. D6 has enaugh problems left, no need to jump on the next rush wagon with even more bugs.
Comment #24
eugenmayer commentedComment #25
sevanden commentedWhy don't you guys start working together on D7, at least those that are interested in combining their forces, time and knowledge for the good of the community? It's not really constructive the way the discussion is going right now ... You don't want to merge in D6, fine ... but you can work together on D7. I think you guys should start a topic/group in order to do so, and whoever is willing to join can do so ...
Comment #26
sevanden commented@18
True those modules exist, as individual modules.
However, I think having a system that allows one to chose how the tagging suggestion are represented would give great flexibility.
On top of that having a similar system that gives the same flexibility to allow one to chose which services are used to provide suggestions adds even more flexibility to the entire system (Calais, Amplify, Yahoo, Google, ..., Internal search, ... )
And if everything can be configured from within one single UI, things will be very easy to use I hope ...
@Everyone involved :)
I think everyone would really benefit from working together on future developments, and as was mentionned work towards 1 system that would render all individual modules obsolete ...
Just an opinion, not necessarely the correct or best one ... :)
Comment #27
nedjoSee http://groups.drupal.org/node/100179 for a proposed API to be used by tag suggestion and autotagging modules. Please review, revise, and comment.