Refactoring Infinite with Link Trees
Posted in Django
on November 30th, 2009 by
Stephen DeGrace
There are three new goals I have in terms of where I'm going with this Infinite application (the suite of Django applications that runs this site). One is simple - to add an app for linking to eclectic outside sites, including for use as a blogroll. Another is to create a graphical tree app as an extension of the Django admin which simplifies the process of building menus and adding local content. Going along with that is a way for applications to conveniently list off what links they have available in such a way as to easily interface with the graphical menu tree app. Finally, I want to leverage the capabilities developed to list content for the menu tree to build an extension to TinyMCE to easily link to local content while blogging.
These goals may all be related. The blogroll application could easily stand alone, powered by a much simpler one-off Django app. However, the functionality is similar to what the menu app does already (except that I would want to add descriptions for the links, and I don't necessarily need a recursive tree structure) that a small extension to the menu app that ignores its recursive structure functionality for the purposes of building a blogroll view into the data would be a very viable options.
However, I'm thinking of a complete refactor of the menu app anyway. I'm thinking of implementing it as a tree of links (losing the concept of menus and submenus built into the data itself) implemented with treebeard. On the side of the Django admin, I would like to use jsTree to implement the graphical tree interface, and have it implement operations on the tree in real time with AJAX. A separate model would be used to point to root nodes and allow them to be identified with short, unique slugs, so one tree at a time, defined as one root node and its descendants, would be loaded for editing at once. You would then be able to select a node and either manually enter a URL or select an item of local content from the list.
The link page would just be a view into this app which uses a particular tree down to the third level (so the second level links would be used as category headings and would not actually be implemented as links in this view). It would have a front end editing interface with limited capabilities reflective of the limited tree it allows and permitting only hard coded URLs. The blogroll for the sidebar would be even simpler - only down to the second level of the tree.
Then, finally, the added capability to poll apps for links to local content would be exploited again this time to get hard coded links to content for access from TinyMCE. Or, I might add a middleware to parse {% url %} tags in content to allow dynamic local linking - the idea is that the local links exposed this way would be dynamic links of the kind that the menu app already supports and not static links that can be broken if the site's URL scheme changes (although, I'm extremely opposed to changing a site's URL scheme once it has been established).
This polling would be accomplished similarly to what I did when I created my frontpage app. Each app would be able to include a .py file that explains to the link collector what links it wants to make available and how best to link to them dynamically.
Anyway, I have the branch created in svn, so the question is whether I will go through with all of this or whether I will go with a simplified blogroll app for now. While the path of least resistance looks attractive, the crucial factor may be the fact that right now I have a simple menu structure which would be trivial to replicate, and I can afford to throw out all that data. If I start a blogroll, be it ever so humble, I might start to accumulate data that's valuable and a bit of work to replicate or migrate. So it may be less trouble later if I at least go down the road of this refactoring for a while and see how feasible it looks.
Comments:
There are 0 comments on this item. Be the first to comment.
Post a Comment
* Required field, your email will not be posted.