Stupid Index Block Tricks

Stupid Index Block Tricks...they’re not just for navigation

Dave ShaykewichUniversity of Victoria

Agenda

• UVic Cascade environment• Index block basics• Tricks• Navigation• Reporting• Content aggregation• Decision tree wizard• Content searching

• Is there something you’d like to share with the class?

The University of Victoria

• The University of Victoria is on an island on the west coast of Canada (~70 miles from Seattle)

• ~18,000 FTEs, 11 Faculties, ~70 Departments

UVic Cascade Environment

• Cascade WCMS is offered as a service to all faculties, departments/units, and research projects on campus (not to individuals)

• Currently ~190 sites, 850 users in Cascade

• Started with Cascade 6.x, now on 7.07

UVic Cascade Environment

• One template for all ‘UVic’ sites

• One config set/site (referencing central template, formats)• Many site-specific blocks/formats

• XSLT shop (history with Banner’s “Luminis” tools)

Index blocks

• Getting started with index blocks & formats• “An index block is a special type of block asset that

returns a listing of assets from the CMS directory structure in the form of XML data.”

• A format is a “transformation asset that can be applied at the region-level” … “the same way that a stylesheet can be applied.”

Index blocks

• XML representation of folders, pages, blocks, files, and external links• Folder, page and block attributes• modified date, by• published date, by• metadata (including custom metadata)

• Page (and block) content (HTML/XML)• “Default” region content on pages, and• Data definition structure and content

Index block tricks

• Index blocks know a whole lot about your site...

Let’s have a look at some tricks we can use to use them to our advantage.

Index blocks

• Rethinking index blocks• They’re more than just navigation generators...

• Index blocks are self-updating, query-able databases of site content (and all of its attributes)

• Formats are the means to query index blocks and output structured HTML markup • and/or CSS• and/or JavaScript • and/or server-side code (e.g., PHP)

Trick 1: Navigation

• Purpose: • Have Cascade generate navigation that maintains

context • i.e., highlights current page’s ancestors’ navigation

Trick 1: Navigation

• Sample: http://www.uvic.ca/future-students/undergraduate/programs/distance/index.php

http://www.uvic.ca/future-students/undergraduate/programs/distance/index.php

http://www.uvic.ca/future-students/undergraduate/programs/distance/index.php

Trick 1: Navigation

• Recipe: • Build out site structure in Cascade

• Folder hierarchy to correspond to navigational elements• Create index block of site folders and pages • Transform index block into navigation HTML

• Recursively step through folders to create a nested unordered list

• Add class of ‘selected’ to each with an descendant that’s “current”

• Add class of ‘expandable’ to each list item that contains child folders

Trick 1: Navigation

Trick 1: Navigation

• The good: • Navigation is automatically constructed as the site is constructed • Context is maintained (so users know where they are in a site)• Format code is relatively simple• Write format once, use it on all your sites, maintain consistency• Example scripts delivered with Cascade (example.com site)

• The bad:

• The ugly• When folders are added/removed, pages need to be re-published • Before index block caching, big sites were very slow to load

Trick 2: Content reporting

• Purpose:• Provide project managers, content contributors with on-

demand reports about the content in their site• Particularly useful during site development• Search within code/tags

• Answer questions like:• Are there any links to an old site in the content?• Are there any pages ready for me to work on?• Which pages are required for prototype usability testing?• Are there any unpublished pages?


• Examples:• Unpublished pages• http://cms.uvic.ca:8080/entity/open.act?id=dd8008

958e68c4483630fb71a436440a&type=page&#highlight

• Hardcoded links to an old site• http://cms.uvic.ca:8080/entity/open.act?id=654609

5d8e68c4482eb9eee92ab7d09c&type=page&#highlight

• Content status (using custom metadata)• http://cms.uvic.ca:8080/entity/open.act?id=af5e6bd

08e68c4481ea0171187018fa1&type=page&#highlight

http://cms.uvic.ca:8080/entity/open.act?id=dd8008958e68c4483630fb71a436440a&type=page&



http://cms.uvic.ca:8080/entity/open.act?id=6546095d8e68c4482eb9eee92ab7d09c&type=page&



http://cms.uvic.ca:8080/entity/open.act?id=af5e6bd08e68c4481ea0171187018fa1&type=page&




• Recipe:• If applicable, create custom metadata for site for attributes you

want to search • Our default metadata set includes the development lifecycle

metadata• Create an index block of all site content (this may require changing

max index block size)• With your format, query index block• Display results

• Create links within Cascade to ‘View’, ‘Edit’, ‘Publish’ page/block (index block has “id” of assets)

`


Who?When?‘Bad’ links?

View |Edit |Publish

Trick 2: Getting started

• Reports:• Identify questions you have (or are continually asked) about a

site’s content• When was it last updated?• Who last published it?• Are there any ‘bad’ links to an old site/URL?

• Configure index block• Write format to query index block to answer the question• Make the output actionable with direct links to page options

(e.g., Edit, Publish, View)


• The good:• On-demand answers to common questions• Very fast to re-purpose and tweak • Example scripts delivered with Cascade (check the _common

site) • The bad:• The ugly:

• Writing the XPath queries can be challenging (especially when getting started)• using XML dev tools like oXygen can really help

Aside: Blocks in Default Region

• Our previous CMS supported ‘block’ equivalents in content areas

• We had to emulate this in Cascade• Created data definition for our standard page

• Content Group (repeatable)• WYSIWYG (for typed-in content)• Block chooser (render-content-depth="unlimited“)

• (we haven’t explored ‘bricks’ yet...)

Aside to the Aside: Structuring XSLT formats for your site

• We wanted the blocks in Default to be data definition blocks (not just straight XTHML/text)

• Therefore, the format for the Default region needed to be able to transform many different types of data definitions


• XSLT formats in Cascade can ‘include’ others

<xsl:include href="site://UVicCa/_internal/formats/…"/>

• This can be really helpful• widget formats can be included into the standard page format (i.e., the format for the

Default region)• widget blocks can be added to pages Default regions via Data Definitions choosers

• then, if the Default region format <xsl:apply-templates> • > and the widget block has a unique namespace• > and there’s a <xsl:template > that matches that namespace

• > the widget XML will be transformed into the widget’s markup


1. Create structured page data-definitions



2. Create format for the default region that includes widgetry formats




3. In format for default region, capture your page content’s DD regions and xsl:apply-templates





4. Create widget data-definitions with a ‘group’ container with unique id (e.g., contacts-by-hr-dept)





4. Create widget data-definitions with a ‘group’ container with unique id (e.g., contacts-by-hr-dept)

5. In widget’s XSLT format, capture widget’s matching template• <xsl:template match=“contacts-by-hr-dept”>


• So? Isn’t this supposed about index block tricks?

• Many of the following index block-driven widgets rely this structure:• widgetry formats are called/applied by the ‘Default’

region’s format• and the blocks are automatically transformed properly

Trick 3: Content aggregation – Staff profiles

• Purpose: • Display staff profiles in a consistent, structured way• Have Cascade automatically aggregate and sort staff

profiles• Give non-technical content contributors ability to CrUD

staff profiles easily

Trick 3: Content aggregation

• Sample:http://www.uvic.ca:8080/hr/contact/home/organization/index.php

http://www.uvic.ca:8080/hr/contact/home/organization/index.php

http://www.uvic.ca:8080/hr/contact/home/organization/index.php


• The recipe:• Develop a data definition to capture and organize profile

data (e.g., name, dept, responsibilities, etc)• Build out Cascade folders to hold profiles• can be used as one way of sorting

• Populate data def profile blocks into folders


• The recipe continued:• Create an index block to aggregate profile info

• This index block will be the data source for all three different pages

• Create a container data def block with a distinct id and block chooser (to refer back to index block)

• Depending sorting criteria, write formats to sort/organize profiles and output HTML• switch format based on namespace of container block

(<xsl:apply-templates >)


By department

By service

By org

by-dept.php

by-service.php

by-org.php


• The good: • One, structured source for profile data• Easy to maintain, automatically sorts• Contributors require very minimal tech skills• Models can be tweaked and re-purposed for any structured content• Some sample code delivered with Cascade (‘news’ in example.com)

• The bad:• Contributors need to be trained to update content somewhere other

than on the page where they see it• … then trained to publish pages they weren’t editing


• The ugly• Managing the inclusion of formats and naming of format

files (vs. namespace of switcher blocks)• Can be very challenging to troubleshoot • “Which transformation, in which format file, from which

site, is being applied to this block?” (consider printing out comments in <xsl:template match=“…” >)

• Working within Cascade to develop your formats can be tedious and inefficient• Consider an XML tool like oXygen


• Content aggregation:• Identify common content types that you’re ‘manually’ aggregating

• Granular content in data definitions is especially queryable (and generally easier for contributors to maintain)

• E.g., [re-]grouped lists of people, events, services, news• Develop static fully-functional model in HTML/Javascript (so you

know what your format needs to output)• Configure index block

• “Folder” (or “Content type” for pages)• Write format to query for sorted/ordered assets and transform into

markup from model

Trick 4: Decision tree wizard

• The purpose • Give end-users a wizard tool to sort through a deep list

of resources (without linking around a site)• Have Cascade automatically aggregate content and build

wizard HTML and JS based on native Cascade structures• Give non-technical content contributors ability to CrUD

the wizard easily(ish)


• Sample: • http://www.uvic.ca/coopandcareer/index-wizard.php

http://www.uvic.ca/coopandcareer/index-wizard.php


• The recipe:• Build out Cascade folder structure to match the decision tree

• Each folder is a ‘question’• Each child folder is a ‘response’• … and so on

• Add custom meta data fields to capture each folder’s:• ‘response’ (to its parent folder’s question), and• ‘question’ (to its child folders)

• To each applicable ‘answer’ folder, add:• ‘External link’ objects for each resource• Images for icons


• The recipe continued:• Create an index block to aggregate tree info• Create a container data def block with a distinct id and

block chooser (to refer back to index block)• Write format to:• Output HTML, CSS and JS to create wizard interaction



• Decision tree wizard:• Develop a model outside of Cascade

• Construct the decision tree on paper• HTML, CSS, JS

• Build out custom metadata for the folders• Translate decision tree into to folder hierarchy with metadata

• Create index block• Based on the model, write format to query for sorted/ordered assets and

transform into • HTML• CSS• JS


• The good:• Ability for semi-technical users to produce a very technical widget• Logical & understandable structuring of decision tree concepts• Re-usable/re-purposable/copyable

• The bad:• Many moving parts• Difficult to troubleshoot once it’s in/published from Cascade• Contributors have to be able to translate decision tree in their heads into Cascade

structures

• The Ugly• Did I mention… many moving parts

• Write XSL to write HTML, CSS & JavaScript

Trick 5: PHP Search & Browse

• The purpose • Allow end-users to search structured information in

your Cascade site (e.g., keyword search for academic programs)

• Have Cascade automatically aggregate and make content ‘findable’

• Give non-technical content contributors ability to CrUD content easily


• Sample: • http://www.uvic.ca/future-students/undergraduate/pro

grams/index.php

http://www.uvic.ca/future-students/undergraduate/programs/index.php

http://www.uvic.ca/future-students/undergraduate/programs/index.php


• The recipe:• Develop a data definition to capture and organize

program data (e.g., name, dept, URL, etc)• Populate data def program blocks into folders• Create an index block to aggregate program info• This index block will be the data source for all three

different pages


• The recipe continued:• Create a container data def block with a distinct id and block

chooser (to refer back to index block)• For this DD block, write format to:

• Output PHP code that will search index block XML• Add HTML search form to page• Call search function on server, passing index block XML as

parameter • Output HTML results from PHP function

• Add DD block to Cascade page• Publish to PHP web server for endusers



• The good:• A framework for searching organized content from Cascade • Customized search & display

• The bad:• Many moving parts• Difficult to troubleshoot once it’s in/published from Cascade

• The Ugly• Did I mention… many moving parts

• Write XSL to write PHP to write HTML, CSS & JavaScript


• U-G-L-Y• XSLT required to publish a PHP ‘open’ tag:

[system-view:external] <xsl:comment>#START-CODE<![CDATA[ <?php ]]>


• Search and browse:• Cascade• Identify content type and attributes for searching• Content in data definitions is especially parse-able

(and generally easier for contributors to manage)• Configure index block• Collect the XML of the index block


• Search and browse:• Front-end• Develop static model of tool in HTML/Javascript (so

you know what your format needs to output)


• Search and browse:• Server-side processing• Develop framework for searching XML (regardless of

whether it is called by Cascade page or not)• Using the sample index block as your datasource,

write code to search the XML• Output markup of results• Use HTML model to test ‘manually’


• Search and browse:• Back to Cascade• Write format to output• Client-side markup for form, results display• Server-side code to call functions to perform

search passing as a parameter, the XML from the index block• Nail down how to escape code in your XSLT

Conclusions

• Start to think of Cascade as a database of content• mildly relational: blocks/pages can relate to other

blocks/pages with (repeatable) data definition block/page choosers

• Index blocks are like ‘views’ on the content database• Formats can • ‘query’ index blocks • transform the results into HTML, JavaScript, server-side

code

Conclusions

• Getting started with index block tricks• Beg, borrow and steal:• The most difficult widget you write will be your first• Reuse and repurpose code to kick start future

widgets

Conclusions

• Getting started with index block tricks• Get organized

• Consider where you want to be able to insert your widgets (i.e., template regions)• How will you apply your widgetry formats to those regions?

• Consider your Data Definitions’ and Formats’ structure and names ahead of time• structure (i.e., name) your DDs uniquely – use ‘groups’ as

well-named containers that can be uniquely XPath queried• name your format files to match• in your ‘default’ format, include widget formats

Questions? Comments? Ideas?

Contact info

• Dave Shaykewich Client Account Manager, UVic Online University of Victoria

[email protected] 250-853-3233

mailto:[email protected]

Technology

Stupid Index Block Tricks