ExtJS extension for PHP Yii Framework (UPDATE)

[gevik]

## Update: 24-JAN-2010

The development of ext4yii is going nicely. The first release will be at version 0.6. The release will contain both open-source and commercial licensed versions. At this moment about 40% of the implementation is complete. Please follow the development progress at http://twitter.com/ext4yii or take a look at the API examples on http://www.ext4yii.com

-----------------------------------------------------------------------------------


Hello,

After developing a proof-of-concept, we are planning to develop a fully fledged ExtJS extension for the Yii (www.yiiframework.com ). Yii is a fast and powerful MVC framework on top of PHP.

The extension will enable developers to declare ExtJS layouts in PHP pages instead of writing JavaScript code. It also provides built-in Ajax functionality to communicate with the backend php classes.

My question is: How much would this be of a value to you?

Here is a code snippet to give you guys an idea of what this is about:

<?php
 
/* Yii view containing the view (mvc) */ 
 
<ext:Panel id="MyPanel" title="Test Panel 1" width="400" height="400">
    <prop:Body>
 
        <ext:Button id="Button1" text="Click Me">
            <prop:Actions>
                <Client:Click handler="alert(sender.text  + ' is clicked!')"/>
            </prop:Actions>
        </ext:Button>
 
        <hr/>
 
        <ext:Button id="Button2" text="Click Me">
            <prop:Actions>
                <Server:Click action="site/button2" showMask="true" 
                    maskMessage="Please Wait..."/>
            </prop:Actions>
        </ext:Button>
 
    </prop:Body>
</ext:Panel>
 
?>

and

 
<?php
/* controller class (MVC) */
class site extends ExtController
{
   function button2Action()
   { 
     // change button1 server-side
     ExtButton::SetText_OnAjax('button 2 is clicked','button2');
 
   }
}
?>

[pcr]

Hi, first time I hear about Yii Framework. I looked at your website. Sounds interesting. Because there was a lack of 'automatic' generating ExtJS components tool I started to write PHP scripts that generate ExtJS components based on my DB-tables. Now I use this tool daily and improve it almost daily. Improvements are nessecary because I need more and more customize the components.
The script generates both sides Front (.js) - and Backendside (.php) scripts.

The problem is the specific components that are needed to do businesslogic.

Maybe Yii with on top an ExtJs extension is interesting. SO I will keep in touch with you about Yii Success with Yii and ExtJS

[ddanatzko]

I've been fighting with myself on the best approach to do exactly this.

I'm working on a similar project using Zend. Since my use case is pretty specific, I was going the route of starting from a viewport (separate JS files) and building predefined classes and factories within the app and a message bus to handle component interaction (there are already some extensions out there that act as controllers within an MVC implementation). Right now, I'm just using the disableLayout method of the view within Zend to handle Ajax responses and I leave it to the client to tell the backend what format it wants the data in. My main reason for this approach is that the data on the backend will be accessed via a restful URI and will be opened to a number of formats (JSON, XML, HTML, RSS, etc). But, the more I think about it, the view for the Ext client is the only view where the logic is external to the backend application....

My only concern with your approach is that chaching could be somewhat of a challenge for larger JS apps. I see a significant advantages in load and execution times by having the JS files separate (cacheable). Have you factored that into your Extension? If so, what is your approach?

I'm still very wet behind the ears on software design patterns and coding in general(if that's not already obvious). So, please feel free to provide some direction here. I'm a big proponent of not reinventing the wheel (hence the reason I'm using 2 separate frameworks). If you've got working code, I'd be more then happy to take it for a test run.

[gevik]

But, the more I think about it, the view for the Ext client is the only view where the logic is external to the backend application....

I agree.

My only concern with your approach is that chaching could be somewhat of a challenge for larger JS apps. I see a significant advantages in load and execution times by having the JS files separate (cacheable). Have you factored that into your Extension? If so, what is your approach?

In our proof-of-concept we have thought about caching. The planning is to implement it in v2. Our approach to caching works only if the contents of the tags (<ext:<whatever>) is not changed. The caching service will only generate the JS the first time and hash it on the server. When a view is about to be rendered for the second time there is a check to skip the cached content and use whatever that was generated before. To give you an example of the proof-of-concept:

<?php

/* This part is unlikely to be changed anytime soon */

<ext:CachedContent>
    <ext:Button id="btnSave" iconCls="icon-save" text="Save Contact">
        <prop:Actions>
            <Server:Click 
                action="cms/save"
                showMsk="true"
                maskMessage="Please wait while saving..."/>
                
        </prop:Actions>
    </ext:Button>
</ext:CachedContent>
?>

[saprot]

Oh yeah, that is what I've been waiting for
is there any approximate date of release?

[gevik]

Oh yeah, that is what I've been waiting for
is there any approximate date of release?

If everything goes as planned, it will be in the first half of 2010.

[ddanatzko]

In our proof-of-concept we have thought about caching. The planning is to implement it in v2. Our approach to caching works only if the contents of the tags (<ext:<whatever>) is not changed. The caching service will only generate the JS the first time and hash it on the server. When a view is about to be rendered for the second time there is a check to skip the cached content and use whatever that was generated before.

I'm not familiar with Yii, so I don't know if it has built in caching classes, but it sounds like this method could be significantly more complex. Why not create a base JS application framework so that you're not programmatically evaluating whether each component withing each view has already been rendered. In some instances, for example rendering navigation, there is a high probability that those components will persist across the app in many places.

IMHO I'm still not convinced on the idea that all the application logic has to reside within the backend...FWIW

Essentially, I guess it depends on the implementation and use case. I personally have a nascent view as I've only been coding for ~5 yrs and doing application development for ~2yrs. I do all my own HTML/CSS/JS/PHP/MySQL development, Systems Administration and 3rd party integrations, so I have to wear a lot of hats. For me, EXT has been a life saver because it allows me to rapidly develop custom portals with a high level of interaction and functionality with very little "design" considerations with regards to the view. A PHP framework that integrates EXT sounds like the ideal solution for my needs as it will most likely improve my development time. The one thing I cannot compromise on is user experience.

Please keep us updated on your progress as this would be very useful for me as a standalone developer. Any benchmarking results between cached, dynamically generated, JS vs hard coded external JS files would also be helpful in making a decision to change my current process.

Thanks!

[Ronaldo]

Personally, I don't believe in creating tags that create javascript code at runtime.
Sure, it does look nice and it seems all very simple, but the real catch is in the detailed business logic you need in the end. And that 'special business logic' is very hard to implement in a tag-like form like this.

I have inherited the ext classes and have added all the functionality I need everytime (for a form or for a grid) in that inherited class. That makes that every grid/form/panel in my app only contains the details for that grid, like the fields and/or the xtypes validation. It makes these classes standardized and short and easy to adapt. But I am still able to overrule a method and do something on the beforesave or afterload events for example when needed.

But this is just my opinion, my preference based on my experience

Ronaldo

[deanna]

If you are looking to preprocess something to become the client UI, you might take a look at GWT from Google (ext has an addon library for it called GXT). GWT is a few tools to make creating the UI more robust, smaller code, and easier. It uses Java code that is compiled into javascript - but not just compiled, it is optimized with a different version of the js for each browser. GWT handles serving the different versions for you. The compiler produces code much smaller than you would do by hand and only will include parts of the library you need in the output.

Also a part of it is UIBinder which lets you describe the interface in xml similar to what you are doing. Then you reference the components created in the Java code.

[gevik]

Hi Ronaldo,

Personally, I don't believe in creating tags that create javascript code at runtime.
Sure, it does look nice and it seems all very simple, but the real catch is in the detailed business logic you need in the end. And that 'special business logic' is very hard to implement in a tag-like form like this.

I have inherited the ext classes and have added all the functionality I need everytime (for a form or for a grid) in that inherited class. That makes that every grid/form/panel in my app only contains the details for that grid, like the fields and/or the xtypes validation. It makes these classes standardized and short and easy to adapt. But I am still able to overrule a method and do something on the beforesave or afterload events for example when needed.

But this is just my opinion, my preference based on my experience

Ronaldo

With a descriptive tag system, you also can attach handlers and call custom javascript functions in your *application* class to do the business logic. I personally am not too keen on coding business logic rules inside the UI controls. This way if I decide to go to a different UI I don't have to worry about re-factoring (most of the time I must say).

The ExtJS Yii extension I am working on is meant to go with the MVC paradigm. It required the developer to think in MVC patterns when designing and applying ExtrJS controls. I guess each one of us likes to work differently, and this is what makes programming fun

(Dank je voor je reactie en fijne feestdagen)

Regards,
Gevik