RE: [CFCDev] Queries vs. beans for displayable objects

[Roland Collins]

Title: Message

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