I am not sure what do you want so say by "We can not use HTMLEditFormat() on the field since they want their formatting preserved".
But it seems that you can take help of regular expression.
First you have make a regular expression for detecting html tag. If make not of that expression you will get everything except html and for that you need to replace "<".
Anyway it will helpfull if you provide some more details regarding formatting.
<cfset newvalue = #ReReplace(yourinputfield,"<","<","ALL")#>
That will replace ALL instances of a < with <
Unless I misunderstood what you're asking.
What exactly you want to do? can you explain more detail's.
Regarding - We can not use HTMLEditFormat() on the field since they want their formatting preserved.
If data is entered into a rich textearea, it will have html tags such as <b>. Every line break will be create <p></p>. If you output this using HTMLEditFormat(), or not only will these tags not function, but they will display.
It's a difficult question.
Thank you for your reply. Yes, using a regular expresion is what I was thinking about too. But it seems to be pretty hard to construct a reg ex without simply looking for "<" and ">" pair. Can you suggest the one that would differ "less than" from the HTML tag opening?
As for the formatting details, Dan Bracuk below gave a great description:
"If data is entered into a rich textearea, it will have html tags such as <b>. Every line break will be create <p></p>. If you output this using HTMLEditFormat(), or not only will these tags not function, but they will display."
Our users need to be able to place, for ex., <li> that will be displayed by a browser as a bullet point not as "<li>" text. At the same time they want to use a single "<" in the meaning of "less than".
I appreciate your thoughts and advice.
Unfortunately, it's not that simple. We can not replace ALL of the "<" instances. We need to replace only those that are NOT the opening angle braket of an HTML tag. We have to find a way to distinguish a single "less than" sign from a part of HTML.
I would appreciate any suggestions you might have.
Thank you. You gave a very clear description of our problem. Do you think it's possible to construct an adequate Reg Ex for this case?
1 person found this helpful
I usually request my client's to enter data in an editor (which operates in 1 of 2 modes, 'editor' and 'code')
In editor, they are writing the "content", so entering "hours < 4" would be written into the "code" side of the editor as "hours < 4" automatically. (ColdFusion's xmlFormat() can convert special characters like this into the proper equivalence.
If they are in 'code' mode, then they are writing the 'behind the scences' code, not the content. In that mode, writing 'hours < 4' would be invalid, since the '<' tag is explicitly seen as the opening of a tag. To make this easier on clients, most of the time, we disable 'code' mode and only let the use the 'editor' mode (relying on the editor to make clean, HTML5-validated code based on their use of it).
In the event you need to handle '<' tags when in a 'code' view, I can see how RegEx's would be a good solution, but I (offhand) can't see how it can logically determine if a 'proper amount of opening and closing tags' are provided, as someone entering:
<p>I am > the sum of my parts, but < the least valuable. Code is > great!</p>
Shows that there can be a random number of 'opening/closing' tags, even though in this case, they were 'supposed' to be interpreted as < and >
1 person found this helpful
Go to cflib.org and look for a function called safetext(). You may find it helpful.
Thank you, Dan. This is actually a great function. I had to write my own (much more simple one) for the same text cleaning purpose. Good to know! Unfortunately, it does not help with my current problem: it strips out listed HTML and Java events but it does not strip the plain single right angle braket. I'm afraid I want too much from my CF 9.
Editor is a very good idea. We are using it in a couple of other places. But we can not place an editor into this particular problematic one: our users like to cut-n-paste their pre-formatted descriptions into this field so the editor would create an additional hassle/obstacle for them. Thanks for your input!