Typed Events: "Chaining"
John C. Bland II
<before>
<broadcasts>
<message name="SetPageConfigs" />
</broadcasts>
</before>
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?
---
John C. Bland II
http://www.johncblandii.com
http://www.johnandseason.com
http://www.twitter.com/johncblandii
---
Suggested sites:
http://www.lifthimhigh.com - "Christian Products for Those Bold Enough to Wear Them"
http://www.sportsmatchmaker.com - "What are you doing today?"
Jared Rypka-Hauer
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
Dan Wilson
“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.”
Guillaume Apollinaire quotes
John C. Bland II
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
Let me know if this is good:
<event-type name="Global">
<before>
<broadcasts>
<message name="SetPageConfigs" />
</broadcasts>
</before>
<views>
<include name="globalnav" template="global/globalnav.cfm"/>
<include name="utilities" template="global/utilities.cfm"/>
<include name="navsearch" template="global/navsearch.cfm"/>
<include name="quicksearch" template="global/quicksearch.cfm"/>
<include name="messagecenter" template="global/messagecenter.cfm"/>
</views>
</after>
</event-type>
<event-type name="HomeTemplate">
<after>
<results>
<result do="template.home" />
</results>
</after>
</event-type>
...
<event-handler name="home" type="Global,HomeTemplate">
<views>
<include name="body" template="pages/home/body.cfm"/>
<include name="panel" template="pages/home/panel.cfm"/>
</views>
</event-handler>
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.
<cffunction name="SetPageConfigs" access="public" returntype="void" output="false">
<cfset arguments.event.setValue("urlConfig", getModelGlue().getBean("urlConfig")) />
</cffunction>
...
<bean id="urlConfig" class="ModelGlue.Bean.CommonBeans.SimpleConfig">
<property name="config">
<map>
<entry key="imagesPath"><value>/assets/images</value></entry>
<entry key="stylesPath"><value>/assets/css</value></entry>
<entry key="scriptsPath"><value>/assets/scripts</value></entry>
</map>
</property>
</bean>
Is this a good way to approach things?
Mind you, the url's are config'd purely for the sake of a potential move to a CDN in which I don't want to find/replace all assets/images paths.
Thoughts?
---
John C. Bland II
http://www.johncblandii.com
http://www.johnandseason.com
http://www.twitter.com/johncblandii
---
Suggested sites:
http://www.lifthimhigh.com - "Christian Products for Those Bold Enough to Wear Them"
http://www.sportsmatchmaker.com - "What are you doing today?"
Jared Rypka-Hauer
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
>
> Let me know if this is good: ...
Dan Wilson
(We blogged the answer: http://www.model-glue.com/blog/index.cfm/2009/10/8/Ask-ModelGlue-Beans-Scope )
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.
Consider this code:
<cfset arguments.event.setValue("urlConfig", getModelGlue().getBean("urlConfig")) />
</cffunction>
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:
beans="urlConfig,UserService">
<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:
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.
Keep sniffing the 'Glue
John C. Bland II
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! ;-)
---
John C. Bland II
http://www.johncblandii.com
http://www.johnandseason.com
http://www.twitter.com/johncblandii
---
Suggested sites:
http://www.lifthimhigh.com - "Christian Products for Those Bold Enough to Wear Them"
http://www.sportsmatchmaker.com - "What are you doing today?"
John C. Bland II
I made the change and it is working as advertised. :-D
---
John C. Bland II
http://www.johncblandii.com
http://www.johnandseason.com
http://www.twitter.com/johncblandii
---
Suggested sites:
http://www.lifthimhigh.com - "Christian Products for Those Bold Enough to Wear Them"
http://www.sportsmatchmaker.com - "What are you doing today?"
Jared Rypka-Hauer
(We blogged the answer: http://www.model-glue.com/blog/index.cfm/2009/10/8/Ask-ModelGlue-Beans-Scope )
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. ...