1. #1
    Ext JS Premium Member gevik's Avatar
    Join Date
    May 2009
    Location
    The Netharlands
    Posts
    266
    Vote Rating
    9
    gevik will become famous soon enough

      0  

    Thumbs up ExtJS extension for PHP Yii Framework (UPDATE)

    ExtJS extension for PHP Yii Framework (UPDATE)


    ## 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 Code:
    <?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 Code:
     
    <?php
    /* controller class (MVC) */
    class site extends ExtController
    {
       function 
    button2Action()
       { 
         
    // change button1 server-side
         
    ExtButton::SetText_OnAjax('button 2 is clicked','button2');
     
       }
    }
    ?>
    Last edited by gevik; 25 Jan 2010 at 1:00 AM. Reason: Update 24-JAN-2010

  2. #2
    Sencha User pcr's Avatar
    Join Date
    Jun 2009
    Posts
    183
    Vote Rating
    2
    pcr is on a distinguished road

      0  

    Default Yii Framework

    Yii Framework


    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

  3. #3
    Sencha User
    Join Date
    Jul 2007
    Location
    Sterling, VA USA
    Posts
    46
    Vote Rating
    0
    ddanatzko is on a distinguished road

      0  

    Smile Similar Project in zend

    Similar Project in zend


    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.
    Scope = Perspective (think like an object)

  4. #4
    Ext JS Premium Member gevik's Avatar
    Join Date
    May 2009
    Location
    The Netharlands
    Posts
    266
    Vote Rating
    9
    gevik will become famous soon enough

      0  

    Default


    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 Code:
    <?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>
    ?>

  5. #5
    Sencha User
    Join Date
    Nov 2009
    Location
    Poland
    Posts
    84
    Vote Rating
    2
    saprot is on a distinguished road

      0  

    Default


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

  6. #6
    Ext JS Premium Member gevik's Avatar
    Join Date
    May 2009
    Location
    The Netharlands
    Posts
    266
    Vote Rating
    9
    gevik will become famous soon enough

      0  

    Default


    Quote Originally Posted by saprot View Post
    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.

  7. #7
    Sencha User
    Join Date
    Jul 2007
    Location
    Sterling, VA USA
    Posts
    46
    Vote Rating
    0
    ddanatzko is on a distinguished road

      0  

    Thumbs up Definitely Interested

    Definitely Interested


    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!
    Scope = Perspective (think like an object)

  8. #8
    Sencha Premium Member Ronaldo's Avatar
    Join Date
    Jul 2007
    Location
    Enschede, The Netherlands
    Posts
    291
    Vote Rating
    1
    Ronaldo is on a distinguished road

      0  

    Default


    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
    Ronald van Raaphorst aka Ronaldo
    I'm a freelance software developer in Java, PHP, and ExtJs.


    Skyperonald_twensoc
    Mailinfo@twensoc.nl

  9. #9
    Ext User deanna's Avatar
    Join Date
    Aug 2007
    Location
    Alabama
    Posts
    306
    Vote Rating
    0
    deanna is on a distinguished road

      0  

    Default


    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.

  10. #10
    Ext JS Premium Member gevik's Avatar
    Join Date
    May 2009
    Location
    The Netharlands
    Posts
    266
    Vote Rating
    9
    gevik will become famous soon enough

      0  

    Default


    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