Trent Richardson

Need a super light weight syntax highlighter for jQuery? This is it, jQuery Litelighter. It’s extremely small, and very easy to use and extend. It has a fully functional api. It comes with two themes built in, and 4 languages: Javascript, Html, CSS, and Generic C-like syntax for C, C++, PHP, Java, etc. A ColdFusion syntax is also provided in the documentation as an example.

The dark theme is very similar font colors, just a darker background.

You will notice it isn’t a super detailed highlighter, that is the objective. Check it out. fork it on Github. Head over to the Documentation. Get your hands dirty!

jQuery Powertable is a jQuery plugin to help spice up your tables. Of course there are a lot of table plugins, but this plugin gives you all the power, yet stays out of the way for you to style. Complete with a full api to remotely manage your table, you can manage from within the table, or outside the table.

So what type of features does this so called table plugin have that are so amazing?

• Move Columns – Works via drag and drop or api call
• Show/Hide Columns – Works from generated handle or api call
• Fixed Columns – Sets columns as fixed upon initialization or api call
• Rows Columns – Sets rows as fixed upon initialization or api call
• Persistant – Use browser storage to remember settings or supply your own

And if that isn’t enough the fact that it eats 1,000 row tables for breakfast should be. The plugin digs down below the jquery level to pure javascript for maximum performance. Finally you should know where and how to get it:

• jQuery Powertable Documentation
• jQuery Powertable on Github

Hope you enjoy!

Accounting.js, meet Finance.js. Thanks to the excellent Car Bounce App, a handy new javascript library is now available. Similar to accounting.js, finance.js tackles other money topics: Financing, Loans, and Interest calculations. So what can Finance.js do?

It may be easiest to describe a simple situation. You financed your car, and you know your monthly payment, how much you financed, and how many months you financed, but you cannot recall your interest rate. There is a method for that. Same with the other 3. So we end up with the following functions:

• finance.calculatePayment – calculate the monthly payment
• finance.calculateAmount – calculate the amount financed
• finance.calculateMonths – calculate the number of months financed
• finance.calculateInterest – calculate the interest rate
• finance.calculateAmortization – calculate an amortization schedule of each month’s interest and balance.
• finance.calculateAccruedInterest – calculate the interest money one would gain in an interest bearing account over X months.

Aside from these finance methods are simple number and currency formatting methods. Provided are USD, GBP, and EUR currency formats and add/remove methods to manage more. Enjoy!

• Finance.js Documentation
• Download or Fork from GitHub

From time to time when querying the database, you have to break the mold. CakePHP gives many options when it comes to complex conditions, but sometimes you need to push the boundaries. Recently I needed to return a subquery as a field name. It wasn’t a high demand query, so I wasn’t too concerned with performance. Here was my first approach to “hack” my way through Cake’s setup:

$paging = array(
	'fields'=>array('User.id', 'User.email', '((select max(ul2.login) from "user_logins" as "ul2" where "ul2"."user_id"="User"."id") >= \''.$two_mo_ago.'\') as "User__alive"'),
	'order'=>'User.email asc',
	'contain'=>array(),
	'limit'=>20
);

I’ve changed my query a bit for simplicity, but the basic concept is to get a true/false if the user has logged in within the past two months. This works for some databases, but I use sqlite for development, and it complained with “User__alive”. To properly group the fields cake uses the Model__field naming, but oddly Sqlite didn’t like me using this. So how can you get Cake to handle all this for you? Simple, use virtualFields with your model. The solution ended up being cleaner than the example above. Here’s what I ended up with:

$this->User->virtualFields['alive'] = '((select max(ul2.login) from "user_logins" "ul2" where "ul2"."user_id"="User"."id") >= \''.$two_mo_ago.'\')';

$paging = array(
	'fields'=>array('User.id', 'User.email', 'User.alive'),
	'order'=>'User.email asc',
	'contain'=>array(),
	'limit'=>20
);

Cake knows how to handle piecing the fields together across databases, so cross platform issue is solved, plus cake’s pagination knows what to do when you sort by this field. Of course you will want to assign these virtualFields in your model so they’re available everywhere, but for simplicity I showed using/assigning it in the controller.

Adding another level of Cake goodness you may want to consider using the model’s buildStatement to generate subquery strings. This will almost eliminate the need to write sql statements at all, thus let Cake do more cross database sql generation for you. I may tackle this in another post. Enjoy!

The avid Impromptu enthusiast will be much pleased with the advancement of using events. Not only does 4.0 bring more events, it also brings better events. First and foremost I must point out there is a change to the state’s submit parameters. The first parameter is now an jQuery.Event, followed by the original 3 parameters from older versions. For backwards compatibility you can find on Github a tag for 3.3.3 which was committed with the new events, but with backwards compatibility of keeping the original parameters for the classic style of passing the submit option during the $.prompt call.

Ok, so why the change?

1. So far with Impromptu you had to return true/false inside the submit callback to tell Impromptu whether or not to close the prompt. You can still do this, however the more appropriate way is to use the first parameter to call event.preventDefault() to prevent the prompt from closing. Think of it as how you would treat an anchor tag’s click event.
2. You can call event.stopPropagation() to prevent event bubbling.
3. You can now bind as many events as you like, though only one may be passed in the $.prompt() options.
4. More events available through the same interface.

In addition to the change of how events work, there were additional events. Here are all available events:

• promptloaded: called when the prompt has been displayed. Parameters (event)
• promptsubmit: called on button click. Parameters (event, value, message, formVals)
• promptclose: same as callback option. Called when prompt has closed. Parameters (event[, value, message, formVals]). Optional parameters are only available when a button was clicked.
• promptstatechanging: called before state change. return false or event.preventDefault() stops the state change. Parameters (event, fromStateName, toStateName)
• promptstatechanged: called after the state change is complete. Parameters (event, stateName)

Now you want to see what the difference is. Lets look at a quick example. I must mention you can still call $.prompt just like before, but just consider these changes “Extras”.

var jqi = $.prompt('Hello World!');

jqi.bind('promptsubmit', function(event, val, msg, fields){
    // To hold the prompt open you can either:
    // event.preventDefault()
    // or
    // return false;
});

Pretty straight forward. Again you can still use the submit, loaded, and callback options just like before with the exception of adding the event parameter first. Feel free to share your opinions!