For everyone who attended, thanks very much for your participation…it definitely means a lot and I hope the sessions were as informative as they were fun to create.
If you didn’t get a chance to attend, the sessions recordings have been posted (see links below).
ColdBox Developers Week is not over, though–there are still a TON of great sessions through the remainder of the week, so be sure to check out the lineup and attend as many as you can. I promise you will not be disappointed!Criteria Builder In Action
If you haven’t already (what, you haven’t? FOR SHAME!), be sure to register for ColdBox Developer Week, starting…well…today! This is a great week of really great sessions covering ColdBox, ContentBox, WireBox, AOP, ORM…phew!
Even if you don’t use ColdBox (yet…), I’d still encourage you to check out some of the sessions. It will give a you a good insight into what you’re missing out on
I’m particularly exited about this CBW, as I have the privilege of presenting two sessions!Criteria Builder in Action (6.17.2013 – 11:00 AM Central)
With ColdBox’s CriteriaBuilder, you can build powerful and dynamic Hibernate criteria queries with very little code. But does it work in real life? To put that question to the test, we’ll explore some real life scenarios and see how CriteriaBuilder can help usBuilding CKEditor Plugins for ContentBox (6.17.2013 – 3:00 PM Central)
In this session, we’ll learn how to extend CKEditor within ColdBox to provide rich, custom content editing capabilities. We’ll also explore how custom CKEditor plugins can be integrated with ColdBox modules to take content editing to the next level.
Hope to see you there!
If you’ve been following along the last couple weeks, we’ve been walking through the process of building a real(ish) application using ExtJS 4.2. We’ve made great progress, and we’re literally on the precipice of bringing together all the supporting pieces that we’ve been building thus far.
While I’m wrapping up the next installment, I have some homework for you If you’ve been building your app in tandem with these walkthroughs, I’d encourage you to tackle the list I describe below. Not only will this put in place some pieces that are necessary for the next steps (and which I won’t necessarily cover in any detail), but will also give you a chance to try out some stuff on your own and get some very useful experience under your belt before we continue.The Homework New CRUD Lists
The first thing to tackle is a few more of our favorite CRUD grids:
Both of these can have the same structure as the Color, Category, Feature, etc. tables. However, to make things a bit interesting, we’ll also want to create a foreign key on Model that will associate the relevant Make.
NOTE: As you’ll remember, our “option” editable grid is used by all our CRUD tables. it is More >
After not one, but TWO diversions, we’re finally back on track! If you remember from our last installment, we built a handy editable grid with support for all our fancy CRUD actions. We also saw that we could build this in a very abstract way, thus accommodating a lot of separate but similar models, yet with very little code duplication.
While this approach definitely has its place, there are times when our data becomes a bit complex and no longer lends itself very well to the editable grid. In these cases, it’s probably best to go back to the ol’ web form…which is precisely what we’ll do.A Bit o’ Planning
Before we start hacking away at a form, let’s plan out what we’ll need. What we want to build in this installment is a management tool for Sales Staff. This has a few initial requirements:
- Display sortable list of all Sales Staff
- Allow for adding new Sales Staff members
- Allow for editing existing Sales Staff members
And here is the data that management wants us to collect:
- First Name
- Last Name
- Date of Birth
- Address (Addy 1, Addy 2, City, State, Zip)
- Hire Date
- Position (a value from our “Position” table)
Now that we have our requirements, let’s think through the kinds of ExtJS assets we’ll More >
Theming in ExtJS 4.2+ is a beautiful, tricky, complicated mistress. On the one hand, it has been completely reworked (for the better…mostly) to be a lot more extensible, take advantage of theme inheritance, care less about how themes are created (and where), and a host of other really nice features.
However, the elegance of the new theming engine comes with a price…namely, a steep learning curve (I should know, I’m still having trouble ascending this hill). Prior to 4.2, casual theming was really easy. You could open a single file, edit a few SASS variables, run the compiler, and you were done. Now, however, the logic and structure of themes is much more distributed, make for a lot more complexity than most people who dabbled in the previous version are probably prepared for.
And of course, there is the brand-newness of it. The documentation, while helpful in getting setup, is particularly thin on the point of actually theming. Most other tutorials, books, etc. follow the documentation in this regard, making really good examples of theming very hard to come by (unless, of course, you only want to change the color of the app from blue to green…if so, you’re covered ).
This, ultimately, More >
I’ll be writing about this later on, but wanted to share some screenshots. I was playing around with the new Theming approach in ExtJS 4.2 tonight, and was trying to get some Twitter Bootstrap-inspired panel UIs going. Here are my initial results with a bit of theme-hackery:
The best part about these is that there was very little actual theming that needed to be done. I think the outcome is pretty sleek…I like the drop-shadow on the panels, the typography, and the more generous font-sizes and white space.
Anyway, just a tease, I suppose. I’ll put up some code later this week.
We’ve finally arrived! After some setup, a bit of layout work, the creation of our first controller, a full version upgrade and even a bug fix, we’re ready to get into the heart of our application…specifically, interacting with data from our server. In order to do this, we’ll need to explore the concepts of Models, Stores and Proxies, as well as creating a new controller and even a fancy data grid with inline editing capability. We’re in for a long haul in this installment, but it’s worth it. When we come out the other side, we’ll not only have real functionality working in our app, but we’ll also have covered some very important concepts that will let us ramp up our development of the rest of the application. Ready? Let’s do it.Data Models
As a developer, you’ve no doubt utilized data models on a regular basis. They are handy things, for not only do they let you describe objects via their properties and relationships, but they also semantically describe your application. In ExtJS, the Ext.data.Model fills this role, providing a really nice way to manage objects which can be grouped together in caches (a Store) and, more interestingly or even bound to More >
In the last installment, we took a few moments to upgrade our app from ExtJS 4.2.0 to ExtJS 4.2.1. As I pointed out, upgrading is not an insignificant decision, as you will have to test and verify that your app continues to work as expected.
Well, in preparing the next several sections, I came across a bug in 4.2.1 that harms a bit of the functionality I was wanting to implement. While these bugs are a natural (albeit frustrating) part of software evolution, ExtJS is fortunately extensible enough that we can easily create a custom patch (or override) that will allow our code to work as expected WITHOUT modifying the core framework. The benefit of this approach, of course, is that we future-proof our code against new versions. So then, when the new version comes out, we can remove our custom patch and see if the issue is resolved in the core. If it’s not, we can simply re-enable our patch, submit another bug ticket , and continue on.Tips for Dealing with Bugs
Before we fix this bug, let me offer a couple suggestions to mentally dealing with bugs in ExtJS:
- Acceptance: The first step to healthily dealing with bugs in ExtJS is to More >
With ExtJS 4.2 came the awesome concept of Event Domains. Basically, these allow you to let your Controllers know about ALOT more events within your applications. For example, in 4.1, you could use the control() method within your controller to listen to component-level events. However, with Event Domains, you can now listen to events in the following domains: Global, Controller, Component, Store.
This is awesome, but there are other domains that you might want to tap. No fear, the Event Domain is easily extensible to include others!A Proxy Domain
In my applications, I generally have a single proxy that handles all my stores’ AJAX traffic. A common event listener for the proxy is the exception event, which fires in the case of a server error response. In the past, I’ve generally just added this to the listener config of the proxy itself, and went about my business.
The problem, of course, is that you generally want to DO something when an exception occurs, such as displaying an error message, resetting the state of a store, etc. The problem with defining the listener directly on the proxy is that you have to intrude your application upon the proxy to communicate the exception beyond the proxy.
But with a custom Event More >
- Known issues
- “Would-be-nice” features that didn’t make the prior release
Fortunately, the ExtJS team is constantly tweaking, fixing, and improving the framework. With each round of development, they’ll do various releases…some major like 4.2, others minor like the recent 4.2.1.Should I Upgrade?
With each new release, you have an important decision to make: will you continue using the version that you have (which is presumably working), or take a chance and upgrade?
What do I mean by “take a chance”?
With each new version, the full framework is re-released, and the upgrade you’ll make is total (unless you hack new changes into your existing version, which is definitely not advised…). While 99% of the changes won’t affect you whatsoever, there may be bug fixes, improvements, or just complete refactorings that will affect your app in some way. Obviously, the Sencha team does the best they can to mitigate these issues, but they happen nevertheless.
So if you are thinking about taking the plunge of upgrading, ask yourself a few questions first:
- Do I NEED to upgrade? Before you upgrade, view the release notes. These will outline all the bug fixes, enhancements, etc. that are included in the More >