views:

56

answers:

1

Would it be considered bad practice to use a widgets title attribute to refer it?

For example I have a number of custom radioBoxCtrls on a panel I only ever need to get/set all the values at once so the container class(a panel) for the radioBoxCtrls objects has the following methods

get_options()
set_options()

To set options for all the radioBoxCtrls a dictionary is passed to the set_options() method. Each key, value pair in the dictionary is a title of a radioBoxCtrl and the title of the button on the radioBoxCtrl that should be set

  def set_options(self, options={}):
        """
        This method sets which radio button is selected 
        on each RadioBoxCtrl object
        @param options: A dictionary  
                        Each key is the title of a RadioBoxCtrl 
                        each keys value is the button on the radio box that is to be selected
        """
        for option_box in self.option_boxes:
            if option_box.title in options.keys()
                option_box.set_selected_button(options[option_box.title])

    def get_options(self):
        """
        This method returns a dictionary of the selected options 
        Each key is the title of a RadioBoxCtrl object
        and each keys value is the name of the button selected on the radio box
        """
        options = defaultdict(list)
        for option_box in self.option_boxes:
            options[option_box.title]=option_box.get_selected_btn()
        return options

So (in an attempt to be clear) when I call the set method from my controller I pass in a dictionary like so:

options = {"Name of radioBoxCtrl": "Option 2", ... }
self.gui.optionsPanel.set_options(options)

Why the hell do you want do that? (you may ask)

Short answer: mvc

I want to create a suitable layer of abstraction. All that my controller needs to know with regard to the options is how to get them to pass to the model when some processing needs to be done and how set them when a config file is loaded...

I thought it would simplify things if I could just call one method to set and vice-versa -but Im not so sure now!


I realize that this is probably more of question on the acceptability of refering to objects by some string attribute they posses, which in my case just happens to be the title.. so feel free to answer it accordingly..

Please feel free to improve the title of question(I wasnt really sure how to word it) and add tags.

Thanks

+2  A: 

I can't tell whether the gurus would call it bad practive. I just know I'd never do it - it is slower, more error-prone, possibly makes it very hard to change a title's name (admittedly, only if you hardcode it everywhere) and (arguably) very inelegant. At least you should associate te options with the widget's identity, which still smells imho, but at least has a few problems less. Maybe that whole part of the application should be refactored to be less centralized so the issue disappears completely.

Edit on how to refactor: Honestly, I can't tell - I know little about the application. The obvious approach would be subclassing all widgets and making them responsible for somehow getting the options and changing accordingly. But I can't tell whether that's really feasible.

delnan
So if were to refactor... what approach would you take -could you maybe give an example, Thanks
volting
What I want do is to provide an abstract interface for the controller -all the controller needs to know is some methods to get the options when model has to do some processing and set the options when a configuration profile is loaded. I think (unless someone has a better idea)I will just stick with what is probably normal approach, just call the setter/getter method of the widget object (in case the radioBox), Thanks
volting
I think your idea of making the widgets responsible for getting the options would violate the rules of mvc which Im trying to follow so I dont think that approach is not an option. Thanks
volting