Welcome to the Edmund mailing list!
seancorfield
My blog posts tried to explain my motivation for this project but I'll
try to do so again in a more coherent manner.
We have a rich, expressive way of writing our user interfaces now -
Flex has an event-based model, various HTML application frameworks
(ColdBox, Mach-II, Model-Glue) have an event-based model, AJAX has a
number of frameworks and you can write complex event-based code there
as well.
However, when we backend these user interfaces with services, those
services tend to be fairly dumb call-and-return interfaces and we see
a lot of duplication of logic between AJAX, Flex and HTML
(controllers). Even if we are not trying to create multiple user
interfaces for a single model, we still tend to put a lot of control
logic in the front end that might be better placed in the backend,
e.g., security logic.
I believe there's a gap here that Edmund could fill: namely that of
offering a rich, event-based way to build services and then those
services can be used by multiple clients - including HTML application
front ends - with a lot less duplication of logic.
So far Edmund is just a concept (well, an Event.cfc exists on my local
hard drive!) and I'm hoping for a truly open development process where
I can incorporate feedback from the community and build something that
people actually want to use.
Some of my ideas for Edmund:
1. Support announce / dispatch of events and listeners for events
(implicit invocation: dispatchers know nothing of listeners, listeners
know nothing of dispatchers).
2. Support both synchronous event handling and asynchronous event
handling. I believe both are important in order to build flexible,
powerful services.
3. Support both programmatic and declarative configuration. Some
people are happy with XML, some are not. Some people prefer convention-
based auto-discovery of application components. I'd like to explore
all three options.
4. Support the option to generate remote facades from some sort of
specification for the event model. Note: this would be optional - you
could write your remote facades by hand and use any of the three
options for configuration (see #3). I just think it would be
convenient to have Edmund be able to auto-generate a remote facade
based on a declarative configuration.
5. Should be lightweight, high-performance and play nicely with any
other frameworks you want to use.
6. Will almost certainly be ColdFusion 8 only. The asynchronous event
handling will need <cfthread> so it might be possible to make that
optional to allow the rest of Edmund to run on earlier versions (or
other engines). We'll see.
I'm looking forward to everyone's feedback and I'll make prototypes
and early builds available here as and when I have them ready. The
code will be hosted on Google Code in my http://code.google.com/p/org-corfield-cfmx/
project (although Edmund will be a top-level folder, not
org.corfield.edmund - unless folks have any reason to prefer the
latter?).
Sean