ExtJS - PHP Class

[xel]

Hi - I am not too good at working with JS Code I must admit - but with Ext I get stuff done - a very big thanks for that. As I am not too good with JS but am code php all day long for a while now I was wondering if there isn't any php-class which creates the ext js codes... You know - just like with XAJAX and SAJAX...

I already started coding one - but as ext is a very big library and I have very small time at the moment it'll take me some time to make it write all of the possible codes and maybe someone did start something like that already and wants to share the code so we can melt it together and get the whole thing done in half the time.

I was thinking about releasing it under licenses like ext itselfe - or maybe even MIT, this has to be thought over after getting the thing itselfe into a nice shape which can be shown to the public.

Anyone interested in creating some php classes for ext? Or did anyone do something alike already?

[tryanDLS]

Ok, not to start a religious war here, but this isn't the 1st time somebody has had this idea. Why do people think it's a good idea to use one language to generate code for another language? Especially, if as you say you're not skilled in the target language. By the time you learn enough Javascript and the Ext framework to be able to generate code, you might as well just write the code. Given the number of features, configuration options and rapid expansion of the Ext framework, you can not possibly keep your generator in sync or up to date - it's an admirable goal, but you'll spend all your time doing that and no time writing code. You might say that once the effort is made, everybody will benefit. Maybe. But, just like .Net or Websphere or a host of others, you end up generating for the least common denominator and then you have to go and massage the generated code anyway.

[xel]

Hi tryanDLS - thanks for the quick answer.

Well - of course you are right with what you say - but as EXT is perfect for writing complex apps with use of php the thought isn't just too far down the road I think.

The real thing why I wanted to do this is just for creating a bridge between the languages which makes it more easy for every php-developer to generate a good gui for there apps without having to worry about JS (as not every good server-side coder is a good client-side coder I think).

You are perfectly right saying it is impossible to stay up-to-date for one person alone - but I think it is the spirit of open source that not only one person but many people are working on something (of corse this depends on popularity and the usability of whatever it is and on many other things). So I have the lil' hope that I wouldn't have to keep on track alone...and maybe the class would be not too far behind sometime.

As for your question about why people (I in particular, for I can not say anything about the thoughts of others) think it is good to generate code with another language - just because I need to generate the code anyway...
I need it in my php-app so I have to write php anyway. As the JS code which needs to be delivered has to be changes depending on many things it would be a good idea to change it with php and not to write many JS files which cover every possibility.
So I'll have to gernerate it with php - one way (echo) or the other (a class which echos it at the end). The way using a class is preferable, because I can reuse the code I already wrote and do not have to "recode the weel" anytime - and the code is more easy to maintain.

Maybe you know a better way for what I try to do (using slightly different JS Codes in many situations, depending on what was before) - if so please share it with me.

I really agree with you in every single point - but I see others too and I think we measure them differently. A big number of frameworks generate html-code and ajax/js code using helper-classes - I do not see any point why these helpers should be better than a helper for Ext - maybe you can give me an idea why this is the case (of course - ext is growing faster then HTML and there own JS-Scripts, but I think it is more powerful now then they are - so in my opinion it would be better being able to generate code for ext as it is now even when ext has been extended much then gernerating code which can do less then the actual ext...)

[prophet]

I don't want to speak for Jack or anything, but I think I remember hearing him say that something like this was in the works already.

[neror]

I don't want to speak for Jack or anything, but I think I remember hearing him say that something like this was in the works already.
I hope he's not working on it himself. His time is MUCH better spent working on Ext itself.

[brian.moeskau]

It would be news to me... If someone is working on this it's not the Ext team.

[jon.whitcraft]

It would be news to me... If someone is working on this it's not the Ext team.
I agree with Brian. It's news to me also. Guess we should ask Jack.. :D

[prophet]

I don't think Jack himself is working on it. I can't remember who he said is... Don't take my word for it though, I don't want to spread a rumor. Heh.

Thinking about it though, I'm not sure what good a PHP class would do.
Perhaps just some utility functions for Ext.form, to format expected responses?

What would you guys want to see in a ExtJS PHP class?

[jon.whitcraft]

I could see the usefulness in a db to form build php class as that would be handy and I've written some scribblings down about doing something like that but i haven't had the time to work on it yet. I think it php classes are built to be helper for specific type of things it could be really handy to some people.

Now I think that if it's done in PHP it would also be beneficial to have it done in Java, Perl, Python, .NET and what ever other programming language is out there for the web.

Just an idea and let me think about it more.

[Gozer]

I think there are several reasons to have a set of tools or a layer that can more or less generate ExtJS code.

- Catch more errors sooner if the layer validates your configuration as much as possible on the server-side first. A language like PHP is more forgiving and by implementing a PHP-to-ExtJS API, you will be less likely to have errors on the client side.

- Faster development - fix bugs in less places and in a more familiar language (what ever that may be), faster time to prototype software if you spend less time frustrating over the UI.

- Easier integration with existing frameworks - I already generate 80% or more of my model (DAO) and view, including forms. If I had a PHP-to-ExtJS layer I could integrate it into my generator and graduate from old-school UI to ExtJS much, much faster.

- It would also be easier to generate the application UI on the fly if the implementation is native to the language you're using. This is particularly helpful if you need to allow/deny parts of the UI, form fields, or change validation rules based upon user type, permissions, or modular configuration.

I'm playing with some scripts that can read the ExtJS API documentation and generate PHP classes that mirror the ExtJS classes and include stub classes that allow you to extend/override the limited behavior of the generated PHP code. I also use separate snippet files that contain the templates of javascript code. It's working so far by doing rough validation of the config options. There is more to do. Much of which might still need to be completed by hand. There are ExtJS methods and properties that aren't much use to anyone on the server side and so the PHP API needs to be designed to understand how to translate that behavior to js code that executes on the client side. I also believe I'll be writing another abstraction layer specific to my application that will further reduce the repetative configuration of things such as forms and tab panels.

Maybe when I get the PHP API to a point where I won't be embarrised, I'll kick it out to the community.

[noso]

I think there are several reasons to have a set of tools or a layer that can more or less generate ExtJS code.

- Catch more errors sooner if the layer validates your configuration as much as possible on the server-side first. A language like PHP is more forgiving and by implementing a PHP-to-ExtJS API, you will be less likely to have errors on the client side.

- Faster development - fix bugs in less places and in a more familiar language (what ever that may be), faster time to prototype software if you spend less time frustrating over the UI.

- Easier integration with existing frameworks - I already generate 80% or more of my model (DAO) and view, including forms. If I had a PHP-to-ExtJS layer I could integrate it into my generator and graduate from old-school UI to ExtJS much, much faster.

- It would also be easier to generate the application UI on the fly if the implementation is native to the language you're using. This is particularly helpful if you need to allow/deny parts of the UI, form fields, or change validation rules based upon user type, permissions, or modular configuration.

I'm playing with some scripts that can read the ExtJS API documentation and generate PHP classes that mirror the ExtJS classes and include stub classes that allow you to extend/override the limited behavior of the generated PHP code. I also use separate snippet files that contain the templates of javascript code. It's working so far by doing rough validation of the config options. There is more to do. Much of which might still need to be completed by hand. There are ExtJS methods and properties that aren't much use to anyone on the server side and so the PHP API needs to be designed to understand how to translate that behavior to js code that executes on the client side. I also believe I'll be writing another abstraction layer specific to my application that will further reduce the repetative configuration of things such as forms and tab panels.

Maybe when I get the PHP API to a point where I won't be embarrised, I'll kick it out to the community.

I'm looking for that for a long time with no success:((!

[Darklight]

you can switch to ColdFusion and use cfext (http://cfext.riaforge.org/) ;D

[esra]

Was there not an a university-based project capable of generating Java and/or PHP code from UML diagrams using a converter? I believe that this project still exists but I personally have not been following its progress.

Off topic, but there is also the PHP-EXT wrapper project here:

http://php-ext.quimera-solutions.com/

A separate wrapper project such as the one above running in parallel with EXT JS development releases might do well if the project is maintained on a continuous basis.

[nlotz]

Off topic, but there is also the PHP-EXT wrapper project here:
http://php-ext.quimera-solutions.com/
Note: PHP-Ext is LGPL-licensed and seems deserted, as there is not a single commit in the repository that took place after ExtJS changed to GPL.

[esra]

Note: PHP-Ext is LGPL-licensed and seems deserted, as there is not a single commit in the repository that took place after ExtJS changed to GPL.

The most recent blog entries in August and the mailing list suggest additional work on this project is underway. The LGPL license is for the wrapper classes, but the EXT JS GPL and commercial licenses continue to apply. It would be good to know from Jack if the LGPL license on the wrappers is considered to be a problem. The authors do not redistribute EXT JS or or Codepress with the wrapper package.

Based on some tests I made last week with the Complex layout and one of my CodeIgniter ME module suites, the wrappers do work with the current 2.2 release.

[abe.elias]

We recently released our FLOSS License Exception for Development (http://www.extjs.com/products/ux-exception.php) specifically to address the needs of Open Source projects that desire to use a more permissive license.

PHP-Ext licensed under the LGPL is perfectly ok.

[nlotz]

PHP-Ext licensed under the LGPL is perfectly ok.
Does the same apply to GWT-Ext (http://gwt-ext.com) ?

[abe.elias]

Yes the same applies to gwt-ext.