Symphony.

Is it possible to declare a variable container (or any other sort of dynamic container) within the content of a Textarea field; to will be populated by an entry in another field or page variable?

E.g. I have Textarea field (i.e. 'Job Description') that references a number also set in another field (i.e. 'Annual Salary') on the entry page. It'd be wonderous if there was a way to automagically have the 'Annual Salary' field populate placeholders in the 'Job Description' text. I could also foresee instances where I would want another page variable to populate some placeholder within a block of text.

Does the magic of Symphony and/or XSLT stretch this far?

Best, Clayton

Yes, read it and bookmark it:

http://chaoticpattern.com/article/manipulating-html-in-xml/

Thanks Lewis. Man, I've been through Ninja training like six times now and I keep missing stuff ;)

Best, Clayton

Hmm, perhaps I'm still not ready for the throwing stars...

So given Allen's tutorial would you create some sort of unique keyword text (or perhaps better yet a unique element like a span with a specific class) in the Textarea that is then grabbed and replaced by another node in the XML (or a page variable)?

I would use some sort of:

[handle-of-entry-or-field]

I would use some sort of: [handle-of-entry-or-field]

So then would this live right within the Textarea text?

• I am a paragraph of text in a Textarea field with a [entry-field-name-container] that will be replaced by Ninja XLST magic.

Can you grab a piece of text via XSLT just based on it's surrounding characters (i.e. [ ]) or does it need to be within a surrounding element?

Boy-With-A-Thousand-Questions, Clayton

It's easier, and i'm guessing more efficient (but I'd need some verification on that) to put it in an element. I'm planning on using something similar for image management. I'm creating entries for my images, and when I go to place my images, I just add a 'reference element';

<image ID="(the entry id of the image I want to place" />

The cool thing about this is that you could also add other things like @width and @height, then use the image manipulation functions to resize/crop the image. You could have @caption to output a caption that's associated with the record, etc.

To keep these custom elements straight, I think you could use custom namespaces, which you could use to validate the form of your elements, and also protect your elements from conflicting.

e.g.:

<ashooner:image id="225" width="200" /> and so forth...

Thanks for the tip Andrew. I'll have to learn up on custom namespaces. It seems like there's no limit to what you can do with this thing. (He looks around hurriedly for world domination plans then realizes it might be more work than it's worth...)

Best, Clayton

Great ideas. What kind of information are you talking about? How do you need to tie together. That will probably determine the best solution. Perhaps you could post an example?

Hi Lewis,

Sorry for the delayed response; I was been sucked into a vortex called can't-see-nose-on-face-or-even-nose-on-wife's-face-for-sake-of-too-much-going-on-at-once for the last few days.

Here are some examples of what I had in mind at least -

Example 1: I have a page that is generated solely from template text and page variables. (Image 01.) Currently I have to keep this templated, static text within the actual xsl page or utility. What would be preferable (I think) is to have this text live within a normal entry to make for easier editing (I think), requiring a way to connect empty placeholders within the entry's text field to the page variables (I think.)

Example 2: (Image 02) Here's a visual per the original question / example. Information that needs to be included within some text areas for an entry is also being entered within separate fields to be uniquely handled for other applications. Is it possible to place a container for the text area field(s) that will be populated by the other fields' data one the entry is saved?

Best, Clayton

@Clayton: Those screenshots were really helpful. I've come up with a possible solution, so let me explain how it works.

I really like Allen's HTML manipulation technique, but the problem is that, in order to extract its full power, you need be able to insert arbitrary data, and therefore your text formatter needs to allow this. Someday soon we should create a new batch of text formatters which come with both "enable random stuff" and "disable random stuff" flavours specifically for this purpose.

But since we don't have this luxury, we need to be able to use your existing text formatter to insert references to fields or other elements. I thought you could probably use <a href=""> elements for that, and provide the field name as the @href's hash fragment. This would require you use Allen's technique, but with the following template for a matches:

<xsl:template match="a">
    <xsl:choose>
        <xsl:when test="starts-with(@href, '#field.')">
            <xsl:param name="field-name" select="substring-after(@href, '#field.')"/>
            <xsl:value-of select="ancestor::my-data-source/*[name() = $field-name]"/>
        </xsl:when>
        <xsl:when test="starts-with(@href, '#page.')">
            <!-- Instructions for page variables -->
        </xsl:when>
        <xsl:otherwise>
            <xsl:element name="{name()}">
                <xsl:apply-templates select="@*"/>
                <xsl:apply-templates/>
            </xsl:element>
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>

Make sure you aren't selecting as in the main template where you process elements. Also, replace "my-data-source" with the real name of your data source element.

How it works: Any link with its @href starting with "#field." turns the remainder into the param $field-name. That link is then replaced with the value of the first child element whose name is the same as $field-name inside the data source element.

So, for example, in order to insert whatever value the annual-salary field contains in your textarea, just write "[x](#field.annual-salary)" (or the equivalent for other text formatters besides Markdown). This should work for any field, just be aware that it uses the xsl:value-of instruction, so you can't reference fields with child elements like tag lists.

I've also added another test for page variables, which works pretty much the same way. You can copy the technique of the field reference test, just adjust the XPath to find where your page variables are located in the XML, and use a "#page." prefix in referring links.

Hope this is helpful! :)

Wow Scott, thanks!

I definitely need to walk through this a few times to make sure I fully understand how it works and its implications but it looks to be a great solution. Thanks again.

My dumbfounded amazement continues... ;)

Utilizing an existing element simplifies the template. Nice work Scott!