Hi,
I wrote this mainly for the CMSMS Dev Team again.
Current when the we change the structure of the page hierarchy, we have the following options:
1. move a page up
2. move a page down
3. delete a bunch of pages
4. move a page under a new parent page
I hope that in the future release, there's few more options:
1. move a page before the other page
2. move a page after the other page
3. I also hope that after deleting some pages, I can be able to undelete them later on, just like windows recycle bin.
4. Next, I don't know if it's appropiate, we could have the cut-and-paste options (like we did in windows) on managing the page hierarchy. But looks like this would involve some concurrency issue, if there are multiple admins doing the hierarchy change, it might have some conflicts...
I'm grad that Ted is going to adapt a new way to managing hierarchy data, with the new algorithm, all options from 1 to 3 are relatively easy to achieve.
At first, I wish to roll my demo of the nested set model, but I would rather leave it to the Dev Team of CMSMS, I would like to just contribute my thoughts of it on the way, make myself a drop which hopefully will lead CMSMS to a torrent:)
Up to now,
I think in order to achieve the moving effect, we should have the table structure similar to this:
id
parent_id --- used mainly for retrieving child list of a page, though we might used table join to do the same using lft and rgt, but using parent_id will avoid it and the query will be very easy...
lft --- used in nested set model, good for sorting the tree
rgt --- used in nested set model, working with lft, good for retrieving a page's subtree and path-to-page
rank --- used mainly for generating the hierarchy number
exist --- 0 or 1,default 1, if the page is deleted, change it to 0
moving --- 0 or 1, default 0,when we try to move a source tree to target tree, we first update the source tree to "moving", then do the corresponding moving...
I think the hierarchy number generation can move to php instead of storing it in database. With the nested set model, we can easily do a paging effect on all pages. After deleting some pages under a specific parent, we can use the sqls like the following to get rid of the "empty holes" in the rank:
set @r:=0
update set @r:=@r+1 where parent_id = {a specific parent}' order by lft asc
for each paging load, we can do this in php
1. get all hierarchy pages of the each page in the current page list using lft and rgt
2. store the corresponding ranks of all related pages
3. form the hierarchy number
I found that the more I used CMSMS, the more I like it, keep up the good work Ted and CMSMS Dev Team:)
With my best,
Jim
more operation choices at hierarchy
more operation choices at hierarchy
Last edited by javathunderbird on Wed Jun 13, 2007 7:00 am, edited 1 time in total.
Re: more operation choices at hierarchy
the hierarchical data in relatiion database as mysql is a cool approach but has some nervios transactions when sorting or adding a node to the tree.
I am getting over one class for unlimited categories and items into them.
I found this article and following it.
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
best regards
svilen
I am getting over one class for unlimited categories and items into them.
I found this article and following it.
http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
best regards
svilen