What cfc best practices

> <cfparam name="session.getemp" default="">
> I (generally, if it can be avoided ~) would not access external scopes
> directly within a CFC method. It breaks encapsulation and makes code less
> reusable.
> hmm I don't understand- I was setting a default for the session.getemp session
> so it was set inside, apologies I don't understand that one

It's perhaps a good idea if you read up on encapsulation or data hiding.
Or the fundamentals of procedural programming (leaving aside OO principles
to start with).

Your function could well be designed to set defaults for *a user object*,
but where that user object is stored and how should not really be its
business. Where possible a function should do one thing:
- validate a user object;
- put it into session.

That's two things.

What happens down the track when you want to valdiate a user object but
*don't* want to put it into session? It could be part of your process for
creating the user record in the first place, before putting it into the DB.
You don't want to have to write another function which is almost the same,
except for the session bit. Then you've got two bits of code to maintain
if anything changes. This is, obviously, just the tip of the iceberg.


My approach here would be to set a vanilla user object (a struct within the
CFC instance holding the bits and pieces of user data), and *return* that.
Then in your calling code you assign that to the session scope.

Google "getters and setters".

In general, a function should only manipulate data within its own scope
(passed-in arguments and variables local to the function (or the CFC
instance), and then pass back a result based on that manipulation. They
should not manipulate anything from "outside". The session scope is
intrinsically outside.

The exception I'd have to this would be to have a session manager, which is
specifically used to maintain values in the session scope. So that's its
job: managaing the session scope. It won't care about whether it's a user
object or authorisation permissions, or a the state of [something] which
persists for the session; it just manages putting things in, and getting
things out of session.

That said, for any good practice, there's a situation where it's not the
best approach. However I don't think this falls into this category.

Dan's probably rolling his eyes and going "overly complicated", but I think
we differ in opinion as to what's a good level of "complication" (I'd
prefer to say "abstraction"), what's too much, and what's too little ;-)


> <cfif NOT IsStruct(session.getemp)>
> <cfset session.getemp = StructNew()></cfif>
> Why don't you just param it to a struct in the first place?
> OK so like this then:
> <cfparam name="session.getemp" default="">

No. You don't want it to be a string, even an empty one. Param it to a
*struct*:

<cfparam name="session.getemp" default="#structNew()#">


> True if the arguments values aren't passed in then there is an error thrown,
> that is why I was using the cfparam to stop any errors if they weren't passed

The error would be thrown by the code making the function call, so the
params would not get a look-in.


> so it should be <cfset var errors="">
> <cfparam name="errors" type="string" default="">
> or can I 'combine' the two?

Just the VAR statement is fine.


> <cfif arguments.username EQ "">
> no name</cfif>
> It's generally considered poor form to output anything from a function.
>
> I'm sorry you completely lost me on this one!

I mean exactly what I said (ie: I wasn't being oblique). In general, the
code within a function should not output anything. A function should
*return* something, not output it.

I cannot recommend what specific books / web pages to read, but I recommend
you google about the place for coding practices when writing functions.

--
Adam