On Wed, Jan 7, 2009 at 6:07 PM, Doug Smidt doug_smi...@yahoo.com wrote:
I do want to use a persisted CFCbut I want to use it on the spot, in the
CFGRID tag. I don't want to:
1) Do exactly what you stated is generally recommended against. I don't want
to be accessing a shared scope
This isn't my argument - it's yours. I'm not going to get into another endless
debate on best practices.
Simply dropping my data into the query attribute doesn't solve my problem, as I
need the same thing to happen in the onChange attribute. I'm not aware of a
replacement for that, and
I recently jumped back into CFGRID after not looking at it for a long time;
what I was able to whip up in short order seems like a very good fit for what
I'm working on.
One thing I wasn't able to figure out (or even know if it's possible)...is
there a way to provide an object in memory to the
Why not point to a CFC that uses the object in memory? Or am I
misreading you? There is no need for the CFC you call to rerun
cfquery. It can simply use an application (or session, whatever)
cached query and perform QofQ on it for sorting.
On Wed, Jan 7, 2009 at 3:02 PM, Doug Smidt
Sorry - I should have been more clear. I'm not necessarily referring to an
object (variable) in a shared scope, though I want that to be an option. I
also don't want to have to access a variable containing my CFC directly from a
shared scope inside of another CFC.
A very basic, quick
So I'm confused - are you saying the only reason you don't want to use
a persisted CFC is what? Why isn't this CFC (myPeeps) cached in
the app scope? You could then make another CFC, just for AJAX
purposes, that works with this app scoped CFC. I know that - in
general - folks recommend against
I do want to use a persisted CFCbut I want to use it on the spot, in the
CFGRID tag. I don't want to:
1) Do exactly what you stated is generally recommended against. I don't want
to be accessing a shared scope directly in a CFC. I've taught others not to do
it, and I'm not going to do
7 matches
Mail list logo
