'add new' button
scottrigby - December 21, 2008 - 03:47
| Project: | Ajax Checklist |
| Version: | 6.x-1.0 |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
It'd be lovely to have an interface that allows creation of checklist items by clicking 'add new' (automatically adding a cb id), rather than having to edit the node then type each checkbox code manually etc.
Perhaps there could be an ajax form for the checklist node embedded on the node view, or in a block (or something like that).
+ Add New Checklist
+ Add New Task:
[ ] existing checklist (select list)
[ ] new checklist (name____)
Maybe this action of creating a new checklist / checkbox could be added as a view handler so views / VBO could do the work of presenting a configurable form. Any thoughts? :)
#1
That sounds like a great idea.
You could implement it with another filter or similar, say
[checklist_controls] at the top of the node. Which gives you links or icons or similar.
An add-item link could then go to a popup form that asks for an item, generates a id and adds it to the bottom of the node body.
An add-checklist to a normal "Add Node" (you'd have to configure somewhere what content type you'd want to use) pops up a form for a new node tile and just adds [checklist_controls] to the top.
Something like that?
I'm about to go away on holliday, will think more in the new year :)
#2
subscribe
#3
I was thinking this could be handled via custom fields?
i.e., when you go to Manage fields, one of the widget types would be a checklist field. You could then set the number of values to unlimited, which already includes that "add another item" button.
Thoughts?
#4
@klucid: yep, i fully agree. Though that may be out of scope for this module. that would really be up to the maintainer.
@asciikewl: what do you think? You use the filter approach, which I'm not sure is the best way for the description above... or is it? Also, I'm not sure how far you'd be willing to deviate from the original approach of this module?
I was strongly considering writing something like that (a checklist cck field). Though there are already so many (mostly done!) directions out there in contrib - my main quandry is which direction to help put effort towards. Because while there are a number of contrib checklist modules, none of them *fully* works like this yet -- Unless I missed one (which is possible!). Here's what I'm aware of so far that look even slightly plausible as a checklist solution for D6:
* http://drupal.org/project/todolist (not quite there - but yeah, basically supposed to be like basecamp ta-da list)
* http://drupal.org/project/list (promising! just not quite yet)
* http://drupal.org/project/casetracker (not exactly, but can be used to create to do lists in a way)
* http://drupal.org/node/353110 (the reason we can't use editable fields)
* http://drupal.org/node/336508 (the state of tasklist for D6)
* http://drupal.org/project/comment_cck (does something similar-ish to project module - allows comments to alter the status of a node - obliquely related to TODO functionality, but def worth mentioning as one approach)
I'm definitely in need of something like this - it seems like others are too - maybe there's something I'm overlooking? If not, some effort should be pooled. But which is the best direction?
#5
Awesome post. Thanks
I'm going to hold my breathe for: http://drupal.org/project/list
#6
Unfortunately our sales drive earlier in the year has been successful beyond expectation, so I'm a tad[1] swamped. I'm keen to spend time on this at the code sprints at DrupalCon and around, if anyone is going there.
[1] I have a friend that says a "tad" must be some NASA measurement of the distance between the sun and the earth.
#7
@asciikewl: :)
What klucid suggested (and what i had been looking into as well) would require modifying this (or some) module to offer a CCK field. Ajax Checklist currently uses a filter approach, so this would be a huge change - or maybe an addition rather than change? Because I assume you'd want to still keep the filter approach even if a CCK field is added. Maybe an Ajax Checklist submodule (ajax_checklist_cck)? Or maybe there's a better approach?
But as the maintainer it really depends where you're willing to see this module go
#8
Being steeped in the excitement of Drupal 7 ideas, I think the way to go is a CCK/FieldAPI field yes. There are serious limitations with the filter approach that could be fixed going to a Field.
#9
Ok - how should we do this?