Extremely Easy Ext.Direct integration with PHP

[j.bruni]

That sounds very good !

Cool! So, hold on. I am working on it. A new version will be released very soon.

[j.bruni]

Hi, everybody!

I am extremely happy to announce a new version for this extremely easy to use integration of PHP with ExtJS.

You can download it from the opening post of this thread.

We do not have many changes. In fact, there are three:

1) Improved compatibility with ExtJS 4: now the JavaScript code verifies if the required ExtJS class for Direct is loaded, and load it if it is not.

2) Comments were revised, fixed and improved. We had a few "documentation bugs" in the comments. Now they are gone. I think I have corrected all of them.

3) The main change is the new constructor_params configuration, a feature recently requested. See how to use it in the example below:

<?php

require 'ExtDirect.php';

class Server
{
    public function __construct( $pretext )
    {
        $this->pretext = $pretext;
    }
    
    public function date( $format )
    {
        return $this->pretext . date( $format );
    }
}

ExtDirect::$constructor_params = array(
    'Server' => array( 'The current server date is ' )
);

ExtDirect::provide( 'Server' );

?>

In the example above, an instance of the "Server" class is created when an action is requested by ExtJS from the client-side. If you need to pass a parameter to the class constructor when this instance is created, now you can!

The constructor_params configuration must be an array, where the keys are the class names and the values are the parameters to be passed to the corresponding constructor (it must be an array also).

[JavascriptParrot]

Thank you! I will test it asap!

[demithron]

Nice class man, but as i can see parameter enableBuffer again absent in new release.
can u back it in next updates?
thanks in advance.

[lsdriscoll]

Hi j.bruni!

First of all, thanks so much for this package! It's saved so much time.

Second, I have been using it with the charts module and have uncovered a potential problem :
The JSON data always returns table data as strings from the proxy, even if it's marked as an integer in the db. Obviously this broke the charts. I have seen many people on forums having the issue that their charts wouldn't work using a direct proxy, so I'm guessing that this might be an Ext problem instead of relating to your code.

Anyway, as a temporary fix I modified lines 621 & 623 so that the json_encode functions included the JSON_NUMERIC_CHECK flag.

Of course, this isn't ideal as it will force ALL number values to be send as integers, when a string may actually be desired.

Was wondering what your thought were on this?

[j.bruni]

Nice class man, but as i can see parameter enableBuffer again absent in new release.
can u back it in next updates?
thanks in advance.

Since enableBuffer parameter has never been available, there is no way to bring it back.

I thought on creating some caching mechanism but never implemented it. IMO, the "cost/benefit" does not worth. It is the first time someone requests it. (If I understood correctly what you meant.)

[j.bruni]

Second, I have been using it with the charts module and have uncovered a potential problem :
The JSON data always returns table data as strings from the proxy, even if it's marked as an integer in the db. Obviously this broke the charts. I have seen many people on forums having the issue that their charts wouldn't work using a direct proxy, so I'm guessing that this might be an Ext problem instead of relating to your code.

Hi! Thanks for your feedback! Sorry for the delay on my reply. Anyway, here are my thoughts on this:

In my point of view, the "potential problem" is not exactly an Ext/JSON issue, but a database issue.

Every data returned from SQL queries is always of string type. The only exception is the null value, which returns as null. Everything else is string, it does not matter the type of the data in the database. A date column, or an integer column... the database query results always arrive in the PHP side as strings.

Also, consider that we can satisfy Ext Data Charts needs of integer values, but will not be able to send JavaScript Date objects, for example, using pure JSON, without any extra processing at the client-side...

So, my approach is: in my server-side app code, I use an intermediary "parse" function which transforms each row of the database result into something ready-to-use for the client side. Something like:

function parse_rows($original_result)
{
    $parsed_result = array();
    foreach($original_result as $row)
    {
        $row['quantity'] = intval($row['quantity']);
        $row['price'] = floatval($row['price']);
        $parsed_result[] = $row;
    }
    return $parsed_result;
}

The important thing here is that we need to transform the database-returned string into its proper integer data-type. In fact, I use this "parse" function to apply other kinds of transformations (for example, joining "first_name" with "last_name" to return a "name" column which does not even exist in the database).

I think this is where the solution should be focused... not at client-side or the JSON encoding. This is my opinion.

[lsdriscoll]

The important thing here is that we need to transform the database-returned string into its proper integer data-type. In fact, I use this "parse" function to apply other kinds of transformations (for example, joining "first_name" with "last_name" to return a "name" column which does not even exist in the database).

I think this is where the solution should be focused... not at client-side or the JSON encoding. This is my opinion.

Hi, thanks for the response!

I completely agree that the solution should be at the server side.

However in terms of your solution, consider this situation:
You have an application that draws data from multiple tables that are designed to provide data 'as is' with no custom processing required. Of course, these tables all have varying column names.
To avoid code replication you have built a generic crud interface to handle these tables and wish to use this interface in future projects.

In this situation, processing strings into integers on a per table basis is not viable as the read method will not know which columns to convert. The only place the data types are defined will be in the ext models themselves.

In my opinion, it would make sense for the data types to be sent along with request and used by the read method to determine how to process the rows.

Of course, the drawback is that this would require overriding the ext core (unless I'm missing something vital).

I look forward to hearing your thoughts on this, no doubt to tell me where I've gone wrong

Lee

[dschere]

// so I'm inside either onReady or launch if I'm using
// MVC

// I do this

var provider = new Ext.direct.PollingProvider({
type:'remoting',
url: <The path to your php script>
});

Ext.direct.Manager.addProvider( provider );

alert( Server.date() );

// would this work?

[DeFacto]

alert( Server.date() );

// would this work?

No. Because alert is called immediately, but Server.date() makes ajax request, that's way you need to use callback function

  Ext.php.Server.date( 'Y-m-d', function(result){ alert( 'Server date is ' + result ); 
                } ); } );