I recently got chance to work on Ext JS 4+ MVC. This post tries to state some experiences, so that it can help other companies and developers making wise decisions about opting Ext JS for a business requirement. We will explore Ext 4 MVC in general and salesforce point of view in the points below:
So, even if multiple developers are programming in EXT MVC style, it would be easier for one developer to understand what other guy has done.
This becomes bigger challenge when one tries to start with latest Ext 4.1 MVC. As, most of the examples on Sencha portal are non-mvc based, and their are very limited tutorials and help available online.
For me it was little bit comfortable because of past Flex and Swing experience, and close similarities between Ext and these technologies. But as both Flex/Swing are out dated now, I doubt others will get this comfort.
Finding right talent is very hard for Ext JS, I feel in general and in my professional circle jQuery + jQuery mobile is extremely popular. If I raise voice for any assistance in jQuery flood of help will come, but extreme reverse happened at least for me when I worked in Ext. I was working on Ext JS 4.1 MVC, help was required on MVC part, best I could find is few guys with some experience in Ext 3, and those are not motivated to learn Ext 4.1 MVC. So this makes it not only hard, but costly to find a correct resource for Ext JS, as this seems to be a rare skill for me.
#2 Ext gives Rich Container/Layouts
Flex or Java swing style layout model with plenty of good layouts like Border, Card, Table, HBox etc.
These layouts are tested across all A-Grade browsers and take off complexity of arranging UI elements.
#3 Ext gives rich component library
Rich library components are available for everything ranging for Tabs, Grids, Buttons etc.
Again, as with layouts these components give rich and stable interface, with cross browser stability and ease to developer.
None if you’re not in salesforce ecosystem. In Salesforce, its a dramatic UI change. A salesforce customer will feel like in different world if he stumbles upon an Ext JS screen.
#4 Ext gives rich variety of Proxies
Proxies are used by EXT for performing CRUD operations on Model, they usually tie up with store to provide the DAO layer. Variety of proxies to handle various forms of communication are available ranging from server side ones like Ajax, REST, Direct and client side like Memory, LocalStorage. For more details please check http://docs.sencha.com/ext-js/4-0/#!/api/Ext.data.proxy.Proxy
Clean isolation of data access via proxies is very helpful in big applications. Such proxies allow easy mocking of services in early stages of development, via MemoryProxy etc.
Apart from isolation proxy and store work really well to do handle common app requirements like
- errorMessage response
- custom ID attribute mappings etc
All the above can be achieved by simple configuration.
- REST Proxy : This doesn’t easily maps Consuming REST services or Apex REST services in Salesforce, you need to write decent code in Ext just to make proxy work right with force.com REST services. A sample component for REST Proxy in force.com is here for reference. Overall these are key disadvantages of using force.com REST services in Ext
- Doing so much code to make Ext and force.com REST services talk defeats the purpose and beauty of EXT because thats not the business requirement, it turns more to be a GEEK’s experiment to make the assembly work.
- If the Ext screens are in heavy use one can easily hit 1000/5000 API call limit in 24 hours or 25 concurrent call limit as well in case many users like customer portal or sites users are accessing the same page. More details here : http://login.salesforce.com/help/doc/en/integrate_api_rate_limiting.htm
- JSON Proxy: One can create a hacky visualforce page to give partial read and update support via this hack. But this doesn’t works well as all CRUD is not possible and code becomes unmaintainable for big apps.
Conclusion : When is Ext JS right for Force.com Platform ?
Force.com platform comes with its on rich and fluent HTML interface, as a developer one should try to reuse native CRUD functionality via Standard/Custom object tabs as much as possible. In case one needs a custom complex screen, developers should try making best use of existing visualforce components like detail, pageBlock, sectionheader, pageBlockTable etc. This keeps your custom screens look like native and doesn’t creates a shock to salesforce users when they stumble upon your visualforce pages.
So, where does Ext fits in ? I would say we should use Ext very carefully only where its really required, we have really good examples in salesforce only i.e. most of the screens are in normal HTML/CSS only, complex ones like Page Layout editor is the one that requires a quick and rich experience on client side, so Ext is used. So developers should use rich ext components like grids, charts etc, where something beyond available visualforce components is really required.
Special thanks goes to Jeff Trull he has done some amazing work with Ext and helped me in fighting Ext JS issues as well.