DataShaman

While developing an app for a client, I came across a problem with ExtJS's form handling.

Let's say you have a form with a Ext.form.ComboBox on it.

When the form's load() function is called, it sets the values of the fields on the form to the data retrieved from the form's store.

Now, if your ComboBox is pulling its data from a standard lookup table, it will usually be setup as a value/text pair.

Problem is that the form displays the value, and not the text associated with that value.

I suspected that the ComboBox had not loaded its data before the form tried to fill in the field value.

This was confirmed by watching the XMLHTTPRequests in FireBug, and also by setting the valueNotFoundText config for the ComboBox to something arbitrary like 'Not found'.

True enough, when I loaded the page again, the ComboBox field displayed 'Not found', despite being loaded with a valid value.

Poring over the code and documentation showed no way of configuring the ComboBox to immediately load and associate itself with the data store.

So I've resorted to doing this instead:

Note that this will probably only work if you use xtype's to define your form fields. YMMV.

It's a bit of a kludge, but it works well enough for me, until I figure out how to do it another more convenient way.

Privoxy is a web proxy with advanced filtering capabilities for protecting privacy, modifying web page data, managing cookies, controlling access, and removing ads, banners, pop-ups and other obnoxious Internet junk.

I have set it up as a filter in front of a Squid cache to stop me exposing my surfing patterns to marketing types out there.

There's been a lot of noise recently about FaceBook's new Beacon system which broadcasts your browsing breadcrumbs to your friends.

Privoxy can easily be setup to prevent FaceBook from tracking where you go - that's what it does best!

Simply edit your /etc/privoxy/user.action file, and look for an uncommented line starting with { +block }. Right underneath that type the following:

.facebook.com/beacon

You can also edit your configuration in your browser. Scroll down to the section listing an action of +block, then click the Add button and enter the same string to block the URL.

This will prevent your browser from contacting any URL in the facebook.com domain where the folder starts with beacon.

Voila!

ExtJS 2.0 was released yesterday, and it's a great improvement in design and speed from the previous version.

However, either I'm doing something really wrong or there are two fundamental functions missing, namely Ext.getDoc and Ext.getBody. Ext.fly also seems to be missing...

These functions are referenced throughout the ExtJS code, and they are not defined anywhere.

For others experiencing the same problem this should work:

Most of the components in ExtJS use a JsonReader by default which, according to the documentation, should not require configuration to fill the component's item array. However, nowhere is it clearly documented what that JSON data format should be.

After much tinkering around in the ExtJS code, I discovered that the following JSON will work correctly with loading data into the Grid without having to identify the root or totalProperty attributes:

So, it's an object mostly made up of an array of items, with a couple of other properties added to tell ExtJS what's there:

One property is length which stores the number of indexed items. The other is metaData, which has in turn a single property (that I've identified so far) called fields which has an array of field descriptors.

The field descriptors are in the same format as when defining a Record with Ext.data.Record.create(). In my case, names suffice, but you can also add in field types, directions to sort, etc. Refer to the Ext documentation at .../docs/output/Ext.data.Record.html#create for a more thorough treatment of the subject.

Nginx or Engine X has an ssl module which can also be used for verifying client certificates.

While the documentation for the module is quite good if you're a programmer, there is a disturbing lack of howto's and tutorials in this regard.

To verify that the client is using a certificate you've signed, you have to define the module option ssl_client_certificate to point to your CA certificate file, in PEM format, which is generated for you by the OpenSSL tools when setting up your CA.

I found Marcus Redivo's SSL Certificate HOWTO to be most useful while setting up my CA.

Then you must set ssl_verify_client to on, and ssl_verify_depth to 1. That last one got me, because even though it says in the documentation that it has a default of 1, if you do not explicitly set it in your config, it doesn't work. YMMV.

The next problem I faced was how to access the client certificate information from PHP. Finding this out took a while as well...

The ssl_module exposes a few variables, which get a bare mention at the bottom of the ssl_module's documentation page.

The one which was most useful for my purposes was this:

$ssl_client_s_dn returns line subject DN of client certificate for established SSL-connection

To get that variable to pass through to PHP via FastCGI, you must define it in your conf/fastcgi_params file, or anywhere in a block where you are using FastCGI, as follows:

fastcgi_param SSL_CLIENT_S_DN $ssl_client_s_dn

You can call the parameter anything you wish, but the $ssl_client_s_dn must remain the same.

Once you've restarted nginx, opened up a secure connection to a phpinfo() page, with an appropriate client certificate loaded in your browser, you should see something like the following variable defined in the $_SERVER array under $_SERVER['SSL_CLIENT_S_DN']:

Now PHP knows who the client is, and can use the emailAddress substring to match against a field in a database to work out role-based permissions.

If you ensure that the file permissions en route are all watertight, this should be a secure password-less authentication mechanism.

Enjoy!

Anyone who's used jQuery, knows that you can write less and do more with JavaScript.

Recently I wanted to use an accordian script to present a large amount of content on one page.

After looking at the options available, I decided that I could write something better. And smaller.

So here's my jQuery accordian script:

Short, huh? Now let's explain how it works. Because jQuery coding is so short, it pretty much reads like English.

When the mouse hovers a title, the cursor is changed to a pointer or hand, and when it moves away from the title, the cursor is changed back to the default shape.

When the title is clicked, any visible content in the whole accordian slides up fast, and any content which is hidden under the current block slides down fast.

This loads the jQuery library script which you should have already. If not, download it from the jQuery site.

This pulls in the script above, which should be saved to accordian.js or whatever you prefer. Just remember to use the same filename on this line.

In the next script block, we're using jQuery's easy onLoad replacement, which guarantees that all elements in the document will be ready, when run. If you've used jQuery, you should be familiar with this construct. If not, then you should read the jQuery documentation.

The jQuery library uses (amongst other methods) CSS selectors to target elements for manipulation. Line 9 sets up the accordian by telling it which block should be turned into an accordian.

As you can see from the source file above, the accordian block must be formatted according to the following structure for it to work correctly:

Use can use any id for the accordian block, just ensure that you use the same id when initializing the accordian.

Without further ado, here's a demo of the accordian script in action.

I needed a JavaScript function which would give me access to the URL querystring, much like PHP's $_GET associative array. Unfortunately most of the solutions I found were either wrong, incomplete or badly written. IMHO.

So, being a programmer, I decided to knock up my own version of the script.

Many of the scripts I saw parsed through the querystring everytime a single query parameter was required, which is inefficient, especially if you're going to be using the same function repeatedly in the same context.

My script adds a property parameters to the window.location DOM object which is where this information should be stored, in my opinion.

It should only be run once to setup the associative array of query parameters, preferably when the document is completely loaded, but I don't think that's necessary since the location object should be ready right from the start.

I'm surprised that the DOM standard hasn't given us an easy way of accessing this information. Especially since the increasing use of Ajax means that more and more decisions are made in the browser rather than in server code.

For a lazy loading getParameter function, you could do this:

The way it works is as follows:

• All query parameters are decoded, so any entity references, %20 and + symbols are converted to their human versions
• If a query parameter does not have a value such as the parameter flag in:
  

  http://example.com/page.php?flag

  then the window.location.parameter['flag'] will return null

• If a query parameter is not defined, then it will follow the usual JavaScript convention and return undefined

I think this covers most situations. I'm not 100% certain that the regular expression replacement of all + signs with spaces is correct, there seems to be some ambiguity about what to do with + signs. None of the supplied native decode functions decode them to spaces. Let me know if you have any answers on that one.