Products
Rob Brooks-Bilson's Blog
I've been working up a few demos lately that make use of the new layout tags in ColdFusion 8, and while I think they really do make Ajax based layouts much easier than using the Ext js and YUI libraries on their own, there are a couple of issues I've bumped into that have me thinking that their potential may be limited. Let me explain.
Today I was working on a dashboard mock-up to show to some of my colleagues. I wanted to show them how simple it is to do a dashboard in ColdFusion, and I wanted to do it using the new cfwindow, cflayout, and cflayoutarea tags. Things were moving along well until I wanted to add an accordion pane on the left-hand side of the layout. Try as I might, I couldn't find the attribute or value in any of the new tags to make it happen. That's when I realized that accordion panes are only available as part of the Flash based cfform controls. Doh! I don't want to use any Flash in my dashboard demo (I'll leave that to a Flex based demo), just straight HTML/Ajax. There are several options for adding an accordion panel outside of ColdFusion (Spry, Ext js, etc.), but I wasn't expecting that the control wasn't going to be included as part of ColdFusion 8.
This led me to more carefully consider the new UI controls in ColdFusion 8. For many layout tasks, they may be sufficient. However, what really has me concerned is situations like this. I still want an accordion control, and in order to get it, I'll have to mix and match the ColdFusion UI controls with another solution. What I'm strongly considering right now is abandoning the new UI controls all together in favor of a custom tag based approach. It turns out that there are two ColdFusion custom tag libraries that each wrap the Ext js library: cfExt by Dan Vega and ColdExt by Justin Carter. I like the custom tag based approach for a number of reasons:
- Utilizes the latest EXTjs library: 2.x. ColdFusion 8 currently uses EXT 1.x, and it doesn't look like they will be upgrading to 2.x anytime soon.
- Custom tags allow for new feature adds faster than new ColdFusion releases.
- Custom tags allow for community contribution.
- Custom tags give you total freedom to customize should you need features not implemented by the original author.
- Custom tags provide a form of insurance against Adobe stopping future development of the new UI tags. While they have always done a good job of maintaining backward compatibility, there are numerous examples of situations where a particular technology was phased out and new features/functionality halted (cfgraph/cfchart, Flash forms, cfform java applets to name a few)
I hope I don't come off as bashing the new UI tags in ColdFusion 8. I really do like how easy they are to use and will be very beneficial to a lot of developers. If, however, you require more flexibility, you may want to consider implementing UI controls natively in JavaScript, or looking into one of the Custom Tag Libraries mentioned previously.
I'd love to hear what others have to say about this topic.
Aura skin for Raymond Camden's BlogCFC inspired by Joe Rinehart & Steven Erat. This blog is running version 5.5.1.
I think the CF8 built-in controls are excellent for building small apps quickly and easily, but I share your concerns about flexibility / extensibility / backwards compatibility.
Touching on your last point, I too have been wondering what will happen when (if?) Adobe decides to upgrade the built-in tags to use Ext 2.0 (or even some other library, if that were feasible)... For example, if you have custom JavaScript that is using the bundled Ext 1.1 library, will an upgrade of the built-in controls to Ext 2.0 be forced upon you, leaving you with custom JavaScript that breaks with the newer - not backwards compatible - controls? Or would there need to be a mechanism for CF to target a particular version of Ext when outputting the built-in controls? Or is it just the developers fault for using semi-undocumented features? I guess the simple answer is to make sure you stick with CF8 for those apps, but maybe in those cases where custom JS is required it's just best to not use the built-in controls at all...
That said, I UI tag development cycles should be separate from the server side language. I've written more about how I see this happening in my own blog:
http://orangepips.instantspot.com/blog/2008/03/25/...
1. I think it blurs the line between server and client processing. I feel the same way about .NET controls for the same reason.
2. The fact that the client-side functionality is provided by third party libraries being bundled to create the aforementioned fuzziness. That feels like a hairball waiting to happen.
3. The release cycles for the bundled libraries themselves tend to be much faster than those of CF.
4. There's no "real" benefit. No additional functionality is being introduced. I suppose it could be argued that existing functionality is being made more accessible, but that sounds pretty lame to my ear.
It seems to me that bundling external software like this ultimately creates more work for the CF team (keeping up with the updates, should they choose to do so) and serves to distract them from improving the application server itself. I'd much rather that they focus their efforts on new/improved backend functionality than on front end constructs that I can implement myself with the JS library of my choice.
Ultimately, if the "verdict" is that they're good for simple stuff, but useless for the hard stuff, then I have to wonder...do we really need them for the simple stuff? It is simple, right?
To me, it seems as though Adobe would/could benefit by making custom tag libraries available (either for free or charge for them) for the various frameworks such as Spry, jQuery, Ext js, et. This would allow the CF engineering team to concentrate on the core application server while still providing a mechanism for easier integration of JavaScript frameworks for client-side processing. It also allows them to make updates to the custom tags in a much shorter development cycle than for the CF server itself. If you are a CF developer, this lets you decide (potentially) which UI framework you want to use, and you'll know that the integration mechanism with CF is much more flexible.
That said, the Adobe team has already headed down the road of including UI features as a core part of the language/application server, so it may be difficult to turn back. Sure they could deprecate the new tags, but I'd bet there are already a decent number of customers using the new functionality - so at a minimum, Adobe would have to create a tag library that mirrored the existing new tags so that there was a clear migration path for existing users.
I do like the idea of releasing separate libraries you can pick and choose from. They are doing this with Spry. But maybe additional ones are best left to the public, as we see happening already (cfExt, ColdExt).
I have to admit that I never really looked at the new Ajax/UI tags until just now (never needed to). I do like the data binding capabilities in the new tags as well as how simple Adobe made it within Spry.
I'm also all for community driven efforts - I really like what I've seen in both cfExt and ColdExt. I'm just wondering out loud whether Adobe really wants to be in the UI productivity space (which it seems that they do), and whether it makes more sense for them to do this within the app server, or via something like custom tag libraries (where I think this stuff belongs).
What I think would be the ultimate, though, would be for Adobe to help sponsor various OS projects (like CFEclipse, cfExt, ColdExt, etc.). They've done it in the past for non-CF OS projects (Apache Axis for one). To date, most ColdFusion OS projects have been fairly small, with relatively small teams. I'd love to see what would happen if some of these projects had official support from Adobe. I'm constantly amazed at what some of the CF OS projects have achieved when they are basically labors of love for a small number of developers.
I think it is a good idea to have a community effort (ie. cflib) which would expand the use of all the features of those AJAX libraries. One should have a certain standard to have the javascript as small and quick as possible. The community can react faster to changes than Adobe.