In fact, Ext (pre 4) is almost just like MFC in that it is primarily a collection of UI widgets that you can put together in any way you wish. This is great for very small UIs that do not have a lot of interconnected parts, but once the number of interconnected item reaches more then a few (say 5 or 6) then it is nearly impossible to map all the emergent properties mentally. Enter MVC.
MVC is a design patter created over 30 years ago, whose sole purpose is the separation of concerns. Business logic (model) is separated from UI (view) and they communicate via a defined set of actions (controller). Anyone familiar with UI programming should be familiar with this pattern. It is used in almost all major UI libraries except ExtJS, until now.
Ext4 aims to fix this flaw by retooling the framework to be MVC. It is almost successful. There is a major problem in separating models from collections (which is understandable given Javascript's nature) but there are more elegant solutions then the one Ext4 uses (see SproutCore and Backbone). There are far too many annoyances at the model level for me to detail here, but as an example the LocalStore and MemoryStore are broken as of this writing and cannot update or remove models since they do not fire events. This problem can be seen is a number of their own grid demos.
I also tried to use the compatibility mode to convert an older Ext3 app to Ext4. I was successful in removing all of the errors and most of the warning, but could not get the page to render. Each component thought it was rendered, but no DOM was presented to the browser. Lots of digging later and it turns out you can't mix MVC Ext4 objects with non-MVC Ext3 like objects. Not sure why, and without errors it is hard to tell what went wrong.
Finally I started from scratch and created extjs4-frame so that I could dig in without having to worry about Ext3 compatibility screwing things up. Thing did not go much better. I watched the videos and then dove right in. As expected what was shown on the videos (obviously dumbed down) worked as expected, but as I started to add complexity things would break in mysterious ways. Turning to the documentation was only marginally helpful, since it appears that it has not been full updated. Also, some of the documentation does not match the JDoc comments in the source (probably human error in generating the docs). This is an annoyance to be sure, but not a show stopper since I know how to read Javascript (as anyone that would be using ExtJS should). However, documentation error (especially when generated from embedded comments) are indicative of a lack of attention to detail and since they do not provide their unit tests I can only guess that their storage engines are not well tested either.
Pros
- Documentation videos are a nice touch
- Simplified code due to the MVC nature
- Sensible file structure (forced)
- Auto-loader (turn off in production, but great for development)
- Better stack and error handling (as compared with Ext 2/3)
- Trees use real models (meaning the server can respond with any hierarchical objects)
- Non-flash based charts
- Smaller size (as compared to Ext 2/3)
- Difficult to understand (even for those with MVC and ExtJS experience)
- No backwards compatibility (the compatibility mode is a joke)
- 4.0.X versions are not guaranteed compatible (there are still a lot of internal changes going on)
- Documentation does not always match source comments and is not always correct (save some time and just start with the code)
- Inconsistant Model/Container behavior
- No generator scripts provided for aiding design patterns
- No unit testing framework provided
- No JS compiler/minifier provided (one that can read the requires directive is almost a must now that they exist)
Overall
Wait for 4.1 to see if things stabilize. Or switch to SproutCore.
No comments:
Post a Comment