The button generators are in a good state. They work! Their potential hasn’t been explored yet and won’t be until people start compositing Fireworks output with TTF text on the fly. However, a useful addition would be to size the TTF text first and create taller, multi-line buttons automatically. This can be done easily in PHP/GD with imageTTFBBox(), which returns the size of a text phrase. The tricky bit is working out where to insert the newlines. Maybe a best guess based on multiplication of the pixel width of a nice-sized character (perhaps n) followed by refinements. It should only need one refinement as the words must be split at the spaces.

That he never visits any of the pages except the front one. Thus we could say the features outside that main page are not useful or not known of. That happened to Chon who wanted the archive but couldn’t see the button for the pixels. One useful addition in this vein would be more buttons actually on the portlets. A delete button to match the edit on messages for logged in users would provide greater immediacy. Something similar to the …bizniss portlet can provide shortcuts to most used profile options (theme), serialising messages is the lazy man’s archive. Many of the improvements to Hype that I’ve talked about are aimed at more potent techniques for users to organise information, things like proper threads and replies and comments allow people to naturally group stuff together (and get’s round the bolding names for replies bizniss.

As well as having section pages, like exactly those that the forum lacks, each function set could be corralled into a portlet, to provide the same access from the front page and to grab advertising space on that page. Bingo!

Hey, people use the mail page though. That could do with some improvement, attachments would be cool.

Hypothetical 0.2 will have features 0.1 could never dream of. The only way for this not to be a hack will be to create a new database and copy the data in. This will also alleviate the temptation to go messing around with live data.

Yesterday wasn’t going so good, but today? Leaps and bounds, my friends.

I now have the three main theme functions, h_page, h_portlet and h_frame running. Frame reads a file which, on the surface, looks like any old normal .php file. However, because the string from using the portlet file has to be passed up the function chain I had to hack it so that the file is read into a variable and then anything looking like PHP is found and executed (eval’d) in place. This means that everything behaves just like the files were being run in place, but the results can be messed around with later on. This is something that I scratched my brain about whilst working on The Forum at Soup and a solution that I’m really happy with :-) :-) :-)! The only flaw is that if you use print or echo they produce text at the top of the page rather than in context. Oh well, just no printing or echoing. If you use <?= ?> instead h_frame picks up on that and inserts the text properly.

I put some code in a file!

Hopefully there will be more later, but for now, here is a list of some code conventions I’m hoping to uphold:

• Names: blah_blah_blahblah. Functions, variables, files, the lot. Additionally functions should be prefixed h_
• All include files go in /lib
• Everything’s part of the session, all the pages. If the userid isn’t there then nothing will work. Oh well, I’m not going to support people who turn off cookies. On the WAP side, I’ll use the PHP SID where it’s needed.
• Definitely gonna go with a page on each site of the transaction. I can’t work out this whole one page does all thing.
• Having all the content in the database is an interesting idea. Have all the content bits as just another kind of portlet.
• MySQL results have result_ prefix and fetch_array’s have arr_ to remind me to use fetch_array and not fetch_row. No fetch_row’ing in h2

Anyway, back to the work…

There’s that little reloader issue. Can javascript check the server? Is it possible to say something like blah = contentsOfURL(“hypothetical.co.uk”)? If not then the problem could be solved using a frame of some sort or other (document.frames.monkeyframe.href = “hype”; if (updateTime(monkeyframe) > oldUpdateTime) reloadmainframe();).

The other one is to get down to tuning autolinks a bit. Possibly, as Chon suggests by mangling the number of clicks a link is given depending on the link age, i.e. a click on a decrepit link means big points. This has the advantage that the sorting can still be done by MySQL. The title lookup system still needs finishing as well. See Hype for another notes along these lines.

DrawFrame just draws the box, drawPortlet is responsible for generating content. That way all the content items that are part of a given site are reuseable. Portlets that just content static HTML may as well call drawFrame inline, depending e.g. nav html would be reuseable. In Hypothetical though, portlets would be going off all the place, especially with portlet groups, such as a bunch of messages. A call to drawPortlet(PT_MESSAGES) would yield the central column of Hypothetical’s home page, whereas drawPortlet(PT_MESSAGELIST) would draw the archive page main content, or some search results, depending, conceivably, on a passed SQL query.

More on WTC “incident” later…

Everything2 style graph. Ability to add nodes and edges. Should technically be called Textgraph but Textmap is snappier, hehe.

nodes:	id, name, body, author, date
edges:	id, key, node

Nodes are the content, edges are the links. Edges automatically detected and inserted into nodes on display.

Difference from everything2 is that there is more than one graph. The point is not to try and link everything together in one mass-mess, but to create interactive text things easily. Example: interactive stories would use highly specific edges (could edge key be a regex? Here is a use for the Data Munging Eugenics system (which needs a recursive acronym). The edges in a documentation textmap would be much more vague.

On reflection, this is just a simplified web, like the www, so I guess it’s of limited use.