Well, for all the "getter" and "setter" haters out there here is
something else to think about thanks to a new article at
JoelOnSoftware. (http://joelonsoftware.com/articles/Wrong.html)
most of the data I store in the database, in many of my applications,
is user generated. They might be surveys, or audits, or shared
documentation (wiki type) things. Heck they might just be user
profiles or something else similar and small like that.
I store the data just as it is given to me. Which, if I were to output
it just like that opens my app to cross site scripting vulnerabilities.
Not so good eh?
So Joel recommends, what seems to me, a pretty good idea. Using a
naming convention he dubs "App Hungarian" that prefixes unsafe strings
with us and safe strings with s.
So my username would be usUsername. Similarly he recommends
naming methods that return unsafe strings USGetUsername or SGetUsername
or having a conversion function called SUsernameFromUS which basically
serves as a wrapper that safely encodes all those unsafe symbols that
might be in the username (or whatever your string migh be).
Though, technically, I think a SFromUS would be fine as it converts any
unsafe string to a safe string. He explains why he calls it
SFromUS instead of USToSafe in his article. If you haven't read
it you should - its pretty interesting. But now, back to my point.
I may not want to call SFromUS all the time. I might want to just
get a safe string from my object. When I'm dumping out its
contents I just want to say #someuser.getUsername()# and be done with
it. However, At this point I don't know if I have a version that
is safe for html output or not. Sometimes I need my content in
its unescaped format. So what I really need is a
someuser.SGetUsername() and a someuser.USGetUsername - I may also need
a someuser.SSetUsername and someuser.USSetUsername - whew.
so know I have effectively doubled all of my getters and setters in
each object that has mutators. what a pain - but it does help in
the way that Joel explains in his article - it makes recognizing
problems in your code much easier.
I think, though, that I would use camelCase and call them
someuser.sSetUsername and someuser.usSetUsername so that it is a bit
easier to read.
The trick here is making sure you really have unsafe code in your
usUsername variable and safe code in your sUsername variable.
Becuase you would definately not want to call SFromUS on your sUsername
if it already had an espcaped value in it. That would muck
everything up. Imagine if you escaped - it would
become   Not so hot.
Anyway, I'm not advocating any path right now, I just thought I would
open up the idea for discussion- see what others think of the idea -
and hear what other kinds of cons (other than more methods) folks might
have against an idea that, to me, seems pretty smart on the surface.
Bill
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
