21st Apr 2005
An Overview of “sub-posts”
Draggable bits of content…
This writeup is a followup to IFrame Sub-Posts?. There’s some influence from what I commented on in TiddlyWiki Rox. There are a couple of personal desires: have a link go to an intermediary (where there can be several branches to choose from, each with some explanation), and to bring a bit of the Wiki experience into the blog realm.
This entry takes a look at the lifetime of a sub-post. The focus is on a possible plugin for WordPress.
What Is A Sub-Post?
A sub-post is like a Wiki entry, in that it is a focused chunk of information. A sub-post is a small window that can be launched from a link within a blog entry. The window can be dragged around. It is not a popup or a frame. Some other ideas:
- can have multiple sub-posts per blog entry
- can have concurrent sub-posts from different blog entries
- sub-posts are independent of a specific blog entry - they can be called from any entry
- sub-posts are referred to by a symbolic name, such as a WikiWord
As you may guess, having floating, draggable DIVS that are independent of blog entries (and which are not pages either) will constitute a fair bit of work in a number of areas. I am still very new to WordPress, and have been mulling over how to implement sub-posts as a plugin. It may well be a good idea to approach this in phases. The rest of this particular writeup looks at the lifetime of a sub-post (or, put another way, all of the tentacles to think about implementing).
Areas To Implement
Since I’m new to WordPress (but not PHP), I can guess at what will need to be done, but will be happy to hear any advice and/or feedback. The main areas would seem to be:
- creating a sub-post - how to make this naturally flow alongside creating a blog posting?
- saving a sub-post - how to grab / extract the data from the user, and get it to the DB?
- per-page JavaScript support
- invocation
- client-side sub-post lifetime
- server-side sub-post administration
Did I miss any of the big areas?
Creating A Sub-Post
I show three basic ideas for getting the sub-post data entered. I’ll note that since a sub-post could extend over several lines, and can include HTML, it would easily overflow the field size limit of WordPress’ “custom fields”.
- wrap in a DIV - I am not sure if I like this idea from the user perspective, or from the perspective of having to parse through the entire blog entry upon a “save” (would need to rewrite part of the blog entry)
- wrapping within a quicktag - seems a little bit better than a DIV, in that a quicktag such as “<!–subpost–>” would make a logical separation point (visually, and in pattern matching)
- separate entity - I like this notion the most. A subpost really should be its own entity, not bound up in a particular blog entry. The reason for wanting to have it on the same editing screen as a blog post is because that is a very likely time one would want to write a sub-post or two.
Save A Sub-Post
This is the phase of where the user is done writing the blog post, and a possible sub-post, and we need to parse through something in order to get the sub-post portion into the database.
- extract from DIV - I’m not wild about this idea. What would be a good method for handling multiple DIVs, each with a sub-post? Perhaps it’s not too bad to say that there would be a DIV naming convention of “subpost_MyFirstSubPost”, “subpost_MySecondSubPost”, and so on.
- extract from quicktag - this is a little better, because the content is already known to be a sub-post (so the user would not have to bother with a “subpost_” prefix.)
- get info from separate sub-post fields - seems like the most straightforward. Just like custom fields, except we can handle more data.
Some of the fields I would save to the database for each sub-post would be: the symbolic name (think of a WikiWord), the original associated blog entry, and the sub-post data itself. The initial goal is to keep things very simple.
Client-side JavaScript Support
The goal would be to provide JS support on a per-page basis. I would not want JS code bound to specific posts if I could help it. There are two broad areas of JS support needed:
- *HTML DIV window creation, drag, hide/close. Keep it simple for the intial version. (Presentation)
- XMLHttpRequest and other data handling functions (Content)
Sub-Post Invocation
(the first thing to do is wind back a bit and think about initial post creation) .. Something has to set up the JavaScript onClick href within a blog entry. The user may type this in by hand, or it may be some bit of quicktag-assisted editing. The idea is to have a bare minimum HREF that contains an onClick with a WikiWord argument that designates the sub-post. There is the notion of “how to call sub-posts from other sites, other blogs?” to think about, down the road …
Using A Sub-Post
Once the JavaScript functions have been invoked with an onClick, the general flow would be:
- create a DIV window with some sort of “loading … ” message
- send off the XMLHttpRequest with the WikiWord sub-post handle. The server side will get this, grab the data from the database, and return it.
- if there is an error, we’ll have some default error text to put in the DIV (better to give user feedback that the sub-post does not resolve, than it is to click on something and not have anything happen)
- in either case, update the DIV
- the user can drag the DIV around. There may be links within the sub-post They would do the usual thing. The only thing to bring up at this point is that some of those links may be to other sub-posts. The takeaway from that is to always be aware of who the one true “sub-post parent” is, and not to accidentally try to write one that is nested.
- the diagram shows “D&D”. A thought for the future would be to enable some sort of drop targets for sub-posts (think of image sub-posts ….)
- there will be some mechanism for closing the sub-post (or hiding)
Sub-Post Administration
In the “Manage” tab, there would be a sub-section for managing each sub-post. The actions should be “Add New”, “Edit”, “View”, and “Delete”.
