The ExtJS framework has a GridPanel object with the ability to group items into sections defined by the developer. It uses a GroupingStore, and a GroupingView in order to visually group items into a loose tree-type structure.
The biggest benefit to that mechanism is that the framework handles all the sorting, DOM elements and interaction code to make it possible.
However, if you’re not using a GridPanel (it’s a heavy component) and just want to display your data in a series of panels, there is no automatic way to group your data, so you need to roll your own code.
Luckily, the framework provides plenty of helper methods to make this a fairly trivial task. All I needed to do was extend the Ext.Panel class and, on initialization, use the collect() method on the assigned Store to determine the groups, and then use the query() method to get all records assigned to each of the groups.
See this code in action using HBox and VBox layouts.
Ext.ux.GroupedPanel = Ext.extend(Ext.Panel, {
itemConfig: {
tpl: new Ext.XTemplate(''),
selector: '',
margins: ''
},
dataConfig: {
store: new Ext.data.Store({}),
records: null,
groupColumn: ''
},
initComponent : function(){
var group_records,i=0,group_panels=[], groups;
// Initialize superclass
Ext.ux.GroupedPanel.superclass.initComponent.call(this);
// If a data structure is specified, load it into the store
if (this.dataConfig.records != null) this.dataConfig.store.load(this.dataConfig.records);
// Use the collect() method to get the unique values in the specified group column
groups = this.dataConfig.store.collect(this.dataConfig.groupColumn);
// Loop through each group
for (; i < groups.length; i=i+1){
// Use the query() method to get the records in the current group
group_records = this.dataConfig.store.query(this.dataConfig.groupColumn, groups[i]);
// Create a panel to contain the current group's records
// Use the specified XTemplate and itemSelector
group_panels[group_panels.length] = new Ext.Panel({
frame: true,
flex: 1,
margins: this.itemConfig.margins,
title: groups[i],
items: new Ext.DataView({
store: group_records,
tpl: this.itemConfig.tpl,
autoHeight: true,
itemSelector: this.itemConfig.selector
})
});
}
// Add all of the group panels to this
this.add(group_panels);
}
});// This panel will contain all group panels, using the vbox layout to
// stack them vertically, and also stretch each panel to its width.
var ContainerPanel = new Ext.ux.GroupedPanel({
layout: 'vbox',
layoutConfig: {
align: 'stretch',
pack: 'start'
},
height:600,
dataConfig: {
store: TeammateStore,
groupColumn: 'Department',
},
itemConfig: {
tpl: new Ext.XTemplate(
'<tpl for=".">',
'<div class="teammate" id="{tmID}">',
'<div class="thumb">{tmID} - {Teammate}</div>',
'</div>',
'</tpl>'
{
compiled: true
}
),
selector: 'div.teammate',
margins: '10 0 0 0'
}
});
ContainerPanel.render('group-grid');Now that I have some solid WPF coding under my belt, I felt like speaking out a little about how it compares, in my mind, to developing in Flex and Actionscript.
First, and foremost, I have to say [BINDABLE] FTW!! That one thing alone sums up the rest of my ramblings below, and you can probably skip the rest of this article if you wish after you read the next opinion.
The cultures of Adobe and Microsoft are best reflected in how you accomplish any development feat – Adobe did its best to make sure the “little stuff” is handled behind the scenes so that development can be done as quickly as possible, while Microsoft assumes absolutely nothing and requires you to write dozens of lines of code to achieve even the simplest of development goals.
If you want absolute, iron-gripped control over every single feature of your application, and want to hand-craft almost every piece of customization or abstraction that is needed, then the Microsoft stack is definitely for you – the uber geek, the one who takes tremendous pride in his mastery of every aspect of his application.
Unfortunately, WPF still has a little ways to go to catch up with the power and features of Flex. Of course, WPF is for desktop apps and runs as a native assembly, and doesn’t need a third party installation that is, admittedly, more bloated and use a bit more memory.
If you want to focus on functionality, and get products/updates released as quickly as possible, and could care less what magic goes on when you bind a Collection to a DataGrid, then the Adobe stack is for you – the quasi geek, the one who needs to do the design, the architecting, the development and the support, and doesn’t have time to spend hours hand-crafting simple tasks that the software should obviously be doing for you.
However, I think the folks at Adobe heaved a huge sigh of relief when Microsoft announced that Silverlight’s focus will now be for mobile development only. Given time, Silverlight would have been a superior product to Flex (on Windows).
For me, I much prefer the Adobe ideology. Perhaps it’s the Star Trek geek in me. My philosophy when it comes to development stems from years of watching Star Trek: The Next Generation. Does that make me an uber geek anyways? Perhaps.
When critical software and systems needed to be modified on the Enterprise, did you see Jordi sit down at a computer terminal, bring up a development environment and figure out how to expose the correct property change event, make sure it implemented the correct interface, open another file to map the property to the system, and then open another file to make sure it looked right (all in a proprietary language that NO ONE ELSE uses)?
No. By the 25th century, they finally get it. Superior engineers – whether they work on software, or warp engines – want the basic tasks done for them if possible. It saves time, and makes work a lot more fun. If I can add a new column to a dataset and have it displayed in my interface in 1 minute, then I’m all for it.
Sure, there are still people in the world who would rather take the 30 minutes to do it “right” by writing every single line of code needed to perform the task.
Sorry, not me. I got shit to do.
It’s been a bit hectic at work in the last 2 years. Well, perhaps hectic isn’t the perfect word, but it’s close. Since I started working here, we’ve gone through two complete development technology stack switches.
Back in the halcyon days of 2007, I had the unenviable task of shoring up some very hastily written applications (by database developers and a couple of hacks who were here before me) using ColdFusion and HTML/Javascript. I beefed up the corporate offerings by implementing industry-accepted practices and patterns, used well-established libraries and got upgrades to the ColdFusion servers.
Then, in late 2008, the decision was made to scrap any future development of HTML/Javascript user interfaces and use Flex instead. That was exciting because of two reasons:
Fast forward to 2010 and now the entire company is rolling over to the .NET stack. Now I get to brush up on my rusty C# skills which I haven’t used in almost 4 years; I get to learn the ASP.NET MVC architecture; I get to have fun learning how to connect our .NET applications to our Oracle databases; lastly, I get to estimate how long it would take to convert our entire ColdFusion code base to .NET.
I’ll still get to work in ColdFusion from time to time, but .NET is the future…. for now. Perhaps 2012 will be the year we convert everything to Java!
I’m all for rolling with the punches and evolving my skill set to match what is needed for the organization to be successful, but I’m also no longer 24 years old with oodles of free time at my disposal (or the accompanying mental agility). Doing these massive switches takes a little more time at my venerable age.
** This post has been removed due to my company’s Internet policies **
Well I’ve finally reached a point in my latest AIR application where I can write up a useful review of the framework I chose to use: Mate.
In my continuing effort to avoid Cairngorm, I’ve been evaluating other Flex frameworks that are lightweight, rapid and comprehensible. In the application previous to this, I implemented PureMVC, and while I did not get to use all of the features, I did think it was a greater balance of ease and power than is Cairngorm, but was still rigid on implementation.
For me, the purpose of any design framework is to enforce some standard patterns to create a scalable, flexible application, while allowing the actual implementation up to the developer and architect. Cairngorm does not fit this idea, and PureMVC came close, but still heavily regulated how the application was structured and implemented.
Mate, on the other hand, simply provides the mechanisms for enforcing a design pattern, while allowing more creativity and flexibility on how to implement it. Foremost to this is its use of the native event model in Actionscript for handling the application behavior. The tags provided by Mate simply add a layer of abstraction on top of this system that makes it both more powerful and more flexible (not to mention easier to learn).
Another concept that I found attractive is that you can break up your application into very granular pieces when you are creating a large project, but also have the ability to combine aspects together for a small application with only a handful of views and events.
Want to combine your event handlers and property injectors into the same file? No problem. They even provide different examples on their site that shows different implementation styles.
I can’t gush enough about the tags available in Mate. Again, another benchmark for me on a valuable framework is how much menial coding it does for me. Hmm, that sounds familiar to another tag-based technology that I enjoy so much. What was that called again?
How do you get objects returned from a RemoteObject call injected into the view? It can’t be much more simple than this:
<Injectors target="{MyModel}">
<PropertyInjector source="{MyEmployeeManager}" sourceKey="employees" targetKey="arrEmployees" />
<PropertyInjector source="{MyProjectManager}" sourceKey="projects" targetKey="arrDivisionProjects" />
<PropertyInjector source="{MyResourceManager}" sourceKey="resources" targetKey="arrPhysicalResources" />
</Injectors>How about event handlers? It makes it real easy to find what you’re looking for when you have a tag named EventHandlers with child tags called RemoteObjectInvoker and MethodInvoker.
<EventHandlers type="{EmployeeEvent.GET_ALL}">
<RemoteObjectInvoker ...>
<resultHandlers>
<MethodInvoker generator="{MyEmployeeManager}"
method="handleResponse"
arguments="{resultObject}"/>
</resultHandlers>
</RemoteObjectInvoker>
</EventHandlers>Ever seen a Hello World example written using Cairngorm? I have and it’s not pretty. I even wrote up a demo on our internal Wiki for a Hello World application using PureMVC. It wasn’t much prettier. It required 12 steps to explain all the mechanisms involved.
In Mate, the required code to get a remote “Hello World!” string and display it in a view in almost laughably simple in comparison. They have a view injection diagram on their site that is a nice representation of how it works in the Mate framework.
In case the tone of my opinions in this article wasn’t a giveaway, I am a fan of Mate. It’s definitely something I’m going to keep evaluating for our future applications. I still have one more framework to look at – Swiz – which a colleague of mine has already starting investigating. What he has shown me so far is also impressive.
All in all, I’m glad that there are now frameworks out there that deliver on the promise of power and flexibility instead of just power.
