Theory Question - abstracting the model with Edmund

[johnfallen]

Is it a goal of event driven programming to "hide" the model from
application controllers? Give controllers the chance to use an
abstraction of the model, but not the model itself?

Meaning all actors (html/Flex controllers) just ask Edmund to "do"
things instead of exposing the real API methods of the application?

It's a "front controller" for your model?

I guess i just asked the same question 3 times.

I'm really enjoying the framework.

[johnfallen]

[johnfallen]

[johnfallen]

[johnfallen]

[johnfallen]

[johnfallen]

[Sean Corfield]

On Feb 21, 8:52 am, johnfallen <johnfal...@gmail.com> wrote:
> Is it a goal of event driven programming to "hide" the model from
> application controllers?

Not really. It's about "hiding" event consumers from event producers.
Those consumers and producers can both be in the same "layer" - or
they could be in different layers.

> It's a "front controller" for your model?

No. Edmund is not a controller of any sort. One of the goals of event-
driven programming is to decentralize control - to move away from
controllers in a way - so that a component can just focus on its own
job and "let the world know" about things.

For example, when you save an object, you might dispatch an event to
say that object has been saved. Any components interested in that
event can then run. Perhaps a cache needs to be updated, perhaps you
just want to log such updates.

My preso for MAX focused on comparing Flex event-based programming
with what Edmund let's you do in ColdFusion because the Flex
programming model is one that requires a lot of distributed
collaboration in an application. For example, a process that modifies
the model needs to announce when it is done so that the views can all
update themselves. Sometimes you need to announce events throughout a
process so that the UI can change independently of the process
updating the model.

[johnfallen]

Ahhhhh...

A much better explanation.

I thought that the controller analogy was a little dubious.

Thanks for the framework, been having a great time with it this
weekend.

This is one cool, and seems VERY flexable, way to program.

you rule sean!

ja

[Alan Livie]

In a purely CF world would Edmund be of benefit to us?

Also, at Scotch On The Road you are talking about the 'Cloud'. Any chance of an Edmund talk as well?

 

Alan

---

From: Sean Corfield <seanco...@gmail.com>
To: edmund-coldfusion <edmund-c...@googlegroups.com>
Sent: Sunday, February 22, 2009 3:31:16 AM
Subject: [edmund-coldfusion] Re: Theory Question - abstracting the model with Edmund

[Sean Corfield]

On Feb 21, 7:38 pm, Alan Livie <alanli...@yahoo.com> wrote:
> In a purely CF world would Edmund be of benefit to us?

I find it of benefit.

In one production app I have an audit trail module that is driven
entirely by events. When a user logs in, logs out, downloads a
document etc, events are triggered. The audit module listens for those
events. The async nature means that auditing can be performed
alongside the request without impacting it. I'm gradually converting
other parts of the app to use async events as a way to streamline
processing.

> Also, at Scotch On The Road you are talking about the 'Cloud'. Any chance of an Edmund talk as well?

Andy has me down for Living in the Cloud at all three venues and he
turned down my Behavior-Driven Development with cfSpec talk (as did
CFUNITED, when they asked me to give Living in the Cloud). cf.Objective
() hasn't confirmed which (if either) of those two talks they will
pick up but they have expressed some interest. I didn't submit Edmund
as a topic because I didn't think the talk went all that well at
Scotch 2008 or CFUNITED 2008. It went better at MAX 2008 but still
left the audience very confused. Until I have something substantially
new to say about Edmund, I don't want to inflict it on anyone else...

I'm happy to talk to individuals informally about Edmund outside
regular conference schedule hours of course, over a beer for example :)