Access Model-Glue from webroot?

21 views
Skip to first unread message

marc

unread,
Jan 22, 2012, 5:13:01 PM1/22/12
to model...@googlegroups.com
Hi,

I have a javascript file: /includes/js/login.js.cfm that I include in the login page of my Model-Glue application:

    <head>
        <script type="text/javascript" src="/includes/js/login.js.cfm"></script>
        [....]
    </head>

Inside file login.js.cfm I want to access the default ColdSpring ApplicationConfiguration bean:

<cfset loginTimeOut=Application["#application.applicationName#"].getBean("ApplicationConfiguration").getConfigSetting("LoginTimespan")>
<cfset loginTimeOutMessage=Application["#application.applicationName#"].getBean("i18nService").getText("message_loginTimeOutMessage")>

In my development environment this works: I get to the Model-Glue framework and can access method getBean().

in my production (shared hosting) environment it does not work: application.applicationName resolves to "CMS" but there is no Application["CMS"] key so I get an CF error page instead of a nice Javascript include.

Application.cfc and Coldspring.xml files are identical in production and development. Only in these 2 files the Application name gets set. I would think that if this.name in Application.cfc's is set to "CMS", I should have a key "CMS" in Applicationscope everywhere in my application, right?

Apparently this is not true.

But In production there is a Application._modelglue key that contains the Model-Glue framework. So if I do

<cfset loginTimeOut=Application._modelglue.getBean("ApplicationConfiguration").getConfigSetting("LoginTimespan")>
<cfset loginTimeOutMessage=Application._modelglue.getBean("i18nService").getText("message_loginTimeOutMessage")>

everything works fine there, but not in my development environment since there is no key Application._modelglue there

So my question is:

How can I access Model-Glue (or the bean I'm after here) in a file that's not "in the framework" as in this case?

Thanks,

Marc

Chris Blackwell

unread,
Jan 23, 2012, 6:17:36 AM1/23/12
to model...@googlegroups.com
I would place your ApplicationConfig, i18nService and any other bean you want to access externally in a parent bean factory, create this in your Application.cfc's onApplicationStart method and set it into the application scope.  The tell ModelGlue to use this as a parent to its internal bean factory.  You do this in your ModelGlue app's index.cfm by setting   <cfset ModelGlue_PARENT_BEAN_FACTORY = application.whereverYouPutYourBeanFactory />

Chris

--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
 
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en

Dan Wilson

unread,
Jan 23, 2012, 8:29:29 AM1/23/12
to model...@googlegroups.com
Without pretty much any exception, you should never access the application scope in a ModelGlue application.

If you are trying to access the default ColdSpring ApplicationConfiguration bean, then treat the javascript file like a normal Model Glue view. This means you need to:
  • Stick your ApplicationConfig bean in the event. (I often do this in the onRequestStart() method)
  • Pull ApplicationConfig out of the event in your view.



DW





--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
 
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to model...@googlegroups.com
To unsubscribe from this group, send email to
model-glue+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en



--
Plutarch - "The mind is not a vessel to be filled but a fire to be kindled."

marc

unread,
Jan 23, 2012, 10:14:45 AM1/23/12
to model...@googlegroups.com
It occured to me after posting to make the javascript file a MG view. This means the js code should be put in the views folder in one of te locations defined in the viewMapping. That javascript code gets included in the head. So instead of

<head>
    <script type="text/javascript" src="/includes/js/myJsFile.js"></script>
</head>

I'll have

<head>
<script type="text/javascript" >
    [... all the javascript formerly included]
</script>
</head>

I guess this has the benefity of less requests to the server to retrieve external js libraries.

Marc

Chris Blackwell

unread,
Jan 24, 2012, 7:23:56 AM1/24/12
to model...@googlegroups.com
Making the js file a modelglue view means that every request for the js will be processed by mg & cf, that's a real waste of resources. Including all your js in the head of your view template is a waste of bandwidth. 

As javascript doesn't care where variables are loaded, only that they are available when needed I'd split all these things up and load them in the most appropriate place.
  • output user/request specific variables, like username, in the head of your page, this could be an included MG view for easy reuse
  • include application level variables via a static js file that is generated in ModelGlue's onApplicationStart, this might include a single strings.js file or one for each locale you support, eg. strings_en.js, including only the appropriate one for the user.
  • include your main js file
This approach has several benefits; 
  • reduce the number of requests processed by CF to a minimum
  • keep the size of each request as small as possible
  • you can make the most of browser caching so static files are only loaded once.  
Forcing the reload of generated static files is simple if you use a param in your script urls eg. <script src="strings.js?v=1234"> Changing the value of v will cause the browser to reload the js.

Chris



Marc

--
Reply all
Reply to author
Forward
0 new messages