0

I am trying to implement a view that contains many elements, whose state change depending on the actions you perform on it. I guess this is something that people often run into so I would like to know what approach works best for you.

What I usually do is define several states for my view: {Loaded,Initialized,...} and then set the state of each element for that state. The thing is even the most trivial event,a click on a button for example, makes the state change, so I need a lot of different states, with many of them containing duplicate information since they are very similar to each other. This seems very repetitive and unefficient but has worked for me up until now, when I need a better way of doing this kind of stuff.

This issue must have been around for quite a while, so it would be nice to know people's tricks & tips, best-practices, and documents of reference.

Fran Sevillano
  • 1,559

1 Answers1

1

To be honest, I am a bit baffled by your question. I have now read it several times and this just doesn't make any sense. If you work in a proper MVC environment, then your view shouldn't need to keep track of state. The view simply displays the data and the state held in the model. It receives events and dispatches them to the controller or directly to the model components (depending on how strict your MVC implementation is).

If the click of a button changes the state of an underlying model, then that model will raise another event, which can lead to a modification of the view through an event handler.

But maybe I am totally off the track here. Could you explain this in a little more detail?

wolfgangsz
  • 5,373
  • 1
  • 22
  • 24
  • Yeah, but there are elements that are not model-dependant, like other buttons or menu items that need to be activated/deactivated. How do I go about these? – Fran Sevillano Jun 17 '11 at 11:14
  • 'If you work in a proper MVC environment (...)' - That is a rather daring assumption, isn't it? ;-) – Treb Jun 17 '11 at 11:30
  • @Francisco: menu items should be generated on the fly by an event handler provided by the relevant model component, which can decide on which menu items are displayed or grayed out, etc. Same goes for other other buttons. – wolfgangsz Jun 17 '11 at 11:45
  • @Treb: Well, clearly the OP is hitting the boundaries of what can be done outside MVC, otherwise he wouldn't be asking this question. – wolfgangsz Jun 17 '11 at 11:47
  • In this particular case is pretty difficult to rely on the model. It's some kind of recording audio view with some controls that need to be activated/deactivated or changed depending on the recording state. I don't see how the data model fits in there. I do look at the model in other views to manage the content but in this particular case it seems hard to me. I think that what I was thinking about was a better way to manage changes in the view when the different events occur. Thanks for the responses though! – Fran Sevillano Jun 17 '11 at 15:26
  • Ahh, I suspect that your problem then is that you haven't abstracted the recorder into a model, and your application is the recorder? – wolfgangsz Jun 17 '11 at 15:28
  • Yeah, that might be the problem. I currently have lots of element.enabled = true, element.enabled = false spread across the code, which makes it very hard to maintain. – Fran Sevillano Jun 17 '11 at 15:32
  • I think you should start thinking along the lines that the application as such is simply what allows the user to interact with the machinery, similar to a cockpit in an aeroplane. The various controls in the cockpit are not the things that they represent, they are just controls. It then would become clear that your recorder needs to be a model, with its own state, and because of the highly complicated state machinery in this case, you would definitely also want to look at having a dedicated controller for the recorder. – wolfgangsz Jun 17 '11 at 15:42