[drupal-devel] [task] Better default workflow
stefan nagtegaal
drupal-devel at drupal.org
Sun Jan 23 17:33:23 UTC 2005
Project: Drupal
Version: cvs
Component: node system
Category: tasks
Priority: normal
Assigned to: drumm
Reported by: drumm
Updated by: stefan nagtegaal
Status: patch
Dries, what does this patch need more before you commit this? This is an
improvement qua consistency, it gives us more space to use the nodeapi,
AND it is very, very clean..
A big +1 again for this patch...
stefan nagtegaal
Previous comments:
------------------------------------------------------------------------
December 10, 2004 - 03:27 : drumm
Attachment: http://drupal.org/files/issues/types1.png (8.05 KB)
This is a screenshot of the page replacing the 'default workflow.'
------------------------------------------------------------------------
December 10, 2004 - 03:29 : drumm
Attachment: http://drupal.org/files/issues/types2.png (18.41 KB)
This is what you get by clicking 'configure.'
------------------------------------------------------------------------
December 10, 2004 - 04:01 : drumm
Attachment: http://drupal.org/files/issues/default_workflow.diff (10.79 KB)
The default workflow page quickly becomes usuable as modules are added.
I think it works much better broken up into one page per content type.
This is a very basic patch which simply moves around the UI and does
not change any functionality.
I see lots of potential in following this path:
* The submission guidelines would make sense on this page. Have the
node module put those in, no need to have it duplicated in all the
modues.
* This page could be moved around to be a top level admin menu with
local tasks 'list' and 'add new type' for making lightweight types on
the fly instead of the very lightweight modules we have now.
* Permissions for who can create nodes or edit their own might make
sense on or next to these pages.
* The various elements of the create content form, or even the node
view, could be reordered with weights.
This requires modules implementing hook_nodeapi('settings') to return
strings containing the form elements instead of associative arrays.
------------------------------------------------------------------------
December 10, 2004 - 04:09 : moshe weitzman
Perhaps we could preserve the overview of all node types and settings in
read only table view. then an edit click would lead to the form you
show. i think the overview of all settings at once is useful sometimes.
------------------------------------------------------------------------
December 10, 2004 - 09:35 : Dries
This is a step in the right direction but the patch needs to evolve a
bit before it is commit-worthy. For one, I would use form_group()
rather than a form_item-hack. For consistency, table headers should
start with a capital letter. Furthermore, I support the idea of
creating a more prominent workflow-menu. Moving the story and forum
settings to this page, might make sense, although I'm not sure people
expect to find the 'submission guidelines' or 'forum structure
settings' under 'workflow'. I guess it would work. Either way, this
patch has potential so keep working on it.
------------------------------------------------------------------------
December 10, 2004 - 16:57 : tostinni
Is this : Configure Workflow by roles [1] could be a way of improvement
to ?
Good ideas for the patch, thanks.
[1] http://drupal.org/node/13129
------------------------------------------------------------------------
December 16, 2004 - 23:22 : Dries
The statistics module's "Display node counter" setting could be part of
the workflow system (that or it should be added to the theme's "Toggle
display" settings). Similarly, the "Display post information on"
setting on the global theme configuration page might be better of being
part of the workflow system.
------------------------------------------------------------------------
December 17, 2004 - 10:55 : Bèr Kessels
Display and rendering setings should always be part of the theme
settings, and preferably only the global settings. they have nothing to
do with workflow, and will confuse people if they are "hidden"there.
Similar to the "permissions" for upload, that are (were?) hidden there,
since uploading has little to do with "allowing uploads".
------------------------------------------------------------------------
January 21, 2005 - 01:26 : drumm
Attachment: http://drupal.org/files/issues/default_workflow_0.diff (16.22 KB)
Here is a cleaned up patch which:
- Capitalizes the column headers
- Uses form_checkboxes() instead of the form_item() hack
Because I wanted to use form_checkboxes() rather than a form_group() I
had to make those 5 variables into one array. There is an update to set
the one variable per node type to the values of the five old ones, and
delete the five. I have not benchmarked the difference of one array per
node type in the variables table vs. five booleans (ints) per node type,
but I expect it might be faster.
I do have more ideas for what should be done once this first step is
finished.
- I think 'content types' should be a menu item in the navigation menu,
not a local task. This will let us put a 'add content type' tab in the
logical place when/if it is time to do that. Also this page is buried
now.
- I think that the submission guidelines and minimum words should go on
these pages.
- I think form_group() should be used once the form grows. We could
stick what we have now in a 'Workflow' fieldset.
- I think that the 'settings' $op of hook_nodeapi() should be rethought
and maybe put in another hook.
- I think that node create/edit permissions could go on these pages.
- I think that this form should have a 'save' $op and use
system_settings_save() because that limits what modules can do to using
variables.
- I think that there should be a 'validate' $op so modules can do
validation.
- I think that the five options should be rethought.
However, these are all separate issues which should have their own
patches and debate and many will have to wait until 4.7. But this gets
the door open for modules and ideas in 4.6.
I'm willing to put more in the overview table, but I would like input
on what it should look like to avoid width problems and be as usable as
possible moving forward. Perhaps that should wait for another patch?
------------------------------------------------------------------------
January 21, 2005 - 01:32 : drumm
BTW, I consider the added 'else' in system.module to be a bugfix. I'm
not exactly sure why system_settings_save() does a drupal_goto(), but
it helps make the form act a lot more predictably if it does the same
type of returning or goto for whichever button is pressed.
------------------------------------------------------------------------
January 22, 2005 - 10:28 : stefan nagtegaal
Wow, i really like this patch!
This implementation is very clean and looks consistant with the way the
input format's are configured. (Which is imo one of the best UI we
have.)
+1 for this..
--
View: http://drupal.org/node/14170
Edit: http://drupal.org/project/comments/add/14170
More information about the drupal-devel
mailing list