Model Glue Views Demystified
At first, getting a grasp on how to "think" about rendered views in Model Glue may appear to be challenging; but I tell you, that you already know exactly how to think about them. If you have EVER included a template using <CFINCLUDE>, then you have a two minute learning curve to working with views in Model Glue.
Breaking your page up into individual pieces, and then including those pieces later on as needed is not a new thing for most of us. That is precisely what Model Glue allows us to do as well. Is it ever required that we divide our code into individual templates? Nay, and neither does Model Glue require it. It is, however, a very good idea in most instances, and MG gives us a very easy way to do this.
Picture if you will, a template.
We have dsp_main.cfm that will act as our layout, containing only DIV tags with appropriate IDs. Dsp_main.cfm also includes our external style sheet to provide appropriate positioning and look and feel to whatever content we put into those DIVs. Before Model Glue, we'd do it like this:
Nothing new there, right? With Model Glue, the same dsp_main.cfm looks like this:
With Model Glue, rather than include those templates within the page itself, the templates were pre-rendered (almost exactly like using a CFSAVECONTENT), the rendered html stuffed into what's called the ViewCollection, and then we simply grab that rendered HTML out of the ViewCollection and output it in a very familiar fashion.
Now, how were those individual templates included? We told Model Glue to do it within the Modelglue.XML file that defines our individual events. For instance, let's say the event we called was 'main.landing' (http://www.mysite.com/index.cfm?event=main.landing). The relevant XML looks like this:
<event-handler name="main.landing">
<broadcasts />
<results />
<views>
<include name="body" template="dsp_content.cfm" /><!-- available in the viewcollection as 'body' -->
<include name="nav" template="dsp_nav.cfm" /><!-- available in the viewcollection as 'nav' -->
<include name="footer" template="dsp_footer.cfm" /><!-- available in the viewcollection as 'footer' -->
<include name="header" template="dsp_header.cfm" /><!-- available in the viewcollection as 'header' -->
<include name="main" template="dsp_main.cfm" /><!-- container template to layout individual parts -->
</views>
</event-handler>
Using the 'include' tag within the 'views' tag, we told Modelglue which templates to render. Of note is the fact that the order in which they are rendered is completely irrelevant, WITH ONE EXCEPTION: the template that acts as the layout container MUST BE RENDERED LAST.
Also of note is the fact that each of your view templates should act independently of one another. For example, let's say that a Model Glue variable is needed in the dsp_nav.cfm and that same variable is also used somewhere in the dsp_content.cfm template. It would be bad practice for you to retrieve that variable within dsp_nav.cfm and then attempt to access the retrieved instance from dsp_content.cfm; each template should be retrieving it for themselves.
That's it, boys and girls. Nothing to it, and very little difference from the way you've been using <CFINCLUDE> all along!
Breaking your page up into individual pieces, and then including those pieces later on as needed is not a new thing for most of us. That is precisely what Model Glue allows us to do as well. Is it ever required that we divide our code into individual templates? Nay, and neither does Model Glue require it. It is, however, a very good idea in most instances, and MG gives us a very easy way to do this.
Picture if you will, a template.
We have dsp_main.cfm that will act as our layout, containing only DIV tags with appropriate IDs. Dsp_main.cfm also includes our external style sheet to provide appropriate positioning and look and feel to whatever content we put into those DIVs. Before Model Glue, we'd do it like this:
<html>
<head>
<title>My Composite Template</title>
<link rel="stylesheet" type="text/css" href="css/styles.css" media="screen" />
</head>
<body>
<div id="header"><cfinclude template="dsp_header.cfm"></div>
<div id="nav"><cfinclude template="dsp_nav.cfm"></div>
<div id="body"><cfinclude template="dsp_body.cfm"></div>
<div id="footer"><cfinclude template="dsp_footer.cfm"></div>
</body>
</html>
<head>
<title>My Composite Template</title>
<link rel="stylesheet" type="text/css" href="css/styles.css" media="screen" />
</head>
<body>
<div id="header"><cfinclude template="dsp_header.cfm"></div>
<div id="nav"><cfinclude template="dsp_nav.cfm"></div>
<div id="body"><cfinclude template="dsp_body.cfm"></div>
<div id="footer"><cfinclude template="dsp_footer.cfm"></div>
</body>
</html>
Nothing new there, right? With Model Glue, the same dsp_main.cfm looks like this:
<!--- grab my rendered views out of the viewcollection... --->
<cfset header = viewCollection.getView("header") />
<cfset footer = viewCollection.getView("footer") />
<cfset body = viewCollection.getView("body") />
<cfset nav = viewCollection.getView("nav") />
<html>
<head>
<title>MG View Demo</title>
<link rel="stylesheet" type="text/css" href="css/styles.css" media="screen" />
</head>
<body>
<div id="header"><cfoutput>#header#</cfoutput></div>
<div id="nav"><cfoutput>#nav#</cfoutput></div>
<div id="body"><cfoutput>#body#</cfoutput></div>
<div id="footer"><cfoutput>#footer#</cfoutput></div>
</body>
</html>
<cfset header = viewCollection.getView("header") />
<cfset footer = viewCollection.getView("footer") />
<cfset body = viewCollection.getView("body") />
<cfset nav = viewCollection.getView("nav") />
<html>
<head>
<title>MG View Demo</title>
<link rel="stylesheet" type="text/css" href="css/styles.css" media="screen" />
</head>
<body>
<div id="header"><cfoutput>#header#</cfoutput></div>
<div id="nav"><cfoutput>#nav#</cfoutput></div>
<div id="body"><cfoutput>#body#</cfoutput></div>
<div id="footer"><cfoutput>#footer#</cfoutput></div>
</body>
</html>
With Model Glue, rather than include those templates within the page itself, the templates were pre-rendered (almost exactly like using a CFSAVECONTENT), the rendered html stuffed into what's called the ViewCollection, and then we simply grab that rendered HTML out of the ViewCollection and output it in a very familiar fashion.
Now, how were those individual templates included? We told Model Glue to do it within the Modelglue.XML file that defines our individual events. For instance, let's say the event we called was 'main.landing' (http://www.mysite.com/index.cfm?event=main.landing). The relevant XML looks like this:
<event-handler name="main.landing">
<broadcasts />
<results />
<views>
<include name="body" template="dsp_content.cfm" /><!-- available in the viewcollection as 'body' -->
<include name="nav" template="dsp_nav.cfm" /><!-- available in the viewcollection as 'nav' -->
<include name="footer" template="dsp_footer.cfm" /><!-- available in the viewcollection as 'footer' -->
<include name="header" template="dsp_header.cfm" /><!-- available in the viewcollection as 'header' -->
<include name="main" template="dsp_main.cfm" /><!-- container template to layout individual parts -->
</views>
</event-handler>
Using the 'include' tag within the 'views' tag, we told Modelglue which templates to render. Of note is the fact that the order in which they are rendered is completely irrelevant, WITH ONE EXCEPTION: the template that acts as the layout container MUST BE RENDERED LAST.
Also of note is the fact that each of your view templates should act independently of one another. For example, let's say that a Model Glue variable is needed in the dsp_nav.cfm and that same variable is also used somewhere in the dsp_content.cfm template. It would be bad practice for you to retrieve that variable within dsp_nav.cfm and then attempt to access the retrieved instance from dsp_content.cfm; each template should be retrieving it for themselves.
That's it, boys and girls. Nothing to it, and very little difference from the way you've been using <CFINCLUDE> all along!
Subscription Options
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
Re: Model Glue Views Demystified
Doug, I'm only starting to get into MG but this is the kind of explanation that I couldn't seem to find anywhere else. Simplified and concise... I get it now.
Thanks,
Max
Thanks,
Max
Posted by Max on July 29, 2007 at 9:32 AM
Re: Model Glue Views Demystified
Hi Max. I'm very glad you found the explanation useful! I've had to learn a lot of this stuff the hard way (banging my head against it, reading every tidbit I could find, then assimilating it all), so it is my personal policy to share what I know. As I become aware of things I've learned that I feel could help somebody else I'll be sure and post them!
Doug :0)
Doug :0)
Posted by dougboude on July 29, 2007 at 10:25 PM
Re: Model Glue Views Demystified
Could not have explained it better if I tried. Your MG:Blog is fast becoming a prerequisite reading list for my team. Cheers
Posted by J Nanda on August 4, 2007 at 4:32 AM
Re: Model Glue Views Demystified
Could not have explained it better if I tried. Your MG:Blog is fast becoming a prerequisite reading list for my team. Cheers
Posted by J Nanda on August 4, 2007 at 4:33 AM