1. Because the insite:edit tag passes the formatted value, an appropriate formatLength parameter is required in the params argument. In our example, formatLength is set to set to long, as shown below. In addition, if we choose to display the timestamps and time zone in date fields, we would set two additional parameters; timePicker:true and timeZoneID:'US/Eastern', also shown below:

   <span class="date">
     <insite:edit
     field="postDate"
     value="formattedDate"
     params="{constraints:{formatLength: 'long'},
       timePicker:true, timeZoneID:'US/Eastern'}" />
   </span>

   Note:

   The date widget in edit mode will function correctly only if we pass a properly formatted date. The datestyle and timestyle arguments in dateformat:create or fmt:formatdate APIs must be consistent with the formatLength params argument in the insite:edit tag. In our example, the datestyle and timestyle arguments in the date formatting API must all be long. If the formattedDate is constructed using the time zone parameter, then the same time zone ID must be used in the insite:edit tag. If the formattedDate is constructed with timestamp using dateformat:getdatetime, then the timePicker:true parameter must be set in the insite:edit tag. And if it is constructed without timestamp using dateformat:getdate, then there is no need to set the timePicker:true parameter.

2. The date will now be rendered according to how we specified its format:

   • With timestamp and timeZoneID:'US/Eastern':

     SEPTEMBER 7, 2011 10:41:14 AM EDT

   • Without timestamp and timeZoneID::

     SEPTEMBER 7, 2011

3. The date field is now editable. Click the date field while viewing an article in the Contributor interface in the Web Mode / Edit View. One of the calendar popup widgets opens.

{constraints: {formatLength: 'long'}, timePicker : true,
  timeZoneID:'US/Eastern' }

When an asset association is used instead of a flex attribute of data type asset, the field attribute needs to be specified, as follows:

Association-named:<associationName>

For example, for an association called topStory the code would be:

<insite:calltemplate 
  field="Association-named:topStory"
  ...
/>

It is also possible to edit a flex asset's parent asset. The syntax for the field attribute is as follows:

Group_<parentDefinitionName>

For example, in the case of avisports, article assets have a Category parent definition:

<insite:calltemplate
  field="Group_Category"
  ...
/>

1. Page assets of the AVIHome subtype have a multivalued text field (see attribute value teaserText in the assetset:getattributevalues tag below). Create a test layout template, rendering only the value of this field.

   <%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
   <%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
   <%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>
   <%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>

   <cs:ftcs>
   
   <render:logdep
     cid='<%=ics.GetVar("tid")%>' 
     c="Template" />
   
   <assetset:setasset 
     name="page" 
     type="Page" 
     id='<%=ics.GetVar("cid")%>' />
   
   <assetset:getattributevalues 
     name="page" 
     attribute="teaserText"
     listvarname="teaserList"
     typename="PageAttribute" />
   
   <div style="width: 500px; font-size: small">
     <ics:listloop listname="teaserList">
       <render:stream list="teaserList" column="value" />
     </ics:listloop>
   </div>
   </cs:ftcs>
   

   This figure shows a sample text layout template:

   Figure 21-7 Sample Text Layout Template

   
   Description of "Figure 21-7 Sample Text Layout Template"
2. Modify this template to make the multivalued teaserText field editable.

   Add the insite taglib directive:

   <%@ taglib prefix="insite" uri="futuretense_cs/insite.tld" %>
   

   and replace the original code:

   <ics:listloop listname="teaserList">
     <render:stream list="teaserList" column="value" />
   </ics:listloop>
   

   with the following code:

   <ics:listloop listname="teaserList">
     <ics:listget
       listname="teaserList"
       fieldname="#curRow" 
       output="currentRowNb" />
     <insite:edit
       assetid='<%=ics.GetVar("cid")%>'
       assettype='<%=ics.GetVar("c")%>'
       field="teaserText"
       list="teaserList"
       column="value"
       index='<%=ics.GetVar("currentRowNb")%>'
       editor="ckeditor" />
   </ics:listloop>
   

   The syntax for the insite:edit tag can be simplified as follows:

   <ics:listloop listname="teaserList">
     <ics:listget 
       listname="teaserList" 
       fieldname="#curRow" 
       output="currentRowNb" />
     <insite:edit
       field="teaserText"
       list="teaserList"
       column="value"
       index='<%=ics.GetVar("currentRowNb")%>' 
       editor="ckeditor" /> 
   </ics:listloop>
   

3. In the Contributor interface, change to Web Mode / Edit View. You are now able to edit each of the existing values using CKEditor.

1. Modify the previous code sample as follows:

   <insite:list 
     field="teaserText" 
     editor="ckeditor" 
     assetid='<%=ics.GetVar("cid")%>'
     assettype='<%=ics.GetVar("c")%>'>
   
       <ics:listloop listname="teaserList">
         <insite:edit list="teaserList" column="value" /> 
       </ics:listloop>
   </insite:list>
   

   The insite:edit tag is now nested inside an insite:list tag. The nested insite:edit tags do not specify the field, assetid, assettype or editor attributes since they are specified at the parent tag level, and each nested insite:edit tag is, by default, inheriting those values when not locally specified. This is also applicable to the params attribute of the insite:edit tag.

   The index attribute is no longer required. In this case, the insite:list tag is keeping track of the current index. The tag assumes that the order in which the insite:edit tag appear matches the order of the multivalued field, that is, the first insite:edit tag edits value #1, and so on. If that is not the case, the index has to be specified. See Specifying a Different Ordering.

   Like the insite:edit tag, the syntax for the insite:list tag can be simplified if the asset being edited is the asset designated by the c (asset type) and cid (asset id) variables; in which case the assetid and assettype attributes can be omitted.

   <insite:list field="teaserText" editor="ckeditor" >
     <ics:listloop listname="teaserList">
       <insite:edit list="teaserList" column="value" /> 
     </ics:listloop>
   </insite:list>
   

2. Now that the insite:list tag was added, a toolbar is displayed whenever the mouse pointer hovers over the area showing the field values.

   When you click that area, a popup gets rendered, allowing you to add, edit, remove, or reorder field values.

   This topic builds on Example 1: Editing Multivalued Text Fields and Example 2: Modifying Multivalued Text Fields.

   In the case of asset reference fields, we will use the insite:slotlist tag instead of the insite:list tag. In this case, rather than nested insite:edit tags, we will have nested insite:calltemplate tags.

   Instead of rendering a single related article, this example goes through the whole list and renders each of them.

3. Modify the previous code sample as follows (for the time being, this code omits any in-context editing capabilities):

   <%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
   <%@ taglib prefix="assetset" uri="futuretense_cs/assetset.tld"%>
   <%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
   <%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>
   
   <cs:ftcs>
   
   <assetset:setasset 
     name="article" 
     type="AVIArticle" 
     id='<%=ics.GetVar("cid")%>' />
   
   <assetset:getattributevalues 
     name="article" 
     attribute="relatedStories" 
     listvarname="relatedStories" 
     typename="ContentAttribute" />
   
   <ics:listloop listname="relatedStories">
     <ics:listget 
      listname="relatedStories" 
      fieldname="value" 
      output="articleId" />
     <render:calltemplate 
       tname="Summary/SideBar" 
       c="AVIArticle" 
       cid='<%=ics.GetVar("articleId")%>' />	
   </ics:listloop>
   </cs:ftcs>
   

   This figure shows the field with three values.

   Figure 21-8 Related Stories with Three Examples

   
   Description of "Figure 21-8 Related Stories with Three Examples"

   The SideBar will now show those three articles.

   Figure 21-9 Related Stories Displayed in SideBar

   
   Description of "Figure 21-9 Related Stories Displayed in SideBar"
4. To make the article list editable, make the following changes:

   <%@ taglib prefix="cs" uri="futuretense_cs/ftcs1_0.tld"%>
   <%@ taglib prefix="assetset" uri="futuretense_cs/ assetset.tld"%>
   <%@ taglib prefix="ics" uri="futuretense_cs/ics.tld"%>
   <%@ taglib prefix="render" uri="futuretense_cs/render.tld"%>
   <%@ taglib prefix="insite" uri="futuretense_cs/insite.tld"%>
   
   <cs:ftcs>
   <render:logdep c="Template" cid='<%=ics.GetVar("tid")%>' />
   
   <assetset:setasset
     name="article"
     type="AVIArticle"
     id='<%=ics.GetVar("cid")%>' />
   
   <assetset:getattributevalues
     name="article"
     attribute="relatedStories"
     listvarname="relatedStories"
     typename="ContentAttribute" />
   
   <insite:slotlist field="relatedStories">
     <ics:listloop listname="relatedStories">
       <ics:listget 
         listname="relatedStories" 
         fieldname="value" 
         output="articleId" />
       <insite:calltemplate
         tname="Summary/SideBar"
         c="AVIArticle"
         cid='<%=ics.GetVar("articleId")%>' />
     </ics:listloop>
   </insite:slotlist>
   </cs:ftcs>
   

   Every item of the list becomes a content-editable slot (droppable zone):

   In addition, since the insite:slotlist tag was used in the example, when hovering over the relatedStories area, you see a toolbar similar to the previous example.

In the previous example, the articles are rendered in a sequence, the first nested insite:calltemplate tag renders article #1, the second insite:calltemplate tag renders article #2, and so on:

<div class="top-stories">
  <div>article #1</div>
  <div>article #2</div>
  <div>article #3</div>
  <div>...</div>
</ul>

Your structure might be different depending on the structure of the HTML markup used in your site. For example, you might want articles to be displayed in a column layout such as this:

article #1  article #2
article #3  article #4
etc.

The underlying HTML markup might be similar to this:

<div class="left-column">
  <div>article #1</div>
  <div>article #3</div>
  ...
</div>
<div class="right-column">
  <div>article #2</div>
  <div>article #4</div>
  ...
</div>

In this example, articles are rendered in an order that doesn’t not match the ordering of the field (#1, #3, #5, then #2, #4, #6, and so on.). If this is the case, WebCenter Sites needs to be aware of the ordering. To do that, you have to explicitly indicate the index of the list item being edited, by using the index attribute as shown in Multivalued Fields.

Caching is not disabled when you are working in Web Mode / Edit View. Therefore, templates that are configured to be cached will still be cached when rendered in Edit View.

When you are working with assets, WebCenter Sites automatically handles cache flushing provided that the correct dependencies are logged. For example, modifying the definition of a particular attribute (for example, changing the allowed types of an asset reference field) automatically flushes all pagelets whose rendering depends on this particular attribute.

However, the page cache has to be manually flushed in these cases:

• Modifying the definition of an association field

• Removing a role from WebCenter Sites, if this role is directly referenced from an insite:calltemplate tag, through the roles attribute

• Removing asset types or subtypes from WebCenter Sites, if this asset type or subtype is referenced from an insite:calltemplate tag through the clegal attribute

<div id="container">
  <div class="content">
    <render:calltemplate 
      tname="HelloDetail" 
      args="c,cid" />
  </div> 
  <div class=side-bar>
    ...
  </div>
</div>
...

1. Add the insite taglib directory.

   <%@ taglib prefix="insite" uri="futuretense_cs/insite.tld" %>
   

2. Replace the previous render:calltemplate tag with an insite:calltemplate tag and add the slotname and variant attributes:

   <div id="container">
     <div class="content">
       <insite:calltemplate 
         slotname="HelloSlot"
   
         tname="HelloDetail"
         variant="HelloDetail|Detail"
         args="c,cid" />
     </div> 
     <div class=side-bar>
       ...
     </div>
   </div>
   ...
   

   By adding the slotname attribute, you are defining a slot, called in the example HelloSlot. The slotname attribute value can be any string, but it must be unique across all templates of a given site. See Understanding the Context System Variable.

3. Run this template again.

   Initially there are no noticeable changes. The article is still rendered using the HelloDetail template, as directed by the tname attribute.

4. Switch to Edit View and hover over the main div section. The changes are as follows:

   • The page fragment inside the main div is now marked with a blue overlay.

   • The slot name is indicated in the top right corner.

   • Clicking the blue overlay also brings up a toolbar.

5. Click the Change Content Layout icon.

   Figure 21-13 Change Content Layout Icon

   
   Description of "Figure 21-13 Change Content Layout Icon"

   The Change Content Layout Dialog opens.

   Using the Change Content Layout option enables you to select a different content layout to render the asset in the main area of the page.

6. The template picker shows the HelloDetail and Detail pagelet templates, specified by the variant attribute. Select the Detail template and click Apply to render the web page.

   Figure 21-14 Output Page with Change Content Layout Dialog

   
   Description of "Figure 21-14 Output Page with Change Content Layout Dialog"

   The slot defined in Figure 21-14 is only meant for presentation editing and is not a content-editable slot (not a droppable zone).

   The reasons for this behavior follows:

   • The insite:calltemplate tag does not define any field attribute. That is, the content of the slot is not the value of an asset reference field.

     The tag is explicitly providing values for c (asset type) and cid (asset id). In this particular case, we want the article asset specified by the incoming c and cid request parameters to be rendered in this location.

     In addition, if the variant attribute had been omitted, the slot layout would not have been editable, since the insite:calltemplate tag specifies an explicit value for the tname attribute (which acts as a default template for all assets dropped in this slot).

     Note:

     The variant attribute can contain any regular expression. For example; variant="Detail.*" would restrict available templates to any pagelet template whose name starts with Detail.

When defining a slot, it is possible for template developers to decide the scope of the slot. Typically, whether any presentation change made in this slot should be local or global.

• local: visible only on the currently edited web page

• global: spanning across multiple web pages in a site (possibly, ALL web pages in a site)

This is done by manipulating the value of the context variable and will be explained in the following sections.

1. Assign the HelloArticleLayout template to two avisports articles (for example,

   All 25 Nevada resorts serving great snow and Cold snap back on the scene).

2. Observe both of these articles in Web Mode of the Contributor interface.

   The main slot is rendered with the default template HelloDetail as this is the template specified as the default template in the JSP code.

3. Assign the Detail template to all 25 Nevada resorts serving great snow article using the Change Content Layout option.
4. Refresh the web page with the Cold snap back on the scene article. The presentation of the main slot has also been modified on this web page as it is also using the Detail template.

The behavior observed in the previous section may be the intended behavior, but in some cases, editorial users will have to be able to make local presentation changes, that is, changes visible only on the current web page being edited.

To do this, the context variable has to be set to a value which will uniquely identify a given web page. In our case, it is enough to initialize context with, for example, the template name, and the identifier and type of the rendered asset:

<ics:setvar
  name="context"
  value='<%=ics.GetVar("c")
  + ":" + ics.GetVar("cid")
  + ":HelloArticleLayout"%>' />

Other parameters can be added to initialize the context, depending on the intended result. We can add the line above to the HelloArticleLayout template and verify that presentation changes are local to each article page.

Both the render:calltemplate tag and the insite:calltemplate tag have an optional context attribute, which can be used to override the current context.

Context is useful only when presentation editing capabilities are enabled on your site.

If that is not the case, context can be removed from every template's cache criteria (avoiding the creation of unnecessary duplicates in the page cache).

A slot meant to contain a CSElement asset is typically defined as:

<insite:calltemplate 
  slotname="Navbar" 
  clegal="CSElement" 
/>

Or can be defined in this manner if the slot is meant to show the same content across all pages of the site:

<insite:calltemplate
  slotname="Navbar" 
  clegal="CSElement" 
  context="Global" 
/>

There is no need to specify a tname attribute in this case, since the CSElement and SiteEntry assets are directly referring to the JSP element in charge of rendering them.

To see SiteEntry or CSElement in the list of allowed asset types for the slot, you have to ensure both asset types have their Can Be Child Asset flag set to True (which means that this asset type can be the child asset type in an association field for another asset type.). See Configuring the Asset Type in Creating Basic Asset Types.

A SiteEntry asset does not hold any code, but simply points at a CSElement asset. The only difference between one case and the other is that, when using a SiteEntry, the element is invoked through the cache engine. Consequently, the same result can be achieved by dropping a SiteEntry asset or dropping its related CSElement asset.

The decision to use SiteEntry or CSElement is therefore implementation-dependent. Exposing a functionality as a SiteEntry only will ensure that caching is used to render this particular code snippet.

Like templates, it is possible to define legal arguments for CSElement assets. Once a CSElement has been dropped in a slot, the legal arguments are accessible from the slot properties panel.

The same applies to dropping a SiteEntry asset except that the legal arguments shown in the slot properties panel are the legal arguments of the related CSElement asset. (SiteEntry assets do not have their own legal arguments.)

When you drop an asset in a content-editable slot, the template rendering this asset can potentially define other slots. To avoid too many controls and slots being rendered in a given area, the behavior of nested slots is automatically degraded to a simple droppable area (without a toolbar and overlay). It is generally recommended to avoid nested slots, to keep the Contributor interface simple and usable for users.

When the stylesheets have to be specifically adjusted for creating or editing content, the corresponding import statements can be enclosed in an insite:ifedit tag:

// import "delivery" stylesheets
<link type="text/css" rel="stylesheet" href="somecss.css" />
...

// then import "editing only" stylesheets. using the insite:ifedit
// tag ensures that only those stylesheets will be imported
// when rendering the template in create/edit mode.

<insite:ifedit>
  <link type="text/css" rel="stylesheet" href="edit.css"  />
  ...
</insite:ifedit>

When you adjust styles for the rendering of slots, the cssstyle attribute of the insite:calltemplate tag can be used to specify additional class names, which can then be used in CSS rules.

<insite:calltemplate 
  slotname="mySlot" 
  ...
  cssstyle="myClassName" 
  ...
/>

For example, if we wanted to force mySlot to have a 50px height when it is empty, we could provide the following CSS rule:

.myClassName .emptyIndicator {height: 50px !important;}

CSS rules can be grouped inside a specific stylesheet, and then imported conditionally, only when the template is executed in the context of Web Mode / Edit View of the Contributor interface, using the insite:ifedit JSP tag.