I almost hesitate to post this, because I don't want to get anyone too excited, but I've been working through some design documents and trying to get a handle on what needs to be done and the best way to do it.

When the website first goes up, of course, it won't immediately have edit access, because I'm focusing on displaying what we already have first. Expanding the website can't happen until we have user login capability and some kind of permissions system. Which lead me to think about permissions and the user hierarchy.

I'm thinking of the descriptions of user access levels in terms of band terminology, just because I think it's more fun that way. The titles would mainly show up in the new forums, the way some BBSes have different titles for how active you have been on the forum. Here are the band-appropriate titles for the user access levels:

FAN: someone who doesn't login or doesn't have a login. Fans can't edit pages. They can rate songs/albums and can post comments, but have to do some kind of Captcha verification for each post.

ROADIE: basic login access. Creating a roadie account requires a one-time Captcha or other verification process to guarantee there's a human involved; there might be other restrictions, or maybe not. Roadies can create or edit pages and do other stuff.

BAND MEMBERS: there are actually three or more different band member titles, but they are all treated the same. The band member titles are LYRICIST, MUSICIAN, VIDEOGRAPHER (or whatever we want to call that,) and maybe ART DESIGNER (for people who make album covers or posters) and PHOTOGRAPHER (if we can convince people to photoshop fake concert photos.) Band members get one additional ability roadies don't have: they approve new band members. I figure the way to do this is let anyone create new lyrics or album concepts, or link videos or mp3s, and so on, then if a band member gives them a rating, they're automatically given the appropriate title.

You can have more than one band member title; it just appears as lyricist/musician or whatever. Heck, we can have another title, DJ for anyone who links a podcast they distribute that gets rated.

MANAGER: Band managers are anyone with the power to delete other people's comments, usually for a specific page or forum. Basically, moderators. Moderators are needed, but yeah, moderators have to be dicks, sometimes, so "manager" fits.

If we need to temporarily deny someone edit access, there could be an RIAA access level.

So, question is: does this seem to be a reasonable assessment of abilities we need to assign? Does the promotion system for roadies becoming band members seem fair? Should there be a specific rating cut-off, like only 2-star lyrics or mp3s get you into the band? Is there anything missing?

Seems like you have a pretty good spectrum of user levels.

A general system that we implemented for a system at work, (which so far has been very effective), is as such:

There are users.
There are groups (which list a set of users).
There are permissions.
Permissions can be assigned to either users or groups.

Pages look at the permission to determine whether or not to allow a behavior. By knowing the user, you can derive whether or not they have the permission, and if so they get to do or see something otherwise not. It makes it easy from a page point of view since it just passes in the current user and permission(s) and gets a boolean response back for whether or not the action is allowed.

The check for a permission just does a two level check, first for direct permission, and then for membership in any of the groups that have that permission assigned.

This can be done using only permissions and users but that is much more difficult to manage since it is easier to manage the permissions at a group level.

The check function on the page could allow either ALL or ANY lists of permissions. ALL would require membership in whatever groups satisfy ALL permissions listed. ANY would require membership to satisfy ANY one permission of the list.

You can do one to one mapping of groups to permission or one to many, whatever works best in the circumstances.

Hmm. Thinking about how to implement that... for users, we can internally have user-access levels expressed as a number from 0 to 99, with 0 meaning "same access as Not Logged In". I'm not seeing a whole lot of gradations for specific abilities, but if we add a new ability, I'd rather change it once somewhere by saying which user access levels get the ability, instead of changing every individual user.

That implements the user permissions, as you describe. For groups, each group has a file that lists the members. There may also be a group permissions file, but for now, I don't see that it will be necessary, since I see groups as mainly controlling bonus permissions for specific pages or areas of the website. That can be implimented in the flavor templates and the meta tags on each page; the template has some kind of test that checks the "meta-group-mod" variable, for example, which is already handled by Blosxom with the meta plugin. If meta-group-mod lists a group that the current user belongs to, that user gets mod abilities, even if not a sitewide moderator.

So, the "band member" level I listed above is not actually an access level, but a group. The ratings action checks to see if the rater is in group "band members". If so, it adds the person rated to the "band member" group and updates the title as necessary. Possibly, there's a check of the rating to see if it meets a certain threshold.

When using tables we have the following relationships (I am assuming that this could be done with and xml file as well).

Assuming username and groupname (or associated ids) are unique across both sets:

User
==========
id
name
...

Group
========
id
name

User_group_member
================
User_id
group_id

Priviledge
============
id
name

privilege_assign
==============
user_or_group_id
priv_id

So let's say there is a page that allows band members to enlist other members:

There would be a privilege named: "band_member_enlist"
there would be a group: "band_members"

the page passes the user and "band_member_enlist" to a validate function which checks two things:
First if there is a pair for user_id and the member_enlist priv,
if not then it checks for which groups are assigned that priv,
and then tests the user_id for membership in those groups. If yes the function returns true otherwise false. The page can use the result of the function to enable or disable things on the page.

So all the functionality you described works in this system. Except for the rating, however that could an additional paramter to the validate function which could look up the rating for the user depending on where it makes sense to find it and do the comparison. The complicated part is if there are different ratings for different things and then you have to resolve that lookup. I would say doing the rating part should be a version 2 deal.

Ratings aren't actually that hard. In fact, they're easier than the user login part, so they'll be coming first. Here's the approximate roadmap:

Version 1 just displays existing documents and is basically just Blosxom + a plugin I need to write to add links. Also during this stage, I need to do the final conversions for the existing pages; I haven't done this yet because I need to know how I'm going to split up the information. That's why I'm writing the latest design doc.

Version 2 adds support for auxiliary documents so that we can add some dynamic content, like adding a link to a new MP3 on the song page without needing to directly edit the song page. Reading a rating technically falls under this category: it's just a matter of looking up a canonical name and getting the number associated with it. But ratings won't be added in v2 because there won't be any ratings until we add actions.

Version 3 is the first of the actions. Every action that changes data will be handled by individual CGI pages, like rating.cgi, search.cgi, and so on. There will be a newpage.cgi and editpage.cgi at this stage, which won't directly change the rest of the website yet, but will instead create or edit copies which an admin can manually approve. And of course, there will be an admin.cgi page for exactly that, since all admin actions need to be tested before we allow any other live editing.

Once admin features, particularly "approve page" and "delete page" and "ban IP", are working, we can move on to Version 4, which is when comments are added (because comments don't require login) and when we can open the site up to some of the existing band members. This will give us a chance to test the comments feature and get corrections to pages using the temporary editpage.cgi.

Version 5 is where we actually add user login ability and thus the ability to create/edit pages for real, promote roadies to band member status, and all the other good stuff. Once user logins are working, we can add additional features. Sometime after v5 is when we can go live for the general public.

Here's an important question, because I want to see if I understand something: most AJAX stuff uses POST, right? Or can be written so that it only sends a request as POST? And opening a standard URL by typing it in or clicking a link is always GET?

I need to make sure stuff like createpage.cgi knows whether it's being called by AJAX or directly.

It kind of depends on the what you are using to do the AJAX. The low level HTTPRequest objects typically allow either GET or POST to be specified. The YUI (Yahoo User Interface) framework also allows GET or POST as does Scriptaculous, etc. The Ext framework I think is primarily POST, which I think is for the best.

I don't know PERL that well, but typically in most Request objects that are passed to the server script there are properties that include the method (POST or GET) so it should be easy to tell what type if request it was.

I have been using the Ext 2.0 for work lately and I have to say it is amazing, both graphically and from a document content management perspective. I have a much better idea of the kind of things we can do from simple to complex.

Yeah, I know about the request method parameter... but the problem is knowing whether a script was called in an AJAX environment (and should send back truncated information) or not. If the user clicks on something to open an AJAX edit box, then the CGI should return just the results of the operation. If someone goes directly to createpage.cgi (because they don't have javascript enabled, for example,) then the CGI needs to display sidebars and the like, to make it look like a uniform website.

Which, as I think about it, I realize the only good way to guarantee the correct response is to have the caller set a variable saying "I AM NOT AJAX".

I would agree with that. Either a variable that says I am AJAX or vice versa. Depends on what you want as default behavior. I would assume that most people allow Javascript these days since AJAX is becoming so prevalent and needed for most sites functionality.

>>7

I notice that Ext 2.0 can interface with Prototype, which is the JavaScript AJAX framework that looked like something I could handle a bit. I do have some concerns about the look, though... all the examples I've seen of YUI/Ext kind of look the same, and not quite what I was hoping. I suppose it's pretty customizable through CSS? Can we round the corners with little PNG overlays or something?

I suppose the look isn't too bad if it's restricted to the actual pop-up elements. The main thing I don't like are the menus and tree panes, like on the doc site:

http://extjs.com/deploy/dev/docs/

There's also a page load delay that kind of annoys me. However, I think if the main page is done without any content loaded by AJAX, and instead additional content is loaded by clicking controls, the load time will be much quicker. For example, on a page for song/COMAR, the liner notes would load, and a context menu on a control would let you create additional tabs and load additional content (lyrics, artists) without changing pages, or jump directly to the lyrics or artists page as a stand-alone page (at lyrics/COMAR and artists/COMAR, respectively.)

I'm also thinking that it's better to avoid too many tabs in the main content area, so we might only want to display the main content and one side-panel to the right with 1-2 tabs visible when open and scrolling tabs if there are more than 2 tabs. This allows you to look at the main content and the comments simultaneously, too.

One thing I may have figured out: if all the AJAX JavaScript component needs is an XML response in a pre-determined format, I may not need to write any Perl at all for components that just load and display content. Blosxom has these things called "flavors", which are templates. You can write an XML flavor and just have the XMLHttpRequest call the url as lyrics/COMAR.xml ... Blosxom would automatically open lyrics/COMAR.txt and interpolate it into head.xml, story.xml, and foot.xml. In fact, that's how it handles RSS feeds already.

This would have to be tested, of course, but it sounds doable.

Prototype basically does two things: It provides a wrapper around the low level AJAX calls, and it provides enhanced functions to access the elements in a page that is in the browser. The main addition is the ability to manage class names of elements, add, remove, and select elements that have a class name. So class names in addition to applying CCS properties to element, can also be used to group elements for the purpose of selection.

A number of the frameworks do this same thing. Ext actually provides the same functionality inherently and has one of the faster selection functions as well as providing very flexible AJAX calls. (For example you can load data to a single element in a document with a simple load function). Through Ext adapter system it allows you to use which ever framework you want, however I think that was mainly so that people who already had an investment in a framework would not have to lose any time converting. If it is a new project then it makes sense to use the Ext base since you don't have to include more than one framework in your project.

In terms of look and feel, it is actually very flexible. Any component that you create can have a CCS style assigned to it to redefine its look at feel. The actually provide an example of how to re-skin the components.

In terms of load time there is a bit of overhead for the javascript but once things are in place it is pretty good, and the ability to load things on demand is very nice. I also think we can keep things as simple as we want. We do not have to have tons of tabs or even panels if we don't want them.

(Actually once you start to use the Document, it works pretty well for that purpose).

The layout part is nice because we can define different regions and dynamically load them as needed. If the Bloxsom can pre-transform the content into HTML that will work very nicely.

Let me know if you would like me to create a new starting page structure and I can put it up in the ibc.spaceroom.org area for preview and then pass the code to you. The coding make sense once you figure it out but the initial learning curve is bit high.

Maybe just a three panel?:

| W | Center | E |

If this forum or email is difficult let me know and I can hit the MOO or GMail Chat.

I played around with a couple of different layouts using Ext and it is pretty much able to do any kind of arrangement you might want. Even if you only want just one area, we could do collapsible panels that can open and close in a single vertically scrollable area. (Not my personal preference, just an example).

I am kind of mixed about the best layout. Much depends on how we want it to work. Are we trying to pack information into one page context or do we want to visually navigate to different information? The visual behavior can be separate from the actual page navigation by selective replacement of the page content so it is a matter of defining what would work best.

I started with the three vertical column layout but it seems that the left side as a nav bar was space that was not very well used and that horizontal space was something we wanted to use effectively.

So that led to north, center, and east layouts A and B

 (A)                (B)

-------------- ------------| |
T T | |
-------------- ------------| |

      |  |                 |  |

C | E| or C | E|

      |  |                 |  |

-------------- ------------| |

C is the main viewing panel and has internal scrolling. E has a scrolling set of tabs for detail information about what is in the C panel. The T panel has room for menus and other links. The E panel is resizable using a splitter between C and E.

Option (A) leaves more room for global functions in the T panel and E can be resized without affecting the top area.

(B) leaves more room for detail content vertically but tends to interfere with the top panel layout when resized. Also visually it implies E's content is global and the T and C are more closely linked.

Other variations could be making E on the left instead of the right, and moving T to the bottom.

Are there other better layouts? Unless we want to remove one of panels then the model will only be more complicated and less space available for any particular region.

I'm not sure if you're talking about just the content area, or the entire page layout. Here's my mental image of the entire page, labeled in my own eccentric way:

----------------
       H
----------------
 L  |     |
----|  I  |  T
    |     |
 S  |-----------  
    |
    |     C
    |
----------------

H is the headline or page title. It's just plain text and fairly simple, no features up there at all... and we might sacrifice it for more vertical real estate.

On the left is a sidebar, S. The top element is the logo, L. The container for both L and S is invisible and provides some padding. The panels or boxes inside S are filled at pageload, by Blosxom, since there's no need to make them dynamic; they are mostly site navigation. A few of the panels are "mildly dynamic", by which I mean content that changes, but there's no need to reload via JavaScript because it's not going to change that much. Stuff like the five most recent pages added. Blosxom does this already via the hotlists plugin. The only truly dynamic features (AJAX-enabled) are things like login, user preferences, and admin commands, which would be accessible immediately below the logo.

To the right is the Content area, C. For pages that aren't artists, albums, or media, it's just a standard text area. For example, if you use an URL like blosxom.cgi/song/2007/ or some other date, Blosxom will list all song pages made in 2007. There would be no need for an album image at the top of this page, or some of the other features we've been talking about for media pages.

Pages for individual songs, albums, artists, and other media have two additional areas above the content area: the Image or Icon, I, and the Title, T. T will just contain the individual page title, the rating for that page, and the tags, plus maybe an easy-to-find download icon with a JavaScript function to open an overlay list of file links.

What I was talking about as far as tabs is specifically the C section on media pages. I'm envisioning something like this at the top left of the C section:

-------------------
| V | About   | > |
-------------------

The "V" here is an icon with a downward triangle, to suggest clicking it would drop down a context menu, which is exactly what this would do. The menu would have page-specific functions, like Edit. The right-angle bracket represents another icon; clicking it opens an overlay area for additional content that covers up the right-hand side of the C section, leaving part of the C section visible on the left. The overlay has another context menu icon and a set of tabs across the top. This is where you would view links, comments, track listings, and additional content. The overlay content would be loaded dynamically via AJAX; the context menu for the overlay would include an Edit command to edit that page and a Jump To command to go to the actual URL for that tab (lyrics/COMAR to view just the COMAR lyrics, comments/COMAR to view the comments about COMAR.)

So in summary: when the user first goes to a page, there's little to no dynamic content loading, but there are clickable buttons/areas that will load content via AJAX.

Let me see if I can upload these icons I just whipped up, too.

Assuming this loads, this is the download icon.

Well, what do you know. That worked. However, the black area should be transparent. Hmmm.

This is the context menu icon.

This is the Open Tabs icon.

The black area seems to be a bug in kareha ... I opened Safari (!) and dragged one of those to my desktop. It is not identical to the PNG I uploaded. So somehow, it gets transformed in transit.

My picture was for the entire page.

Check out this:
http://ibc.spaceroom.org

It is not fully functional yet. You can expand the overlay section by clicking on the << icon on the right side.
The menu buttons can have icons associated with them as well.

I think it is pretty close to the layout you suggested.

Yeah, pretty much, although I don't like scrolling frames. Also, the CSS in the final layout would have to be tweaked to get rid of the white... It needs to be the same color as the top part. It would be about 3 or 4 times wider, too.

Redesigned the buttons to be more toon-like and distinct.

This first cut is using a viewport and border layout which gives auto fit to the window and the north, south, east, west and central options. However because it is a viewport if there is more content in the central area it will need to be scrollable otherwise it will clip.

However we are not limited to that layout. It is possible to more absolute positioned elements, but then it is quite a bit more work to get things to size appropriately to all resolutions, since we would have to do the coding to set the sizes of things.

I don't really see the problem with a scrollable region, but that is me.

I just hate having more than one scrollbar, because then you have to switch focus all the time.

Did more work on the buttons. Here's a pic of them on the same color background you are using for the menus. Columns alternate between normal and mouseover (lit) versions, with the right-hand side being the "open" state and the left-hand side being the "closed" state for the context menu, tab overlay, and download buttons.

It is interesting how when I mouseover the image it shows as a png file, but when I click on save image it asks to save as a jpg file. (Using Firefox). Perhaps you could email the image to me?
That would make sure I get the best version.

>>18
Check out the site again.
I set the background colors of the panels to the IBC blue color and removed the panel borders. I started playing with using the icon for the button. There is still more work to do to get it to change image when selected but we can at least see something.

>>22

Odd. I'll email you the individual buttons instead of that "allbuttons" image, which is just to circumvent a restriction on uploads here.

I may be changing the highlight version, though. I've already changed the download button to make the arrow green, to distinguish it from the context menu button more. And, since the download button is supposed to open the tabs overlay and select the download tab, I'm dropping the "download open" versions.

>>23

"About" shouldn't be a button. It's just supposed to be text, a label for that section, to distinguish it from the tabs in the overlay. Looks good, though!

I got the images and moved them up to the site.
I have the context and tab main images. I am still working through the CSS to get the mouseover to show the lit versions. (For the moment it is still showing the Ext defaults).

My only concern is that these buttons are pretty large. I like the images but perhaps something around 50px?

I wanted them to be fairly distinguishable. I'll try them at 50px, but I think the download button will have to be redesigned at that resolution.

Hmmm... "About" seems to have moved from between the buttons. It should be separating the buttons, so that there's a distinction between the button that affects the current content and the button that displays additional content. Sort of like how you wouldn't want your exit without saving button right next to your save button, although that's a more extreme case. If we're moving "About" out from between the two buttons, it's best to not use it at all, since its only purpose is to make the page easier for people to use.

It is kind of odd from a UI design to have text between buttons. If separation is the main issue I can do spacers, or there is a way to have the second button align to the other side of the toolbar. The title bar above the toolbar can be something more descriptive, or we can get rid of it. If you really want text between the buttons I can still do it.

I made an update using the toolbar option which moves the second button to the other side. Does this work?

Is there some content stuff we could play with? The visuals are pretty and all but I would like to see how to load the content.

One thing mentioned in >>13 is that blosxom.cgi would generate the main wrapper. With the framework, it would make more sense, since the Javascript is doing this already, to just generated the content area below the buttons. Basically using a simple load function I can populate the main content area with HTML returned from the cgi functions.

I'm not sure what's odd about text between buttons, but it can be removed if necessary. The important thing is: the context menu button for each section should be clearly visually associated with the section it affects, and the button to display tabs should be closer to where the tabs are going to appear.

We may still have some different ideas about how the page is going to look visually. I tried doing a more detailed ASCII version below:

|-----------------page--width------------------|
|            WEBSITE TITLE HERE                |
|----------------------------------------------|
|     |               |                        |
|  L  |               |                        |
|     |               |                        |
|-----|     Image     |     Title              |
|     |               |                        |
|  S  |               |                        |
|  I  |               |                        |
|  D  |----------------------------------------|
|  E  | V | About   | > |                      |
|  B  |-----------------|                      |
|  A  |                                        |
|  R  | Stuff is written down here.            |
|     | It fills up as much of the window      |
|     | as is necessary (only one scrollbar)   |
|     |                                        |
|----------------------------------------------|

Here is a close-up of what happens in the content area when you click the context menu button:

|----------------------------------------|
| V | About   | > |                      |
|-------------|----                      | 
| Context     |                          | 
| Menu        |ten down here.            | 
| Drops Down  |s much of the window      |
|-------------|ry (only one scrollbar)   |
|                                        |
-----------------------------------------|

Here is another close-up of what happens to the content area when you click the tab expand button. Note that the tabs (and the context menu button for the tab area) slide out of the right end of what we should probably call the "content control bar". The tab bar does not literally have to be animated as sliding out -- it could just pop into existence, or fade in, or whatever -- but it should be aligned. The user should know where to look for controls.

|----------------------------------------|
| V | About   | > | V | tab 1 | tab 2 |  |
|-----------------|-----------|-------\--|
|                 |                      |
| Stuff is written|   Tab contents in    |
| It fills up as m|   overlay on right   |
| as is necessary |                      |
|                 |                      |
-----------------------------------------|

The overlay menu button looks identical to the context menu button for the main page, so that the user learns to identify the symbol of a downward-pointing triangle with the action "open a menu so I can do stuff". The location of the second button serves as a visual cue that it affects the overlay area instead of the main area. Likewise, the position of the tab expand button acts as a visual cue that something is going to happen that far across, while the right-pointing triangle on the button shows where the tabs are going to appear.

Now, in this context, the section title "About" is technically unnecessary, it's just providing more visual cues, separating the two buttons on the content control bar and suggesting what is happening below the bar. It can be removed, as long as there's some distance between the two buttons, and the location of the right-hand button suggests where stuff is going to happen. In that case, though, it might be better if the (blank) middle portion of the control bar is a different background color than the background for the buttons, to act as a further visual cue.

Some additional notes:

There will be a different flavor available for those who can't or won't use JavaScript. I'm thinking of calling it "1993". There will still be a control bar in the same position as the JavaScript control bar, except that instead of buttons, there will be a set of links:

(edit page)  (add comment) [ ... ] (more pages)

The "more pages" link jumps to an anchor near the bottom of the page, where there's a list of links to associated pages:

jump to Lyrics
jump to Artists
jump to Comments

The downloads, if present on a page, would appear before the "more pages" section, but after the main content. Near the top of the page, in place of the Download button, would be a link to an anchor to the download section.

All of this, as I said, is handled by a separate flavor template. People can go to blosxom.cgi/song/COMAR.1993 to get the non-JavaScript version, or log in and set their default flavor to 1993.

You mention something about having the framework generate the wrapper, but I think you can see why that's not going to work. The template for the main flavor will have the links to the JavaScript in it, versus the 1993 flavor, which doesn't have the JavaScript. We don't want the JS framework loading the content, because that adds an unnecessary step. Just load the main page, including the JavaScript functionality to provide additional content without navigating away from the page.

I'm currently still working on the necessary plug-ins to provide needed functionality, but I'll see if I can translate a couple pages for a minimal version of the website and upload it tonight.

Here's a very small test version of the website.

http://interrobangcartel.com/blosxom.cgi

None of the formatting is ready yet, obviously, but it's getting close. I only did a couple pages because I had to prep them all by hand; until I have the plug-ins written, I can't write any mass conversion scripts.

One thing I discovered today is that Markdown is just too damn slow for on-the-fly conversions (about five times the speed of the test site) The files currently have actual HTML embedded in them. When we're ready to test editing, the editing script will translate the HTML to Markdown, let the user edit, then convert to HTML via Markdown. That restricts Markdown to running once per page instead of every time we load the page.

If you want to see an example of a flavor in action, try this URL:

http://interrobangcartel.com/blosxom.cgi/index.rss

You can also try this:

http://interrobangcartel.com/blosxom.cgi/2008

That's the date filter, which doesn't work because everything was uploaded today. But it gives you an idea of what it can do.

Oh, and if you want to see the raw data files, they are here:

http://interrobangcartel.com/test/

>>29

I don't there is a question so much about the basic layout and look, I think it is more a question of implementation.
( BTW: http://ibc.spaceroom.org has been updated to look more like your latest picture.)

The thing is that in the layouts you have, there are a lot of dynamic behaviors. (Button events, region sizing, tab construction, menus). The framework can provide those behaviors but it requires a bit different approach to how to construct the display and populate the different regions.

I guess I am a bit confused about the role of blosxom. Do you want it to produce the entire page, or do you want it to produce the content for the page. Both ways are possible. There are pros and cons for both approaches. By putting more layout responsibility on Blosxom it requires an integration of the Javascript with the elements in the page produced by Blosxom. If the framework handles the layout and menuing, then only pure content needs to be retreived and displayed in the appropriate regions, but it requires various functions to get specific kinds of content. My preference in this direction comes from the idea of separating content from functionality (though functionality can be controlled by content).

If you want to pursue the more Blosxom oriented view then we will have to define the content to include <div> and other tags with both specific id and class name attributes to allow the javascript to attach the right functionality.

We can get the same behavior but the amount and kind of work could be very different.

Definitely, Blosxom needs to produce the entire page. The way I see it, we have two kinds of content: the main content to which an URL points, and the "value-added" content that is associated with that content. If you go to:

http://interrobangcartel.com/blosxom.cgi/lyrics/Chalice_Of_Fire.html

... you get the lyrics to Chalice Of Fire. If you go to:

http://interrobangcartel.com/blosxom.cgi/song/Chalice_Of_Fire.html

... you get the Chalice of Fire song page, which, when the website is more complete, will include either a link to the lyrics or a tab that fills with the lyrics. The content in the lyrics tab is the "value-added" content; it doesn't have to load or display when the page loads. It can wait to load when JavaScript loads it, which might only be when the tabs are visible and the lyrics tab is selected. Select a different tab, different "value-added" content loads. This doesn't affect the main content, nor does it affect the sidebar, which for the most part is static (doesn't change after the main page loads.) There can be dynamic components in the sidebar, like the login box, but the sidebar itself isn't dynamic and doesn't need to be.

Now, we can use just the CSS part of Ext for any static component. That's fine: head.html loads Ext and any additional JavaScript as well as any stylesheets needed, and Blosxom already marks some things with div tags and classes/ids, so it's not a big deal to embed an Ext container anywhere we want. The problem comes from trying to load the main content dynamically into a container. First, you've got two different modes:

# if you go to a permalink (like blosxom.cgi/welcome.html) you get exactly one story;
#if you go to a category (directory), Blosxom generates an index of recent stories in that category.

These are two different kinds of displays, one with the image box and info box (like for a song or album,) one without. That means Ext containers for those components have to be conditionally included, instead of always visible.

Second, Blosxom's story.html template looks sort of like this:

<h2>$title</h2>
$body

The variables are interpolated. Title contains the first line of the source file, $body contains everything after the first blank line. The $meta namespace contains any meta-tags that occur after the title but before the body. Now, you can change this to:

<div class="SomeExtTitleClass">
  $title
</div>
<div class="SomeExtContentClass">
  $body
</div>

... or you can even add OnClick or OnMouseOver JS handlers to the divs, or all sorts of things, right in the template. But you're going to have problems letting Ext do all of the layout, because how is it going to get $body?

Getting content to load is not as difficult as you might think with Ext, there are a number of ways to achieve the same goal. I think all of the things you describe can be done using a single container page. I could describe the whole mechanism but at this point arguing about methods seems a unproductive. So lets look at how to integrate this stuff into the blosxom approach.

So one of the key functions that is very useful is the Ext.onReady event handler. This is how we will attach the event handlers to the specific components. We can do tests for which things exist and which do not (for example image and title divs) and then connect the appropriate handlers to them. The code can be included using a <script> tag. It may be useful to have a couple of flavors of initialization code depending on the page type since that will reduce code that is not needed. If there is common code we can put it in files that are included before the init.