> It gets lost when it's written back into a form. Bingo! Man, I'll give you this, you're loyal... :) like a dog with a bone...
> page1.cfm > <form action="page2.cfm" method="post" name="testForm"> > <input name="title" value="#attributes.title#" /> > <br /> > <textarea name="body">#attributes.body#</textarea> That right there is your problem -- these form input elements are precisely the situation htmleditformat() was designed for. use it around both of the attributes variables in the form here ^ ... as in value="#htmleditformat(attributes.title)#" and <textarea>#htmleditformat(attributes.body)#</textarea> What happens is when you display the input element if the value has a " in it, you end up with bad html markup, hence, "html-edit-format" -- a format which allows you to edit a string of text safely in an html form. So instead of this <input name="title" value="my"string"with"quotes" /> (see the problem?) what you need, and what you'll get with htmleditformat is <input name="title" value="my"string"with"quotes" /> The reason your values still got lost when you set your client variables with htmleditformat() is because your client variables don't have any need for that formatting, but the form (which you omitted) does. Really, no user-provided value (anything a user can enter via form or url) should ever be displayed to an html page without using htmleditformat() (or in some cases xmlformat) unless you're designing an application which will be used strictly by web-programmers (or are providing the users with a browser WYSIWYG to format their input -- I don't care for them myself, partly because so many users abuse the privilege to produce 20pt lime blinking text on a bright orange background (MY EYES! MY EYES! OH GOD! MY EYES! MAKE IT STOP!) and also because they're a great way to allow users to perform cross-site scripting attacks on your site, but what the hell). http://www.imperva.com/application_defense_center/glossary/cross_site_ scripting.html > page2.cfm > <cfcase value="preview"> > <!--- since it's a preview write it to the client scope > ---> > <cfset client.title = htmlEditFormat(form.title)> > <cfset client.body = htmlRditFormat(form.body)> > </cfcase> > </cfswitch> Drop the htmleditformat() calls here. > <cfoutput> > <strong>#form.title#</strong? > <br /> > #paragraphFormat(form.body)# > <br /> > </cfoutput> Add them in again here. In the latter case, you need to put the HTMLEditFormat() call inside the paragraphFormat() call. > See what I am getting at now? By the way > this is very much simplified right now. Yep... trust me -- in _EVERY_ case where you're outputting the strings to an html page (as in the first and last examples above), use it -- do _NOT_ use it in _ANY_ other case and you'll be fine. :) HTMLEditFormat == output to html (ALWAYS) HTMLEditFormat != setting variables (of any kind) HTMLEditFormat != database updates HTMLEditFormat != something other than html output Don't feel bad -- nobody uses it where I work either (correctly or otherwise)... :-/ (Sorry if I seem off ... it's just been a long day for me, I'm really not trying to be snarky.) s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:5:166867 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/5 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:5 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.5 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
