joeri
13 Aug 2009, 7:16 AM
Hello everyone,
I work for a Belgian software and services company specializing in real estate and facility management.
We've recently concluded the first phase of the migration of our web application suite to the ExtJS library, and I thought this was an excellent opportunity to reflect a bit on our experiences in integrating Ext into an existing codebase.
Our web application is a little over 200.000 functional lines of code, with page design based on custom-developed PHP form libraries. Up until a year or two ago, it served mostly as an "add-on" to our windows application suite, but with the market moving to the web, we were seeing rising market pressure to deliver more complex functionality, on par with what we deliver in our desktop apps. It was difficult to realize this cost-effectively on the technology base that we had. At the same time, the rise of web 2.0 has changed user expectations, and the in-house developed look and feel just didn't cut it anymore (we don't have a dedicated design team). Because of this, we started looking at javascript toolkits to replace our UI with, and eventually settled on ExtJS, mostly because it had the most polished component set.
Due to the size of the codebase relative to our manpower, porting the entire suite all at once was not an option. The solution we came to was replacing it from the outside in. First changing the navigation elements, and then gradually replacing the different modules and module segments with ExtJS screens. The development was done on ExtJS 2, but because it took only a day of work to migrate, we'll be shipping on ExtJS 3.
The migration of the navigation turned out to be quite easy. In a matter of weeks, we went from this:
http://sebrechts.net/files/2009/mymcs/9_5.PNG
To this:
http://sebrechts.net/files/2009/mymcs/10_0.png
You can tell that the actual feature segment itself is still using our old UI code, but it's embedded in an iframe, and the surrounding ExtJS UI makes the whole thing appear more modern, especially when you start clicking around in the navigation. We used the opportunity of the redesign to shuffle around the navigation a little bit, enhancing its usability. I'm personally very happy with the result. The UI has a lot of small usability improvements, such as true URL's behind the navigation tree nodes (before they were javascript handlers only), so that users can right-click to "open in a new window" or to bookmark. Another improvement is the use of tabbed navigation, where now the user can load more than one module at the same time, instead of being restricted to working with one module at a time.
Once we had the navigation up and running, to learn more about ExtJS, we built a new module that embedded a gadget portal:
http://sebrechts.net/files/2009/mymcs/10_0_today.png
This took a bit longer, a few months of work. Administrators can design layout templates, mixing external pages with custom gadgets that show the user's calls, reservations, work orders, and so on... They can also restrict how users are allowed to modify those gadget pages. The gadget portal example was a big help, as were the forums. The component set offered by Ext is very rich, and was easily adapted to our purposes. We simply couldn't have built anything like this as fast as we did it using Ext, let alone with such a nice look and feel. I know there are a few people on these forums that are unhappy with Ext's ability to adapt to their needs, but I found that by just adapting my designs to what Ext is good at, design and development went very smoothly.
Throughout the whole experience the remarkable thing was the ease of cross-browser support. Cross-browser bugfixing went almost to zero. I would build some feature in firefox, open it in IE or Chrome, and it would just work. Very different from what I was used to.
There were ofcourse some challenges specific to Ext that we didn't have in our old way of working. Most notably:
- Because we have to load functionality on-demand, we had to work out an on-demand loading infrastructure. We ended up writing a custom on-demand loader with dependancy tracking, double-load request detection (multiple modules trying to load the same file at roughly the same time), and preconfigured packages (e.g. single command to "load the grid and our grid extensions"). This was one area where Ext didn't provide a good solution out of the box, and none of the community solutions were quite what we needed.
- Because Ext components are loaded as .js files, we had to figure out how to get state into them. We ended up settling on a JSON-RPC web services infrastructure. The container page obtains a session token and some basic information, and provides this to all components running in the container. Each component after loading runs a web service request (to an URL relative to the page's base URL), to fetch its configuration and update its layout accordingly. The standardization in client-server communication turned out to dramatically simplify development and security architecture, and opens the door to letting customers write their own front-ends to our system. Ext.Direct wasn't considered because we developed on version 2.
- Translation, normally done with the static js files, was complicated by the fact that we allow users to edit their own translations. The solution we arrived at was generating translation override files from PHP. This behaves for all intents and purposes like the static js translations, but the translations are fetched from our back-end storage instead of from static files. Changing language reloads the entire UI, which is not ideal, but no worse than the old system.
- The difference in development practices between our old way of working and the ExtJS way of working is enormous. Before the UI was generated mostly in PHP, with a sprinkling of Javascript. Now the UI is generated entirely in javascript. It has not been easy to retrain developers in the new way of working, especially hampered by a disjointed collection of best practices documentation. The community's efforts are definitely appreciated, but they are not as well-organized and authorative as we wanted. I ended up doing code reviews to "fix" bad practices with a corrective approach. It would help to have better "official" best practices documentation, with a holistic approach focused around entire application development, and assuming only basic javascript knowledge. I bought "Learning ExtJS", but found it too simplistic and too light on best practices guidelines.
Overall though, we are quite happy with ExtJS. It has noticeably improved our ability to deliver great software, and that's what matters at the end of the day.
I work for a Belgian software and services company specializing in real estate and facility management.
We've recently concluded the first phase of the migration of our web application suite to the ExtJS library, and I thought this was an excellent opportunity to reflect a bit on our experiences in integrating Ext into an existing codebase.
Our web application is a little over 200.000 functional lines of code, with page design based on custom-developed PHP form libraries. Up until a year or two ago, it served mostly as an "add-on" to our windows application suite, but with the market moving to the web, we were seeing rising market pressure to deliver more complex functionality, on par with what we deliver in our desktop apps. It was difficult to realize this cost-effectively on the technology base that we had. At the same time, the rise of web 2.0 has changed user expectations, and the in-house developed look and feel just didn't cut it anymore (we don't have a dedicated design team). Because of this, we started looking at javascript toolkits to replace our UI with, and eventually settled on ExtJS, mostly because it had the most polished component set.
Due to the size of the codebase relative to our manpower, porting the entire suite all at once was not an option. The solution we came to was replacing it from the outside in. First changing the navigation elements, and then gradually replacing the different modules and module segments with ExtJS screens. The development was done on ExtJS 2, but because it took only a day of work to migrate, we'll be shipping on ExtJS 3.
The migration of the navigation turned out to be quite easy. In a matter of weeks, we went from this:
http://sebrechts.net/files/2009/mymcs/9_5.PNG
To this:
http://sebrechts.net/files/2009/mymcs/10_0.png
You can tell that the actual feature segment itself is still using our old UI code, but it's embedded in an iframe, and the surrounding ExtJS UI makes the whole thing appear more modern, especially when you start clicking around in the navigation. We used the opportunity of the redesign to shuffle around the navigation a little bit, enhancing its usability. I'm personally very happy with the result. The UI has a lot of small usability improvements, such as true URL's behind the navigation tree nodes (before they were javascript handlers only), so that users can right-click to "open in a new window" or to bookmark. Another improvement is the use of tabbed navigation, where now the user can load more than one module at the same time, instead of being restricted to working with one module at a time.
Once we had the navigation up and running, to learn more about ExtJS, we built a new module that embedded a gadget portal:
http://sebrechts.net/files/2009/mymcs/10_0_today.png
This took a bit longer, a few months of work. Administrators can design layout templates, mixing external pages with custom gadgets that show the user's calls, reservations, work orders, and so on... They can also restrict how users are allowed to modify those gadget pages. The gadget portal example was a big help, as were the forums. The component set offered by Ext is very rich, and was easily adapted to our purposes. We simply couldn't have built anything like this as fast as we did it using Ext, let alone with such a nice look and feel. I know there are a few people on these forums that are unhappy with Ext's ability to adapt to their needs, but I found that by just adapting my designs to what Ext is good at, design and development went very smoothly.
Throughout the whole experience the remarkable thing was the ease of cross-browser support. Cross-browser bugfixing went almost to zero. I would build some feature in firefox, open it in IE or Chrome, and it would just work. Very different from what I was used to.
There were ofcourse some challenges specific to Ext that we didn't have in our old way of working. Most notably:
- Because we have to load functionality on-demand, we had to work out an on-demand loading infrastructure. We ended up writing a custom on-demand loader with dependancy tracking, double-load request detection (multiple modules trying to load the same file at roughly the same time), and preconfigured packages (e.g. single command to "load the grid and our grid extensions"). This was one area where Ext didn't provide a good solution out of the box, and none of the community solutions were quite what we needed.
- Because Ext components are loaded as .js files, we had to figure out how to get state into them. We ended up settling on a JSON-RPC web services infrastructure. The container page obtains a session token and some basic information, and provides this to all components running in the container. Each component after loading runs a web service request (to an URL relative to the page's base URL), to fetch its configuration and update its layout accordingly. The standardization in client-server communication turned out to dramatically simplify development and security architecture, and opens the door to letting customers write their own front-ends to our system. Ext.Direct wasn't considered because we developed on version 2.
- Translation, normally done with the static js files, was complicated by the fact that we allow users to edit their own translations. The solution we arrived at was generating translation override files from PHP. This behaves for all intents and purposes like the static js translations, but the translations are fetched from our back-end storage instead of from static files. Changing language reloads the entire UI, which is not ideal, but no worse than the old system.
- The difference in development practices between our old way of working and the ExtJS way of working is enormous. Before the UI was generated mostly in PHP, with a sprinkling of Javascript. Now the UI is generated entirely in javascript. It has not been easy to retrain developers in the new way of working, especially hampered by a disjointed collection of best practices documentation. The community's efforts are definitely appreciated, but they are not as well-organized and authorative as we wanted. I ended up doing code reviews to "fix" bad practices with a corrective approach. It would help to have better "official" best practices documentation, with a holistic approach focused around entire application development, and assuming only basic javascript knowledge. I bought "Learning ExtJS", but found it too simplistic and too light on best practices guidelines.
Overall though, we are quite happy with ExtJS. It has noticeably improved our ability to deliver great software, and that's what matters at the end of the day.