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!