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.
FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhi
Stupid Index Block Tricks
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
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
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)
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
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
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
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
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
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