This plugin converts a normal table with both row and column level headers to an somewhat interactive format - it is named bullsEye because the goal was to create a targeting effect when the mouse is being moved on the cells and row and column headings. Maybe something like “draw cell lines” or “table zoom” would have been more appropriate but I don’t feel the need to agonize over names.
It was created so that large tables of data can be shown, and as the mouse is moved over the cells, visual effects are applied to the table so that the corresponding row and column header are highlighted so the current position within the table of data is revealed.
It also animates lines from the selected cell to the cell’s corresponding row and column headers, making the identification of the cell’s headers even easier to see.
When moving the mouse over a column or row header, it will highlight all intersecting cells and draw the line to them - this enables the quick identification of what cells are populated with data, as the application this plugin was developed for has intermittent data.
So for example, if the mouse is moved over a column heading, only the cells in that column that are populated with data will be highlighted and lines will drawn from each those populated cells to it’s row heading for quick visual reference.
The last bit of functionality is to either fade in or zoom in extra data on the cell level that is hidden by default when hovering over a cell.
The hover content can be HTML formatted and when it is revealed, the div used will automatically center over the selected cell and will be sized to align with total amount of cells configured - for example it can be 3 rows and 5 columns, or 3 row and 3 columns. This is visually appealing because the hover content will fit in the existing grid lines.
This is my first jQuery plugin - if anyone finds bugs or has usability suggestions let me know. I have tested it in Firefox, Opera, and Safari and the behaviors are pretty much identical.
If anyone wants to develop just fork the github repository and contact me if you have developed something you feel should be merged into the main release.
LINK: bullsEye Live Example
LINK: bullsEye Github repository and Download
This post will walk you through the steps I took to enable OpenID login in a project I am working on. I wanted to enable OpenID alongside existing user data stored in MySQL database.
This tutorial actually covers more than just the subject of OpenID; it shows how to create your own custom authentication and authorization in Pylons, and how to create your own authorization decorators to protect Pylons actions.
I will assume you already have Pylons, SQLAlchemy, Mako, and MySQL installed, and will start by creating a new Pylons project project for this tutorial.
» Read the rest of this entry «
I have been very disappointed with the voicemail emailing capabilities of Asterisk PBX. If you need to use a SMTP host, it can be a time consuming task to configure sendmail, postfix, etc, to use an external SMTP provider. And once you get the emails to send, customizing and scripting is very limited.
I wanted to be able to use SMTP, add BCC and CC recipients, have full scripting control over the message body and subject, and attach the voicemail recording in the e-mail. It seemed like writing a script and using the ‘mailcmd’ setting in the [general] section of the asterisk voicemail.conf file was a suitable way to handle this, so I took this route.
» Read the rest of this entry «
Unable to find a ComboBox component for Ext JS that would work in an Ext Grid, permit multiple selections, and support both local and remote datasources with multiple fields (one for display, one for the index), I set out to build my own some time back.
Note: Since I began working on this some time back, a similar Ext plugin was developed by another developer: see http://lovcombo.extjs.eu/
Examples after the fold.
» Read the rest of this entry «
In this article I will discuss how I obtained a 5x speedup on a Smarty driven website on a Lighttpd Web server. This is achieved by enabling Lighttpd to a directly access and serve the cached files directly from the file system, rather than calling into Smarty.
Why is this approach so much faster?
Smarty’s caching engine does a great job at compiling the templates at the correct interval and this creates a drastic speedup compared to recompiling the template on each page request.
However, even when Smarty is serving up cached pages, there is a lot of overhead added to each request when compared to the Web server directly serving the cached page. This is because PHP is still being loaded, the Smarty library is being included, and a small amount of logic is being performed within Smarty before the cached page is finally being passed along.
Is this caching technique right for every situation?
In cases where the cache life must be very short due to frequent changes to the data being rendered, the approach I will explain in this article may not be viable. However, in these cases it would be still possible to use a push method to remove cache when the data changes, versus adding the overhead of checking for changes on each page request. In my opinion, this push approach to caching reduces the cost to the lowest possible value, so if the need for performance is of the utmost importance, then it makes sense to implement this approach.
In my case, the data changes occur infrequently and a combination of clearing the cache on a scheduled interval plus a method to manually force a recompilation of a specific page is adequate, and a worthwhile trade-off for the performance increase. Also, I am a performance junkie.
Implementation Notes
Since Smarty is a flexible library, every implementation is unique. So while I cannot give imperitive instructions on how you can implement this lighttpd cache, can explain how I did it.
This was my lighttpd configuration for the site prior to implementing the cache. It has a few basic rewrite rules so request for a (htm|html) file gets passed to the index.php. This file acts as a handler to determine the actual smarty template to load, enabling the use of friendly URLs.
$HTTP["host"] == "www.site.com" {
server.document-root = "/var/www/site/html"
url.rewrite = (
"/(.*)\.(htm|html)(\?.*)??$" => "/index.php?p=$1",
"/(.*)/(\?.*)??$" => "/index.php?p=$1",
"/(.*)/(.*)/$" => "/index.php?p=$1/$2"
)
}
And after implementing the cache, this is the lighttpd host configuration:
$HTTP["host"] =~ "www.site.com" {
server.document-root = "/var/www/site/html"
magnet.attract-physical-path-to = ("/var/www/site/html/rewrite.lua")
}
Below is the code for rewrite.lua (referenced in the lighttpd conf above) which implements lighttpd mod_magnet to handle the rewrite rules. It checks the file system to determine if a cached file exists, and if so, it serves that file. Otherwise, it rewrites to the index.php handler so smarty can generate the new cache file.
The cache_path variable in the rewrite.lua script is my smarty cache dir ( $smarty->cache_dir ), plus the $smarty->cache_id (mine is blank, be sure to append it to the cache_path variable as a subdir of your smarty cache_dir)
At this point, lighttpd is rewriting all requests to my index.php handler since it will not find a cached copy in the the cache_path dir. I now have to work with the index.php handler file so Smarty will save the compiled HTML files into the cache_path defined in rewrite.lua. To do this, I wrote a custom cache handler function for smarty and stuck it in the index.php file. So far, my Smarty setup is looking like this:
The main thing here is that the caching is enabled, each request will recompile the template, the compile_id is blank, and the cache_dir matches what is set for cache_path in rewrite.lua.
The function server_rewrite_cache_handler() overrides the default smarty cache read/write/clear logic so that the file is saved in the correct directory structure that matches the request that was rewritten from lighttpd.
The one last thing is to disable several lines of code in the smarty/internals/core.write_cache_file.php, as by default Smarty will add some serialized data to the top of the cache data it passes to our custom cache handler function. The changes are shown below and occur around line 65 and 66 of the core.write_cache_file.php file.
#$_cache_info = serialize($smarty->_cache_info);
#$params['results'] = strlen($_cache_info) . "\n" . $_cache_info . $params['results'];
That is all, you should see a drastic speedup at this point.
