>
> > As I understand the MVC pattern, the idea is that controllers know what
> they
> > can do and listen for someone asking for those things to be done -- it's
> all
>
> Ah ha. And this why the main view sends an event saying 'start up',
> and you map (with eventHandlers) that to per-command events ?
> So every command method has an associated event ?
>
I think you're munging the terminology here a bit. By "command method" I
think you mean controller method/function? And by "associated event" I think
you mean "message"? If so, then yes.
Think about Model-Glue as that guy that everybody knows that introduces
people to each other because of common interests. Your controllers tell him,
"I'm running a business where I tell people if the current user is logged in
or not" and someone else tells him "I need to know if the current user is
logged in or not" and he says, "I have just the guy for you!" (Again, think
about business logic chunks, not application events)
When the controller tells our friend (MG) what he can do, he's registering a
message-listener. "If anyone needs isLoggedIn status, you send them to me,
ok?" The key bit is "anyone." He doesn't care who (what event) it is. He
knows that someone (anyone) wants to know if the user is logged in, and
he'll answer every time anyone asks.
When the event (note: not the view, the event -- this is strictly
configuration) tells our friend (MG) that he needs some work done, he
doesn't tell him where he wants it done, he just says, "I need isLoggedIn
status" and lets his friend figure out who should fill that request. (This
is where you're getting tripped up, I think. In your configuration, our
friend -- MG -- knows who the event is and says "do any of my contacts
(controllers) do stuff for this guy?" The controllers shouldn't need to know
what events they service, only what they do.)
> > From a coding standpoint, the problem with that organization is that when
> > you add a new event that needs to use some existing business logic, not
> only
> > do you have to write the event configuration, but now you also have to go
> > back and update the various controllers to respond to that event.
>
> Well, I'd have to update the MG config to send the new event to the
> existing controller...
>
You don't send the event to the controller, your event just says, "I need
some work done" -- possibly a dozen messages, each for a different piece of
work that it needs done -- and it doesn't care who responds as long as
someone does.
Yes, this is all in the MG config, but as I mentioned earlier, you're
cluttering up your controller config with duplicate message listeners for
every event they need to respond to. Instead, the generally accepted
approach is to have the event broadcast the one message that corresponds to
the controller function that should be run; the controller maps one message
to one function.
> > In "my"
> > proposed organization, you just write the event configuration and
> broadcast
> > the message corresponding to the business logic you want to use, and
> there
> > is no need to update controller configuration.
>
> Can you give an example of when you'd write a new event (by which I
> think we mean a user action, like clicking a button, right ?) that
> needs to reuse business logic, but doesn't also need new business
> logic ?
> If I'm adding new logic, I'm going to be editing the config. anyway,
> so may as well 'just' add another listener to the existing code as
> well as creating the new one.
> If I'm only reusing existing logic, they'll be an existing event.
>
You're going to have to edit the config whether the event uses new or
existing functionality... it doesn't matter. But the point I'm trying to
make is that once the existing functionality is working -- your model and
controller work, and listen for a message, and respond to it -- you don't
want to have to edit that too (add a new message listener for the same
function for a different event). You have no choice but to define
(configure) the new event (button click), so the simplest, easiest, most
efficient way to do that is to only edit the event configuration, and not
also the controller configuration.
So on button click, you want to do two things: verify that the user is still
logged in, because you don't want to save their changes unless they are; and
then save changes. In MG-CF XML, this would be:
<event-handler name="myBtnClick">
<broadcasts>
<message name="userIsLoggedIn"/>
<message name="saveChangesFoo"/>
</broadcasts>
<results>
<result name="notLoggedIn" do="home" redirect="true"
preserveState="false"/>
</results>
<views>
<view name="body" template="changesSaved.cfm"/>
</views>
</event-handler>
Maybe you mean things like:
> There is an event that is mapped to two different controllers/methods
> i.e. they both listen to the same message broadcast.
> Now I need to get just one of those methods to fire when something else
> happens.
> Would I not need to create a new event, regardless of which way it's done ?
>
While it is possible for two different controllers (or two different
functions in the same controller) to respond to the same message, it's
(generally) not a good idea for precisely the reason you mention. A message
should be indicative of a unique bit of work.
Another way of looking at it is that your events are zombies. They don't
know what the heck they are doing. They just announce their existence and
let god sort it out. Instead, human events know what their purpose is and
although they don't go to the source to get what they want, they know what
they want and ask god for it.
I'm no MVC pro, but this is how I understand the pattern. Most of what I
know I picked up from reading Sean Corfield and Joe Rinehart.
Adam
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
For more about Model-Glue, check http://www.model-glue.com .
-~----------~----~----~----~------~----~------~--~---
