Status/Resolution/Reason: Closed/Fixed/
Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)
Created: 09/11/2012
Components: Documentation
Versions: 10.0
Failure Type: Unspecified
Found In Build/Fixed In Build: Final /
Priority/Frequency: Trivial / Some users will encounter
Locale/System: English / Win All
Vote Count: 2
From http://stackoverflow.com/questions/10604987/should-encodeforhtml-encodeforurl-be-used-from-cf10-onward-in-flavor-of-h/10612662#10612662
{quote}
In an earlier question encodeForHtml() vs htmlEditFormat(), how are they different, it seems like the new encodeForHtml() & encodeForURL() functions are superior than htmlEditFormat() & urlFormat() respectively.
Should the esapi-based encodeForXXX functions be used in flavor of the exiting ones? Would the 2 older functions be deprecated?
{quote}
The new functions cover all the territory the old functions did, plus they are more "aware" of more recent potential risks in incompletely escaped mark-up. I see no reason to use the old functions given the existence of the new functions.
As for deprecation, I'm all for it. If encodeForHtml() - for example - is better / more secure that htmlEditFormat(), then it is at best poor form to not flag the latter as obsolete and that the new function should be used instead. At worst it's negligent not to do so.
I would urge Adobe to mark htmlEditFormat() etc as deprecated in the docs, and advise why. I would not suggest they take it any further than deprecation at this point though.
--
Adam
----------------------------- Additional Watson Details -----------------------------
Watson Bug ID: 3329177
Deployment Phase: Release Candidate
External Customer Info:
External Company:
External Customer Name: Adam Cameron.
External Customer Email:
External Test Config: My Hardware and Environment details:
Attachments:
Comments: