Stupid Index Block Tricks

16,139 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
16,139
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Stupid Index Block Tricks

  1. 1. Stupid Index Block Tricks... they’re not just for navigation Dave Shaykewich University of Victoria
  2. 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. 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. 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. 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. 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. 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. 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. 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. 10. Trick 1: Navigation • Purpose: • Have Cascade generate navigation that maintains context • i.e., highlights current page’s ancestors’ navigation
  11. 11. Trick 1: Navigation • Sample: http://www.uvic.ca/future-students/undergraduate/programs/distance/index.php
  12. 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. 13. Trick 1: Navigation
  14. 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. 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. 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. 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. 18. ` Trick 2: Content reporting Who? When? ‘Bad’ links? View | Edit | Publish
  19. 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. 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. 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. 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. 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. 24. Aside to the Aside: Structuring XSLT formats for your site 1. Create structured page data-definitions
  25. 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. 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. 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. 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. 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. 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. 31. Trick 3: Content aggregation • Sample: http://www.uvic.ca:8080/hr/contact/home/organization/in dex.php
  32. 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. 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. 34. Trick 3: Content aggregation By department By service By org by-dept.php by-service.php by-org.php
  35. 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. 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. 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. 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. 39. Trick 4: Decision tree wizard • Sample: • http://www.uvic.ca/coopandcareer/index-wizard.php
  40. 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. 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. 42. Trick 4: Decision tree wizard
  43. 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. 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. 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. 46. Trick 5: PHP Search & Browse • Sample: • http://www.uvic.ca/future- students/undergraduate/programs/index.php
  47. 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. 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. 49. Trick 5: PHP Search & Browse
  50. 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. 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. 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. 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. 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. 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. 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. 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. 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. 59. Questions? Comments? Ideas?
  60. 60. Contact info • Dave Shaykewich Client Account Manager, UVic Online University of Victoria dshaykew@uvic.ca 250-853-3233

×