Robustly does it.

Sometimes, when your stood in a forest, you see a lot of trees but you don’t see the wood.

Having had a short break from Rapidsite while I was employed on a few other tasks, I’m gaining a better insight into the Rapidsite application as a whole. When I returned to Rapidsite I was forced to spend some time getting to know where everything was again and how it all goes together. I’ve often found this to be a useful exercise, and together with a solid round of documenting the code, I feel I’ve gained fresh insight into the application.

If it looks like a duck, and it sounds like a duck… it’s a duck.

Mostly I’ve been concerned about the pages editor, this is the page that allows a user to add or remove a page, or to change attributes such as it’s position within the site, it’s ranking within any menus, it’s title and status.

Most web site structures follow a tree like structure, with the home page at the top, then a first tier of pages coming off this and possible subsequent tiers of pages coming off them. i.e.

Home

|

welcome    about us    products    contact us    links

 |

product a    product b    product c

This structure is easily represented in XML, as an xml document will natively follow a tree like structure as well. It will have a root node, with other nodes coming off it, and possible other nodes coming off them.

So the question is why do we constantly try to crowbar this structure into a database, whose natural structure is tabular (table like)? I discussed possible methods to get around this in a post about modified pre-order tree traversal algorithm.

But why get around it? why wrestle with xml style data structures and try to cram them kicking and screaming into a table? Why not simply put them into an XML data structure, like a sitemap?

“doink” the sound of a penny dropping.

So I’ve moved over to xml data structures to represent both the site structure and the  page content, which is xhtml, which is a form of xml, makes sense does it not?

Suddenly things which were so hard are becoming so much easier. Take changing a pages position within the site, previously I had to record data on parent page id, sibling pages ids, save all this in a database table then look it up and reinterpret it when I wanted to display or edit the page. Then if I deleted a page I had to write functions to iterate over the whole database table, looking for pages that may have been affected by the changes, altering their parent or sibling records to accommodate the new site structure, and finally checking the menu page rank of each page to update those. Gnaaaaargh!

Now, I just open the sitemap xml file, move the node representing the page to it’s new position within the xml structure, or delete it if required, et voilà! Jobs a good-un.

This should help us to maintain a more robust, easier to manipulate and simpler to manage site structure editing process, which should help to speed us through the testing phase which is coming up soon.

All in all, a good week.