January 17, 2012 Ted Patrick
I wanted to share my thoughts on my progress learning Ext JS 4.1 as a developer new to Sencha. As an application developer I have used many different development environments and application frameworks throughout my career and whenever I learn something new I compare back to my experience. Overall I have been very impressed with Sencha frameworks as they provide a professional foundation to build an application atop.
Interpreted
The single hardest shift for me is embracing the interpreted nature of JavaScript within the Ext JS framework in general. While not new to interpreted systems, I personally expect compiler emitted errors/warnings/flags, syntax auto-completion, and strong typing for member variables, return types and assignments. Having come most recently from Java, I find that being shown errors and autocompletion as I type is a great productivity enhancement but these benefits are tied to the nature of a strongly typed and compiled language. The general lack of these facilities in working with JavaScript is really the first hurdle in moving to web technology. Truth is, as I got more comfortable with the interpreted nature of the the language, I quickly found myself enjoying the advantages:
- JavaScript’s flexibility is a double edged sword. The language’s freedom is a joy but you must use best practices to avoid common pitfalls.
- Modern browsers offer developers great insight into application behavior at runtime. I have found the Chrome developer Console and Debugger JavaScript tools to be invaluable.
- Ext JS uses JavaScript as a meta-language to provide deeper OOP/MVC/Class Loading/Mixin support is very elegant for larger scale application development. These facilities exist in very few frameworks and really differentiate Ext JS and Touch. The ability to extend components or leverage a clean MVC pattern within an application make it very developer friendly as a framework.
- Leveraging JavaScript object literals and JSON for data/component instantiation is very productive. The ability to load components remotely, define UI as objects at runtime, and leverage client layout templating is very powerful. The syntax of larger object literals using xtype takes some getting used to. I found myself formatting my code more than normal to avoid the dreaded missing comma errors deep within an object literal.
- Using the Eclipse VJET Plugin was a great productivity boost for JavaScript and Ext JS development. The plugin provides auto-completion for JavaScript and there are several open source syntaxes for Ext JS. Being able to see instances, warnings/errors, and in-context return types is a very pleasant addition based on my past experience. VJET VJET+ExtJS
Ext JS “Standard Library”
Ext JS provides a foundational set of helper classes and methods to make building applications easier. I found that the Ext.Array, Ext.Date, Ext.String, Ext.Object, Ext.Loader classes make working with data very easy and generally simplify building applications. Every application will use these common libraries and having them included and integrated into the framework is great.
Ext.require( [ 'widget.*' , 'layout.*' , 'Ext.data.*' ] ); Ext.Array.each( [ 1, 2, 3, 4 ], function( name ) { console.log( name ); }); Ext.Object.getSize( { age:23 , height:6, name:"Ted" } ); //3
Containers
Ext JS provides a rich set of containers (Ext.window.Window, Ext.panel.Panel, Ext.container.Container, Ext.grid.Panel, etc.) to allow developers to easily create nested views and more complex application logic. In Ext JS, containers’ layout behavior is programmatic and allows you to set the behavior of a container at runtime to ‘vbox’, ‘hbox’, or any of the Ext.layout.container types. Additionally you can set sizes dynamically by assigning values to the ‘flex’ property on items within a container.
Xtype
Ext JS provides a loosely typed data format called Xtype to allow you to pass trees of containers and controls as a single object. It is a very, very powerful technique and really makes building lots of UI components at all at once easy. In Flex and Android I used declarative XML for component initialization and layout but these are closely tied into compiler workflow. In an interpreted system, you want to leverage a format that is rapidly parsed and supports remote loading. As Xtype is a JavaScript Object Literal, it is parsed at the speed of the JavaScript engine in use. On both mobile and desktop targets, this is very fast. While you can create components independently, using xtype for component generation is much more productive once you get the hang of it. Here are 3 xtypes passed within an Array:
[ { xtype: 'container', html:'First Item', flex:1 } , { xtype: 'splitter' } , { xtype: 'container', html:'Second Item', flex:1, maintainFlex:true } ]
If this were assigned to a container’s ‘item’ property, it would render a split view. I found this very simple and elegant, compared to the complexity in other frameworks.
Styling
I have styled components in several frameworks. In Ext JS, abstracting style properties as runtime loaded CSS for all components is very powerful. Better still, generating CSS from the providedSASS/Compass source formats makes building a global style change quite easy. In both Flex and Android, style is baked in at compile-time and is less flexible than a runtime interpreted model. While I now feel comfortable generating a base color change in Ext JS, it will take me some time to absorb the finer details of CSS styling of the components. This is easily one of the more complex areas of the framework and will take me time to fully understand.
Hello Sencha
Given this is my first real post on Ext JS on Sencha.com, I thought it would be good to post the simplest example possible. The example creates a window with an image inside. Feel free to paste into a local html file and open in a browser.
Hello Sencha
I will continue to document my journey learning Ext JS and Touch frameworks as I go. There is clearly a lot to learn and hopefully sharing my experience will help others new to Sencha. More to follow.
댓글 없음:
댓글 쓰기