Adobe Extending Dreamweaver CS4 - Manual (Page 339)

333 EXTENDING DREAMWEAVER CS4
Data translators
</p><p style="position:absolute;top:179px;left:148px;white-space:nowrap" class="ft06"> <br>
Then you create a translator for the bean:messagestruts tag, the translator fails because you are creating a
MM:BeginLock section inside a MM:BeginLock section. A workaround is to create a JSP wrapper around the
bean:message tag that uses regular JSP tags like <%= My_lookup.lookup("show.message") %> . This causes your
translator to skip this code, and the translation succeeds.
Creating Property inspectors for locked content
After you create a translator, you need to create a Property inspector for the content so the user can change its
properties (for example, the file to be included or one of the conditions in a conditional statement). Inspecting
translated content is a unique problem for several reasons:
• The user might want to change the properties of the translated content, and those changes must be reflected in the
untranslated content.
• The Document Object Model (DOM) contains the translated content (that is, the lock tags and the tags they
surround are nodes in the DOM), but the outerHTML property of the documentElement object and the
dreamweaver.getSelection() and dreamweaver.nodeToOffsets() functions act on the untranslated source.
• The tags you inspect are different before and after translation.
A Property inspector for the HAPPY tag might have a comment that looks similar to the following example:
The Property inspector for the translated HAPPY tag, however, would have a comment that looks similar to the
following example:
The canInspectSelection() function for the untranslated HAPPY Property inspector is simple. Because the
selection type is exact , it can return a value of true without further analysis. For the translated HAPPY Property
inspector, this function is more complicated; the keyword *LOCKED* indicates that the Property inspector is
appropriate when the selection is within a locked region, but because a document can have several locked regions,
further checks must be performed to determine whether the Property inspector matches this particular locked
region.
Another problem is inherent in inspecting translated content. When you call the dom.getSelection() function,
the values that return by default are offsets into the untranslated source. To expand the selection properly so that
the locked region (and only the locked region) is selected, use the following technique:
var currentDOM = dw.getDocumentDOM();
var offsets = currentDOM.getSelection();
var theSelection = currentDOM.offsetsToNode(offsets[0],offsets[0]+1);
Using offsets[0]+1 as the second argument ensures that you remain within the opening lock tag when you convert
the offsets to a node. If you use offsets[1] as the second argument, you risk selecting the node above the lock.
After you make the selection (after ensuring that its nodeType is node.ELEMENT_NODE ), you can inspect the type
attribute to see if the locked region matches this Property inspector, as shown in the following example: