[cfaussie] Re: cfc - cfargument best practice
I'd take the Validator one step further and have it identify which specific fields are missing. That will have the added side effect of making it easier to report errors to the view layer. (And yes, this is how Spring does it. Check out the Validator interface in the javadocs. I'd link, but our external net access is down). Robin Hilliard wrote: > Hi Adam, > > I'd go with the bean or structure option - Dale has a valid point > about argument checking but the problem is that every time your > database columns change you're also going to have to modify the > signature of your function (and any other functions handling this > data) to match. > > Passing a structure will solve this. If validation is important build > it into your bean property setters or create a separate validator > class or function (i.e. a class with a validate(struct or bean) : > boolean method) you and then the validation logic you write can be > reused wherever you deal with data from this table, not just when you > call this specific function. > > If you want a name for this idea, it's called the "Value Object" or > "Data Transfer Object" design pattern - although as patterns go the > definition is starting to get a little muddy. > > Cheers, > Robin > > -- Haikal Saadh Applications Programmer ICT Resources, TALSS QUT Kelvin Grove --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: cfc - cfargument best practice
Hi Adam, I'd go with the bean or structure option - Dale has a valid point about argument checking but the problem is that every time your database columns change you're also going to have to modify the signature of your function (and any other functions handling this data) to match. Passing a structure will solve this. If validation is important build it into your bean property setters or create a separate validator class or function (i.e. a class with a validate(struct or bean) : boolean method) you and then the validation logic you write can be reused wherever you deal with data from this table, not just when you call this specific function. If you want a name for this idea, it's called the "Value Object" or "Data Transfer Object" design pattern - although as patterns go the definition is starting to get a little muddy. Cheers, Robin __ Robin Hilliard Director - RocketBoots Pty Ltd Consulting . Recruitment . Software Licensing . Training http://www.rocketboots.com.au For schedule/availability call Pamela Higgins: w+61 7 5451 0362 m+61 419 677 151 f+61 3 9923 6261 e[EMAIL PROTECTED] or Direct: m+61 418 414 341 e[EMAIL PROTECTED] On 29/05/2007, at 10:53 AM, Adam Chapman wrote: > > Hi All, > > I have the need to create a cfc method which will update a large > number > of db fields.. (50+). Here are 2 options I'm considering: > > 1. Accept an argument for each field > 2. Accept a single argument containing a structure with all the data > required for each field > > Thoughts? > > Cheers, > Adam > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: cfc - cfargument best practice
I chose to write this as a separate note because I know some don't read long notes. :-) I wanted to make sure in the brief note that people knew where I was going in this longer one. The other replies have been useful and may well be exactly what you sought, but your simple question of whether to accept a single argument or a struct of arguments also points to a syntax feature of CFML I wanted to make sure you (and others) are aware of. No offense intended if it was clear to you and you were really asking more about specific aspects related to creating DB update methods. The ArgumentCollection attribute is an oft-missed CFML feature that you can use when you call your method, which allows you to pass in multiple arguments as a single struct. It's mostly about simplifying the process of calling the method. You could also just hard code it yourself, and then break up the struct inside the function, but I just want to make sure you know that you'd not need to. Whether you call the method with CFINVOKE, or by calling it with dot-notation on a reference from a CFOBJECT or createObject call, you can pass in argumentcollection=somestrut, and that struct would be one you'd create which would hold all the same (required or default) arguments you would otherwise pass in individually. They will be mapped to their same-named CFARGUMENTs in the function, or would also all be accessible as array elements in the arguments scope. Hope that helps someone. /charlie Member, Adobe Community Experts program www.carehart.org -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Adam Chapman Sent: Monday, May 28, 2007 8:54 PM To: cfaussie@googlegroups.com Subject: [cfaussie] cfc - cfargument best practice Hi All, I have the need to create a cfc method which will update a large number of db fields.. (50+). Here are 2 options I'm considering: 1. Accept an argument for each field 2. Accept a single argument containing a structure with all the data required for each field Thoughts? Cheers, Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: cfc - cfargument best practice
Adam, it's not clear if from your question if you're aware of the ArgumentCollection attribute, which can help in such a situation. I'll share a couple thoughts in the next note in case it would help you or others facing that challenge. /charlie Member, Adobe Community Experts program www.carehart.org -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Adam Chapman Sent: Monday, May 28, 2007 8:54 PM To: cfaussie@googlegroups.com Subject: [cfaussie] cfc - cfargument best practice Hi All, I have the need to create a cfc method which will update a large number of db fields.. (50+). Here are 2 options I'm considering: 1. Accept an argument for each field 2. Accept a single argument containing a structure with all the data required for each field Thoughts? Cheers, Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: cfc - cfargument best practice
I will agree with Mike, a Bean with setters and getters for your object can be added to a collection of beans and you get your validation with the setter. And the beauty is that you can override you DAO object to then take the collection and iterate over the object. Andrew Scott Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 8676 4223 Mobile: 0404 998 273 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: cfc - cfargument best practice
In those circumstances I'd much prefer passing in a bean containing all the parameters. It's a lot tidier on the passing page - the .cfm page - and you know that the bean always has a value for every field. When you initiailise the bean it gives a default value to every single setter, even if the default value is "". Thats a lot like your question of whether or not to pass in a structure. I am working at present on a site where a lot of the cfc invocations are with each argument passed in separately, and it's tedious having to check that every time none of hte form variables or other parameters are missed. i'd much rather see something like than all teh variables spelled out as arguments.That way I know that if there was a field in the form, it'll find its way to the update method without my having to check it against the list of arguments being passed in. Cheers Mike Kear Windsor, NSW, Australia Adobe Certified Advanced ColdFusion Developer AFP Webworks http://afpwebworks.com ColdFusion, PHP, ASP, ASP.NET hosting from AUD$15/month On 5/29/07, Adam Chapman <[EMAIL PROTECTED]> wrote: > > Hi Dale, > > Thanks for the reply.. I think I must have been a bit vague with my > question, I already have the cfc set up using the DOA/Gateway model.. > > I guess I'm asking which of the 2 options for accepting a large amount > of data is prettier.. or whether there are pros and cons of either which > will make one more attractive than the other. > > Cheers, > Adam > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: cfc - cfargument best practice
In that case I like Option 1. As you get some validation when passing in fields with incorrect names etc. Where as if you define a struct and pass it in, the error is in execution rather than matching the function signature. Mind you, 50 columns is a lot and I wonder if your DB is structured correctly. Regards Dale Fraser http://dalefraser.blogspot.com -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Adam Chapman Sent: Tuesday, 29 May 2007 11:11 AM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: cfc - cfargument best practice Hi Dale, Thanks for the reply.. I think I must have been a bit vague with my question, I already have the cfc set up using the DOA/Gateway model.. I guess I'm asking which of the 2 options for accepting a large amount of data is prettier.. or whether there are pros and cons of either which will make one more attractive than the other. Cheers, Adam -Original Message- From: Dale Fraser [mailto:[EMAIL PROTECTED] Sent: Tuesday, 29 May 2007 11:01 AM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: cfc - cfargument best practice I think it depends on the cfc and it's purpose. You could write one generic class, lets say called Database.cfc Which could have methods such as select, update, insert etc. Then they could take paramaters such as you described in 2. This class is then generic and can be smart enough to update any table. If however you have a class called say Product.cfc And it deals only with products and it has an update method, then I would suggest option 1, as then the method constrains the required fields and can have intelligence. If you are really keen you could have Product.cfc extend Database.cfc Regards Dale Fraser http://dalefraser.blogspot.com -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Adam Chapman Sent: Tuesday, 29 May 2007 10:54 AM To: cfaussie@googlegroups.com Subject: [cfaussie] cfc - cfargument best practice Hi All, I have the need to create a cfc method which will update a large number of db fields.. (50+). Here are 2 options I'm considering: 1. Accept an argument for each field 2. Accept a single argument containing a structure with all the data required for each field Thoughts? Cheers, Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: cfc - cfargument best practice
Hi Dale, Thanks for the reply.. I think I must have been a bit vague with my question, I already have the cfc set up using the DOA/Gateway model.. I guess I'm asking which of the 2 options for accepting a large amount of data is prettier.. or whether there are pros and cons of either which will make one more attractive than the other. Cheers, Adam -Original Message- From: Dale Fraser [mailto:[EMAIL PROTECTED] Sent: Tuesday, 29 May 2007 11:01 AM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: cfc - cfargument best practice I think it depends on the cfc and it's purpose. You could write one generic class, lets say called Database.cfc Which could have methods such as select, update, insert etc. Then they could take paramaters such as you described in 2. This class is then generic and can be smart enough to update any table. If however you have a class called say Product.cfc And it deals only with products and it has an update method, then I would suggest option 1, as then the method constrains the required fields and can have intelligence. If you are really keen you could have Product.cfc extend Database.cfc Regards Dale Fraser http://dalefraser.blogspot.com -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Adam Chapman Sent: Tuesday, 29 May 2007 10:54 AM To: cfaussie@googlegroups.com Subject: [cfaussie] cfc - cfargument best practice Hi All, I have the need to create a cfc method which will update a large number of db fields.. (50+). Here are 2 options I'm considering: 1. Accept an argument for each field 2. Accept a single argument containing a structure with all the data required for each field Thoughts? Cheers, Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: cfc - cfargument best practice
I think it depends on the cfc and it's purpose. You could write one generic class, lets say called Database.cfc Which could have methods such as select, update, insert etc. Then they could take paramaters such as you described in 2. This class is then generic and can be smart enough to update any table. If however you have a class called say Product.cfc And it deals only with products and it has an update method, then I would suggest option 1, as then the method constrains the required fields and can have intelligence. If you are really keen you could have Product.cfc extend Database.cfc Regards Dale Fraser http://dalefraser.blogspot.com -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Adam Chapman Sent: Tuesday, 29 May 2007 10:54 AM To: cfaussie@googlegroups.com Subject: [cfaussie] cfc - cfargument best practice Hi All, I have the need to create a cfc method which will update a large number of db fields.. (50+). Here are 2 options I'm considering: 1. Accept an argument for each field 2. Accept a single argument containing a structure with all the data required for each field Thoughts? Cheers, Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
