April 7, 2005
For now, the site is only hosting Java components, but hopes to expend to a much wider audience. Let's hope that O'Reilly includes ColdFusion, Flash, Flex, Dreamweaver, and maybe even Central in that lot.
April 7, 2005
Some of the new features with this release include:
- Extended browser support
- Works on xHTML pages
- Now possible to choose which corners are rounded.
- Lite anti-aliasing effects
- Several additional cosmetic enhancements
March 29, 2005
My appologies to anyone who tried to consume the RSS from my two posts earlier today (or tried to follow the links on MXNA or the Goog). I accidentally sent my development blog config file to my production server, which had the effect of publishing the URL for my development server in the RSS feeds. Ooops.
So, if you tried following the links and found that you got an error, that's why. I've since corrected the problem, so all links from here on out should resolve fine.
March 29, 2005
After a nice three year stint on the CFCZone.org website, I've decided to resurect my personal domain and relocate my blog there. The new blog is available now, and can be found here:
If you notice, the only thing that's really changed is the domain name. The permalinks are still the same as the back-end is still using the same database. PLEASE UPDATE YOUR RSS READERS as I plan to turn off the cfczone.org version of my blog in a few weeks. In the meantime, both sites will have the exact same content.
On my personal site, I've added more CF related content such as links to articles, papers, and presentations I've done over the years. I'll be adding more content as time permits.
One other thing worth mentioning about the new site is a new blog I'm launching, tentatively named Foo(d) Bar. Thanks to Steve Rittler for the play on words. This new blog is an outlet for me to talk about one of my big passions in life - all things food. I decided to create a separate blog for this as I didn't want to dilute my technical blog with too much OT information.
March 29, 2005
March 18, 2005
Macromedia has just released the first updater for CFMX 7, ColdFusion MX 7 Cumulative Hot Fix 1. This hotfix corrects a problem with the new reporting functionality in CFMX 7. What's most interesting, however, isn't what's being fixed, but rather the fix process itself.
In previous versions od ColdFusion, hot fixes consisted (usually) of .jar files that you had to manually copy onto your ColdFusion servers, replacing existing .jar files. In CFMX 7, the process is different. Hot fixes and updates are now installed via the CF Administrator. In addition to making the overall update process simpler, it has the added benefit of making it easier to see which updates have been applied from within the CF Admin itself. Kudos to Macromedia for listening to developer feedback and implementing this much needed feature.
March 9, 2005
As I mentioned in my last post, we're currently in the process of porting our Intranet to use FarCry for the back-end. Since FarCry is compatible with CFMX 7, I thought it might be interesting to standardize all of our web based forms around ColdFusion 7's implementation of XML forms. In ase you aren't familiar with how they work, XML forms in CFMX 7 let you code your forms using cfform and it's associated tags. Unlike the "old" cfform, however, the new implementation allows you to specify XML as the form type. Doing this allows you to do some pretty amazing things.
For one, you can write your form once, and skin it a number of ways with pre-built skins that ship with ColdFusion. If you aren't happy with any of those skins, you can create your own using xsl, either from scratch or by extendiny any of the existing styles. This is where the power comes in and what got me thinking...
Well, it looks like we won't have to do that afterall. Because of the design of the XML forms implementation, we can basically write our own xsl transformations to map cfform validation to qForms! We're just starting to look into what's involved in doing this, but so far, it looks promising. Darryl Lyons over at Mossy Blog notes a similar use, using the XML forms to generate DHTML (in this case, a DHTML tree instead of the built-in Flash/Java tree). Very cool indeed. Stay tuned for more on this as we delve deeper into the project.
March 9, 2005
Sean Corfield has a timely post on his blog discussing several posts around the ColdFusion blogosphere related to when an application might be to small to bother with a framework.
This is timely for me because my team was just discussing this the other day. In our case, we've standardized all of our new application development (with one minor exception which I'll discuss shortly) on Mach-II. I could go on and on about all of the reasons we've done this, but it boils down to a few that you've probably seen over and over.
I've been working with CF at the same company since version 1.5, and have had the fortunate/unfortunate experience of watching all of our applications grow, mature, refactor, upgrade, migrate, and ocassionally die - all under ColdFusion. Along the way, my coding style has changed as both I as a developer and CFML as a language matured. When I was the sole coder, I coded how I pleased, and was always adapting my coding style to try new ways of doing things. As time went on, and I was able to add developers to the team, it became obvious pretty quickly that the "cowboy coding" mentality was not going to continue to work.
My perspective on all of this may be different than yours. As I've said, I've been with the same company for 9 years, so I've had a chance to experience first-hand what it means to maintain applications written by several different developers over several versions of the language, over long periods of time. Applications that started off fairly elegant (for their time) became nightmares to maintain as each application was architected differently, the original developer moved on, etc.
I made a decision toward the end of 2003 that all new ColdFusion development in the company would be standardized on Mach-II. We have a pretty ecclectic team, with skills ranging from CF to Java to VB to AS with varying experience with OO. The transitionto OO CF development using Mach-II was not overnight. Along the way, we made some pretty basic mistakes. The point is, though, that we learned from those mistakes and we moved forward. We're still doing that today. However, for all of the initial pain we went through, we would never go back. If you ask anyone on our team how small an application needs to be before we don't do it in Mach-II, the answer you'll get back is that there are no applications that are too small.
Earlier in this post, I said that we are using Mach-II for almost all of our CF development. The exception to that is FarCry. We're currently converting our existng Intranet (a combination of a lot of static content and a handfull of applications) to a FarCry site. Why use FarCry and not roll our own CMS? Simple. I have a limited amount of development hours with which to take on projects. Anything I can get off-the-shelf saves me development time that I can better spend elsewhere. Is FarCry perfect? Nope. But it works well, is fairly extensible, has an active user community, and it's open source. This brings me to part of my point. In FarCry, it's possible to integrate external applications into the CMS through a variety of means. One thing my team found a challenge, though, was that any custom development they had to do in FarCry, they found themselves wanting to use Mach-II for! They've gotten so used to Mach-II that they have a hard time getting away from it. As one of the guys put it, "I feel dirty writing code in a .cfm".
That's enough from me for now. I plan to blog a few more thoughts on this and other framework/standardization issues in the near future as this seems to be a topic to a lot of developers at the moment.
February 23, 2005
Ray Camden, Ben Forta, and Sean Corfield have all blogged about the new features in cfquery such as the new result attribute/structure and the ability to introspect query meta data using getMetaData(). I thought I'd tie all three of these posts together with a visual example of just what you get. Consider the following query:
<h3>Query Meta Data</h3>
Rather than rehash the other posts, a picture is worth a thousand words:
|COLUMNLIST||ARTID, ARTISTID, ARTNAME, DESCRIPTION, ISSOLD, LARGEIMAGE, MEDIAID, PRICE|
|SQL||SELECT * FROM art|
Query Meta Data