>
<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
1 Correct answer
8
Replies
AdChoices