Yes it is an *awesome* feature in CF. I also use it often with the
cfmail tag.
<cfmail query="myQuery" group="person" to="email">
Here is a list of your dependents and their benefits
<cfoutput group="dependent">
#dependent#
<cfoutput>
#benefit#
</cfoutput>
</cfoutput>
</cfmail>
Someone in my group here was using these complicated structures and loops
and database queries within the loops to do the same thing. I took his
template, simplified it with grouping and instead of 5 minutes to run it
takes about 5 seconds!
Jason Cronk
Verizon
"Roland Collins"
<[EMAIL PROTECTED] To: [email protected]
m> cc:
Sent by: Subject: RE: [CFCDev] Queries
vs. beans for displayable objects [spam] pending
[EMAIL PROTECTED] deletion
one.org
03/04/2006 11:59
PM
Please respond to
CFCDev
There isn’t a limitation of nesting as far as I know. You can add
subgroups like this:
<cfoutput query="myQuery" group="person">
#person#<br />
<cfoutput group="dependent">
#dependent#<br />
<cfoutput>
#benefit#<br />
</cfoutput>
</cfoutput>
</cfoutput>
Notice the difference is that you just don’t specify the query name on the
inner cfoutput tags.
I’m amazed how few people know about this *awesome* feature in CF!!! J I
use it constantly – it makes life sooo much easier.
Roland
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Peter Bell
Sent: Saturday, March 04, 2006 10:07 PM
To: [email protected]
Subject: RE: [CFCDev] Queries vs. beans for displayable objects
Hello Roland,
Interesting. Make that very interesting. Make that "great idea"!
Assuming Person is in person table and Dependent is in dependent table
(with different properties), I guess to get the right query data you'd just
join where PersonID = DependentPersonID so you'd get use something like:
<cfquery name="myQuery" datasource="whatever">
SELECT FieldList
FROM Person p, Dependent d
WHERE p.PersonID = d.DependentPersonID
ORDER BY p.PersonLastName, p.PersonFirstName, d.DependentLastName,
d.DependentFirstName
</cfquery>
<cfoutput query=”myQuery” group=”PersonID”>
#PersonFirstName# #PersonLastName#<br>
<cfoutput>
#DependentFirstName# #DependentLastName<br>
</cfoutput>
<br>
</cfoutput>
Is that going in the right direction? I suppose there is some inefficiency
in terms of the payload as I have 3 copies of personfirstname and
personlastname for every person, but compared with instantiating 40 objects
or serializing and deserializing XML, it's sounding like a pretty useful
approach.
I guess the only real limitation would be if you had multiple sub
groupings. Lets say you had an order which comprised of a couple of
addresses (billing and shipping) and x order items. Would there be any way
to handle that at all using this? I guess this is limited to a
master:detail situation as opposed to a master: detail: detail one or is
there a work around I'm not thinking of?
Best Wishes,
Peter
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Roland Collins
Sent: Saturday, March 04, 2006 9:32 PM
To: [email protected]
Subject: RE: [CFCDev] Queries vs. beans for displayable objects
cfoutput group=”my_grouped_column” is extremely useful for exactly
what you’re trying to do. So if you’re trying to do this:
Person 1
Dependent 1
Dependent 2
Dependent 3
Person 2
Dependent 1
Dependent 2
…etc
All you do is structure your data set to contain both the Dependent
and Person information and then order it by the top-level item. So
your recordset would look like this:
person dependent other_data
Person 1 Dependent 1 a
Person 1 Dependent 2 b
Person 1 Dependent 3 c
Person 2 Dependent 1 x
Person 2 Dependent 2 y
Then in cf, all you do is group the top-level object:
<cfoutput query=”myQuery” group=”person”>
#person#<br>
<cfoutput>
#dependent#<br>
</cfoutput>
</cfoutput>
The inner cfoutput automatically iterates through all of the
sub-items for you.
Hope that helps!
Roland
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Bell
Sent: Saturday, March 04, 2006 7:52 PM
To: [email protected]
Subject: [CFCDev] Queries vs. beans for displayable objects
After a lot of playing around, I'm really starting to like the
practical nature of using queries as a data transfer mechanism for
simple displayable objects where you need to display 1..n objects and
where you do NOT need to display any ..n aggregates or compositions
(it gets a little convoluted where you have to display 10 insured
persons and the three dependents for each).
The weakness of queries is that they are dumb. There are no methods,
so you end up with the ultimate anemic domain model with all of the
methods in the service layer. On the other hand, for simple objects
that mainly have CRUD features that need to work on both 1 and n
instances, queries provide a simple display method and putting
validation into the service layer means that it can be used
efficiently for 1 or n objects without the overhead of creating an
array of objects and iterating through n-objects when trying to
delete 200 records or even save updated pricing for 40 products from
a single screen.
Any thoughts/experiences?
Also, does anyone have a clean data structure for working with lists
of objects each of which have ..n aggregations/compositions. Example
- I want to display 10 insured persons with a list of dependents
below each of the 10. Obviously you can create an object for each
item which could contain a property which would be a struct of the
sub objects (or a query if you were willing to create 10 objects but
not 40 objects), but I'm not in a rush to be generating 40 or 50
additional objects per page request and I can see situations where
I'd have too many objects to cache them in a more persistent scope
(imagine a list of products with associated attribtues where you have
a database of 500,000 products). XML gives the same capabilities but
now with the serialization/deserialization overhead instead of the
object instantiation overhead and then you probably need designers
capable of writing XSLT's which is not something most of the
designers I work with would want to learn. I'm actually playing with
a structure using naming conventions for associated structures and an
entity level templates, so if you want to display 10 insured persons
with 3 depenents, you describe the person list template, stick a
little "Dependent" tag inside it and then create a separate template
for displaying the dependents which is then iterated through and
dropped into the list template in the appropriate place.
Anyone else trying anything similar, and does anyone have any great
ideas on performant ways of passing data that involved multiple
objects each of which may be composed of n ..n compositions (i.e.
anything other than creating all the objects or
serializing/deserializing into somehting like XML)?
As always, any thoughts/ideas much appreciated.
Best Wishes,
Peter
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by
CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by
CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of
the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of
the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
