Another way to look at the problem is to analyze if the literal values of "A", "B", "P" and "I" have meaning internally within your object model. That is, are you going to store the literal value somewhere? Because if not, then those characters or values are just part of how you are presenting your interface and have no business being inside your object model. In that case I would go for the second option because it isolates something specific to the presentation layer (the actual string values chosen for the form control) from the object model. This way it will be responsibility of whoever is sitting between your presentation layer and your object model (controller, event handler, etc) to translate between both parties.
On Tue, Sep 2, 2008 at 2:44 PM, Brian Kotek <[EMAIL PROTECTED]> wrote: > You can also look at some design patterns for guidance. Something like the > State pattern may be of use here. I wrote an article about it a while back > that you can see at > http://articles.techrepublic.com.com/5100-10878_11-6167539.html > > > > > On Tue, Sep 2, 2008 at 2:07 PM, Ronan Lucio <[EMAIL PROTECTED]> wrote: > >> Hi All, >> >> In the company I work we have an application where each client (record) >> can assume different status: active, inactive, blocked or partial blocked. >> >> The client form for record updates has a combo box where the user can >> select the client's status: >> >> <select name="status" id="status"> >> <option value="A">Active</option> >> <option value="B">Blocked</option> >> <option value="P">Partial Blocked</option> >> <option value="I">Inactive</option> >> </select> >> >> >> OO thinking take me to the "Tell, don't ask" philosophy. >> So how do I need to for every setStatus() operation? >> >> Option 1: Set by code >> ====== >> >> client.setStatus( form.status ); >> >> >> Option 2: Special sets >> ====== >> >> if ( form.status == 'A' ) { >> client.activate(); >> } else if ( form.status == 'B' ) { >> client.block(); >> } else if ( form.status == 'P' ) { >> client.partialBlock(); >> } else if ( form.status == 'I' ) { >> client.deactivate(); >> } >> >> >> The problem in the second approach is the it still have to keep some >> business logic and, it still needs to know the status codes. >> >> Using the first approach it still gives me the possibility to encapsulate >> the business logic inside it's set(): >> >> function setStatus( status ) { >> >> if ( arguments.status == 'A' ) { >> client.activate(); >> } else if ( arguments.status == 'B' ) { >> client.block(); >> } else if ( arguments.status == 'P' ) { >> client.partialBlock(); >> } else if ( arguments.status == 'I' ) { >> client.deactivate(); >> } >> >> } >> } >> >> >> Any help would be appreciated, >> Ronan >> >> >> > > > > -- Oscar Arevalo http://www.oscararevalo.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
