join forces to create Node bulk operations?
| Project: | Taxonomy Multi Editor |
| Version: | 6.x-1.1 |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Hi. I'm just in the process of creating a Language bulk operations project, and I came across your Taxonomy multi editor.
Looking at our two modules, they seem to me to be very similar, and both fairly small. Both add options to the update selector at admin/content/node: assigning taxonomy terms (TBE), or setting the node language (LBO).
This makes me think: What if we were to combine our modules into a "Node bulk operations" module, that included our two features (bulk assignment of taxonomy terms and languages), as well as others that might come along in the future? I see a couple of benefits to users and developers from this approach:
- Reduce administrative overhead, by having only one module to install.
- Provide a common home for other interesting node bulk update operations that may come along in the future.
- We could provide a selection interface (page of checkboxes) that would allow administrators to choose which of the provided operations they wished to enable on their site.
One thing to know about LBO is that my intent is to get its functionality integrated into core. However, I missed the code freeze for D7, so it's going to be needed for D6 and D7 at least, for a good while yet. The same might be true of other operations-- a Node bulk operations module would provide a common home for them until or unless they get accepted into core.
Our two modules currently use slightly different form interfaces (TME adds a multi-select box below the main update operation selector, while LBO adds subcategories within the update selector), but the difference is trivial and I'm sure we could harmonize them.
I'm just getting my project underway so I haven't uploaded any code yet, but the code is written and it works. You can see it at http://drupal.org/files/issues/languageops.tar_.gz .
What do you think? Let me know if this seems interesting to you.
Thanks,
Andrew.
#1
Your idea is sound, and is a forward direction.
Two things bug me,
#1, Although the UIs of the two modules are in the same place, I don't think they do jobs that are at all similar - from a user requirement. The tasks are quite different, so grouping them together looks like bloat. In this case, I'd favour small modules rather than an oddly-combined package. Although I see you are thinking big-picture about "Node" bulk operations ... which would end up being a grab bag of actions. :-/
#2 There are better ways of doing this now. The taxonomy_multi_editor was built long before the 'actions' API was put into core. With the actions API, I think that these actions should be able to be exposed better to the system.
We have Views Bulk Operations which is the place to be looking to as a destination for these features.
I do not know how we can add secondary selectors to VBO - which both of our actions need. But merging closer to the internal actions API is the direction to move.
... On investigation, I've not used it, but the VBO UI looks like a bit of overhead to set up, whereas I tried to integrate TME as naturally as possible (and I imagine yours is similar). Not really sure what to think here.
It would need some more investigation into the internals of the actions API.
#2
OK, thanks for your comments.
Re #1: I agree the the two kinds of operations (taxonomy and language) are unrelated from the user's point of view. So we have on the one hand the bloat of installing a combined module for the user who only needs one of the operations, vs. bloat of installing two modules instead of one for the user who needs both.
Maybe the first sort of user is more common. On the other hand, in a combined module, I expect that each operation would only present itself when it made sense, i.e. when taxonomies existed or the locale module was enabled (and if the operation wasn't deselected in the config interface). So the UI bloat would in that sense be zero.
When I applied for a CVS account to create LBO, the request was initially denied on the basis that the language bulk set operation on its own was "too simple" to justify a stand-alone module. The request was later granted, but I appreciate that we don't want a bunch of small modules cluttering up Drupal. So I'm just trying to think about how to make things more efficient for users.
Re #2: I'm not familiar with the actions API, but regardless of which API is used, I think that the operations in both of our modules should be integrated into core, in the taxonomy and locale modules respectively. I'll be trying to get LBO into D8 core later on.
As for VBO-- now there's some bloat. Views and VBO are great, but they're way overkill to have to install, and create a view, just to be able to set taxonomy terms or language in bulk. I do intend to submit the language bulk set operation as a patch to VBO, but I also want to provide it separately for users who don't use VBO. If I work out the secondary selector problem there I'll point you to it.
It sounds to me as though you don't favor combining our modules right now, so that's okay. I'll go ahead with LBO. Give me a holler over there if you change your mind.
Andrew.
#3
True VBO itself is bloat for a little job like this, but I think (I've not myself looked deeper at the API I'm referring to) that it is presenting a UI to a core API/hook, and that our job is to expose our operations to that API (and it should just work using core UI too). VBO is an illustration of this being used.
What's going on is that I knew there was some learning to do, and hadn't considered how much more development was worth doing on this module to update it.
I may be wrong about the system altogether, but that's what I recall from looking at the internals once.
But you are right, I don't see these two different jobs living together in the same project. Conceptually it just dilutes the findability to me.
I'd rather see TME get shifted over to taxonomy_manager to make that a more complete solution or something (I've not thought hard about it).
And maybe your contribution could enhance another language-related project? It could get better traction that way.
#4
No, I've already looked at other multilanguage projects. None of them seems like a good fit.
#5