Simple design question

Jamie_McQuay · January 9, 2009, 1:52pm

I’m designing an application using wxpython and i have a basic question about a design choice.

When populating a dialog, which is the more preferred design choice:

1.) Pass the data model to the UI code to populate the dialog and update the model on OK

or

2.) Provide get/set accessors to all the components on the dialog and let the controller configure it.

not a wxpython specific question but i thought i’d start here for feedback.

Thanks,

Jamie

···


Jamie McQuay

Scimatic Software Inc.

[www.scimatic.com](http://www.scimatic.com/) 

****We build software for scientists.****

</details>

Kevin_Ollivier2 · January 9, 2009, 4:50pm

Hi Jamie,

I’m designing an application using wxpython and i have a basic question about a design choice.

When populating a dialog, which is the more preferred design choice:

1.) Pass the data model to the UI code to populate the dialog and update the model on OK

or

2.) Provide get/set accessors to all the components on the dialog and let the controller configure it.

not a wxpython specific question but i thought i’d start here for feedback.

While it’s not particularly a huge issue in this case, and while most wx code I see tends to do #1, you’re better off going with #2 to get in the habit of using MVC, IMHO. Once you move your data into a custom dialog, you can only use that dialog with that data. While that may be the intention right now, as your code grows and expands, it’s not uncommon to want to reuse UI code in numerous places, and it’s much easier if you just design it to be reusable from the start. At least IMHO

Regards,

Kevin

···

On Jan 9, 2009, at 5:52 AM, Jamie McQuay wrote:

Thanks,

Jamie

Jamie McQuay

Scimatic Software Inc.

www.scimatic.com

We build software for scientists.

wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Jamie_McQuay · January 9, 2009, 4:57pm

Thanks Kevin,
You point makes sense... by using method #2 i would have a more generic dialog.

Thanks,

Jamie

···

On 9-Jan-09, at 11:50 AM, Kevin Ollivier wrote:

Hi Jamie,

On Jan 9, 2009, at 5:52 AM, Jamie McQuay wrote:

I'm designing an application using wxpython and i have a basic question about a design choice.

When populating a dialog, which is the more preferred design choice:
1.) Pass the data model to the UI code to populate the dialog and update the model on OK
or
2.) Provide get/set accessors to all the components on the dialog and let the controller configure it.

not a wxpython specific question but i thought i'd start here for feedback.

While it's not particularly a huge issue in this case, and while most wx code I see tends to do #1, you're better off going with #2 to get in the habit of using MVC, IMHO. Once you move your data into a custom dialog, you can only use that dialog with that data. While that may be the intention right now, as your code grows and expands, it's not uncommon to want to reuse UI code in numerous places, and it's much easier if you just design it to be reusable from the start. At least IMHO

Chris_Barker1 · January 9, 2009, 5:39pm

Kevin Ollivier wrote:

code I see tends to do #1, you're better off going with #2 to get in the habit of using MVC, IMHO. Once you move your data into a custom dialog, you can only use that dialog with that data. While that may be the intention right now, as your code grows and expands, it's not uncommon to want to reuse UI code in numerous places, and it's much easier if you just design it to be reusable from the start. At least IMHO

hmmm -- I wonder---

no matter what you do, you need to define an API of some sort.

Option #1 defines the API for the Dialog as a given Data Object being passed in. If you want to use the dialog with some other model, it will need to pass in that Data object -- but, thanks to duck typing, all it needs to do is pass in a data object that behaves in the same way.

Option #2 defines the API of the dialog as a set of getters and setters (though I'd probably use properties..). In order to use that Dialog with another model, you need the new model to call all the same getters and setters -- is that really any easier?

Another point -- I think it's far more likely that you'll want to use the same model with a different View than vice-versa anyway -- though maybe that's just my use-cases.

I think Option #1 involves less code, so that gives it an edge -- but maybe not.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Kevin_Ollivier2 · January 9, 2009, 8:37pm

Hi Chris,

Kevin Ollivier wrote:

code I see tends to do #1, you're better off going with #2 to get in the habit of using MVC, IMHO. Once you move your data into a custom dialog, you can only use that dialog with that data. While that may be the intention right now, as your code grows and expands, it's not uncommon to want to reuse UI code in numerous places, and it's much easier if you just design it to be reusable from the start. At least IMHO

hmmm -- I wonder---

no matter what you do, you need to define an API of some sort.

Option #1 defines the API for the Dialog as a given Data Object being passed in. If you want to use the dialog with some other model, it will need to pass in that Data object -- but, thanks to duck typing, all it needs to do is pass in a data object that behaves in the same way.

Yes, but that's true of #2 too.

Option #2 defines the API of the dialog as a set of getters and setters (though I'd probably use properties..). In order to use that Dialog with another model, you need the new model to call all the same getters and setters -- is that really any easier?

Easier? Not really. The easiest route is to just stuff everything into the constructor for the dialog subclass, which is why that approach tends to be popular. I'm more arguing what is the most robust approach.

Another point -- I think it's far more likely that you'll want to use the same model with a different View than vice-versa anyway -- though maybe that's just my use-cases.

Which is actually a pretty good reason not to design your model's API around what a particular view needs, don't you think?

Here's the thing. If you design your data model to simply provide any data it has to any client, and you design your view to simply display whatever data is given, then you don't have to refactor when you need a new view for your data. You just write a new controller.

I think Option #1 involves less code, so that gives it an edge -- but maybe not.

When we're speaking in hypotheticals, it's hard to know for sure. I doubt it would be a significant amount of extra code though, as we're largely talking about where we put the code to load the view's contents and perhaps record any changes to it.

In any case, I personally stopped caring about writing the least amount of code possible a long time ago - most programmers can type a line of code pretty fast, and can read reasonably fast as well, so I don't really think that's a major performance bottleneck when writing an app. I think it's far more important that my code is easily readable, straightforward, and resilient to change, rather than concise or elegant. To that end, for the most part I've found that decoupling usually brings benefits, especially when done from the start.

For example, I actually wrote a lot of code taking the approach of #1 up until probably a couple years ago, and I found that it encourages some bad habits regarding tying model and view, which led to some pretty nasty bugs, and also made writing isolated tests / bug reductions difficult because often my view would need a "fake" data object just so I could test that it loads/runs, and sometimes that data object would contain pointers to other objects, which would also need to be faked, etc. This then discourages one from doing test-driven development because it's more work to setup such tests and setting up a fake environment looks pretty hacky/ugly, and so you just say screw it and do "manual testing", e.g. run real world tests, which tends to stress common cases and ignore corner cases, and also are limited by how many testers you have and how much time you/they can spend testing. Not to mention it's almost impossible to keep track of what exactly was and was not tested.

Also, by keeping the view truly separate, I could also make the code reusable for any wxPython user, which could help others and maybe get some good bug reports, whereas if my app's data model is tied into the core of the class, that wouldn't be possible without refactoring or again requiring every app to create some special data model to use the class. Easiest and best aren't often the same, and in fact, I'd say are often in conflict with one another. As with lots of things in life, you can either do the hard work up front, or put it off until later when it will be twice as hard. (e.g. my refactoring of my first major Python app) In my experience, not doing the hard work has rarely ever been an option unless you're writing some quick, one-off or throwaway code.

Regards,

Kevin

···

On Jan 9, 2009, at 9:39 AM, Christopher Barker wrote:

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Jamie_McQuay · January 9, 2009, 8:49pm

Thanks for the replies Kevin & Chris.

I’ve decided to go with my second option (i.e. the dialog will not know anything about the model). The testing issue that Kevin made (faking a data model inorder to test) was the main deciding factor for me.

Thanks again for the great information.

Jamie

···

On 9-Jan-09, at 3:37 PM, Kevin Ollivier wrote:

Hi Chris,

On Jan 9, 2009, at 9:39 AM, Christopher Barker wrote:

Kevin Ollivier wrote:

code I see tends to do #1, you’re better off going with #2 to get in the habit of using MVC, IMHO. Once you move your data into a custom dialog, you can only use that dialog with that data. While that may be the intention right now, as your code grows and expands, it’s not uncommon to want to reuse UI code in numerous places, and it’s much easier if you just design it to be reusable from the start. At least IMHO

hmmm – I wonder—

no matter what you do, you need to define an API of some sort.

Option #1 defines the API for the Dialog as a given Data Object being passed in. If you want to use the dialog with some other model, it will need to pass in that Data object – but, thanks to duck typing, all it needs to do is pass in a data object that behaves in the same way.

Yes, but that’s true of #2 too.

Option #2 defines the API of the dialog as a set of getters and setters (though I’d probably use properties…). In order to use that Dialog with another model, you need the new model to call all the same getters and setters – is that really any easier?

Easier? Not really. The easiest route is to just stuff everything into the constructor for the dialog subclass, which is why that approach tends to be popular. I’m more arguing what is the most robust approach.

Another point – I think it’s far more likely that you’ll want to use the same model with a different View than vice-versa anyway – though maybe that’s just my use-cases.

Which is actually a pretty good reason not to design your model’s API around what a particular view needs, don’t you think?

Here’s the thing. If you design your data model to simply provide any data it has to any client, and you design your view to simply display whatever data is given, then you don’t have to refactor when you need a new view for your data. You just write a new controller.

I think Option #1 involves less code, so that gives it an edge – but maybe not.

When we’re speaking in hypotheticals, it’s hard to know for sure. I doubt it would be a significant amount of extra code though, as we’re largely talking about where we put the code to load the view’s contents and perhaps record any changes to it.

In any case, I personally stopped caring about writing the least amount of code possible a long time ago - most programmers can type a line of code pretty fast, and can read reasonably fast as well, so I don’t really think that’s a major performance bottleneck when writing an app. I think it’s far more important that my code is easily readable, straightforward, and resilient to change, rather than concise or elegant. To that end, for the most part I’ve found that decoupling usually brings benefits, especially when done from the start.

For example, I actually wrote a lot of code taking the approach of #1 up until probably a couple years ago, and I found that it encourages some bad habits regarding tying model and view, which led to some pretty nasty bugs, and also made writing isolated tests / bug reductions difficult because often my view would need a “fake” data object just so I could test that it loads/runs, and sometimes that data object would contain pointers to other objects, which would also need to be faked, etc. This then discourages one from doing test-driven development because it’s more work to setup such tests and setting up a fake environment looks pretty hacky/ugly, and so you just say screw it and do “manual testing”, e.g. run real world tests, which tends to stress common cases and ignore corner cases, and also are limited by how many testers you have and how much time you/they can spend testing. Not to mention it’s almost impossible to keep track of what exactly was and was not tested.

Also, by keeping the view truly separate, I could also make the code reusable for any wxPython user, which could help others and maybe get some good bug reports, whereas if my app’s data model is tied into the core of the class, that wouldn’t be possible without refactoring or again requiring every app to create some special data model to use the class. Easiest and best aren’t often the same, and in fact, I’d say are often in conflict with one another. As with lots of things in life, you can either do the hard work up front, or put it off until later when it will be twice as hard. (e.g. my refactoring of my first major Python app) In my experience, not doing the hard work has rarely ever been an option unless you’re writing some quick, one-off or throwaway code.

Regards,

Kevin

Chris_Barker1 · January 9, 2009, 9:37pm

Kevin Ollivier wrote:

Easier? Not really. The easiest route is to just stuff everything into the constructor for the dialog subclass, which is why that approach tends to be popular. I'm more arguing what is the most robust approach.

When I said "easier", I meant easier to adapt a new model to the given dialog, which translates to robust and de-coupled.

Which is actually a pretty good reason not to design your model's API around what a particular view needs, don't you think?

I think there is a bit of a communication gap here. When I was writing about passing a "Data Object" in , I DID NOT mean a referenced to the whole dang model! What I mean is some sort of simple data object (maybe as simple as a dict) that contains the data required. If this object is clearly defined, then the API and the coupling are clearly defined, and no, the Dialog does not and should not know anything about the model other than what data is provides/needs.

Here's the thing. If you design your data model to simply provide any data it has to any client, and you design your view to simply display whatever data is given,

But how is that data given -- it seem here we have the trade-off between it being given as a self-contained, well-defined object, and a bunch of Setters and Getters -- is that really better?

then you don't have to refactor when you need a new view for your data. You just write a new controller.

Which has to know all about which getters and setters to call. Is that better than having a controller that constructs an appropriate data object?

In any case, I personally stopped caring about writing the least amount of code possible a long time ago

I agree there -- but if all else is the same, then less code is fewer bugs (not counting test code!) -- but all else needs to be the same!

I'm in a struggle to really "get" MVC (or MVP, or...). When I rad about it it sounds so clean an logical, but when I actual need to implement something, complications always arise right away -- and it's not obvious where to put stuff.

I'm still looking for an example that is simple enough to grasp quickly, but complex enough to demonstrate something meaningful.

Hmmm - maybe I"ll try to write one for the wxPython wiki....

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

driscollis · January 9, 2009, 10:02pm

Chris,

In any case, I personally stopped caring about writing the least amount of code possible a long time ago

I agree there -- but if all else is the same, then less code is fewer bugs (not counting test code!) -- but all else needs to be the same!

I'm in a struggle to really "get" MVC (or MVP, or...). When I rad about it it sounds so clean an logical, but when I actual need to implement something, complications always arise right away -- and it's not obvious where to put stuff.

I'm still looking for an example that is simple enough to grasp quickly, but complex enough to demonstrate something meaningful.

Hmmm - maybe I"ll try to write one for the wxPython wiki....

-Chris

I don't "get" it either, which is why I don't usually use the whole MVC paradigm. But I'd like to learn it, so I suppose I should make something in TurboGears and then try to copy their ideas in wxPython. Then I could post it here for you guys to pick apart until we get a good example...or you could do something like that!

Mike

Nitro · January 9, 2009, 10:10pm

I think Option #2 has another benefit. Option #1 is basically viewer + controller in a single UI class. Now if you decouple the viewer from the controller you get some advantages. For example you can have some kind of security-relevant data. Now you have two controller classes, one which displays data to an anonymous user and one to an admin user. The controller would use the properties/accessors defined in Option #2 to show only those parts of the data that the user has access to and leaves all other fields empty. It could also control whether the user is allowed to change things in the model by entering some data into a text control for instance. If you want to do the same thing with Option #1 you end up with lots of if-clauses checking user rights etc, before displaying anything. That's not nice code imo, so Option #1 seems to make more sense to me.
Ideally wxPython would provide a standard way to feed the controls with data (I think there was a gsoc project related to it this year which was cancelled). Then you could write adapters for your model and pass the adapted models into the wx controls directly. That's a different thing though...

-Matthias

···

Am 09.01.2009, 18:39 Uhr, schrieb Christopher Barker <Chris.Barker@noaa.gov>:

Kevin Ollivier wrote:

code I see tends to do #1, you're better off going with #2 to get in the habit of using MVC, IMHO. Once you move your data into a custom dialog, you can only use that dialog with that data. While that may be the intention right now, as your code grows and expands, it's not uncommon to want to reuse UI code in numerous places, and it's much easier if you just design it to be reusable from the start. At least IMHO

hmmm -- I wonder---

no matter what you do, you need to define an API of some sort.

Option #1 defines the API for the Dialog as a given Data Object being passed in. If you want to use the dialog with some other model, it will need to pass in that Data object -- but, thanks to duck typing, all it needs to do is pass in a data object that behaves in the same way.

Option #2 defines the API of the dialog as a set of getters and setters (though I'd probably use properties..). In order to use that Dialog with another model, you need the new model to call all the same getters and setters -- is that really any easier?

Nitro · January 9, 2009, 10:14pm

Ooops, it should read "Option #2 seems to make more sense to me".

-Matthias

···

Am 09.01.2009, 23:10 Uhr, schrieb Nitro <nitro@dr-code.org>:

Am 09.01.2009, 18:39 Uhr, schrieb Christopher Barker > <Chris.Barker@noaa.gov>:

Kevin Ollivier wrote:

code I see tends to do #1, you're better off going with #2 to get in the habit of using MVC, IMHO. Once you move your data into a custom dialog, you can only use that dialog with that data. While that may be the intention right now, as your code grows and expands, it's not uncommon to want to reuse UI code in numerous places, and it's much easier if you just design it to be reusable from the start. At least IMHO

hmmm -- I wonder---

no matter what you do, you need to define an API of some sort.

Option #1 defines the API for the Dialog as a given Data Object being passed in. If you want to use the dialog with some other model, it will need to pass in that Data object -- but, thanks to duck typing, all it needs to do is pass in a data object that behaves in the same way.

Option #2 defines the API of the dialog as a set of getters and setters (though I'd probably use properties..). In order to use that Dialog with another model, you need the new model to call all the same getters and setters -- is that really any easier?

I think Option #2 has another benefit. Option #1 is basically viewer + controller in a single UI class. Now if you decouple the viewer from the controller you get some advantages. For example you can have some kind of security-relevant data. Now you have two controller classes, one which displays data to an anonymous user and one to an admin user. The controller would use the properties/accessors defined in Option #2 to show only those parts of the data that the user has access to and leaves all other fields empty. It could also control whether the user is allowed to change things in the model by entering some data into a text control for instance. If you want to do the same thing with Option #1 you end up with lots of if-clauses checking user rights etc, before displaying anything. That's not nice code imo, so Option #1 seems to make more sense to me.

Chris_Barker1 · January 9, 2009, 10:21pm

Mike Driscoll wrote:

I don't "get" it either, which is why I don't usually use the whole MVC paradigm. But I'd like to learn it, so I suppose I should make something in TurboGears and then try to copy their ideas in wxPython.

Do you think TG does it well?

I've been working on a Pylons app, and while they use the terms "model" and "controller", I"m not at all sure that it's de-coupled!

But what you propose is a good idea -- if it's all done right, one should be able to write a model and use that exact some model in a wxPython gui app and a TG (or Pylons, or ...) web app.

While we're at it, we should be able to so multiple models, too -- like maybe a SQLite based one and a simple flat file or pickle-based one.

I propose something like a simple address book app, perhaps.

but when can I find the time to work on it???

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

driscollis · January 9, 2009, 10:26pm

Hi Chris,

Mike Driscoll wrote:

I don't "get" it either, which is why I don't usually use the whole MVC paradigm. But I'd like to learn it, so I suppose I should make something in TurboGears and then try to copy their ideas in wxPython.

Do you think TG does it well?

I've been working on a Pylons app, and while they use the terms "model" and "controller", I"m not at all sure that it's de-coupled!

But what you propose is a good idea -- if it's all done right, one should be able to write a model and use that exact some model in a wxPython gui app and a TG (or Pylons, or ...) web app.

While we're at it, we should be able to so multiple models, too -- like maybe a SQLite based one and a simple flat file or pickle-based one.

I propose something like a simple address book app, perhaps.

but when can I find the time to work on it???

-Chris

I already have a mostly working simple address book-like app that I plan on improving tonight or over the weekend. It's to be used in a tutorial on sqlalchemy and wxPython that I've left on the back burner for a couple of months. Once I've got the editing and deleting parts done, I can post it and we can look at decoupling it or re-writing it from scratch...the SA stuff is mostly decoupled already, so I don't think it'll be a big deal to finish that up.

Mike

Chris_Barker1 · January 9, 2009, 10:29pm

Nitro wrote:

I think Option #2 has another benefit. Option #1 is basically viewer + controller in a single UI class.

Ah, yes - that's a good way to think of it.

Frankly, I'm still confused about the controller -- it's what ties the model and view together. However, it seems that that means that you need a different controller for each model-view pair, in which case, why NOT tie the controller to the view?

Now if you decouple the viewer from the controller you get some advantages. For example you can have some kind of security-relevant data. Now you have two controller classes, one which displays data to an anonymous user and one to an admin user.

But is this better than having two view classes -- one for anonymous, and one for admin? Indeed, it may be harder, to support two controllers and one view, the view needs to support being able to do either, anyway -- i.e. be dynamic, for instance not showing a given text field, or showing it and not having it be editable.

I really do need to get an example together -- it's hard to nail this down in the abstract.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Nitro · January 9, 2009, 10:49pm

Nitro wrote:

I think Option #2 has another benefit. Option #1 is basically viewer + controller in a single UI class.

Ah, yes - that's a good way to think of it.

Frankly, I'm still confused about the controller -- it's what ties the model and view together. However, it seems that that means that you need a different controller for each model-view pair, in which case, why NOT tie the controller to the view?

Yes, you need one controller for each model-view pair. I wouldn't want to tie it because you cannot use the same view and model with a different controller anymore. The point is you can have multiple controllers for the same model-view pair.
You could also say "I can tie all my code into a single class, why use MVC at all". Of course it's not a must, but separating things often makes them easier to read and easier to switch.

Now if you decouple the viewer from the controller you get some advantages. For example you can have some kind of security-relevant data. Now you have two controller classes, one which displays data to an anonymous user and one to an admin user.

But is this better than having two view classes -- one for anonymous, and one for admin? Indeed, it may be harder, to support two controllers and one view, the view needs to support being able to do either, anyway -- i.e. be dynamic, for instance not showing a given text field, or showing it and not having it be editable.

Maybe my example was a bad one, I am not sure if you'd put stuff like user access rights checking into a controller or the model itself.

Here's a different one. You have a view which displays information about a book and a data model with books. Now you write a controller which just reads the model data and sets it to the view via the view's accessors. So you'll end up with a view which shows data about your book.
Then the boss of a bookstore comes to you and tells you he's mostly interested in cheap books. So you go write another controller which does the same as the one before, but tells the view to draw its "price" box in red if the price of the book is below 10$. Now you can write a third controller which converts the price from dollars (in the data model) to pounds before displaying it. The same controller will also convert the price entered in pounds on the view to dollar before storing it in the model.
So in the end you wrote one model, three controllers and reused the same view class. And you separated the view from the other logic (just displaying, highlighting fields when certain conditions are met, currency conversion).

To me MVC is also a bit vague, especially the controller part. Separating view and model is quite clear, but the controller part escapes me quite often in common, concrete situations.

I really do need to get an example together -- it's hard to nail this down in the abstract.

Yes, abstract discussions like this tend to be void if not used with concrete examples.

-Matthias

···

Am 09.01.2009, 23:29 Uhr, schrieb Christopher Barker <Chris.Barker@noaa.gov>:

Kevin_Ollivier2 · January 9, 2009, 11:55pm

Hi Chris,

Kevin Ollivier wrote:

Easier? Not really. The easiest route is to just stuff everything into the constructor for the dialog subclass, which is why that approach tends to be popular. I'm more arguing what is the most robust approach.

When I said "easier", I meant easier to adapt a new model to the given dialog, which translates to robust and de-coupled.

Which is actually a pretty good reason not to design your model's API around what a particular view needs, don't you think?

I think there is a bit of a communication gap here. When I was writing about passing a "Data Object" in , I DID NOT mean a referenced to the whole dang model! What I mean is some sort of simple data object (maybe as simple as a dict) that contains the data required. If this object is clearly defined, then the API and the coupling are clearly defined, and no, the Dialog does not and should not know anything about the model other than what data is provides/needs.

Here's the thing. If you design your data model to simply provide any data it has to any client, and you design your view to simply display whatever data is given,

But how is that data given -- it seem here we have the trade-off between it being given as a self-contained, well-defined object, and a bunch of Setters and Getters -- is that really better?

then you don't have to refactor when you need a new view for your data. You just write a new controller.

Which has to know all about which getters and setters to call. Is that better than having a controller that constructs an appropriate data object?

In any case, I personally stopped caring about writing the least amount of code possible a long time ago

I agree there -- but if all else is the same, then less code is fewer bugs (not counting test code!) -- but all else needs to be the same!

I'm in a struggle to really "get" MVC (or MVP, or...). When I rad about it it sounds so clean an logical, but when I actual need to implement something, complications always arise right away -- and it's not obvious where to put stuff.

TBH, I do think the discussion is getting pretty confusing. This discussion of Getters and Setters vs "data objects" is highly abstract to me and I'm not even really sure I see what you're getting at. I don't know what the problem is with using Getters/Setters, or properties in Python, and I don't know what your concept of a data object is, but it sounds to me like what you're proposing is to add a middle man between the view and its properties. So when the view wants one of its own properties (e.g. a text field's value, or setup) loaded, set, or updated, it must interact with this data object to do so.

I think it may become clearer to us both if you worked up a code sample to give an idea of what you're proposing. To paraphrase, example code is worth a thousand words.

I'm still looking for an example that is simple enough to grasp quickly, but complex enough to demonstrate something meaningful.

Hmmm - maybe I"ll try to write one for the wxPython wiki....

yeah, what would be ideal is if we came up with some code, maybe even a chunk from a real app, that we could go explore and discuss. I don't mind coming up with a code example for MVC in general, but at the same time, I don't know what kind of example would cross that line between too simple and something meaningful.

Regards,

Kevin

···

On Jan 9, 2009, at 1:37 PM, Christopher Barker wrote:

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

driscollis · January 10, 2009, 4:20am

Christopher Barker wrote:

Mike Driscoll wrote:

I don't "get" it either, which is why I don't usually use the whole MVC paradigm. But I'd like to learn it, so I suppose I should make something in TurboGears and then try to copy their ideas in wxPython.

Do you think TG does it well?

I forgot to answer this...When I used TG 1.x last year, I thought it did a job of the MVC paradigm...at least, the book or docs or whatever it was explained it quite well. Unfortunately, I have yet to figure out how to actually do it in anything other than book examples...come to think of it, I have yet to figure out how to do TDD either.

Anyway, as I said in my other email, I'll try to get that code put together so I can embarrass myself by posting it here.

Until then!

Mike

Jamie_McQuay · January 10, 2009, 2:01pm

To let you guys know, there is a decent description of the MVC pattern on the wiki already:

http://wiki.wxpython.org/ModelViewController/

This one seems to fully implement the MVC pattern (i.e. the model is using the pubsub library to inform it’s subscribers of updates).

Cheers,

Jamie

···

On 9-Jan-09, at 11:20 PM, Mike Driscoll wrote:

Christopher Barker wrote:

Mike Driscoll wrote:

I don’t “get” it either, which is why I don’t usually use the whole MVC paradigm. But I’d like to learn it, so I suppose I should make something in TurboGears and then try to copy their ideas in wxPython.

Do you think TG does it well?

I forgot to answer this…When I used TG 1.x last year, I thought it did a job of the MVC paradigm…at least, the book or docs or whatever it was explained it quite well. Unfortunately, I have yet to figure out how to actually do it in anything other than book examples…come to think of it, I have yet to figure out how to do TDD either.

Anyway, as I said in my other email, I’ll try to get that code put together so I can embarrass myself by posting it here.

Until then!

Mike


Jamie McQuay

Scimatic Software Inc.

[www.scimatic.com](http://www.scimatic.com/) 

****We build software for scientists.****

</details>

driscollis · January 10, 2009, 5:33pm

Jamie McQuay wrote:

Christopher Barker wrote:

Mike Driscoll wrote:

I don't "get" it either, which is why I don't usually use the whole MVC paradigm. But I'd like to learn it, so I suppose I should make something in TurboGears and then try to copy their ideas in wxPython.

Do you think TG does it well?

I forgot to answer this...When I used TG 1.x last year, I thought it did a job of the MVC paradigm...at least, the book or docs or whatever it was explained it quite well. Unfortunately, I have yet to figure out how to actually do it in anything other than book examples...come to think of it, I have yet to figure out how to do TDD either.

Anyway, as I said in my other email, I'll try to get that code put together so I can embarrass myself by posting it here.

Until then!

Mike

To let you guys know, there is a decent description of the MVC pattern on the wiki already:
ModelViewController - wxPyWiki

This one seems to fully implement the MVC pattern (i.e. the model is using the pubsub library to inform it's subscribers of updates).

Cheers,

Jamie

I've read that page before, but I don't think it used to have that example. Maybe no one needs another example then?

Mike

···

On 9-Jan-09, at 11:20 PM, Mike Driscoll wrote:

Kevin_Ollivier2 · January 10, 2009, 7:32pm

Hi Mike,

Christopher Barker wrote:

Mike Driscoll wrote:

I don't "get" it either, which is why I don't usually use the whole MVC paradigm. But I'd like to learn it, so I suppose I should make something in TurboGears and then try to copy their ideas in wxPython.

Do you think TG does it well?

I forgot to answer this...When I used TG 1.x last year, I thought it did a job of the MVC paradigm...at least, the book or docs or whatever it was explained it quite well. Unfortunately, I have yet to figure out how to actually do it in anything other than book examples...come to think of it, I have yet to figure out how to do TDD either.

Then how about a quick lesson in TDD? Take the MVC example in that link. What people usually do is code up the Model class, then write a View and Controller (or usually View + Controller in wx), then test them by clicking around and typing in data, right?

Instead of that, just write the Model class (done for us here!), then write a Unit test suite using PyUnit, and add methods testAddMoney and testRemoveMoney. Then test it with some common values, such as 0, 1, 10, -1, or myModel.money, or even myModel.money + 10. These simple values already raise a question. Are negative values (debt?) acceptable as either input or as a total, or should the class raise an exception and not allow a transaction with negative values or a negative result? Once you're done sorting those sorts of issues out, write your view and write whatever automated tests you can for that. (may be restricted to getter/setter testing) Ditto for the Controller. Now you're doing TDD.

The main idea behind TDD is that you try and think of and test the corner cases while you're designing each new API rather than hoping that app testing shakes them out. The other benefit, of course, is that since the tests are automated, you can run them after every change and be notified the moment a regression is introduced.

As a practical matter, I often find that doing things this way gets me into a mode where I want to poke and prod the API to see if I can break something, and sadly, usually I'm successful. I've definitely found and fixed bugs that would have been hard to isolate in a real app using this method. Also, it does make me feel good though to know that those cases I wrote tests for work and won't break in the future without me knowing about it.

BTW, regarding your sample, although I do think the link Jamie posted is pretty good, if your example code differs in any significant way (e.g. maybe it is more complex, has more interactions, etc.) I think it wouldn't hurt to post it. The thing about simple examples is that they only cover the basics and don't answer questions about what to do in more complex scenarios.

Regards,

Kevin

···

On Jan 9, 2009, at 8:20 PM, Mike Driscoll wrote:

Anyway, as I said in my other email, I'll try to get that code put together so I can embarrass myself by posting it here.

Until then!

Mike

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Michael_Hipp1 · January 10, 2009, 7:55pm

Mike Driscoll wrote:

Jamie McQuay wrote:

To let you guys know, there is a decent description of the MVC pattern on the wiki already:
ModelViewController - wxPyWiki

This one seems to fully implement the MVC pattern (i.e. the model is using the pubsub library to inform it's subscribers of updates).

Cheers,

Jamie

I've read that page before, but I don't think it used to have that example. Maybe no one needs another example then?

Just my IMHO...

I don't think that page is much help. (No offense to those who posted it.) The code seems very hard to follow (e.g. what, pray tell, is "an observable"). It needs lots more prose.

MVC is simple. Until it isn't.

Building sterile laboratory-clean examples of "model gets data, view shows data, model saves data" is trivially easy.

But what about the "real" cases where the view needs to validate some piece of data or query the model for a lookup to do autocompletion on a field *before* it's time to save anything. (Does the view interrogate the model? Does the controller do it on behalf of the of the view? How does the controller interpose itself in that exchange without having countless patched-together methods and pubsub receivers to handle only *one* relatively simple view?)

I've found dozens of cases in my own code where those sterile examples turn to day-old spaghetti when real requirements appear.

Didn't mean this as a rant. I'd really love to see someone create a really good example (tutorial?) using wxPython.

Thanks,
Michael