This year's cf.Objective() is offering SIX pre-conference classes! You can choose from Building Secure CFML Applications, ColdBox: 100 Training, Developing Applications with ColdFusion 9 ORM, Getting Started with Flex / AIR Development, Mach-II / OOP from the Ground Up, Rapid Development with Model-Glue 3! Wow!
Some of these are one-day courses (Wednesday April 21st) and some are two-day courses (Tuesday April 20th and Wednesday April 21st).
I'm looking forward to that first week of June despite the crazy travel schedule (I arrive Sunday afternoon and fly back the following Saturday, hopping from Edinburgh to Heathrow on a horribly early flight).
I'll be looking at ColdBox, Mach-II and Model-Glue - talking about their similarities and their differences - and showing demos of each framework.
Please see the event listing on Adobe Groups for more details and to RSVP (you must login with your Adobe ID to RSVP!).
I've been using ColdFusion since 2001, back when I worked at Macromedia and my team of Java and C++ developers first encountered CFML in the form of very early builds of what went on to become CFMX (6.0). We were pretty skeptical at first.
You can read the What's New in 1.6 wiki page to learn about the recent additions. I had already used the publish/subscribe listener invocation (more like Model-Glue), the improved Application.cfc integration and the ColdSpring Property (which replaces the old Plugin). The major new features in 1.6 are caching and logging which were not in the early build I was using, unfortunately (for me!).
Official support is provided for Adobe ColdFusion MX 7 / 8, Open BlueDragon 7+, New Atlanta BlueDragon 7+ (but not BlueDragon.NET - which I was a bit surprised by). They're hoping to add official support for Railo soon - but have heard that it runs just fine on that engine.
Here's what I said in response:
We've worked hard to make cf.Objective() 2008 a "must see" event. We have a number of firsts this year that we're very proud of:
- The public release of Open BlueDragon on May 3rd!
- The public unveiling - and Alpha - of Model-Glue 3: Gesture!
- The public unveiling of Mate, the new Flex framework from AsFusion!
- The first conference to feature the latest rising star in the frameworks world: ColdBox - with an introductory session and a two hour, hands-on advanced workshop!
- The first public information about Swiz, the new Flex framework from Chris Scott of ColdSpring fame!
- Speaking of Chris Scott, we're the first conference to feature a two-hour, hands-on workshop for ColdSpring!
- We're also the first conference to feature a two-hour, hands-on workshop on agile development for ColdFusion developers by the leading light in automated process & testing, John Paul Ashenfelter!
If you're a Mach-II user - or thinking of using Mach-II - you might also be interested in the pre-conference classes.
We hear a lot of talk about using individual Java objects within ColdFusion but the reality of enterprise development is that entire subsystems tend to built entirely in Java. Software teams that serve the enterprise often build large, complex systems using Spring and Hibernate. How do you go about using ColdFusion with such systems? I haven't seen any presentations on this subject so I was pleasantly surprised when I started reviewing Andrew Powell's slide deck to find that he was focusing on how ColdFusion can provide the web front end to enterprise class Java systems.
He introduces Spring (the Java version) with a demo and then introduces Hibernate (the industry standard ORM for Java), again with a demo. After that, he will walk you through solutions to the problem of connecting ColdFusion on the front end to Spring on the backend and, using Mach-II as an example, he then shows how to create an MVC web application that allows you to leverage the entire Spring-powered, Hibernate-persisted Java backend.
If you work along a Java team - or you are considering using more Java for your backend systems - this talk will provide you with a lot of good information about how well ColdFusion plays in this space.
I wanted to let folks know what a great job Matt and Peter are doing with the framework. Mach-II 1.5 was a very impressive release with a lot of new features that help you manage large-scale application development: modules, includes, subroutines, extended property data type support, SES URL support and bindable property parameters.
In Mach-II, inside an event handler, you notify a specific listener to execute a specific method. In Model-Glue, inside an event handler, you simply broadcast a message and any listeners that have been declared for that message are executed automatically by the framework.
Model-Glue has come on in leaps and bounds - the rearchitecture based on ColdSpring, the scaffolding infrastructure, the integrated support for Reactor and Transfer for "generic database messages". It's very impressive. And now we're got the beginnings of a Flex version, which is very promising.
Now that I'm consulting and have a number of clients, I'm encountering Mach-II quite a bit and looking at the 1.5 release. I've mentioned in the past that I think 1.5 looked quite impressive (when Peter Farrell gave the "what's new?" talk at cf.Objective(), for example). Recently, I've been making recommendations for frameworks for clients and finding myself recommending Mach-II for some clients, mostly due to the new features in 1.5. For some of the sites my clients are trying to build, the modules, includes and subroutines really do allow you to build much larger, much more modular sites than earlier versions of Mach-II.
The extended property semantics in Mach-II 1.5 are also very nice, allowing you to specify structured configuration data - including full-on CFCs - as well as allowing property values to be dynamically substituted into parameter values throughout the configuration.
I still don't really like the direct invocation model (with <notify>) compared to Model-Glue's broadcast / listener mechanism, but the other features are pretty compelling.
One thing I have seen mentioned, but cannot find, is Peter Farrell's new ColdSpringProperty CFC, to replace the old ColdSpringPlugin. Anyone know where to get a copy?
Brian Kotek has a great post about data vs content in the context of AJAX and frameworks. He emphasizes the benefit of having your model in CFCs as the easier way to expose data-centric functionality to AJAX and notes that for data calls, you should not be trying to go through the MVC framework. It's a good read.
As a framework developer, it can be really hard maintaining complete backward compatibility as you move the architecture forward and there are often parts of the framework that you don't want to have to maintain indefinitely.
It's good to see the Mach II team being so public and forward-looking about the framework so that users can plan to move forward as well.
Next up I covered the Fusebox 5.5 release which is currently in limited Alpha with a public Beta planned in July (as soon as we can get enough documentation together on the new features). I also announced publicly that providing a migration path for Fusebox 3 was on the roadmap (for Fusebox 5.7 probably).
Matt Woodward (and Peter Farrell) presented Mach II 1.5 which is in Beta right now, and the new website. He also talked about plans for their 2.0 release (but didn't go into specifics).
Next up was Chris Scott, who said that an official 1.2 release would appear within a few weeks and then they would be working toward a 1.5 release. This will be the last release of ColdSpring that will run on CFMX 7 - ColdSpring 2.0 will require CF8 because they want to take advantage of cfinterface and onMissingMethod() to make ColdSpring faster (and simplify the core files).
Last up was Doug Hughes who assured us that Reactor would hit an official 1.0 release as soon as the documentation was complete. Ah, the dreaded documentation...
Kudos to the Mach II team for what has clearly been a lot of work behind the scenes!
Anyway, I figured I'd put a note out based on the answers I've been giving these folks.
First off, Mach II is alive and well and getting some serious attention from Matt Woodward, Peter Farrell, Kurt Wiersma and others (like Dave Shuck who is taking on the role of Mach II community manager).
Second, Mach II is a mature, stable framework so you should not expect to see a steady stream of changes. That would make life hell for developers trying to use the framework! One release a year is probably a good pace for a framework once it is well-established.
Third, a public beta of Mach II 1.5 should be released at CFUNITED along with a brand new web site. Hopefully that will stop the questions.
CFUNITED will be a major event for frameworks: Mach II 1.5, Model-Glue 2.0 and a public beta of Fusebox 5.5 (I hope!).
The example blog application created for the MAX frameworks debate is going to be released soon - as an example of a full blown application built with Mach II, Model-Glue and Fusebox (as well as ColdSpring in the Mach II and Model-Glue cases). Definitely something to look at, no matter which framework you use (or not).
Matt is also working on a detailed comparison of Mach II and Model-Glue which should make interesting reading.
He is also producing a (much needed!) update to my original Mach II development guide. Big thanx for taking that so I won't have to feel bad about how long it's been since I updated it. My excuse? Well, I haven't worked on any Mach II applications for quite a while...
As someone who has contributed extensively to Mach II, Model-Glue, Fusebox, ColdSpring and Reactor (phew!), I would like to step up and defend Joe's decisions - he's done a sterling job, sticking to his vision for the framework and has been very clear about what should be in the framework and what should not. As a framework developer myself, I can tell you it's a rocky road. The "community" deluge you with requests for all sorts of features and you have to stand firm and defend your vision. None of the popular frameworks are "kitchen sink" efforts - there are countless feature requests that have been denied by the framework authors.
I've requested enhancements to all these frameworks. Some of those requests have been implemented but most have been denied. Even as lead developer on one of the Mach II releases, some of my suggested enhancements were turned down (and some of the changed Peter implemented in Mach II were reverted as inappropriate for the framework).
When I built Fusebox 5, I was deliberately very conservative about what went into the framework and what didn't. I implemented a few things the community really wanted that I didn't think were great ideas but I also did not implement several things that I thought were great ideas that the community weren't very interested in.
Fusebox 5.1 will be a fairly conservative enhancement release. Fusebox 6 has more scope for adding features but, even so, backward compatibility will be maintained and the addition of features will be strictly controlled but community-driven.
I don't know how community-driven Mach II is. I don't think it has a public bug tracker (Model-Glue, Fusebox, ColdSpring and Reactor all do). I get the impression that Application.cfc support was added for coolness (the other frameworks have taken great pains to remain compatible with CFMX 6.1 and equivalent competing ColdFusion engines).
And then you need to put a Flex front-end on your application. That means you need to expose your model as a set of remote methods. If you got your application design right, that'll be easy: just open up your model CFCs and change the access attributes and you'll be done, right?
First off, while I think the tests are interesting, I've always been one to say don't worry about performance too much because "fast enough" is almost always sufficient. Very few websites get the sort of traffic to need heavy load testing and tuning, frankly, and as we know there are some very high traffic sites out there running on various frameworks. macromedia.com runs (about a quarter of its applications) on Mach II and the performance under load testing met all of our criteria.
My comments about the tests Webapper ran were meant to say:
- It's no surprise Fusebox is "faster" because it is more of a compiler than anything else (the framework doesn't really "do" anything at runtime, once your XML is compiled to CFML)
- I was pleasantly surprised that Mach II was not slower than a hand-coded CFC-based application - a lot of people complain about the "overhead" of Mach II but this shows that is not necessarily true
The point of the original (Webapper) article was that JVM tuning can have a dramatic effect on performance, as can Trusted Cache.
Those wonderful folks over at Webapper have been doing some load testing on various frameworks using the ColdFusion PetMarket application (featured in the February CFDJ). They tested Fusebox 4.1, Mach II and Simon Horwith's "no framework" versions of PetMarket. Fusebox 4.1 was the fastest which really isn't much of a surprise since it compiles everything down to straight line CFML on the first request so subsequent requests just process a single file. What surprised me was that the Mach II version outperformed Simon's version (albeit, not by very much). Overall, Simon's version was 100% slower than the Fusebox 4.1 version. Unfortunately, Webapper couldn't test the Model-Glue version because "the PetMarket Model Glue application was not fully functional". Based on my experiences, I'd expect Model-Glue to fall somewhere between Fusebox 4.1 and Mach II performance so I hope they get a chance at some point to show that.
Probably the biggest news in this release is the introduction of resultArg= and contentArg= as the new "best practice" to avoid using the request scope.
There is also a <redirect> command (added to the XML language) so that you don't need to write a filter for simple redirects.
Keep an eye on Peter Farrell's blog for hints and tips on using the new release!
The #coldfusion channel is often all over the shop and sometimes politically incorrect in the extreme but the framework-related channels are generally much quieter and much more on-topic.
We will be meeting at the Portland offices of Schoonertech - directions are now on the PDXCFUG website.
Don't forget that there are also full-day classes being run on the Wednesday before the conference (9/28):
- (FB103 Intro to Fusebox - Simon Horwith - cancelled)
- FB301 Advanced Fusebox - Jeff Peters
- (MT101 Mach II - Hal Helms - cancelled)
I'm going to be in Salt Lake City so I'll miss this year's conference which I'm fairly bummed about - it really looks like a great lineup!
Only a week left to get the early bird price too so hurry up and register!
Read Ray's enthusiastic response to Wayne's blog posting about the technique.
This should apply to other frameworks that use XML configuration files but I haven't tried it.
And, no, I will not be there this year - it clashes with a cat show in Salt Lake City so I'll be on the road from California to Utah while the conference takes place!
I'm back from a long weekend away and I'm very gratified to see several people writing good, reasoned, blog posts explaining why Peter is wrong. Although Elyse seems to side more with Peter.
Those who know me will be well aware that I'm stirring the pot to provoke discussion and to make people think for themselves about their technology choices. That's one of the main drivers behind my "Frameworks: Fusebox or Mach II?" talk (Wednesday 6:10pm and Friday 10:40am at CFUNITED)...
Now the question in my mind is whether I should "promote" Model-Glue from the notes (for folks to read after downloading the PPT) to content in the actual presentation itself? In some ways, most of the comparisons (between Fusebox and M**) would turn out the same but there are some interesting differences as well. Thoughts?
The first thing that kept tripping me up was that Mach II uses event= for the event-handler name but Model-Glue uses name=. It's a hard habit to break as I repeatedly found out! Overall, the Model-Glue grammar is more verbose because of its nested structure but the visual effect is a much less dense XML file: Mach II's flat syntax means event handlers have a sequence of single-line XML tags; Model-Glue has a broadcasts section containing indented message tags followed by a views section containing indented include tags and a results section containing indented result tags. The nesting and the simpler tag language leads to more whitespace and more vertical layout which, in my opinion, is easier to read.
A corollary to that is that Mach II lets you intersperse view-page tags, notify tags, event-arg tags and so on which can make it a little hard to follow exactly what is going on in a complex event handler. Model-Glue makes you list your broadcast messages first, followed by your view includes, followed by any continuation events (results). That means you have a clearer separation of control logic and presentation than Mach II allows. Model-Glue uses the event object consistently as the data bus so it doesn't suffer from the event-arg injections that are necessary in Mach II (unless you're using a custom Mach II invoker to store results directly in the event object!).
Shifting the configuration of Mach II's listeners out to config beans in Model-Glue meant that I could cut the number of listener declarations from 25 to just 6 controllers. Then instead of notifying one of 25 listeners to call a method, I was able to send a parameterized message to one of just 6 controllers - the parameter specifying which config bean the controller needs to use. Since the config beans are singletons, they can maintain the state I was previously maintaining in all my separate listeners. This pretty much turned my previous architecture on its head because the configuration is now a dynamic attribute of each controller invocation rather than a static attribute of each listener declaration. Since I don't actually have to preserve the URL structure, I can make further simplifications to the application structure now - but for now the benefits of moving the configuration out of the main line are enough.
One stumbling block I hit was where I was running some business logic, generating a view and then using the rendered view in some more business logic. I was emailing the intermediate view results to interested parties. In Mach II, because you can mix notify and view-page tags, it's pretty easy to perform business logic on the result of a view rendering. While the mixture of business and presentation logic leaves a bad taste in my mouth, there appears to be no easy way to deal with this in Model-Glue and it still feels like there should be... My workaround was to duplicate the view into a cfsavecontent within a controller since it was such a simple view (fortunately). I'm not very happy with that either.
Coming back to the event object issue, Model-Glue's consistency means that every controller method gets passed the event object and is expected to return it - result values are added to the event object rather than being returned from controller methods. The downside is that controller methods tend to conclude with:
<cfreturn arguments.event />
There's no doubt that Model-Glue has benefitted from the experiences of both Mach II and Fusebox but it has also added its own unique elements. Consistency and simplicity are key drivers for Model-Glue which means you sacrifice some power and expressiveness. As always, it's all about tradeoffs and you need to make the choice based on the needs of your project (and, to some extent, your own personal preferences).
As you probably know by now, I'm working on our next generation order management system. The current, live system relies on a lot of batch processes, powered by ColdFusion, shuffling, processing and generating a lot of XML files. The previous system was also batch processed but used proprietary file formats (mostly CSV - comma-separated value - formats) and was not powered by ColdFusion.
The next generation system relies very heavily on CFMX 7's event gateway system to provide near real-time data transfer between all the various IT systems. So it's mostly CFCs, all running quietly in the background.
However, even this new system will still deal with some batch jobs and, like its predecessor, it has a simple HTML user interface for certain manual tasks, mostly related to debugging and monitoring.
Since Mach II is a Macromedia Web Team standard, that's what I used to build the current administrative interface. A handful of listeners that drive the underlying order management CFCs and a handful of views that display the debugging and monitoring options and results. All of the batch jobs use Mach II URLs too and, since the batch jobs interact with a lot of servers, there are actually 25 listener declarations, even though there are only five distinct CFCs used as listeners. The mach-ii.xml file described all of the various FTP and directory structures across development, QA and production - each listener declaration represented one of the basic five listeners configured for a particular scenario. During system maintenance, the IT Operations folks would sometimes need to modify the mach-ii.xml file (changing a directory path or a password or...).
That should ring some alarm bells. Application structure / control flow should be separate from configuration data.
At first, it had been OK to manage things this way but as the number of different configurations grew, I had begun to realize that the time would come when I would need to restructure the application - in a fairly radical way, most likely.
I decided that all the configuration should be separate from the main control file and that I needed a way for the configuration to be automatically mapped to objects, for easy manipulation within the main application code.
Sounds like... a managed container... perhaps "Inversion of Control"...
Since that sort of restructuring was likely to involve touching all of the Mach II code (all the listener configuration would need to move elsewhere, as well as some basic configuration data that was currently stored as Mach II property tags), I figured that maybe changing to another framework would not be that much more work. A framework that provided a similar MVC structure but with automatically managed configuration objects. Model-Glue, to be precise.
I started the conversion Tuesday morning (May 31st) but spent most of the day planning out the design of the configuration beans that I would need, looking at how I could improve the maintainability of the configuration as well as simplify the code that used the data. I'd created the outline of one bean by close of business.
Wednesday was very productive with the bulk of mach-ii.xml rewritten as ModelGlue.xml and most of the original Mach II listeners rewritten as Model-Glue controllers. The main administrative menu page appeared and a few of the options actually worked.
Today saw the completion of the rewrite, including the tedious task of writing over a dozen very similar FTP connection configuration files! I did some unit testing and then checked everything into CVS and pushed it to the shared development server for folks to use.
mach-ii.xml file: 522 lines, 23K of fairly dense XML, 25 listener declarations.
ModelGlue.xml file: 427 lines, 11K of fairly well-spaced XML, 6 controller declarations, 5 config bean CFCs, 22 bean configuration files (710 lines, 16K of XML).
In a future entry, I'll talk about some of the issues, benefits and mindshifts I encountered during the conversion of this application.
I've already added a comment in response to several other comments there but I want to highlight a couple of observations he makes.
He draws a clear distinction between the primary application frameworks (Fusebox, Mach II, Model-Glue) and the "supporting" frameworks (Tartan, CFHibernate, ColdSpring). This is important to understand: you can use the supporting frameworks on their own, i.e., with your own ad hoc code, but they really work well when used with the primary application frameworks. Indeed, Tartan includes a Mach II listener and Model-Glue includes a Tartan proxy.
He also notes that Mach II gives the appearance of a framework that is not evolving very fast and compares it to Model-Glue, saying the latter "might very well take over". It will definitely be an area to watch closely.
More on this topic when I speak at SacCFUG, BACFUG, CFUNITED and PDXCFUG over the next few months. After CFUNITED, I'll make seven variants of a sample application available - each variant shows a different framework or a different style within a single framework.
Original: Jeff and Hal talk about domain models and how you can use fully OO models with Fusebox - "doing OO" doesn't mean you have to use Mach II. The conversation is a nice gentle introduction to the idea of domain models as well as as some thoughts on why you might choose Fusebox or Mach II for the controller in your application.
Update: The discussion is the latest in Hal's series of occasional newsletters and having re-read it a couple of times I wanted to comment on a couple of pieces.
On the choice of frameworks, Hal says:
"So, if I were working on a team with Ben Edwards and Sean Corfield, both OO guys, I imagine we'd use Mach-II. If I was working on a team with other programmers (who may be as good or better than Ben or Sean, but simply don't do OO), I think I'd choose Fusebox."I'm an OO guy but I'm a real fan of Fusebox 4.1 as well. I might even try to persuade Ben to use Fusebox if he was working with me. As Hal shows in in the newsletter, the domain model is where all the real OO-ness is - and you can use that with either framework.
Then Jeff asks why Mach II requires OO-aware programmers and Hal gives this very good answer:
"Mach-II exposes more of its internal architecture than does Fusebox. As I said earlier, you could change Fusebox's architecture from procedural to OO and no one would notice. If you went from OO to procedural with Mach-II, everyone's code would break. The controller components Mach-II programmers create extend the Mach-II framework components."
I'm designing a new website using Adalon so I'm going through the whole wireframe, XFA, fuseactions, fuses design process and it's hard. This is just not what I'm used to.
The site ought to be pretty simple: it's a basic task manager with elementary user identification. I know how to design it from a model point of view, using an OO model design. But trying to follow FLiP to drill down from the user experience into the mechanics is killing me!
I'm trying really hard to follow the process. I keep walking through the use cases, with input and output variables being passed between fuses but it's so painful for me.
I hadn't realized how differently I think about problems - but it definitely highlights why FLiP doesn't 'click' for me.
So why am I putting myself through this pain? I'm writing a presentation that compares Fusebox and Mach II. I know how I'd design the Mach II version and I'd use a very similar approach for an OO MVC Fusebox 4.1 design. But to really get a good comparison of the frameworks, I really want to start with a 'traditional' procedural Fusebox application.
I'd be interested to hear your stories of paradigm shifts...
Read about the conversion process and the reasons why I went through yet another conversion exercise. Don't expect this to be the last word on frameworks!
Phil Cruz pointed out that 1.0.10 added get/setProperty() to ViewContext and hence you can simply say getProperty("fnlib") in a view to get your function library back.
Very elegant!
Of course, this poll is pretty heavily skewed because it represents a segment of my blog readership rather than the CF community as a whole (anecdotal evidence suggests about 6-10% of CF developers at large use Fusebox whereas my poll shows about 30-35%). Still the numbers are interesting and I'm very pleased to see so many people are using some sort of framework.
There was a discussion about which framework was best suited to which type of developer. Some folks clearly think Fusebox is easier to learn and therefore more approachable for novice developers - and I'd agree. I definitely got the impression that folks are migrating from Fusebox 3 to either Fusebox 4 / 4.1 or to Mach II, basing their choice on the skill sets of the teams they are working with.
What I want to draw attention to here is a key point in the conclusion of his Inversion of Control Containers review:
"In particular, I salute Howard for resisting attempts to twist HiveMind into something it's not - a rare quality, particularly in open source. HiveMind does (mostly :-) ) one thing and does it well."
Mike comments that PicoContainer looks like it followed the XP YAGNI (You Ain't Gonna Need It) principle and each new release seems to have haphazardly added those features which - guess what? - you did need them after all. He also comments that "Spring's just a bit took kitchen-sinky for me."
My point? Frameworks work best when they are cohesive, focused. That usually means tightly-controlled rather than being open source free-for-alls and it also usually means that the creator(s) started with a coherent vision of the whole.
So, when you're asking for Fusebox or Mach II to be opened up so y'all can contribute code, think about Mike's comments on why some frameworks work better than others.
As I plan out the talk, I'd like some feedback from you on what level of background information you'd like to see in such a talk about the frameworks themselves. I don't think I can assume knowledge of both frameworks but I suspect that any audience for that talk is going to be familiar with one or those frameworks.
Comments?
You can see the final list on my Mach II bugs & enhancements page.
We've gotten a lot of good feedback about what folks would like to see in the framework and we'll be taking that into account for the next major release. Some of the suggestions are very good but require a lot of careful design and probably quite a lot of prototyping before we can settle on exactly how to incorporate these suggestions.
I'll be making the final tweaks to the core files this week and handing the changes off to Ben who will run through the final integration process and build the release, along with any documentation changes we need to make (there will be a couple).
Check out my Mach II bugs and enhancements page for status of various items.
Some comments on the feedback so far...
Yes, Matt Liotta provided a patch to allow calls to config() to be deferred until the very first call of a listener method which can help if your configuration is expensive. I might look into that again if folks really think it's worth adding.
For security of the XML file, you can simply store it outside the webroot - see the Mach II Development Guide for discussion of that. You can actually put all your components and views outside the webroot too.
Interesting idea about including the XML to allow dynamic generation but that would make it very hard to run the framework in 'production' - how would you know whether to reload the application? Dynamic mode tests the timestamp on the XML file, production mode never tests and never reloads. Development mode never tests but always reloads.
Event queue and cflocation - the entire event queue is processed for each request, even if one of the events causes a cflocation to be generated, the other events in the queue will still be processed.
Ability to append contentKey - Fusebox allows this so I can see a similar mechanism for Mach II being reasonable.
Properties - I agree that the current syntax is ugly but it should not be made available as a global 'scope' since that breaks all encapsulation. How about if getProperty() and setProperty() methods were directly available in a listener?
Some of the ideas being bounced around include:
- Allowing the event object to be used as a target for <view-page contentKey=> and <notify resultKey=> and as a source for <event-arg variable=> somehow. Feedback suggests that new invokers, perhaps EventInvoker and EventArgsInvoker, be provided to address the notify issue (and perhaps deprecate the current invokers?). What about the view-page and event-arg issues? How should we solve those?
- Attaching the event context to an event so that any method that is passed an event can actually get access to the event context as well, e.g., a listener could call arguments.event.getEventContext() and manipulate the event queue
- Introducing a BaseComponent class and refactoring common code out of Listener, EventFilter and Plugin into this new class - the net effect would be less duplication of code and EventFilter would gain an announceEvent() method
- Providing a new component that provides an event-level way to 'call' the framework, intended for use by Flash Remoting, Web Services and the ne Blackstone event gateway
- Change plugin execution order from "random" to "as declared" (and improve performance)
Good feedback so far. Seems like the "big" mach-ii.xml is the number one concern for a lot of folks.
We're very interested in (and into)Mach II here at Amkor, but didn't send anyone to the conference since it was mainly a Fusebox centric gig. Had there been more Mach II on the schedule, we would love to have sent someone. I'm hoping those guys put together a Mach II specific conference at some point.Yes, the Fusebox 2004 conference was pretty much purely a Fusebox gig. Ben Edwards ran a Mach II Birds of a Feather but there were very few Mach II users present and perhaps an Intro to Mach II would have been more appropriate. I made sure my presentation was very focused on Fusebox 4 and didn't even mention Mach II.I know Fuseox seems to have a bigger following right now, but I really think Mach II is a solid framework for OO development in CF. It's made a believer out of us.
Last year's Fusebox conference was one day (and one track) of Fusebox stuff and a half day overview of Mach II - really as part of its launch. I went as an attendee last year because of that half day session (but found plenty of value in the Fusebox sessions too).
I hope to be able to go to Fusebox 2005 (even if it has no Mach II content) but I'd certainly be interested in seeing a Mach II conference of some sort.
Opening this up for comments, who would like to see a Mach II specific conference? Or do you have other suggestions - perhaps a Mach II track at Fusebox 2005?
It's another Mach II ColdFusion application on the front end and sales information is also processed by ColdFusion on the back end as part of the integration with the Oracle ERP system. The front end and the back end communicate using JMS - yes, the back end uses my JMS event gateway and runs on Blackstone. So I'm very pleased to see this new product offering go live!
I've got too much invested in Movable Type to switch to a CF-based blog. There's a few little old PHP sections floating around that weren't part of the Mach II code and those haven't been touched. If I need to edit them, I may well convert them.
No more asking why I don't use CF on my own site!
See you there?
Launched some time back but I never got around to blogging it, Macromedia's new Events application is powered by Mach II as well.
Next up was Ben Forta's keynote on Blackstone! He raced through some of the things he's been showing at CFUG presentations (Flash forms, PDF generation, report generation, sourceless deployment and EAR / WAR file packaging) and then gave a CFUN exclusive sneak peak: the event gateway!
This is probably the most exciting and radical addition ever to ColdFusion: by writing a small amount of Java, it allows you to connect pretty much anything to ColdFusion and have external, asynchronous events trigger method calls on a CFC.
The example Ben showed was a agent that watched a folder for new, changed or deleted files and automatically called the appropriate method on a CFC to populate / update a database based on the contents of the file. Whilst this generated a lot of "ooohs" from the audience, I suspect that the real impact of this feature will take a while to sink in - it opens up a whole new field of use for ColdFusion since this lets it process requests which are not web-based...
I'll be writing a lot more on this feature in the future...
Before my talk, I met with Daniel Dougherty who'd been picked to interview me for five minutes and he had some great questions - I believe the various attendee / speaker interviews will get posted by TeraTech later so I'll keep y'all in suspense!
Then it was time for my Mach II talk. A good percentage of folks in the audience were on CFMX 6.1 and were already using either Fusebox or Mach II so that was quite a change from some of my gigs. The presentation seemed to go over well and there were some good questions from the floor - thanx to everyone who attended (and special thanx to those folks who gave me a good evaluation so I got a bottle of wine at the wrap-up session for tying as 'best speaker' with Charlie Arehart from New Atlanta! I'm honored!)
I'll blog more later but right now I'm going to meet some folks in the bar before everyone heads off home!
The drive back? Slow traffic out of San Diego, had to stop to get fresh tires on the Mustang due to a nasty bulge in the wall of the Bridgestones it was wearing before (tread separation perhaps?) and then an accident on the Grapevine held us up for an age (seems to happen almost every time I drive back that way).
We have confirmed the location for our April 13th SacCFUG meeting.I'm looking forward to speaking up in Sacramento and fielding all manner of questions! :)
New Horizons is hosting the meeting. They are located at 1215 Howe Avenue in Sacramento next to TGI Fridays. The nearest major cross street is Arden Avenue.
We expect the meeting to run from 6:30pm to 8:30pm. We would like you to be available to speak and answer questions about Mach II from 7:00pm to 7:50pm, if that is comfortable for you. I would expect a lot of questions as there is interest in Fusebox and Mach II here and there have been no other speakers on the topic since Hal was out here a couple of years ago.
Gordon Clarke, manager of Sierra MMUG in Auburn will be announcing your talk at his meeting next week, so we expect folks from his group to show up.
My only (very minor) criticism would be recommending the use of the CFCInvoker_EventArgs style listener invocation (passing all the event arguments as separate ColdFusion arguments) instead of the CFCInvoker_Event style (passing a single event object argument) which has become the de facto preferred way because it provides more control, more flexibility and better maintainability.
Then Paul Kenney made an innocent observation on the Mach II forums and the lightbulb went on: views are executed as the body of a ViewContext object and so they have access to the arguments of the displayView() method! Duh! That means that we don't need to use request scope inside a view to access the event object - and we probably shouldn't (coupling of code to scopes etc) - we can use arguments.event instead. Or just simply event although I prefer the explicit scoping myself.
It also means that a view can find out its name (arguments.viewName) which may or may not be useful (for example if you define two views with different names but the same physical view file). You can also tell whether a view will render straight to the screen or whether it is going to be saved in a variable - by testing arguments.contentKey (which will be "" if no contentKey= attribute was specified in the <view-page> command).
In the evening, I went out to dinner with several user group managers under the wing of Ed Sullivan and had some enjoyable discussions about ColdFusion and the MX universe. It's really encouraging to see how passionate folks are here about the Macromedia technologies!
The Mach II Development Guide has been updated (Release 1.1.1) to reflect the changes in the 1.0.9 core files. Note in particular the changes in the plugins section!
