Labels

accessibility (2) ADF (1) archiver (3) cmu (1) contributor (13) cookie (1) DAM (3) date (3) download (3) dynamic list (4) ephox (5) fatwire (1) fck (1) filters (1) folders (4) headers (2) IBR (3) ImageAlchemy (3) java (4) javascript (2) layout/template (4) link (6) locale (2) multilingual (1) rendition (3) replicator (4) rules (1) schema (1) search (11) sites (1) sitestudio (24) ssp/sspu (5) SSUrlFieldName (2) stellent (4) timezone (1) urm (1) weblogic (1) workflow (2)

Monday 14 June 2010

Secrets of wcmFragment

The wcmFragment tag that came with SiteStudio10gR4 was a great new way to reference fragments. The big improvement with this tag is that the fragment no longer needs to leave any XML code in your pages. Here's an example of how to use it:
[!--$wcmFragment("myID","myContentId","myFragment",
     "mySnippet","myParameter=value")--]
However I've noticed a few documentation oddities regarding wcmFragment that were worth clarifying...
  • When using it on a region template or subtemplate the documentation states that "only the first drop-point snippet will be used." This is not quite accurate What it really means is that there is no provided interface to choose a snippet. You can still call any snippet you need, just switch to code view and type it into your code. 
  • When used on a Page Template the fragment is still referenced in the XML data island. This is not necessary. Happily delete the fragment reference from the ssinfo tag. This will de-clutter your code, improving SEO. (The only exception is for fragments inside old-style contribution regions.)
  • The manual says that wcmFragment uses a fragment reference ID called "fragmentInstanceID." Older versions used "ssFragmentInstanceId" and I thought this might cause problems. It turns out that "ssFragmentInstanceId" is still the variable name used. It also says to use "ssParameter=value" for parameters but it actually gets translated into "ssFragmentInstanceId_ssParameter=value" which is the old format that fragments used, so old fragments will continue to work just fine.
  • The manual also states that "it is recommended that, whenever possible, you create fragments with a single body snippet." I'd suggest this is silly talk. The only issue with snippets is that if you have a head snippet which needs to appear inside the HEAD tag of a page, you won't be able to call it from a Region Template (because it is always part of the BODY tag.) You'll have to call the head snippet from a Page Template's head tag. It's a bit sucky but with a bit of region-reading smarts you could work out if the snippet is needed or not.
I'd also like to mention that navigation fragments, which are still included in 11g, are still stupid: section-based navigation is terrible for site with more than a dozen sections. Use a content item to define your navigation.

5 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. If you are going to use this code in contributor regions(as we did) my advice is to use instead of [!--$code--] because sometime the WYSIWYG editor likes to "make code nicer" and breaks it.
    As for the SSinfo tag you can just hide it for non contributor users and this will fix your SEO issues.

    It`s also nice that you can declare params before the snippet and use them in it.

    ReplyDelete
  3. Hiding the SSInfo tag is not a good idea, there is code inside which affects the page in and out of contribution mode. Only remove it if you are not using legacy-style contribution regions.

    ReplyDelete
  4. RE: Section-based navigation

    How do you handle breadcrumbs if you're not using website sections?

    ReplyDelete
  5. Content can be reused anywhere, there is no way to know what path the user took to reach the page. Need to stick with website sections for the breadcrumb - it is not your navigation structure, it is your site structure.

    ReplyDelete