> -----Original Message-----
> From: [email protected] [mailto:[EMAIL PROTECTED] Behalf
> Of Greg Stevens
> Sent: Saturday, 21 June 2008 5:46 AM
> To: CFCDev
> Subject: [CFCDEV] Re: Naming / Coding / Design Standards
>
>
>
> @Mike,
>
> I never thought of the possiblity of "sQLCommand" before. One thing I
> have always assumed I was doing correct was always lowercasing all of
> my starting word in a variable, meaning it would always be
> "sqlCommand" in my mind. When I first read "sAMAccountName" I thought
> you must have accidentally hit the shift key on your keyboard, until I
> did a search and saw that really is how it's spelt ;)
>
> @Mike, Bryan,
> I am leaning towards getId() rather than getID() and having table
> columns with "id" rather than "ID". I used to prefix the id column
> with the table name for something like userID, but after finishing the
> largest project I've ever done I decided that prefixing the id with
> the table name is just extraneous. I got so sick of typing userID or
> things like "missedSurveyResponseReasonID" (ya, it got that bad). For
> foreign keys, I have a standard of "fk_{tableName}_{id}" so it results
> in something like blogPost.fk_user_id.
>
> Bryan, when you have a field like userID, does your user then have a
> method named "getUserID()" or is it just "getID()"? I really like
> having a standard "id" property on all my classes so that no matter
> what object I am dealing with, I know it's primary key can be obtained
> just by going object.getId(). This helps me to write slightly more
> generic code.
>
> @Bryan,
> "URL" makes sense. Same with lowercasing it when variables start with
> it, such as urlEncodedFormat(). I have been doing it this way but just
> recently changd when I started wrapping all my href's with
> #request.location.url("aldfkjl")#. I preferred all lower case there so
> my code wasn't screaming at me all the time. I guess that doesn't need
> to change though, since the function name starts lower case meaning it
> should continue being lower case. so That's good. It stays as
> #request.location.url("adlfjjlaf")# and if I had it different it may
> be #Request.location.adminURL("someAction"). So that is good.
>
> Variables being mixed camel case - I agree, thanks for clearing me up
> and helping make a decision on it.
>
> I completely agree with you on lower casing package names and all
> files other than classes. I Have been torn lately about certain file
> names though for public web pages. Should it be about-us.cfm or
> aboutus.cfm or about_us.cfm? I understand Google searches "about-us"
> as "about us" so that seems obvious to me, but than it becomes
> inconsistent with private included templates like sideNav.cfm, I don't
> really want to name that include side-nav.cfm. Any thoughts on that -
> getting real off topic now?
>
> I was using ColdSpring for a while but then switched over to LightWire
> because I needed to do some more programmatic actions that were easy
>snip
> ****
>
> Still a bit more left to decide on (and not like this is set in
> concrete yet). Would like to hear about me getting rid of the Gateway
> for just a DAO and also having the DAO have a DataSource or Connector
> of some type that just returns queries.
>
Re just having a DAO (no Gateway) - yep, go for it.
Re returning arrays of objects from the DAO - I like everything about this
EXCEPT the fact that it's not going to work. OK, to back off that statement
a bit - if you are going to swim against this particular tide, do a
proof-of-concept, really nail your load testing, and be sure your queries
aren't going to return more records than the ones you load tested against.
You might end up with some DAO functions returning arrays and some larger
data sets coming back as queries, so make sure you're philosophically
comfortable with that.
Separate connector? Nothing against it, but not sure why this is a good
idea.
Jaime
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
