Jonathan Anderson's Web page

Hitop bits and pieces

This is a makeshift page put up to cover various Hitop bits and pieces I have found out that you'll find useful. It is being thrown up in literally 5 minutes as I have better things to do than this. So forgive the look and the lack of navigation out of here.

Database connections

For connecting to a database you need to use the following tags:

<@HITOP>
See the page on Hitop.org about this. Use the LIBS attribute to point to your Hitop plugins if they are not in a system directory, but in a user directory.
<@REQUIRES>
See the page on Hitop.org about this. You'll need to specify both the database plugin 'db' and the appropriate database driver plugin ('pgsql' for Postgres).
<@CONNECT>
Attributes to use here:
  • USING - set the name of your database driver plugin.
  • HANDLE - set the name of the handle you want to use.
  • USER - your username on the database (usually the same as your system username).
  • PASSWORD - if you need this, set it. It won't appear in error messages. If your server uses something like remote authentication to work out which user you are then you won't need it.
  • DATABASE - set the name of your database here.
  • PORT - pretty obvious. If connecting to a remote server specify the port to connect on. Postgres users will usually want 5432.
  • SERVER - specify the host name of the remote server. If using Unix sockets specify the directory containing the sockets here. This method can help get around unreliable identd problems. Do specify your port number if doing this.
<@QUERY>
Attributes to use here are:
  • HANDLE - the handle you used in <@CONNECT>.
  • ENTRY - the procedure called for each row retrieved. The names of the columns are used as names of parameters to pass to this procedure.
  • SQLQUERY - your query. (thought you'd never get here, eh?)
  • DISCARD - this discards the output of your query, useful for doing SQL update queries.
  • ASSIGN - removes the need for ENTRY as it takes only the first row and assigns it to the variables.
<@DISCONNECT>
Attributes to use here:
  • HANDLE - the handle you used in <@CONNECT>.

Hitop Quick and Dirty FAQ

This is quick and dirty because I am throwing stuff up as and when I think of it in as little time as possible, so please bear with me. If you have any questions email me.

With the forthcoming advent of Hitop2 many of these solutions simply won't be needed, but until then these are invaluable.

How do I round a number up?
This should work where NOTROUNDED is a number, decimal point optional:
<@SET NAME="ROUNDED" VALUE="${'${'${'0.${NOTROUNDED:AFTER('.')}*2':EVAL()}.':BEFORE('.')} +${'${NOTROUNDED}.':BEFORE('.')}':EVAL()}">
How do I do DIV in Hitop?
Imagine calculating the number of rows of a table with a given number of columns and cells. The initial calculation is to get the minimal number of rows:
<@SET NAME="ROWS" VALUE="${'${'${CELLS}/${COLS}':EVAL()}.':BEFORE('.')}">
Further calculation is needed to ascertain if an extra row is needed in case the numbers don't divide wholly.
How do I write content management in Hitop?
Use a database. Hitop cannot write to files. This is a feature, not a bug. You are therefore going to need to use a database to store your content, with the associated requirement of replacing single quote characters with \' in your input. Databases are fortunately pretty good at handling concurrent users and simultaneous write/read requests on the same data.
How do I remove selected characters from a string? How do I keep selected characters in a string?
Use the undocumented REMOVENOTOF() string function. For example, to strip a variable meant to be a number of any non-numeric characters:
<@SET NAME="TREATED" VALUE="${UNTREATED:REMOVENOTOF('0123456789')}">
Or to check to see if UNTREATED had any nasty characters in it:
<@IF NAME="UNTREATED" COMPARE="NE" VALUE="${UNTREATED:REMOVENOTOF('0123456789')}">
I've got many rows of data in my database and I want to place them into arrays. How do I go about this if Hitop has no array data structure?
Simulate it. Take the following piece of code:
<@QUERY HANDLE="db" SQLQUERY="select pic_id from pictures order by pic_id;" ENTRY="MAKEARRAY">
Then in your MAKEARRAY procedure put:
<@QUERY HANDLE="db" SQLQUERY="select image_path as path${PIC_ID}, width as width${PIC_ID}, height as height${PIC_ID} from pictures where pic_id=${PIC_ID};" ASSIGN>
Let us assume you chose numercial picture IDs in your database table, you now have PATH1, HEIGHT1 and WIDTH1 all matching the data for your first image you extracted, with appropriately named variables for higher picture IDs.
Alternatively...you can do:
<@QUERY HANDLE="db" SQLQUERY="select pic_id, image_path, width, height from pictures order by pic_id;" ENTRY="MAKEARRAY">
Then in MAKEARRAY put:
<@SET NAME="PATH${PIC_ID}" VALUE="${IMAGE_PATH}" SCOPE="GLOBAL">
<@SET NAME="WIDTH${PIC_ID}" VALUE="${WIDTH}" SCOPE="GLOBAL">
...
And so on. Clearly this gives greater flexibility as you can now assign scope to each variable. Crucially, it is less database connection intensive too. Databases are quick. Connections take time, and can be considered wasteful.
How can I stop my Hitop becoming an unmanageable mess?
Modularise. Split code into separate files and group related files in directories.
For example you may have a login system on your web site that requires various security procedures to be run to verify login details and log failed accesses. You may also have lots of form input that needs checking to filter out bad characters before allowing it to pass into a database, or cookie-checking code. All this is security-related.
So place your cookie-checking code in one file, your form input-checking code in another and your login-checking coded in another. Then place all files in security/
Now you can load each set of functions a needed by using multi-stage templates. Multi-stage templates are covered in another question.
How can I neatly organise my large site and stop my template from becoming unwieldy?
Use multi-stage templates. For example one section of your site has a gallery which requires a special template for those pages. Have a general template that covers all pages on the site, and a template that covers only the area of the screen where the gallery is to reside. Then your individual gallery page references your gallery template, which in turn will reference your main template.