This session will consider: - what data is available from index blocks - Cascade's object and data types and their implications on indexes - organizing transformation 'formats' for multi-/re-use Example widgets include: - Handy reports for project managers and site administrators - News aggregation and syndication blocks - Dynamic decision tree web widgets - XPath-based search and browse web widgets Bring your inspired indexing ideas and innovations for sharing.

1. Stupid Index Block Tricks...
they’re not just for navigation
Dave Shaykewich
University of Victoria

2. 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?

3. 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

4. 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

5. 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)

6. 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.”

7. 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

8. 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.

9. 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)

10. Trick 1: Navigation
• Purpose:
• Have Cascade generate navigation that maintains
context
• i.e., highlights current page’s ancestors’ navigation

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

12. 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

13. Trick 1: Navigation

14. 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

15. 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?

16. Trick 2: Content reporting
• Examples:
• Unpublished pages
• http://cms.uvic.ca:8080/entity/open.act?id=dd8008958e
68c4483630fb71a436440a&type=page&#highlight
• Hardcoded links to an old site
• http://cms.uvic.ca:8080/entity/open.act?id=6546095d8e6
8c4482eb9eee92ab7d09c&type=page&#highlight
• Content status (using custom metadata)
• http://cms.uvic.ca:8080/entity/open.act?id=af5e6bd08e6
8c4481ea0171187018fa1&type=page&#highlight

17. Trick 2: Content reporting
• 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)

18. `
Trick 2: Content reporting
Who?
When?
‘Bad’ links?
View |
Edit |
Publish

19. 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)

20. Trick 2: Content reporting
• 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

21. 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...)

22. 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

23. Aside to the Aside: Structuring XSLT formats for your
site
• 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

24. Aside to the Aside: Structuring XSLT formats for your
site
1. Create structured page data-definitions

25. Aside to the Aside: Structuring XSLT formats for your
site
1. Create structured page data-definitions
2. Create format for the default region that includes widgetry formats

26. Aside to the Aside: Structuring XSLT formats for your
site
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

27. Aside to the Aside: Structuring XSLT formats for your
site
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)

28. Aside to the Aside: Structuring XSLT formats for your
site
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)
5. In widget’s XSLT format, capture widget’s matching template
• <xsl:template match=“contacts-by-hr-dept”>

29. Aside to the Aside: Structuring XSLT formats for your
site
• 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

30. 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

31. Trick 3: Content aggregation
• Sample:
http://www.uvic.ca:8080/hr/contact/home/organization/in
dex.php

32. Trick 3: Content aggregation
• 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

33. Trick 3: Content aggregation
• 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 >)

34. Trick 3: Content aggregation
By department
By service
By org
by-dept.php
by-service.php
by-org.php

35. Trick 3: Content aggregation
• 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

36. Trick 3: Content aggregation
• 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

37. Trick 3: Getting started
• 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

38. 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)

39. Trick 4: Decision tree wizard
• Sample:
• http://www.uvic.ca/coopandcareer/index-wizard.php

40. Trick 4: Decision tree wizard
• 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

41. Trick 4: Decision tree wizard
• 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

42. Trick 4: Decision tree wizard

43. Trick 4: Getting started
• 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

44. Trick 4: Decision tree wizard
• 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

45. 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

46. Trick 5: PHP Search & Browse
• Sample:
• http://www.uvic.ca/future-
students/undergraduate/programs/index.php

47. Trick 5: PHP Search & Browse
• 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

48. Trick 5: PHP Search & Browse
• 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

49. Trick 5: PHP Search & Browse

50. Trick 5: PHP Search & Browse
• 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

51. Trick 5: PHP Search & Browse
• U-G-L-Y
• XSLT required to publish a PHP ‘open’ tag:
[system-view:external]
<xsl:comment>#START-CODE<![CDATA[ <?php ]]>

52. Trick 5: Getting started
• 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

53. Trick 5: Getting started
• Search and browse:
• Front-end
• Develop static model of tool in HTML/Javascript (so
you know what your format needs to output)

54. Trick 5: Getting started
• 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’

55. Trick 5: Getting started
• 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

56. 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

57. 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

58. 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

59. Questions? Comments? Ideas?

60. Contact info
• Dave Shaykewich
Client Account Manager, UVic Online
University of Victoria
dshaykew@uvic.ca
250-853-3233