Oh yeah, damn -- can't believe I forgot that.
Guess you'll have to pass it in as a struct (or define your arguments in
advance) and do some work to build your abstraction.
> From: Sean A Corfield <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Tue, 7 Oct 2003 23:00:54 -0700
> To: [EMAI
On Monday, Oct 6, 2003, at 11:13 US/Pacific, Nathan Dintenfass wrote:
But, that said, if you want to do what you are doing, one option would
be to
actually have a getRecordSet method in your extending component that
calls
super.getRecordSet()
...
Unfortunately, you cannot do that :(
When yo
On Monday, Oct 6, 2003, at 07:51 US/Pacific, Dave Carabetta wrote:
Is it possible to extend multiple components with one component? Is
so, how?
No it is not possible.
In CF (and JAVA), there is only single inheritance. However, with CF,
you can add methods to the /WEB-INF/cftags/component.cfc an
On Monday, Oct 6, 2003, at 08:02 US/Pacific, Bryan F. Hogan wrote:
I've heard that in order for a variable only to exist within a specific
function that you var scope it.
Correct.
However, they also say
that you don't reference the var scoped variable with the Variables
scope
prefix.
Correct. 'va
On Monday, Oct 6, 2003, at 08:27 US/Pacific, Bryan F. Hogan wrote:
#Variables.thisTest#
works in regular CFML pages.
But in regular CFML pages, "thisTest=1" is shorthand for
"variables.thisTest=1" whereas if you say (inside a UDF / CFC method):
then you are creating thisTest in 'var' scope whic
How much of a performance advantage is storing your model (and controller)
CFCs in application or session scope? And if it's that much, why wouldn't
you want to store everything in the application scope (or session where
appropriate)? I mean, why wouldn't you want to put all of your view pages
into
Well,
If if you do customer = from, I´m sure your code
will work fine.
But as CF works, when you do this, you´re simply
sayng that the variable name "customer" is a pointer to the structure
"form".
Any change made in the customer struct will change
the value of the form, because they´re
> exactly what you shouldn't do -- keep your instance data inside your CFC
and
> build the appropriate API using methods to get the data out in a way that
> makes sense for your component.
Exactly.. use accessor methods to access the Class Instance Variables...
I see what you are getting to now..
PREFACE: This isn't a personal attack on you, Andy. If it sounds that way,
it's because of the impersonal communication mechanism, not my intentions.
To paraphrase, "fu**in' email".
Using objects doesn't mean you're doing OO programming. I can take a
vanilla FB application, convert each circuit
I'm not sure I understand what you are asking.
If you return "THIS" you can simply string the init() method on your
createObject call.
So, something like:
user = createObject("...").init("Nathan","Dintenfass");
userName = user.getName();
I don't understand what you mean by "variables.user.firs
> I also always return THIS from the init() method to allow me to do:
> foo = createobject("component","foo").init();
If you return THIS from the init() method, you only get reference to
Instance methods.
No Instance variables are returned.
>From the below example..
user = createObject("Component
Title: Message
Global
Search and Replace
:)
-Original Message-From: Paul Giesenhagen
[mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 4:02
PMTo: [EMAIL PROTECTED]Subject: Re: [CFCDev] Code
Reuse
Yes, I see your point, but it seems that you have
a chunk of
So if you have form.firstName and
form.lastName
Doing this isn't good enough:
You must
// once you do the above
// customer will now hold the form values in the
customer struct?
#customer.firstName#
Paul Giesenhagen
QuillDesign
- Original Message -
From:
Title: Message
Yes, I see your point, but it seems that you have a
chunk of code (the cfc) that is re-usable (which is good), but everwhere you
call the cfc you have to update if you change firstName to first_name thus it
leaves you in the same situation before you did code reuse.
This is
Hi Paul,
It is possible and recommended.
In fact, you shoudn´t have FORM or any other scope
favriables inside your cfc, only arguments, thats the best
practice.
Althou you may want to pass and get every argument
independenttly, which seems more flexible and more OO.
As you mnay know, fo
Title: Message
Rather
than let the cfc know about the two different ways it can get data, just let it
concentrate only on one. The cfc should only accept firstName and
lastName. In your code that calls the cfc, use a cfif to determine which
set of variables will populate the cfc.
One
mi
A form
is a structso it should work fine either way
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of Paul
GiesenhagenSent: Tuesday, October 07, 2003 4:43 PMTo:
[EMAIL PROTECTED]Subject: [CFCDev] Code Reuse
Ok, I am really trying to utiliz
Ok, I am really trying to utilize CFC's and utilize
their pronounced ability to handle alot of good code reuse.
I have a CFC that handles customer
information. And I have two ways that customer information can be
populated and manipulated:
1) Through a form (form.firstName,
form.lastNam
Sorry about the OT, but both replies have me thinking. Thanks much as
always.
Take care,
Justin
-Original Message-
From: Nathan Dintenfass [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 07, 2003 1:06 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Dynamic SQL, Stored Procs, and Reports
No way around writting it to a file first. CF is a file driven language, so
if you want to execute code, it has to be contained within a file. It's
certainly not an ideal solution, but one that makes sense for certain
situations.
If you're not needing tremendous scalability and you're on CFMX 6.
[insert obligatory urging to keep posts on topic -- about CFCs]
You can do that, but generally speaking it's a bad idea. Performance will
be considerably less than optimal using that method, which likely defeats
much of the benefit of using a stored proc in the first place. Why not just
dynamic
I have found you can write the code to a file then include it, and that
seems to be a horribly bad idea. Is there any other way to execute
dynamically built cf code? I want to build this string and execute it?
Sorry for the OT.
Justin
-Original Message-
From: Justin Balog [
Howdy,
Kind of on the topic or reports, I was looking to build by storedproc call
dynamically, then execute it in my report cfc. Has anyone ever done this,
if so, do you evaluate the built string?
Thanks,
Justin
--
You are subscribed to
We're using an adapted version of FuseBuilder to generate our data
components. Fusebuilder (as downloaded) generates useful qry_
fusefiles from a SQL Server DB. We adapted it to generate data
components based on a PostgreSQL DB. I think Barry (who did all the
work on this) plans to put somethin
Adam and Jeff
Excellent! I learned something today
Thanks
-Original Message-
From: Adam Wayne Lehman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 07, 2003 10:08 AM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Using Structs
I might be missing your question but simple loop should
I might be missing your question but simple loop should do the trick for
accessing the data and populating your select box. If you are talking
about dynamically creating the array from a query you can just use
arrayAppend() like so:
state = arrayNew(1);
for(i = 1; i LTE stateQuery
how about
state[2]= structNew();
state[2].name = "New York";
state[2].addb = "NY";
just adding each state into a new index of the first dimension. Actually,
theres no real need to use an array at all, it could all be a struct:
state = structNew();
state["AL"] = "Alabama";
state["NY"] = "New York
How do you go about generating your data layer objects from your database?
Some sort of automated process? I'd be very interested to see how that
works. The lack of a good IDE for CFCs makes for a lot of legwork that I'd
love to avoid. I assume that your data layer is doing type checking and
suc
Yes, though I set up the variables in the init() method instead of the
pseudo-constructor area.
I also usually don't put variables. in front of instance once I've created
it.
I also always return THIS from the init() method to allow me to do:
foo = createobject("component","foo").init();
But, y
> instance.userID = userIDValue;
> instance.familyName = getUser.familyName;
Ok. this sounds good usage... but still it looks kinda messy compared to
Java OOP.
> As for returning "VARIABLES" -- this is something that should be done very
> rarely and only when you need to abstractly do things like
I am indeed saying that you should not use "this" to hold your instance
data. There was some justification for in 6.0 because the VARIABLES scope
was broken, but in 6.1 that justification is gone.
Your second alternative would be more aptly:
variables.userID = userIDValue;
variables.familyName =
I'm having trouble seeing what 'legitimate' reason there might be
for storing an instance of 900-year old person in your database. 900
years looks suspiciously like a 'flag' value to me, and if that's
the case, I think I'd prefer to address it by modifying the database
table (or object definiti
Hi Barney,
I think I'm starting to see where our differences arise :-)
CFTRY vs CFIF:
--
I hadn't thought of the differences in approaches being procedural
vs event-driven, but that ties in well with the fact that the caller
of the objects, in our case, is a presentation layer writ
33 matches
Mail list logo
