iconv -f UTF-16 -t UTF-8 input_file > output_file

And you’re done! Easy as pie…when you know what the problem is.

Now, with dynamic data, you can’t predict what your data will look like, and your code needs to be flexible enough to handle any situation without causing headaches for the user.  With ChartDirector, you pass in datasets via arrays across the chart, so for example the above datasets would be created by:

$data0 = array(100, 125, 245, 147, 67);
$data1 = array(85, 156, 179, 211, 123);
$data2 = array(97, 87, 56, 267, 157);

Such that, the numbers line up in the arrays (vertically) in how they correspond to the resulting chart. In my situation and test data, I found I had a situation like the following:

$data0 = array(100, 125, 0, 147, 67);
$data1 = array(85, 156, 0, 211, 123);
$data2 = array(97, 87, 0, 267, 157);

So, the bar for the 3rd item in the chart would be distributed equally as 33.33% when, in fact, there was no data. I assumed the chart would display a blank spot for that bar. After searching the less than optimal support forums (to no fault of the creators / maintainers), I found I needed to instead use a constant defined in the ChartDirector code – ‘NoValue’, where I had…wait for it….no value. Putting a small check in my code to replace zeros with ‘NoValue’ proved to produce the results I was after.

Note to fellow developers: If you’re posting in a forum for assistance, please be more verbose in your subject line. It really helps with searching if the subject can provide some bit of context around what the problem is.

Reference: http://api.jquery.com/submit/#comment-30950448 – Thanks Scotty!

You create SSH tunnels using:

ssh -D 8080 username@remote_server

Which opens port 8080 on the local machine. Then, you can configure your browser of choice to use a SOCKS v5 Proxy at 127.0.0.1:8080. Specifically in Firefox, make sure that none of your other proxy settings are set.

It should look like the following:

Now, you can check the IP address for your connection by visiting a site like: http://www.whatsmyip.org/

It’s open-source, which I really like, but the ease of getting it setup, and the polished look and feel just make me happy to use it.

Great work guys!

So, checking to see the file permissions under /var/lib/ldap, I see a file objectClass.bdb owned by root. Changed it to openldap:openldap, and all is well.

Moral of the story: Always check file permissions. Especially after starting up the server.

The implementation is fairly simple, upon login, we use cURL or something similar and generate a POST request, using the username and password. The remote script grabs the session ID and user ID and returns the values to the originating server. We then, set the cookie values.

Now, the interesting bit. phpBB has multiple layers by which it validates the session. Since our remote server is originating the request, we don’t have the same IP as the user. Second, it uses the User-Agent string of the browser to validate the session. Using cURL, we don’t have a browser. Now, with cURL, you can set various settings (User-Agent string, X-Forwarded-For header, etc) – but if you’d rather not depend on that, you can simply un-check those settings in phpBB.

Of course, I’d recommend using the cURL settings, but to get you started and ensure the connectivity is working.

$export = $this->getRequest ()->getParam ( 'export' );
 
switch ($export)
{
    case 'odt' :
        $grid = "Bvb_Grid_Deploy_Odt";
        break;
    case 'ods' :
        $grid = "Bvb_Grid_Deploy_Ods";
        break;
    case 'xml' :
        $grid = "Bvb_Grid_Deploy_Xml";
        break;
    case 'csv' :
        $grid = "Bvb_Grid_Deploy_Csv";
        break;
    case 'excel' :
        $grid = "Bvb_Grid_Deploy_Excel";
        break;
    case 'word' :
        $grid = "Bvb_Grid_Deploy_Word";
        break;
    case 'wordx' :
        $grid = "Bvb_Grid_Deploy_Wordx";
        break;
    case 'pdf' :
        $grid = "Bvb_Grid_Deploy_Pdf";
        break;
    case 'print' :
        $grid = "Bvb_Grid_Deploy_Print";
        break;
    default :
        $grid = "Bvb_Grid_Deploy_Table";
        break;
}
 
$grid = new $grid (false, 'DataGrid Example', '/tmp', array('download'));
$grid->setDataFromCsv(dirname(__FILE__).'/Detail_Limited.csv');
$grid->imagesUrl = '/images/';
 
$this->view->grid = $grid->deploy();

The code at the end is mine, which basically tells the DataGrid where to render/save the exported file, which is then immediately sent for download. I also am not using the Zend_Db stuff for the data. As a proof-of-concept, I’m using a simple dataset in CSV, which works amazingly well. The filters, sorting, and pagination still work with CSV.

I’m thinking about writing an adapter for Doctrine, such that one could construct a Doctrine query object, pass it into the DataGrid, and everything would work, as it does with the Zend_Db counterparts.

The ORM then has a User, UserRole, and Role object to use in accessing these tables and adding / removing relationships with ease, since it only needs to worry about the single surrogate ‘id’ key on each table.  In the linking table (as a design concern), one should place a Unique Index on the user_id/role_id column combination.

The other option is using a composite candidate key.  I may have the specific terminology wrong, but the idea is that instead of the single surrogate key to identify a unique record in the linking table, you use a design like the diagram below, which combines the columns that are foreign keys to their respective tables to create the primary key.  The combination of the columns creates a unique identifying key.  The difficulty emerges with ORMs attempting to create objects out this design, and attempting to correctly generate the SQL required to make updates / deletes, etc, using each member of the composite key.

Personally speaking, I’m a fan of the surrogate key approach, but I’ve worked with both.  I won’t discuss the performance impacts of either design, since I don’t have nearly the research base to accurately describe it.  But, using simple integer based keys, the difference should be low.