Right now I have a new tree.cfc that matches the API from the current tree.cfc. It uses another component, XmlTree.cfc, stored in application memory that handles the actual xml calls--moving branches, etc. So far the site tree is working well on my development instance, including moving, copying and deleting branches. Also our navigation custom tags seem to be handling it as well. To keep things safe, all methods that modify the data do so on a copy of the xml inside a <cflock> tag and then saves it back if successful.
A few caveats:
I haven't tuned it. I'm sure it's probably slower than using the database.
It doesn't return "parentid" or "nright" in the query objects and "nleft" is just the currentrecord in the query for ordering purposes.
So, first question, is this a stupid idea?
Second, is anyone interested? I could get the files packaged up if anyone is curious.
Third, why didn't I look into XPath long ago? It's pretty cool! :)
The xml file is pretty basic. An xsl file is used to tack on the depth attributes.
<trees>
<tree typename="dmNavigation>
<node objectid="..." name="root" depth="0">
<node objectid="..." name="Home" depth="1">
...
</node>
</node>
</tree>
<tree typename="categories">
...
</tree>
</trees>
--Kyle
Kyle Singer Lead Web Developer Whitman College Technology Services [EMAIL PROTECTED]
--- You are currently subscribed to farcry-dev as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
