I don't think typed events have any sort of inheritance, and typically the broadcasts are redundant like that by design. Its something everyone complains about until they have an ultramassive application and realize that knowing what your events are doing at a glance is extremely valuable.
The thing is, In exchange for a bit of redundancy, you have automatic documentation built in to your application. If you name your events and controller functions well, and you use the MG config file as it's intended, you could send me your config file and I would have an immediate idea of what your application is doing. It's why MG is so popular for team dev efforts.
Trust me, I understand your frustration, but there is a payoff... it just comes a bit later on.
J
On Oct 8, 2009, at 10:09 AM 10/8/09, John C. Bland II wrote:
> I try to set a type on an eventtype but it doesn't work (figured it > wouldn't) so my question is: can I "chain" (create parent types) > typed events?
> I don't want to have to have the above block for all X of my typed > events. Thoughts?
> I don't think typed events have any sort of inheritance, and typically
> the broadcasts are redundant like that by design. Its something
> everyone complains about until they have an ultramassive application
> and realize that knowing what your events are doing at a glance is
> extremely valuable.
> The thing is, In exchange for a bit of redundancy, you have automatic
> documentation built in to your application. If you name your events
> and controller functions well, and you use the MG config file as it's
> intended, you could send me your config file and I would have an
> immediate idea of what your application is doing. It's why MG is so
> popular for team dev efforts.
> Trust me, I understand your frustration, but there is a payoff... it
> just comes a bit later on.
> J
> On Oct 8, 2009, at 10:09 AM 10/8/09, John C. Bland II wrote:
> > Ok...I'm messing with the typed events and realize I have multiple
> > event types with duplicated code.
> > I try to set a type on an eventtype but it doesn't work (figured it
> > wouldn't) so my question is: can I "chain" (create parent types)
> > typed events?
> > I don't want to have to have the above block for all X of my typed
> > events. Thoughts?
-- “Come to the edge, he said. They said: We are afraid. Come to the edge, he
said. They came. He pushed them and they flew.”
The idea is my page is separated into mini-views so I can pick and choose
what is included from the config. For instance, the messagecenter is only
shown on some pages and not all. Whenever it is "config'd" it shows up.
The SetPageConfigs event basically gets a custom bean and adds it to the
event so on the page I can control specific things like base url's to
images, styles, scripts, etc.
> I don't think typed events have any sort of inheritance, and typically
> the broadcasts are redundant like that by design. Its something
> everyone complains about until they have an ultramassive application
> and realize that knowing what your events are doing at a glance is
> extremely valuable.
> The thing is, In exchange for a bit of redundancy, you have automatic
> documentation built in to your application. If you name your events
> and controller functions well, and you use the MG config file as it's
> intended, you could send me your config file and I would have an
> immediate idea of what your application is doing. It's why MG is so
> popular for team dev efforts.
> Trust me, I understand your frustration, but there is a payoff... it
> just comes a bit later on.
> J
> On Oct 8, 2009, at 10:09 AM 10/8/09, John C. Bland II wrote:
> > Ok...I'm messing with the typed events and realize I have multiple
> > event types with duplicated code.
> > I try to set a type on an eventtype but it doesn't work (figured it
> > wouldn't) so my question is: can I "chain" (create parent types)
> > typed events?
> > I don't want to have to have the above block for all X of my typed
> > events. Thoughts?
Should work. If there's someone here with a bit more familiarity with typed events, I'm sure they can comment further... I haven't had a chance to play with them much yet... I was stuck using MG:U when MG:G was getting off the ground. :( As I understand things, though, you have the idea right. I like how you're using the SimpleConfig to pull configuration details from... *gasp* the config files. ;)
I have are a couple observations tho:
1) There are onRequestStart and End functions that, if in a controller, will automatically run at the appropriate time. You could put the PageConfigs operation in there. On the other hand, that makes them rather invisible, and voodoo isn't good if you're expecting your configs to document your application. I keep meaning to write a MG config file parser that would show you a map of your events, but I never quite get around to it. Anyway... just sayin. (I'd actually leave it how it is till you have a reason to switch.)
2) You said "The SetPageConfigs event..." and I just want to point out that SetPageConfigs is a broadcast, or a message, not an event. Niggling perhaps, but an important, and common, mistake that can lead to a great deal of confusion... especially on the lists. Events are defined with event-handlers and event-handlers broadcast messages. ;) Don't let it happen again! *G*
On Oct 8, 2009, at 11:44 AM 10/8/09, John C. Bland II wrote:
Hi , John, that looks pretty good. You are definitely on the right track with your event type work. Your question is actually a very timely one and gives us an opportunity to share a new feature of Model-Glue 3. Since you are interested in short cuts and in using MG3 most effectively, let's talk about the newly added Beans scope.
In your code sample, you defined a configuration bean in ColdSpring, always a good thing, and retrieved it from ColdSpring with the syntax getModelGlue().getBean("urlConfig").
Nothing is wrong with that syntax at all, and your code will work fine. However, there is an even easier way to get beans from ColdSpring. MG3 introduces the concept of the Beans scope that is not only easier, but it also leaves good documentation of your application as well.
The urlConfig object is retrieved from ColdSpring through the getModelGlue().getBean() declaration. What is nice about this is it makes accessing ColdSpring managed objects very easy. However, it sort of makes it difficult to find all the the Coldspring managed beans in a specific controller. Using Find tools to scan source code for references is not really the very best thing because other developer may have chosen a name that isn't obvious or has been abstracted for some reason. Model-Glue 3 introduces the notion of a 'beans' scope. The Beans scope is a controller-wide scope containing all the ColdSpring managed beans for a specific controller. Here is a short sample:
<cffunction name="doSetUp" output="false" access="public" returntype= "void" hint="I perform global setup stuff for each request"> <cfargument name="event" type="any"> <cfset arguments.event.setValue("urlConfig", beans.urlConfig ) /> </cffunction> ...
See the beans attribute of the cfcomponent tag? This is a comma separated list of all the ColdSpring managed beans we need in this controller. Inside the doSetup() method, we use the prefix 'beans' to get at the specific object: beans.xxxxx
One nice effect of this technique is less typing on the keyboard.
More importantly, we now have a bit of *auto-documentation* on exactly which ColdSpring managed beans are used by this controller. This documentation is at the very top of the file. Now, when you maintain your code, or code from other developers, you can simply read the beans attribute in your controller to find out which beans are in use, rather than scanning or reading lots of code for that information. Nice huh?
Model-Glue is all about building applications quicker and reducing maintenance costs and I'm sure you'll agree the Beans scope makes sense on both fronts.
It is working so far. :-) This MG stuff is already saving me a bunch of time
for sure.
1) You know what...that's a good idea. I get the voodoo part so I'll
definitely keep it in the back of my mind but since this is for sure a
global process it could work best in the onRequestStart. Good point!
2) Perfect. Thanks for the correction. I wanna speak intelligently so any
points of clarification help. I'll watch it homie! ;-)
> Should work. If there's someone here with a bit more familiarity with
> typed events, I'm sure they can comment further... I haven't had a
> chance to play with them much yet... I was stuck using MG:U when MG:G
> was getting off the ground. :( As I understand things, though, you
> have the idea right. I like how you're using the SimpleConfig to pull
> configuration details from... *gasp* the config files. ;)
> I have are a couple observations tho:
> 1) There are onRequestStart and End functions that, if in a
> controller, will automatically run at the appropriate time. You could
> put the PageConfigs operation in there. On the other hand, that makes
> them rather invisible, and voodoo isn't good if you're expecting your
> configs to document your application. I keep meaning to write a MG
> config file parser that would show you a map of your events, but I
> never quite get around to it. Anyway... just sayin. (I'd actually
> leave it how it is till you have a reason to switch.)
> 2) You said "The SetPageConfigs event..." and I just want to point out
> that SetPageConfigs is a broadcast, or a message, not an event.
> Niggling perhaps, but an important, and common, mistake that can lead
> to a great deal of confusion... especially on the lists. Events are
> defined with event-handlers and event-handlers broadcast messages. ;)
> Don't let it happen again! *G*
> On Oct 8, 2009, at 11:44 AM 10/8/09, John C. Bland II wrote:
> > You make a great point about documenting the app.
> > I've figured out my holes in my config and have it working much
> > better now. I even have separated config files. :-D Woot! lol
> Hi , John, that looks pretty good. You are definitely on the right track
> with your event type work. Your question is actually a very timely one and
> gives us an opportunity to share a new feature of Model-Glue 3. Since you
> are interested in short cuts and in using MG3 most effectively, let's talk
> about the newly added Beans scope.
> In your code sample, you defined a configuration bean in ColdSpring, always
> a good thing, and retrieved it from ColdSpring with the syntax
> getModelGlue().getBean("urlConfig").
> Nothing is wrong with that syntax at all, and your code will work fine.
> However, there is an even easier way to get beans from ColdSpring. MG3
> introduces the concept of the Beans scope that is not only easier, but it
> also leaves good documentation of your application as well.
> The urlConfig object is retrieved from ColdSpring through the
> getModelGlue().getBean() declaration. What is nice about this is it makes
> accessing ColdSpring managed objects very easy. However, it sort of makes it
> difficult to find all the the Coldspring managed beans in a specific
> controller. Using Find tools to scan source code for references is not
> really the very best thing because other developer may have chosen a name
> that isn't obvious or has been abstracted for some reason. Model-Glue 3
> introduces the notion of a 'beans' scope. The Beans scope is a
> controller-wide scope containing all the ColdSpring managed beans for a
> specific controller. Here is a short sample:
> <cffunction name="doSetUp" output="false" access="public" returntype=
> "void" hint="I perform global setup stuff for each request">
> <cfargument name="event" type="any">
> <cfset arguments.event.setValue("urlConfig", beans.urlConfig ) />
> </cffunction>
> ...
> See the beans attribute of the cfcomponent tag? This is a comma separated
> list of all the ColdSpring managed beans we need in this controller. Inside
> the doSetup() method, we use the prefix 'beans' to get at the specific
> object:
> beans.xxxxx
> One nice effect of this technique is less typing on the keyboard.
> More importantly, we now have a bit of *auto-documentation* on exactly
> which ColdSpring managed beans are used by this controller. This
> documentation is at the very top of the file. Now, when you maintain your
> code, or code from other developers, you can simply read the beans attribute
> in your controller to find out which beans are in use, rather than scanning
> or reading lots of code for that information. Nice huh?
> Model-Glue is all about building applications quicker and reducing
> maintenance costs and I'm sure you'll agree the Beans scope makes sense on
> both fronts.
> Hi , John, that looks pretty good. You are definitely on the right > track with your event type work. Your question is actually a very > timely one and gives us an opportunity to share a new feature of > Model-Glue 3. Since you are interested in short cuts and in using > MG3 most effectively, let's talk about the newly added Beans > scope. ...
