An ASPAjaxWikiBlog Thingy

OK, using TW as a UI for TagMe has proved to be a dead herring, or was that a red end?

Basically I would have to remodel TagMe’s data er… model to match that of TW which I don’t like. I also would start having lots of duplicate code - if TW then… - so I’ve decided to create a simple (don’t they all start "simple"…?) database for saving tiddlers and using XMLHttp to load and save tiddlers to an SQL database.

When "done" is clicked the system saves the tiddler to the database - the direct wikitext and a rendered (wikified) copy is saved for some good reason I forgot.

So far it’s peachy but I still have to get the hang of the encoding scheme TW is using (unescapeLineBreaks)…

It may be necessary to save both the rendered (wikified) and unrendered text when saving a tiddler. The reason is that some tiddlers use plugins but contain no content in their unrendered form. In their rendered form however, they have juicy text and links which:

1. The TagMe search will miss
2. Cannot be displayed without the TW engine

If we save the rendered text we will be able to do something that TW can’t currently do namely, searching the effective contents (rendered text).

Possible Issues

OK, saving a single tiddler to TagMe was relatively trivial. Hijacking the TiddlyWiki.prototype.saveTiddler() function and adding the following at the end.

var TiddlerObj = {subject:tiddler.title, body:tiddler.text, wikiword:tiddler.title, id:title, tags:tiddler.tags}
ajax.PostObject("tagme.asp", TiddlerObj, "POST", "action=save")

The action "save" is a new action in tagme.asp which basically inserts or updates depending on the existance of the tiddler. It also obtains the id from the wikiword in the parameter id.

ajax.PostObject is also a new function which simply serializes a simple object as a series of parameters basically resulting in the following post data:
subject=MyTiddler&body=Hello+World&wikiword=MyTiddler&id=MyOldTiddlerTitle&tags=Tag1,Tag+2

Actually in order to get the comma seperated tags we must pass the following as the tags attribute of TiddlerObj:

tags:tiddler.tags.join(’,').replace(/[\[\]]/, "") 

This ensures the TW-style tags (Tag1 [[Tag 2]]) get converted to our CSV Tags.

I use TiddlyWiki daily because it’s the leanest, meanest, simplest, most intelligent personal data management system I’ve ever seen.

It’s only drawbacks are the lack of scalability and the lack of content/code seperation. This means, if you have 7 wiki files for managing 7 projects you have to update them all when a TW upgrade is available. This is especially difficult if you’ve customized the code yourself and not always using hijacking plugins (naughty).

Regarding scalability, there’s only so much you can do with an HTML file where all data is loaded into memory at once. Sometime in the future you will have a performance problem.

I propose to hijack 3 aspects of TiddlyWiki and move all tiddler data to the server’s database.

1. SaveToDiv() -> Don’t save to HTML, post entry/entries to server
2. LoadFromDiv() -> Likewise, load all tiddlers (except their main body text) from the server into memory.
3. Access to the tiddler’s body (not cached in memory)

In this way, memory is saved by only loading a tiddlers body (80-90% of the data size) when it is needed.

OK, please download the first release (v.1.4.1) from HyperUpload. I would appreciate any feedback.

System Requirements: 

1. ASP Web Server (tested in IIS on WinXP)
2. SQL Server (tested on Microsoft SQL Server 2000 on WinXP)

What’s a Blog without comments? With this in mind I’ve created the [data] table as a generic storage for everything. The view [post] will return all classic posts (data_type=’p'), while a planned view [comments] will return all comments (data_type=’c').

The advantage of this is that the search function only has to look in 1 table. We could even add further data types for attachments (’a') and images (’i') later and still have them taggable and searchable.

Any AJAX Application, which does not reload the page will cause grief to the poor user who clicks their back button:

1. They expect the last state to appear
2. They won’t even be on the current page anymore

The workaround for this is to use several very clever tricks (1 for each browser) to provide a history path. The main aspects are:

1. Using a hidden IFrame to "fool2 the browser into generating a history
2. Saving state in the page’s hash (#) or fragment anchor
3. Reading the state from the hash and updating accordingly

It’s all rather complicated under the hood but luckily there’s such a thing as the Really Simple History which hides the complexity and provides all you need for most cool browsers.

You still need to call it’s dhtmlHistory.add() method each time your app changes state and remember to add your own listener for catching history changes by the user -> dhtmlHistory.addListener(myFunc).

Um, it’s like a cool web application I made (codename TagMe) which tries to offer the functionality of a Blog and a Wiki of course using all the latest technology buzzwords:

• AJAX
• Wiki
• Blog
• Tagging
• erm ASP?

It’s work in progress and I want people to download it, use it and provide feedback.

The system runs on any ASP-capable server (like IIS) and uses Microsoft SQL Server as a database. I’m sure it would work with MS Access too.

The database is nothing fancy and consists of 2 tables (data and tag).

The ASP side is also simple and consists of 3 pages:

1. admin.asp -  The page for authors to edit their wiki/blog posts
2. index.asp - The page for visitors to view the wiki/blog posts
3. tagme.asp - The server side proxy for putting the "X" in AJAX

The client side functionality is in 4 scripts:

1. tagme.js - The main functionality of managing and viewing posts
2. ajax.jsl - Handles the communication with the server (tagme.asp)
3. dhtml.js - Some basic DHTML functions
4. dhtmlHistory.js - A cool library (aka. TSH) for managing back button behaviour in AJAX apps