> > I like your nomenclature better (although I don't disagree with the
> original
> > +++ idea since the ensuing fuse *will* be dependent on your query file
> > anyway),
> No it won't. It's dependant on the attributes that are passed out of the
> query file and into some other fuse(s).
that's circular reasoning. You're passing the attributes out of the query
file and then saying that because they got passed out of the query file that
then that's why you necessarily had to pass them out of the query file.
Your nomenclature for how to refer to a DSP or ACT file that is dependent on
a QRY file has some merit, particularly when contrasting q Query file
included inside a Fuse versus one included inside a Fuseaction. But each
should be treated as a black box, and the query is not functioning the same
as the incoming FORM/URL vars . It's the difference between a fuse (the ACT,
DSP, or QRY files) and the fuseaction, as there is a one-to-many
relationship there, and how they are handled in terms of trips to the server
are different as well. There's nothing to gained (or lost) by refering to
them in either the atttributes scope or the query scope, but there is a cost
associated with copying them to attributes scope.
>
> > but I do wonder what the renaming to Attributes scope point is.
> We consolidate all of our input from the front-end (URL, Form, Attributes)
> into one scope. Why not do the same for data that comes from the back end?
>
> By copying query data to the attributes scope, I can work with that data
> in other fuses without having to worry about the query that it came from.
>
yes. absolutely. and you could also do this by coping it from Query scope to
Attributes scope at the top of the fuse that actually uses it. Much like
CF_ReuseForm does. Now you remain consistent with others' standards while at
the same time employing a technqieu that you find useful. You're requiring
the fuse that handles the back-end to pre-process data expectant on the
front end--that doesn't accomplish what you wanted which was to divorce the
two. I think it also leaves open q question of what to do about a persistant
query which adds some complication to the mess
>
> > What does it do that isn't done with everyone else's query files (where
> the
> > variable remains available in the QUERY scope)?
> That's just it. It may be available, but WHERE it's available? That answer
> could be different for each fuseaction the fuse is used in (unless you do
> it my way, which is to always put the same data in the same place).
Again, I don't see the distinction. If you need to post-process the query
data, then that is best done by the fuse that needs it, probably with a
custom tag CF_Query2Attributes. If you want the DB to be divorced, which we
all seem to agree on, then the conversation with the DB should be limited to
"here is the data that I want" and "here is the data that I'm giving you"
If it needs to be massaged in some way that the DB is not going to do it,
then that should be done after the query is returned
>
> > how is your choice of RDBMS
> > in any way affected by your translating the query results into attribute
> > vars?
> It's not the choice of RDBMS. It's the fact that the structure of the
> database may change, or I may throw in a middle tier, or maybe I'll move
> from RDBMS to LDAP, etc.
>
uh, and your point is.....? Your "new" way works as efficiently as the
current way, which is what I asked. In the current way, such changes would
be handled also by going into the QRY file and makign modifications. You're
just making one set of mods now. It's no different than using QuerySims...by
the time the QYR file is done processing one cannot tell the difference
between having actually hit the DB or not.
> > and are there any implications for Neo where it's expected that the
> > dot notation will always imply (and create-on-the-fly) a structure?
> No.
>
well until NEO your CFSET to attributes scope will be phantom sets. They'll
work but to make them truly in Attributes scope you'll have to do what
CF_formurl2Attributes does.
> > Wouldn't you have been as well served by something akin to a
> > CF_FORMURLQUERY2ATTRIBUTES tag ? (or just CF_Query2Attributes so you
don't
> > have to reproduce all that typing each time (after all one of the points
> of
> > the original post was 'do you really use Fusedocs for all your query
> files?'
> > so certainly a custom tag makes some sense).
> I'd thought about a <CF_Query2Attributes> tag that would be called within
> the qry_ file, but I've found the extra typing is worth the clarity and
> flexibility that copying each field by hand provides. For example, there
> have
> been times when the database provided first, middle and last name, but my
> app only needed name. So what I did is
> <cfset attributes.name = myQuery.firstname & " " & myQuery.lastname>.
ahha, now I see why we are in disagreement. I will leave it to a RDBMS guy
to explain why handling it that way is wrong. Maybe Adam Churvis can jump in
here since he has a knock for explaining it in terms that make sense to
non-DBAs
> I actually consider this technique fundamental to the value of fusebox but
> whenever I share it with others they think I'm weird. Everyone seems to
> equate rapid development with minimal typing.
" I wouldn't be so paranoid if everyone weren't against me" :)
jokes aside, if everyone thinks it's weird then try looking at it from a
different angle and see if you can find a contradiction by playing devil's
advocate with your own technique. It may be that your technique is just
different, rather than weird. Or maybe they are right.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
