Thanks for this Kevan. The quick 'logic in the view' fix went live and I was given a day to do a refactoring before moving onto something else.
I would like a good stab at a) and your ideas are along the lines I want to go down. It's still a bit vague thouh the best way to do it. In the end I did something like b). I have a new 'display' bean that is composed of the main BeanA but has additional properties for the other 'odds'n'ends' it needs. I don't really have duplication in the getters and setters as onMissingMethod() nicely takes care of most of them. I do have delegate methods though in the display bean delegating to BeanA making the Iterator's loadQuery() work as normal. It's not fully OO but it does keep the controllers and views free of duplicated business logic and works ok for now. If in a few months time we go 'doh' we can dio more refactoring into a more complex a) solution with the Iterator populating several beans but possibly with only the data the View actually needs (it will keep the dba happy too:-) Alan ________________________________________ From: [email protected] [EMAIL PROTECTED] On Behalf Of Kevan Stannard [EMAIL PROTECTED] Sent: 08 July 2008 21:21 To: [email protected] Subject: [CFCDEV] Re: Iterators / IBO's Hi Alan This is a great question. (a) sounds like a good solution. Just thinking this one through - your BeanA would have functions like beanA.getBeanB() and beanA.getBeanC(), but then your BeanA needs to know how to get access to BeanB and BeanC all the time. You would also have a function like beanA.loadQuery(query,row) which would populate beanA as well as populate the composed BeanB and BeanC (they would perhaps also have corresponding loadQuery() functions and would take the same query as a parameter). Not sure if you should "recreate" or "repopulate" BeanB and BeanC each time though - probably depends on how complex your bean initialisation is. If your BeanA does not currently know how to get access to BeanB and BeanC then perhaps you could create some kind of decorator/wrapper around BeanA (a ComposedBeanA, for example) that has all of the functions of BeanA but adds the extra getBeanB(), getBeanC() and loadQuery() functions. For (b) you would want to avoid any duplicate code in the getters/setters of this new bean and the original beans. You might end up composing the original bean objects inside the new one anyway so it would perhaps end up looking like the ComposedBeanA object. Another option would be to just put the new function in its own separate calculator/helper component and just pass in the parameters it needs, then continue using the raw query data for the display. Not a very OO solution but will probably take only 10 mins to implement ... Kevan -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Livie Sent: Saturday, 5 July 2008 7:46 PM To: [email protected] Subject: [CFCDEV] Iterators / IBO's I'm an occasional user of iterators. I have a query that involved joins on several tables because data from those tables is needed inside the <cfoutput query in the View. Logic started creeping into the View as the query was looped. ie <cfoutput query="qGetXXX"> <cfif qGetXXX.thisBoolCol> <cfset valueToDisplay = qGetXXX.aNumericCol * qGetXXX.anotherNumericCol> <cfelse> <cfset valueToDisplay = qGetXXX.aNumericCol + 1 /> </cfif> </cfoutput> I want to use the Iterator so the logic is taken out the view but I get the performance benefit of query instead of bean array. My question is about the complexity of the bean and apologies if it isn't the best explanation I give! The data returned in the query is from several tables but only one or two columns may be used. I have simple beans for most of the tables involved in the joins. Should I a) Create a complex bean with associations to the other beans ie beanA has its own properties but is composed of a BeanB and BeanC even though I only need one property out of BeanB and 2 from BeanC. b) create a new bean specific to what the page / query is doing ie have a BeanD with properties of all the display data I need where I can still use getters to provide the encapsulation I need. My thinking is a) is a more elegant solution and more reusable but I need to do more work to build the bean in my bean factory and also bring more data out of the db and b) is quicker, leaner but I have little chance of reusing it elsewhere in the app. Any thoughts? Especially from users of Iterators / IBO's Alan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
