How to dynamically change the onclick handler

More related to just web development in general, but sometimes you might need to change the onclick event handler of an element. This can be a little tricky, but I find the best way to do this is:

element.onclick = function() {this_is_my_function($param)}

The tricky part is that the value of the onclick is a reference to the function and not the function itself. So if you simply put:

element.onclick = this_is_my_function($param)

It would actually fail. You need to wrap this under another function, hence the original code where the function() calls the this_is_my_function().

Setting the access to the templates_c

The templates_c folder is location of where the smarty tag templates are compiled to. And these templates are used to display the Xataface application. So it's important that end-users are able to read from this folder so that they are use the application. To properly set this up, the templates_c folder should have the 755 permissions:

chmod 755 templates_c

This basically means that everyone has read and execute access. And also that the owner has write access to the file/folder.

You then need to explicitly set the permissions for the user 'apache' because end users will be under that username when viewing the application. To do this:

setfacl -m user:apache:rwx,mask:rwx templates_c

After that end-users should have no problem viewing the application!

How to change the label of the save button?

Recently ran into an interesting request on how to change the label of the save button on the edit form to something else. While I don't believe there is a direct way to do this in Xataface, you can utilize a little workaround with the feature of "internationalization" of Xataface to get this to work.

How you can do this is:

1. Create a 'lang' folder in the delegate folder of your class you wish to change the edit form form


2. Inside that folder, create an en.ini file.


3. Then add this line:
   

   save_button_label="Submit"

   
   What this does is it overrides the label and causes it to say Submit.

The real function of this feature is to actually allow the display of that label to differ depending on the language chosen. In our case, we just override the original label for english (ie. en) and volia!

A nice little work around hey?

Getting related records

One thing you'll want to do is to grab related records in Xataface. Say for example, you have an abstract record that belongs to a conference. In the relationships.ini file of your abstract table, you would include something like this:

[Conference]
conference.ConferenceID="$AbstractConferenceID"

Where the conference is the name of the conference table, ConferenceID is the name of the index of that table, and $AbstractConferenceID is the foreign ID in your abstract record that corresponds to the the particular record in the conference table. Note the name of the relationship is "Conference."

In Xataface, if you have an abstract record you can quickly retrieve the related conference by simply doing this:

$conference = $record->getRelatedRecord('Conference')

This will retrieve the conference as a xataface_related_record object. It is important to realize that this is not the same thing as a xataface_record. If you want to convert this related_record object into a xataface_record object you can use the toRecord() function:

$conference = $record->getRelatedRecord('Conference')->toRecord();

This is a powerful technique that can save a lot of time.

Xataface svn repository

One good thing you should do if you are planning to develop an application with Xataface is to actually checkout the svn repository of Xataface. The most recent code for Xataface which includes bug fixes and features will be added to this repository. I used tortoiseSVN as my svn client, and to checkout you simply use this address:

http://weblite.ca/svn/dataface/core/trunk

Keeping your database up to date throughout development

A major development issue in any computer project that requires a database is keeping your database structure keep to date with the different versions of the code. Keep database up to date is always a difficult because you cannot simply put it under version (thou technically you can because you can create an sql statement that represents the entire database). But Xataface provides an interesting way to handle this through the use of an Installer.php (make sure it's capital I) class in the conf folder.

The idea behind this is your application will be associated with a version number which you specify in the database. And then Xataface will run the Installer.php file which checks which version is in the database, and then it will call a bunch of functions that update the database table. The functions are named after the version number they should be applied to. So for example:

<?php
class conf_Installer {
function update_582(){
$sql[] = 'ALTER TABLE `webpage_sites` ADD `dynamic` TINYINT(1) AFTER `require_approval`';
$sql[] = 'ALTER TABLE `webpage_sites` ADD `irrelevant_get_params` TEXT NULL AFTER `aliases` , ADD `relevant_get_params` TEXT NULL AFTER `irrelevant_get_params`';
foreach ($sql as $q){
mysql_query($q, df_db());
}
}
?>

What happens is it will see if the database version is 582 or above and then it will apply this change to the database. The this general function format can be used for any version numbers.

To actually setup the database version, we don't actually need to setup a separate database table to handle this. We make a version.txt file in the application and xataface will create a version table in the database for us. The contents of the file will look like this:

0.1 680

The 0.1 really means nothing. It is simply used to note which major release we are on. It is the second number that means something. That is the exact version number that gets stored into the database.

And by setting up these two things, it becomes extremely easy to manage the database in xataface!

SVN committing

This isn't exactly a Xataface related issue, but I found myself continually forgetting about this that I thought it would be good to blog about this so I can remember. When I have ssh'ed onto the server and I need to do a svn commit, I get an error message about not having an editor to input my svn commit message. The following piece of code fixes this:

export EDITOR=vi

Where vi is the editor program we are using. If you have something else installed on your server (and hopefully you do because vi really blows), then you can just use that.

Update: You can actually avoid having to do this by adding that exact line into your .bash_profile file. This file gets executed upon log in and runs a set of commands. So if you do this, it will always just set your editor and you won't have to worry about it anymore.