While testing XMod applications in some of the newer versions of DotNetNuke, I became very concerned that my template branch logic was not performing as expected when testing xmod:if statements against a XMod HTML editor (<htmlinput>) form control. In default instances of DotNetNuke, the <htmlinput> control will render the FCK Editor control that is commonly used with many DotNetNuke modules.
After further examination of the generated <htmlinput> control, I realized after looking at the editor soruce code, that the FCK Editor was generating an empty paragraph even though I had added no content to the control.
This became very troublesome due to the fact that I was testing template code to see if the user had entered content into the control using the xmod:if statement against the template call to xmod:field. The results were always returning content existed. When, in fact, the user had not entered any content.
At this point, I was looking for alternatives to using the HTML editor control. The only control that came close to meeting my requirements was the text area control (<textarea>).
Now, many of you have used the XMod text area control (<textarea>) only to abandon it due to its inability to render paragraphs and line breaks. You user input became an endless line of text which was not the result you expected.
In this lesson, I will explain the concept of preserving white space and link breaks using the template tag <xmdod:field and how to test if the user entered basic text or HTML code into the <textarea> control.
To begin, we must understand that when returning form input on our XMod templates, we use the <xmod:field tag. This is the primary field used in all display templates.
As an example, if we have a <textarea> control on our Xmod form named shortDescript, we would show the content of this controlon out view templates using the following code example:
<xmod:field name="shortDescript" class="Normal"/>
Beginning with XMod Version 4.5.0.3 Released: 08/15/2006 , the addition of preservelinebreaks and preserveWhitespace property was added to the <xmod:field> tag. If true, this replaces consecutive single space characters with a space character followed by HTML entities for the remaining spaces. This enables template designers to preserve the formatting of the originally entered text.
The two attributes that we are interested in are:
preservelinebreaks
(Optional) If "true" then displayed text will have its line feed characters replaced by the XHTML-compliant <br /> tag. This allows you to preserve line breaks as they were entered in the original. Typically, this is used with <textarea> controls to aid in usability where you can't expect (or don't want) the user to manually type in <br /> tags. In these scenarios, when the user hits the ENTER key in the text area, the expectation is that a line break will be inserted at that point. NOTE: This property is intended as a display aid for use with text-only or HTML-encoded values. It may interfere with field values that are intended to be interpreted as HTML by the browser.
preservewhitespace
(Optional) If "true" then, for each set of multiple spaces in the value, XMod will replace them with a space followed by a sequence of (non-breaking space) HTML entities. So, if 10 consecutive spaces are found, XMod will display 1 space followed by 9 entities. This allows you to preserve spaces as they were entered in the original. Typically, this is used with <textarea> or <input> controls to aid in usability where you can't expect (or don't want) the user to manually type in entities. NOTE: This property is intended as a display aid for use with text-only or HTML-encoded values. It may interfere with field values that are intended to be interpreted as HTML by the browser.
Great! Now if our user had entered two paragraphs of text to the <textarea> control, and had separated the paragraphs by hitting the enter key twice, the template would render the two paragraphs using the following template code:
<xmod:field name="shortDescript" class="Normal"
preservelinebreaks="true" preservewhitespace="true"/>
It will convert the rendered template content from:
This is the content of paragraph one.This is the content of paragraph two.
to
This is the content of paragraph one.
This is the content of paragraph two.
But, what if your user is versed in HTML and had entered field values that are intended to be interpreted as HTML by the browser?
If HTML was entered into the <textarea> control using the above line of template code, you will not get the results you intended.
The Solution:
When I create a XMod form that ustilizes the <textarea> control, I add a hidden field value below the <textarea> control. Don't confuse this with a common form hidded field value. I am creating a field and setting the display style as none.
Example:
<textarea ref="shortDescript" rows="8" width="300"
default="Enter your description here">
<label>Short Description: </label>
<default>Replace this text with your shortdescription...</default>
</textarea>
<input ref="ShortDescriptHTML" class="NormalTextBox"
style="display:none;"></input>
The shortDescriptHTML value will be given a value of Yes or No based on the input the user entered into <textarea> control (Basic Text or HTML).
How does that work?
First, we must understand that a custom Xmod form typically has an add record button (<addbutton>) and an update button (<updatebutton>) at the end of the form code. These two controls allow the ability to add the record and, if allowed, the user can update the record after it has been entered.
What is not commonly known is that, with Xmod, you also have the ability to run JavaScript on the button action. In a real situation, you would probably call a function that checks values, performs calculations, etc. and then have that function return true or false - true to continue processing and false to cancel processing.
Here comes the magical powers:
In our <textarea> control example, I add a JavaScipt function call to both the
<addbutton>
and
<updatebutton>
named checkHTML().
Example:
<addbutton text="Add" display="button" onclick="checkHTML();"/>
<updatebutton text="Update" display="button" onclick="checkHTML();"/>
Whenever the user adds or updates a record, the checkHTML routine runs a JavaScript function that checks if the user entered basic text or HTML code into the <textarea> control and assigns the value Yes or No to the ShortDescriptHTML input field before the record is added or updated. We accomplish this in the JavaScript function, by comparing the <textarea> control content against a regular expression that looks for common HTML elements in the content. If the regular expression finds HTML code in the content it returns the value Yes - otherwise No.
Back to our view template:
On our view template we now use a XMod: select statement to determine how to render the content of our <textarea> control form field.
The code would look like this:
<xmod:if name="shortDescript">
<xmod:select mode="standard">
<case value="<xmod:field name="ShortDescriptHTML"/>" operator="="
comparetype="regex" expression="\bYes\b">
<p><xmod:field name="ShortDescript" class="dnnpNormal" /></p>
</case>
<case value="<xmod:field name="ShortDescriptHTML"/>" operator="="
comparetype="regex" expression="\bNo\b">
<p><xmod:field name="ShortDescript" preservewhitespace="true"
preservelinebreaks="true" class="Normal" /></p>
</case>
<else></else>
</xmod:select>
</xmod:if>
Code Explanation:
First, we check to see if any content has been added to <textarea> control named shortDescript using the xmod:if statement.
Next, we use the xmod:select statement to traverse the value of the input field named ShortDescriptHTML.
If the value of the ShortDescriptHTML field is Yes, we render the <textarea> control normally so the HTML code is preserved.
If the value of the ShortDescriptHTML field is No, we render the content using the preservewhitespace="true" and the preservelinebreaks="true" attributes to allow our paragraph formatting to render properly.
Enjoy,
Buck