Are there any plans to make this compatible with Ext4?
Are there any plans to make this compatible with Ext4?
What do I need to set count_only_required_params to, so that optional parameters are optional?
I've been extremely far far away from this forum for several months. But now I'm here!
@Andrew Peacock: Thank you very much for the support!
@walldorff: Yes, ExtDirect::provide() needs to be the last call. The only documentation we currently have is this thread... specially the first posts. Take a look!
@tiagoadp & JorisA: I have not used ExtJs 4 yet. Isn't it compatible? Have someone tried? Which are the errors? Anyway, it sounds like a good idea to make it ExtJs 4 compatible, if it isn't. Just added to my "to do" list.
@hschaefer123: State Provider integration? Sounds very nice! I'm sorry I have not taken the time to take care of your request yet.
@padawan & hschaefer123: Thanks! Every praise really motivates us!
@ttbgwt: Your request is so old now... are you still interested? The answer would go beyond the strict scope of this Ext.Direct integration.
This post (http://www.sencha.com/forum/showthre...l=1#post480214) teaches how apply configurations (I know you read it, I am linking for the others...)
All configurations must come before the "ExtDirect::provide" call:
In your case, you want to perform the following configuration:PHP Code:
ExtDirect::$configuration_name = $value;
This will make the "len" property of the respective API declaration correspond to the number of required parameters. So, for a PHP method declared like this...PHP Code:
ExtDirect::$count_only_required_params = true;
...the "len" value will be "1", instead of "2".PHP Code:
function calculate_something( $needed, $optional = 9 )
And this is all.
Now, ExtJS requires you to make the remote function call with the number of parameters declared in the "len" property. In other words: there is no such things as "optional parameters" in the client-side, because of the way ExtJS Direct is designed.
In the example, you need to choose: it will be either "1" or "2" parameters. You simply can't choose "1" and optionally "2", at the ExtJS side. Makes sense?
Last edited by j.bruni; 26 May 2011 at 1:29 AM. Reason: corrections
Guess I should have bothered to try before I ask, so far it's been working great with Ext4, haven't run into any problems yet
By the way, what about supporting custom events like these:
I think the ability to allow hooking into direct calls or even complete batches could make user or rights checking a lot easier.
At the server-side, I use the authorization_function configuration to grant or deny the execution of the request.
ExtDirect::$authorization_function = 'authorize';
function authorize( string $class, string $method )
if ( user_is_allowed_to_perform_this_action( $class . '::' . $method ) )
The key is to change the $response['type'], which most affect the ExtJS receiving of the message at the client-side.PHP Code:
ExtDirect::$transform_response = 'transform_response';
function transform_response( $action, $response )
// Types of the parameters received by this function:
// $action - ExtDirectAction
// $response - array
if ( $some_condition )
$response['type'] = 'event';
$response['name'] = 'trace';
$response['where'] = 'Where this YYYY happen';
$response['trace'] = 'Some data';
// return modified response
I really love this implementation of Ext Direct. Thanks for all of the work you have put into this. I noticed on the video about 6 months ago they said that Ext.Direct allowed for long running processes to be specified separately so that they return on their own time. Is there a way to do this with the current implementation? I have a dashboard with several things loading, and some of the reports take about 7-10 seconds, so i want those to return on their own time, and not hold up the rest of the batch.
1) Create two distinct remote providers. One of them would handle the long running processes only. The other one would handle the other processes. To do this, you need to create two PHP files, one for each API. In this case, you need to include both files using the <script> tag. Calls to one provider do not get mixed with the calls to the other provider.
2) Set enableBuffer to false. See Ext.Direct.RemotingProvider documentation. This setting allows / disallows to send multiple method calls in a single request. If you set it to false, each method will be called through its separated HTTP request. You may want to mix this idea with the previous one, by setting enableBuffer to false only to the long running processes provider, and leaving the default value to the other provider.
Problem is... you don't have a way to change enableBuffer value with the current implementation.
Solution is... we can implement it.
Below line #41 (static public $id = '';), add:
And change the $api_array variable declaration, adding the enableBuffer key, like this:PHP Code:
* @var boolean|integer Ext.Direct Provider attribute "enableBuffer"
static public $enableBuffer = 10;
Now, in your code, you should be able to set enableBuffer to false like this:PHP Code:
$api_array = array(
'id' => self::$id,
'url' => ( empty( self::$url ) ? $_SERVER['PHP_SELF'] : self::$url ),
'type' => 'remoting',
'namespace' => self::$namespace,
'descriptor' => self::$descriptor,
'enableBuffer' => self::$enableBuffer
This line must come, as all other configurations, before the call to ExtDirect::provide.PHP Code:
ExtDirect::$enableBuffer = false;
I hope this helps... What do you think?
Thanks for the quick reply. I think that this will work. I am still trying to decide whether to use the enableBuffer on my set of long running ones (they are all connecting to our exchange server to pull data) because they all return at the same time, so i may just do two different providers. One for our database driven reports, and one for exchange server. However, knowing the option to set the enable buffer will come in handy later if someone desires a very complex report on the dashboard.
Today is "Extremely Easy Ext.Direct integration with PHP" birthday!
This thread was opened exactly one year ago, in June 23rd, 2010.
Thanks everybody for the comments, questions, reports, suggestions, praises, support.
Thanks also to the whole ExtJS team, past, present and future.
And I also want to thank the open source software community.
And, why not? Thanks to my father, mother, wife, kids, pets, nature and God.