why one weight field per level ?
yched - September 21, 2008 - 01:40
| Project: | DraggableViews |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
Thanks for this module, looks really useful !
One thing I don't get is why you need one CCK 'weight' field per depth-level. The existing hardcoded db structures that store tree-like hierarchies (menu, taxonomy terms...) usually use a single weight column (weight being 'order as a child of its parent').
I haven't looked at the internals of the module, but from a naive outside look, it seems one CCK field could be enough to store the weights ?
#1
Er, I think I get it actually - that's probably in order to define views ordering - by weight_level_1, then weight_level_2.
I wonder if this could be streamlined :
- either by hardcoding the sort criteria used by 'Draggable Table' views - after all, who would want to display the rows in a different order ? Views2 might very well not allow that, though.
- or by creating your own Views 'draggable_sort' sort handler that takes care of figuring the right display order from parents and weights.
#2
Well, for outputting the whole thing a single field and an appropriate sort-handler would be enough - I already thought about this too :)
But I'd loose flexibility of the nodes handling.
Draggableviews was primary designed to act as a project-manager to manage the priority of milestones and tasks. This project manager should not use its own structure but rather should "assist" the existing structure. For expample it must be possible to output all tasks without their parents in the correct order. This wouldn't be possible if counting started new with each milestone.
Moreover the performance of outputting would suffer - you already mentioned this. I actually did it like drupal with its navigation system admin/build/menu-customize/navigation:
When you take a look at the "menu_links" database table you'll notice that they have a fixed number of hierarchy levels you can use. It stores each weight of each level. I think they did it because of perfomance issues.
Thanks for calling this into question, it's worth to discuss about it,
best wishes,
sevi
#3
Paging required to continue counting even if a new hierarchy level is opened. I can't find any arguments any more against your request. Probably I'll change the module to use only one order field at all.
#4
Have a look at http://drupal.org/node/313081
The current dev uses only one weight field at all :)
#5
#6
#7
Automatically closed -- issue fixed for 2 weeks with no activity.