Welcome!

Adobe Flex Authors: Matthew Lobas, PR.com Newswire, Shelly Palmer, Kevin Benedict

Related Topics: Adobe Flex

Adobe Flex: Article

Advanced Templating

Moving around regionally

Dreamweaver hides many wonderful (and often overlooked) tools. While you may be a long-time user of Dreamweaver templates you might not know some of their more powerful features. This article explains how two of these "template secrets" interact, and how you might use them on your pages. I'll assume you have some experience with the basics of Dreamweaver templates, which were greatly improved in Dreamweaver MX (DMX), but remain nearly the same in MX 2004.

Among the many features Macromedia added to Dreamweaver MX's template capability is a collection of new regions, one of which is called an optional region (see Image I). The name of this region is a blatant giveaway of its function - it is a region that may, or may not, be written into, hence visible on pages built from templates. We'll call such template-based pages child pages in this article. To understand how optional regions work, it's important to review the template process.

 

An engine that drives all of DMX's template functionality is called into play at several times during your use of templates. When you spawn a child page (using FILE | New > Templates > Site > (template file name) > Create), this engine is called to conditionally (I'll talk more about the condition part later). Copy the template's code into the child page. When you make edits to the child page, the engine is invoked to check those edits and to make sure that you have not tried to change any non-editable region's content (there are those who believe that the engine contains a random trigger for the error message associated with this check!). And finally, when you make changes to a template page, the engine serves to propagate those changes forward into all existing child pages based on that template (and to once again check to make sure that you have not tried to nest editable regions, or something equally troublesome). The important idea here is that this template engine is deeply and continuously involved in the state of your template-managed site's pages.

The name "optional region" implies that there is some condition on which this region somehow depends, and that is true. These conditions are communicated to the template engine by way of one or more variables that are accessible to each child page, and that can be changed as desired by you, the developer. These variables are called "template parameters" (catchy name, don't you think?). A template parameter is automatically created for you whenever an optional region is inserted into a page. You can then use this parameter's value to modify the display of that optional region's contents on any given child page of this template. To do this, you would open the child page, select MODIFY | template properties..., find and select the parameter's name in the ensuing list of available parameters, and enter a new value for that parameter. On making this change, the template engine examines the parent template page first and then the parameter's value as just changed on the child page, and adjusts the child page's code (and its optional region, if any) accordingly.

Since parameters can be central to the way in which the template's code is written to the child page, it is important to understand a bit more about them. A parameter can hold a value of any sort. This is a bit dangerous when accepting free-form input from a developer. As a result, Macromedia has confined things a bit by allowing only five kinds of parameters: text, URL, number, color, and Boolean. The type of parameter defines which type of user interface you are offered on making a change to that parameter's value, and this is mighty convenient. A text parameter allows the entry of free-form text into an input field, whereas a URL parameter gives you the option to browse to and select a new target file.

In addition to parameter type, there is also a way to assign a parameter default value. This value is used by the template engine to determine how to interpret any use of optional regions or template expressions (a discussion of template expressions will be reserved for a subsequent article) on the page so that the correct code can be written to the child pages. The default value for a parameter is usually determined when that parameter or optional region is defined. Of course, the default value must be consistent with the type assigned to the template parameter or bad things will likely happen.

Finally, each parameter must have a name associated with it so that uses of that parameter's contents can be easily located on child pages.

To see how this works, create a new page in DMX and save it as an HTML template. Use INSERT | Template Objects > Optional Region, leave the default values (name="OptionalRegion1" and Show by default selected), and click OK. Look at the code. In the header of the document you will find the parameter's declaration (see Image II).

 

<!-- TemplateParam name="OptionalRegion1" type="boolean" value="true" -->

In the body of the document you will find the optional region.

<!-- TemplateBeginIf cond="OptionalRegion1" -->
OptionalRegion1<!-- TemplateEndIf -->

Save this file again (ignore the no editable region prompt) and spawn a child page from it. Note that the child page uses the value of the Parameter (true) to satisfy the test

cond="OptionalRegion1"

hence the contents are displayed on the child page. By using MODIFY | Template Properties, you can set the value of this parameter to "false" when you select the OptionalRegion1 parameter and then click the Show OptionalRegion1 checkbox (note that the value is shown under the column labeled "Value"; see Image III). On clicking the OK button, this optional region's content will disappear from the child page. Note carefully that this content disappears because it's not written to the page. When an optional region is not "optioned," that code is never written to the child page (and if it was written before changing the parameter, it is erased from the page by the template engine).

 

So, parameters can be used to control regions, and regions can be used to control page content display. But consider this: an optional region is not necessarily usable only for things that can be displayed. Remember that when the condition fails, the code is not written to the child. So we should broaden this concept to the following: an optional region can control what code is written to the child page.

Note: The code for the parameter's definition is exposed on the child page in code view, as if it were in an editable region. But it is important that you not make changes to the parameter by editing it in code view; otherwise, the page will not be properly updated by the template engine. Changes to parameter values should always be done using the MODIFY | Template Properties approach.

Why bother with this detail? It can be mighty useful, that's why! Here are some scenarios in which you might want to use this method:

Scenario I
Your pages contain images that are section specific. In a single template file, you can insert each image and place an optional region around it with a default value of false. Name these regions something like Section1, Section2, etc. This will give you code that looks something like what is shown in Code I.

Since all of these parameters evaluate false, none of this code will be written to the child pages, i.e., the disadvantage of bulky template markup is minimized. On any given child page where these images are required, use MODIFY | Template Properties to set the desired image's controlling parameter's value to true, and they will then appear on that page when the code is added to reflect this change.

Scenario II
Obviously, the method in Scenario I can be easily adapted to navigation buttons in a "two-state" menu (i.e., each menu button has an up and a down state). Each up and each down button would be placed on the template page, and each button's image would be controlled by an optional region. While somewhat awkward for a complex menu, this method would easily allow you to set the "down state" for any button on any child page. A simple extension of this concept would also allow this method to work for CSS menus rather than image-based menus, using something like the following:

<!-- TemplateBeginIf cond="Link1up" --><a href="link1.html"
class="linkup">Link1</a><!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="Link1down" --><a href="link1.html"
class="linkdown">Link1</a><!-- TemplateEndIf -->

(Be aware that there are better ways to do this using template expressions or multipleIf conditions, but that will be explored in future articles.)

Scenario III
Nothing prevents you from adding an optional region to the head of your template document. This can be handy in some situations.

Say you are working in a collaborative environment, and you want your developers to be able to easily select from one of several stylesheets for the child pages. It is quite simple to put the alternate stylesheet links into optional regions, as shown below.

<!-- TemplateBeginIf cond="Stylesheet1" --><link href="../styles1.css"
rel="stylesheet" type="text/css"> <!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="Stylesheet2" --><link href="../styles2.css"
rel="stylesheet" type="text/css"> <!-- TemplateEndIf -->

Using MODIFY | Template Properties provides easy access to these parameters, allowing instant changes to the referenced stylesheet without unnecessarily giving access to any of the remainder of the head region.

Scenario IV
It is quite possible, and sometimes useful, to use optional regions for selecting between server-side includes on a page, e.g.,

<!-- TemplateBeginIf cond="Include1" --><!-- #include file="myinclude1.asp"
--><!-- TemplateEndIf -->
<!-- TemplateBeginIf cond="Include2" --><!-- #include file="myinclude2.asp"
--><!-- TemplateEndIf -->

This might permit the easy selection of two different navigation schemes within a single template-controlled site.

Note: Although this discussion focuses on optional regions, for which parameters are automatically created by DMX, it is important to mention that this is the only instance in which DMX does the automatic writing of the parameter's code. If you want to use parameters without inserting an optional region, you will have to add the parameter code manually. In addition, the optional region parameters are always Boolean type. If you want another type, you will have to make that change manually, too. Snippets in DMX can work really nicely for this. You can find a template parameter snippet extension on www.dreamweavermx-templates.com for free download.

End Note
Now that the groundwork has been laid for understanding how template parameters work, and how they can be used to control the display of optional regions, it will be much simpler to move on to more advanced applications of these new template features, like multiple conditional tests and template expressions. I hope to be able to share those with you in coming issues.

These ideas and much more about Dreamweaver MX templates are explored in some depth on our book's companion site at www.dreamweavermx-templates.com, developed and written in collaboration with Brad Halstead. I hope that you find this site and its contents useful in your exploration of template capabilities!

More Stories By Murray Summers

Murray Summers is a biochemist by training, but has spent the last 20 years working in the computer industry. In 1998, Murray started Great Web Sights (www.great-web-sites.com). As a Team Macromedia Volunteer, he also participates in the sponsored newsgroups for Dreamweaver and other Macromedia products. Murray is a Macromedia Certified Web site Developer and Dreamweaver Developer

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...