Title: Message
Good catch! Thanks.
 
Best Wishes,
Peter
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Will Tomlinson
Sent: Saturday, March 04, 2006 9:47 PM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Queries vs. beans for displayable objects

One little gotcha I've run into in my cart application is, when you group like this, say, for a product model, with dependent SKUS, it works best to use a left outer join. If you don't, you won't even get the product model returned in your output.

Then what I do is run an if on that inner <cfoutput>

<cfif dependent NEQ "">#dependent#<cfelse>This model has no SKU's. Would you like to add one? blah blah blah...</cfif>

Will

Roland Collins wrote:

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: CFCDev@cfczone.org
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 cfcdev@cfczone.org 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/cfcdev@cfczone.org ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org

No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006

-- 
Will Tomlinson
Phone: 336.230.1123

"Custom software development for the web"
*******************************************************
ColdFusion Programming
Database Design
HTML
XHTML
XML
_javascript_
Flash
SQL
MySQL
Microsoft SQL Server
Microsoft Access
3D modeling
Custom graphics

www.winstoncourtsports.com *NEW*
www.artistneedle.com 
www.wtomlinson.com
www.singinginfo.com
www.priceequipment.com
www.uniquetool.net
www.kennedyshipyards.com
www.virtualautosystem.com
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org

Reply via email to