Thursday, February 22
The second most confusing and problematical aspect of Minx is the system of implicit containers.*
I've mentioned before that Minx has multiple hierachies, defined by Sites, Folders, Threads, Posts and Attachments. You can have as many of each as you want, and they can be nested any way you want, and can be intersected and unioned and what not in many strange and wonderful ways.
For a simple example, let's say you want to go to http://ai.mu.nu/blog/post/thats_going_to_need_stitches
The ai.mu.nu part specifies the site; the blog/post part specifies the folder; and the thats_going_to_need_stitches specifies the thread.** Which is all fine and dandy. That thread will likely have a category assigned to it, which is in fact another folder - in this case the "geek" folder - so that it can also be reached at http://ai.mu.nu/blog/geek/thats_going_to_need_stitches (or something like that). And that category, even though it's actually just another folder which is attached to the entry in question, is to your template an implicit secondary immediate parent structure, so it has to be automatically provided as an appropriate set of template tags.
With me so far?
The problem with this is context. My test site just blew up because the inline comments decided that they needed to be paged (so that only the first 20 comments were displayed inline, and for the rest you had to go to the next page); the problem being that because the page itself was a folder context rather than a thread context, the pager data for the comments (which are posts) wasn't set up. The fix was simply to have the comment paging code check first whether the requisite data was set up... which was a good idea in any case.
This just gets more complicated when you consider that certain objects - the Entry object is a good example - combine the aspects of two or more other objects. An Entry is essentially a Thread combined with a Post, but it also provides access to one or more Author objects and optionally a Folder object, and has to automatically create all the contexts involved. And since an Entry is always viewed inside a Folder context anyway, this can get a little fiddly.
For me. For the user, it's supposed to Just Work™.
One of the solutions I've put in place is explicit substructure tags to complement the implicit tags. Example: The [comments] tag creates a list of comments relevant to the current context, which might be a Folder, a User, a Thread, a Post, or possibly something else. It works out the applicable context automatically, prepares the necessary SQL queries, processes the data, and interprets your template for you. Easy-peasy, unless you wanted it to do something different.
So now, in addition to the semi-automatic [comments] tag and the fully-automatic [comments:here] tag, you have a set of tags such as [entry:comments], [user:comments], [folder:comments], [site:comments], and so on.
The problem with this is that there are, at last count, 12 specialised variants of the [sites] tag, 12 variants of [folders], 6 of [threads], 6 of [posts], and currently 9 of [attachments], and every one of them has to have a complete set of explicit substructure (and superstructure!) tags. So my structural tag table is now dynamically rather than statically generated.
The saving grace, or rather the two saving graces, are these: First, the code for this is largely O(1); the whole template engine works on hash tables, so this doesn't slow it down; and second, because all these variants are variants rather than explicit structures in their own right, this is all actually very well organised. The [category] structure is independent of the [folder] structure (and the [section] structure and the [area] structure and the [archive] and [subforum] and [directory] structures and so on...) but the fields in each one are identical. So as long as you know that [category] is a variant of [folder], you're all set.
How I'm going to structure the documentation for this I don't quite know yet.
* The most confusing and problematical aspect of Minx right now is the user interface customisation system. It doesn't give you a life-jacket, just a whole lot of rope. It's not hard to customise it to the point that you're effectively locked out of your own blog. I will be putting a failsafe in there that lets you log in to the maintenance system using the default settings, but that's not there yet...
I'd go with dynamically generated documentation.
Posted by: TallDave at Thursday, February 22 2007 11:42 PM (odS+4)
Posted by: Pixy Misa at Friday, February 23 2007 01:05 AM (FSeIE)
Posted by: michele at Friday, February 23 2007 11:51 AM (oRqqq)
Posted by: triticale at Saturday, February 24 2007 12:10 AM (9YuSf)
Actually, the back end is MySQL as you'd expect. But the template engine uses hash tables. Template tags retrieve data from the database into the hash table, and extract data from the hash table and put it into the page, depending on the type of tag.
So [comments] sets up a SQL query and iterates through the results, updating the hash table as it goes, and tags like [comments.text] retrieve data from the hash table.
Posted by: Pixy Misa at Saturday, February 24 2007 01:19 AM (FSeIE)
Posted by: Steven Den Beste at Saturday, February 24 2007 01:23 AM (+rSRq)
Posted by: TallDave at Saturday, February 24 2007 03:18 PM (odS+4)
Posted by: triticale at Saturday, February 24 2007 10:54 PM (r8DWN)
Posted by: BeckoningChasm at Sunday, February 25 2007 10:52 PM (pGYvN)
Posted by: Pixy Misa at Monday, February 26 2007 01:38 AM (VImBE)
Pixy, Livejournal is still banned.
Posted by: Pete Zaitcev at Monday, February 26 2007 02:31 PM (9imyF)
52 queries taking 0.2263 seconds, 287 records returned.
Powered by Minx 1.1.6c-pink.