Google SoC Project - MVC

Hello wxpython-dev,

My name is Keith Holman, and as part of my Google Summer of Code project I will be working on improving wxPython so that users of the library can better separate their data models from their presentation logic (Model-View-Controller). Please contact me on the #wxwidgets channel or by email if there’s anything in particular that you think I should look into.

Thanks for your time!

Keith Holman

My project: http://code.google.com/soc/2008/wxpython/appinfo.html?csaid=4D381307376131D4
My email: cobalt037@gmail.com
IRC nickname: holmak

Hi Keith,

My suggestion is to investigate Cells technology (pycells and Trellis) integration with wxPython

Peter

···

On Wed, May 28, 2008 at 8:41 AM, Keith Holman cobalt037@gmail.com wrote:

Hello wxpython-dev,

My name is Keith Holman, and as part of my Google Summer of Code project I will be working on improving wxPython so that users of the library can better separate their data models from their presentation logic (Model-View-Controller). Please contact me on the #wxwidgets channel or by email if there’s anything in particular that you think I should look into.

Thanks for your time!

Keith Holman

My project: http://code.google.com/soc/2008/wxpython/appinfo.html?csaid=4D381307376131D4

My email: cobalt037@gmail.com
IRC nickname: holmak


wxpython-dev mailing list

wxpython-dev@lists.wxwidgets.org

http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev


There is NO FATE, we are the creators.

Hi Peter,

Hi Keith,

My suggestion is to investigate Cells technology (pycells and Trellis) integration with wxPython

Definitely worth taking a look at, but I think a better approach would be to simply allow wxPython controls to take a model and controller, and use them when set. This way we’re not trying to re-invent wxPython or trying to get fundamentally different frameworks with different design philosophies and target audiences to try and play nice together. We’re just extending it to be MVC-friendly. We can use something like wx.lib.pubsub to send notifications when either the model or the view changes, and the controller sets up listeners for these events and handles any changes that needs made.

Regards,

Kevin

···

On May 29, 2008, at 1:57 AM, Peter Damoc wrote:

Peter

On Wed, May 28, 2008 at 8:41 AM, Keith Holman cobalt037@gmail.com wrote:

Hello wxpython-dev,

My name is Keith Holman, and as part of my Google Summer of Code project I will be working on improving wxPython so that users of the library can better separate their data models from their presentation logic (Model-View-Controller). Please contact me on the #wxwidgets channel or by email if there’s anything in particular that you think I should look into.

Thanks for your time!

Keith Holman

My project: http://code.google.com/soc/2008/wxpython/appinfo.html?csaid=4D381307376131D4
My email: cobalt037@gmail.com
IRC nickname: holmak


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


There is NO FATE, we are the creators. _______________________________________________
wxpython-dev mailing list
wxpython-dev@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

I am doing the same for FloatCanvas. Internally I wrote a little "event manager" which just wraps wx.lib.pubsub so it can be replaced with another implementation if desired. One of the problems I encountered while doing this is that topics are supposed to be only strings. This seems to be a problem, because if I want to subscribe only for the updates of a specific object it's not (cleanly) possible.

Doing something like

obj = createSomeModelWhichSendsEventsWhenItChanges()
Publisher().subscribe( (obj,), obj_all_messages_handler )
Publisher().subscribe( (obj, 'sizeChanged'), obj_size_changed_handler )

is not possible right now. Maybe you could set the topic to (str(id(obj)),), but that doesn't seem like a clean solution. I am also wondering whether this would work at all for the default wxPython objects, because you might get different objs for the same underlying C++ object. Of course not using any of these objects doesn't create the problem.

I can see three solutions:

1) Patch pubsub so that it allows non-strings to be used.
2) Don't make publisher a singleton. Instead use it something like

obj = createSomeModelWhichSendsEventsWhenItChanges()
obj.subscribe( '', obj_all_messages_handler )
obj.subscribe( 'sizeChanged', obj_size_changed_handler )

or

obj = createSomeModelWhichSendsEventsWhenItChanges()
obj.events.subscribe( '', obj_all_messages_handler )
obj.events.subscribe( 'sizeChanged', obj_size_changed_handler )

This also involves changing pubsub. Either you'd have to inherit from Publisher or create an attribute from Publisher or you inherit from a helper class that provides the same subscribe/sendMessage methods and forwards them to the global publisher by prepending (obj,) which is basically 1).

3) Use a third-party module like pydispatcher/louie ( http://pydispatcher.sourceforge.net/ ). The advantage here is that pydispatcher seems quite robust to me (used it for years without issues) and pubsub doesn't look like it's used all that much and so there are probably still some bugs lurking. It also supports using arbitrary subscribers (not only functions that take a single argument) with keywords and arbitrary topics.
The disadvantages here is that it doesn't support something like a topic tree out of the box (though I think this is possible by connecting one event to an other via a function - so you could connect 'sports/baseball' to 'sports'). The whole thing also happens in a single module instead of a class, so there's only one pydispatcher for everything. The approach in 2) could be faked with it though (just make subscribe prepend (obj,) in front of the topic.
Maybe there are other observer/observable design pattern implementations in python which I am not familiar with and which could be useful here.

What's your opinion on solving this?

-Matthias

···

Am 30.05.2008, 07:41 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com>:

Hi Peter,

On May 29, 2008, at 1:57 AM, Peter Damoc wrote:

Hi Keith,

My suggestion is to investigate Cells technology (pycells and
Trellis) integration with wxPython

Definitely worth taking a look at, but I think a better approach would
be to simply allow wxPython controls to take a model and controller,
and use them when set. This way we're not trying to re-invent wxPython
or trying to get fundamentally different frameworks with different
design philosophies and target audiences to try and play nice
together. We're just extending it to be MVC-friendly. We can use
something like wx.lib.pubsub to send notifications when either the
model or the view changes, and the controller sets up listeners for
these events and handles any changes that needs made.

Nitro wrote:

I am doing the same for FloatCanvas. Internally I wrote a little "event manager" which just wraps wx.lib.pubsub so it can be replaced with another implementation if desired. One of the problems I encountered while doing this is that topics are supposed to be only strings.

Or tuples of strings.

This seems to be a problem, because if I want to subscribe only for the updates of a specific object it's not (cleanly) possible.

Doing something like

obj = createSomeModelWhichSendsEventsWhenItChanges()
Publisher().subscribe( (obj,), obj_all_messages_handler )
Publisher().subscribe( (obj, 'sizeChanged'), obj_size_changed_handler )

is not possible right now.

If obj has a unique name then you can just use that for a component of the topic name.

Maybe you could set the topic to (str(id(obj)),), but that doesn't seem like a clean solution.

It amounts to almost the same thing, except with a name then the programmer could set that if they want to be able to use it later for some reason, like a find object by name function.

I am also wondering whether this would work at all for the default wxPython objects, because you might get different objs for the same underlying C++ object. Of course not using any of these objects doesn't create the problem.

I can see three solutions:

Here is another. Use the hierarchal matching capabilities of pubsub to help with topic filtering and matching. For example, you might define a rule that all FC topics should use a set number of components, perhaps something like:

  action.canvasName.layerName.objName

(or the equivalent tuple form.) Already with pubsub you'll be able to subscribe to messages that are more general or more detailed (from left to right in the topic name.) For example, you can get all sizeChanged actions in the fooCanvas by just subscribing to "sizeChanged.fooCanvas", or whatever. Next, add to pubsub the ability to do wildcard topic matches and you'll then be able to go the other direction. For example to get messages for any action on the redCircle object you can subscribe to "*.*.*.redCircle". Does that give you everything you need?

You may also want to look at pubsub3. It's the next generation of pubsub forked off into its own project. I haven't had the time to integrate it back into wxPython but it should probably be done one of these days.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Kevin Ollivier wrote:

Hi Peter,

Hi Keith,

My suggestion is to investigate Cells technology (pycells and Trellis) integration with wxPython

Definitely worth taking a look at, but I think a better approach would be to simply allow wxPython controls to take a model and controller, and use them when set. This way we're not trying to re-invent wxPython or trying to get fundamentally different frameworks with different design philosophies and target audiences to try and play nice together. We're just extending it to be MVC-friendly. We can use something like wx.lib.pubsub to send notifications when either the model or the view changes, and the controller sets up listeners for these events and handles any changes that needs made.

I'm not sure how to go about implementing this, but some thoughts I've had about MVC in wxPython are that it would be nice to be able to have some sort of modular controller and/or model. In other words, each widget involved in the view would have an associated component that would automatically integrate itself into a composite controller or model of some sort. Then there would be a standard but flexible way to hook that to the application's model. This would allow the app model to be whatever it needs to be for the app or the programmer's preferences, and just use a flexible but well defined interface for communicating with the rest of the system, which was all built automatically based on how the UI is put together.

···

On May 29, 2008, at 1:57 AM, Peter Damoc wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Robin Dunn wrote:

Kevin Ollivier wrote:

Hi Peter,

Hi Keith,

My suggestion is to investigate Cells technology (pycells and Trellis) integration with wxPython

Definitely worth taking a look at, but I think a better approach would be to simply allow wxPython controls to take a model and controller, and use them when set. This way we're not trying to re-invent wxPython or trying to get fundamentally different frameworks with different design philosophies and target audiences to try and play nice together. We're just extending it to be MVC-friendly. We can use something like wx.lib.pubsub to send notifications when either the model or the view changes, and the controller sets up listeners for these events and handles any changes that needs made.

I'm not sure how to go about implementing this, but some thoughts I've had about MVC in wxPython are that it would be nice to be able to have some sort of modular controller and/or model. In other words, each widget involved in the view would have an associated component that would automatically integrate itself into a composite controller or model of some sort. Then there would be a standard but flexible way to hook that to the application's model. This would allow the app model to be whatever it needs to be for the app or the programmer's preferences, and just use a flexible but well defined interface for communicating with the rest of the system, which was all built automatically based on how the UI is put together.

Yes, I have been trying to brainstorm something like this for one of my projects. To me the most elegant solution is a model, view, and controller which can each exist independently and don't need any of the other parts.

So you can have a View (wxPython app), say a contact list, that allows you to add, edit, and remove entries. The View knows what boxes to pop up, how to add entries to the View's list when you click Add, etc. When "changes" occur (whatever ultimately requires an updated Model), you just use pubsub like pubsub.Publisher().sendMessage("CONTACT ADDED", ('Bob', '755-555-1212', 'bob@aol.com')), or something like that. The View doesn't care if anything is listening. The controller can pick up on this, and make the appropriate model calls. Without a controller, there is just no data persistence.

When the View launches it would send a pubsub message, informing anyone that may be listening that it can be populated with information. Now if a controller is there, it could iterate over its contacts, sending the identical messages ("CONTACT ADDED", ('Bob', '755-555-1212', 'bob@aol.com')), and the View knows the appropriate way to represent that contact.

You can also import the controller from a command-line and manually call whatever functions the controller binds to the appropriate pubsub messages (addContact(self, Name, Phone, Email)), (or you could do it with pubsub :slight_smile: without a need for the View.

Using a solution like this and using pubsub, you can have multiple Views for the same data and multiple Models storing the data in completely different ways, without any extra work at all. You have all these components just announcing occurrences, and anything that wants to act on it can do so in the way it defines as useful.

In less abstract words (from my blueprint at Proper MVC : Blueprints : wxBanker): "Have the GUI and the controller send the same messages when the same action is performed, with unique IDs created by the generator. Each component maintains a list of uIDs to ignore, and a uID is added to it either when it has already responded to it or has generated it itself. For example, the user removes an account in the GUI. The GUI sends ("ACCOUNT REMOVED", (uID, accountNum)). The Controller receives this, realizes IT didn't generate the message (based on the uID), and acts on it. It then sends the same message (with the same ID). The GUI will ignore it, since it sent it and has already done the appropriate GUI things. The Controller will also ignore this message since it will have added the ID to its "sent" list as well."

So one way to accomplish better MVC in Python would to wrap pubsub in a way which allows each component to send messages in a standard way, and handling the aforementioned situations so each thing only responds to the message once, and making this transparent to the user.

Note all of this isn't strict MVC. To do it strictly (or as strict as you can in wxPython) you would have to Bind all wxPython events directly to the controller's appropriate functions. But this requires a controller which not only knows details about the View, but a View that REQUIRES an underlying controller. I don't see this as being particularly elegant or useful.

Okay, sorry for the long post, but I wanted to contribute my ideas and ideally get some feedback as well.

Thanks for reading, if you made it this far!
- Mike Rooney

···

On May 29, 2008, at 1:57 AM, Peter Damoc wrote:

Hi Mike,

Robin Dunn wrote:

Kevin Ollivier wrote:

Hi Peter,

Hi Keith,

My suggestion is to investigate Cells technology (pycells and Trellis) integration with wxPython

Definitely worth taking a look at, but I think a better approach would be to simply allow wxPython controls to take a model and controller, and use them when set. This way we're not trying to re-invent wxPython or trying to get fundamentally different frameworks with different design philosophies and target audiences to try and play nice together. We're just extending it to be MVC-friendly. We can use something like wx.lib.pubsub to send notifications when either the model or the view changes, and the controller sets up listeners for these events and handles any changes that needs made.

I'm not sure how to go about implementing this, but some thoughts I've had about MVC in wxPython are that it would be nice to be able to have some sort of modular controller and/or model. In other words, each widget involved in the view would have an associated component that would automatically integrate itself into a composite controller or model of some sort. Then there would be a standard but flexible way to hook that to the application's model. This would allow the app model to be whatever it needs to be for the app or the programmer's preferences, and just use a flexible but well defined interface for communicating with the rest of the system, which was all built automatically based on how the UI is put together.

Yes, I have been trying to brainstorm something like this for one of my projects. To me the most elegant solution is a model, view, and controller which can each exist independently and don't need any of the other parts.

So you can have a View (wxPython app), say a contact list, that allows you to add, edit, and remove entries. The View knows what boxes to pop up, how to add entries to the View's list when you click Add, etc. When "changes" occur (whatever ultimately requires an updated Model), you just use pubsub like pubsub.Publisher().sendMessage("CONTACT ADDED", ('Bob', '755-555-1212', 'bob@aol.com')), or something like that. The View doesn't care if anything is listening. The controller can pick up on this, and make the appropriate model calls. Without a controller, there is just no data persistence.

When the View launches it would send a pubsub message, informing anyone that may be listening that it can be populated with information. Now if a controller is there, it could iterate over its contacts, sending the identical messages ("CONTACT ADDED", ('Bob', '755-555-1212', 'bob@aol.com')), and the View knows the appropriate way to represent that contact.

No, if we're talking about MVC here, the view should not know how to represent a contact; the controller would store that logic. A view's sole purpose is to visualize data, and in order for the view to be as reusable as possible, it must know as little about the semantic meaning of that data as possible. A view should only know what type of data to draw (e.g. bool, string, number, custom) and where to draw it. In other words, a view should not know how to respond to a "CONTACT ADDED" message, because it should have no knowledge of the model, nor should it directly be passed data from the model like you suggest here. Instead, the "contact added" message should be sent from the model to the controller and the controller will do the work to add the contact to the view. (Or, the view will send a "Load data" message to the controller, and the controller will read through the model and populate the view with its data.)

The best way to think of the controller, IMHO, is to think of it as a translator. When something happens in the model, the controller translates it into terms the view can understand (e.g. a series of commands needed to visualize the change in the model), and when something happens in the view, the controller translates it into terms the model can understand (e.g. a series of data manipulations). I don't see the purpose of the controller sending out messages, as its entire purpose is to respond to messages from the model and view. From your comments, however, you seem to be visualizing the controller as just passing messages around, but really in that case, why can't the view just send messages directly to the model and vice-versa?

You can also import the controller from a command-line and manually call whatever functions the controller binds to the appropriate pubsub messages (addContact(self, Name, Phone, Email)), (or you could do it with pubsub :slight_smile: without a need for the View.

Using a solution like this and using pubsub, you can have multiple Views for the same data and multiple Models storing the data in completely different ways, without any extra work at all. You have all these components just announcing occurrences, and anything that wants to act on it can do so in the way it defines as useful.

In less abstract words (from my blueprint at Proper MVC : Blueprints : wxBanker): "Have the GUI and the controller send the same messages when the same action is performed, with unique IDs created by the generator. Each component maintains a list of uIDs to ignore, and a uID is added to it either when it has already responded to it or has generated it itself. For example, the user removes an account in the GUI. The GUI sends ("ACCOUNT REMOVED", (uID, accountNum)). The Controller receives this, realizes IT didn't generate the message (based on the uID), and acts on it. It then sends the same message (with the same ID). The GUI will ignore it, since it sent it and has already done the appropriate GUI things. The Controller will also ignore this message since it will have added the ID to its "sent" list as well."

So one way to accomplish better MVC in Python would to wrap pubsub in a way which allows each component to send messages in a standard way, and handling the aforementioned situations so each thing only responds to the message once, and making this transparent to the user.

Note all of this isn't strict MVC. To do it strictly (or as strict as you can in wxPython) you would have to Bind all wxPython events directly to the controller's appropriate functions. But this requires a controller which not only knows details about the View, but a View that REQUIRES an underlying controller. I don't see this as being particularly elegant or useful.

A wxPython control/view will not require an underlying controller, unless you're using MVC, of course. :wink: If you do want to use MVC, though, yes, you absolutely need all three parts - a Model, a View, and a Controller. I personally think that calling Bind to bind view events to the controller for handling is not only useful but necessary. You do have to write that code somewhere - the only question is where. If it's not in your Controller class, then you're either tying your view to your model, or vice-versa, and making both less reusable with other controls because the controller parts will need re-written for each view.

AFAICT, your goal seems to be cutting all connections between the three components, but the reason we have the controller in the first place is because there needs to be something that links the model and the view together, and thus that must have knowledge of both of them. Now, you can merge the controller into the view (or the model) if you want, but the controller is still there (i.e. it's whatever code responds to "CONTACT ADDED"). The only difference is that you've now tied your view and model together, which IMHO is not a good thing if you want to reuse that code in another view.

Regards,

Kevin

···

On May 30, 2008, at 12:17 PM, Mike Rooney wrote:

On May 29, 2008, at 1:57 AM, Peter Damoc wrote:

Okay, sorry for the long post, but I wanted to contribute my ideas and ideally get some feedback as well.

Thanks for reading, if you made it this far!
- Mike Rooney
_______________________________________________
wxpython-dev mailing list
wxpython-dev@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

This seems to be a problem, because if I want to subscribe only for the updates of a specific object it's not (cleanly) possible.
Doing something like
obj = createSomeModelWhichSendsEventsWhenItChanges()
Publisher().subscribe( (obj,), obj_all_messages_handler )
Publisher().subscribe( (obj, 'sizeChanged'), obj_size_changed_handler )
is not possible right now.

If obj has a unique name then you can just use that for a component of the topic name.

Yes. But this means I have to generate a unique name for every object that's ever part of the MVC mechanism. This could be realized by using a factory function or by inheriting the objects in question from some base class which provides the capabilities.

Maybe you could set the topic to (str(id(obj)),), but that doesn't seem like a clean solution.

It amounts to almost the same thing, except with a name then the programmer could set that if they want to be able to use it later for some reason, like a find object by name function.

The programmer might use non-unique names, maybe even between unrelated objects and this might cause problems. So I think one needs to distinguish between a unique ID of an object and its name.
Maybe str(hash(obj)) is a better solution, still not the one which I'd think is the best though.

Here is another. Use the hierarchal matching capabilities of pubsub to help with topic filtering and matching. For example, you might define a rule that all FC topics should use a set number of components, perhaps something like:

  action.canvasName.layerName.objName

(or the equivalent tuple form.) Already with pubsub you'll be able to subscribe to messages that are more general or more detailed (from left to right in the topic name.) For example, you can get all sizeChanged actions in the fooCanvas by just subscribing to "sizeChanged.fooCanvas", or whatever. Next, add to pubsub the ability to do wildcard topic matches and you'll then be able to go the other direction. For example to get messages for any action on the redCircle object you can subscribe to "*.*.*.redCircle". Does that give you everything you need?

The hierarchy is not (yet?) a huge problem. Your ideas surely sound convincing when it comes to hierarchy though. I'll remember this. However, it does not solve the "topics are only strings or tuples thereof". At least you'd have to be able to do something like ('*', '*', '*', redCircleObj). Pubsub would then automatically take str(hash(redCircleObj)). This could be realized by feeding each topic into a canonical_topic() function which just takes the hash() of anything that's not a string.

You may also want to look at pubsub3. It's the next generation of pubsub forked off into its own project. I haven't had the time to integrate it back into wxPython but it should probably be done one of these days.

Ahh, I didn't know pubsub was moved out of wxPython. I just read their webpage, but it seems topics are still limited to strings. In pubsub3 you're allowed to only send already registered messages. I implemented this for fc, too, but then removed it, because it seemed to be counter-productive at times.

-Matthias

···

Am 30.05.2008, 20:48 Uhr, schrieb Robin Dunn <robin@alldunn.com>:

Hi Kevin,

Kevin Ollivier wrote:

No, if we're talking about MVC here, the view should not know how to represent a contact; the controller would store that logic. A view's sole purpose is to visualize data, and in order for the view to be as reusable as possible, it must know as little about the semantic meaning of that data as possible. A view should only know what type of data to draw (e.g. bool, string, number, custom) and where to draw it. In other words, a view should not know how to respond to a "CONTACT ADDED" message, because it should have no knowledge of the model, nor should it directly be passed data from the model like you suggest here. Instead, the "contact added" message should be sent from the model to the controller and the controller will do the work to add the contact to the view. (Or, the view will send a "Load data" message to the controller, and the controller will read through the model and populate the view with its data.)

Yes, I think you have some valid criticisms of my concepts. Maybe what I want is not MVC, but I don't like the idea of requiring a Controller for the View to be useful, and then coupling the Controller to that View. If you bind the events directly to the controller and then manipulate the wx objects from the controller (which I have done in one project), that becomes very awkward to me. Now if you want another sort of View, say Excel, HTML, text, et cetera, your Controller can't handle it. You have to make some meta-Controller which handles all of the controllers for each View, and has to know exactly how many Views and Controllers there are and are active at any given time. Manipulating Excel tables is only useful for an Excel View, why abstract non-abstract knowledge? You are just moving it for the sake of moving it.

I guess I just don't understand the point of taking logic out of the View which only pertains to the View. I would like Views which understand how to display the appropriate raw data, which the controller handles/generates, and the model stores.

The best way to think of the controller, IMHO, is to think of it as a translator. When something happens in the model, the controller translates it into terms the view can understand (e.g. a series of commands needed to visualize the change in the model), and when something happens in the view, the controller translates it into terms the model can understand (e.g. a series of data manipulations). I don't see the purpose of the controller sending out messages, as its entire purpose is to respond to messages from the model and view.

In many ways your description seems to match what I imagine as well. However I don't understand the criticism of the Controller sending messages. This is only barely different from the Controller calling View functions, which your concept does. This is exactly what sending the messages accomplishes anyway, except now it has been wrapped in such a way as to make the Controller agnostic to the *specific* View (not Views in general!) and how many of them there are, if any. The entire purpose of the Controller is not to respond to messages from the Controller and View, it is to actually DO things (the business logic), and then let the View and Model know when to update themselves. It doesn't need to know the nitty-gritty implementation-specific details of doing so.

From your comments, however, you seem to be visualizing the controller as just passing messages around, but really in that case, why can't the view just send messages directly to the model and vice-versa?

No, the Controller handles all the business logic. It knows what needs to be persisted and when; neither the View or the Model care about or understand this. It understands what actions are valid and when. With my idea of MVC, you can import the controller, and call all the methods you want to create and manage files in whatever is appropriate. This allows the application to be used from a command-prompt, PyShell, et cetera. If you have a View, you also get to see those changes happening (and perhaps interact with them there), and if you have a Model, those changes get persisted somewhere. But you shouldn't NEED either of these to perform business logic.

A wxPython control/view will not require an underlying controller, unless you're using MVC, of course. :wink: If you do want to use MVC, though, yes, you absolutely need all three parts - a Model, a View, and a Controller. I personally think that calling Bind to bind view events to the controller for handling is not only useful but necessary. You do have to write that code somewhere - the only question is where. If it's not in your Controller class, then you're either tying your view to your model, or vice-versa, and making both less reusable with other controls because the controller parts will need re-written for each view.

AFAICT, your goal seems to be cutting all connections between the three components, but the reason we have the controller in the first place is because there needs to be something that links the model and the view together, and thus that must have knowledge of both of them.

The controller does do this linking you say and has knowledge of both of them, just not SPECIFIC knowledge. It knows a View may be out there presenting data and allowing the user to manipulate it, and it knows there are ways to represent this data in a persistable way via a Model. It knows what sorts of things a View may be interested in, and what sorts of events and actions the Model may be interested in, and handles all the logic in between.

Now, you can merge the controller into the view (or the model) if you want, but the controller is still there (i.e. it's whatever code responds to "CONTACT ADDED"). The only difference is that you've now tied your view and model together, which IMHO is not a good thing if you want to reuse that code in another view.

But you are only saying I have tied the the Controller and View together because you are calling something a Controller which I am not, and mixing our views. It is perfectly fine to criticize why my View does too much or why my Controller does too little, but you can't say my Controller is coupled to the View and be consistent with either of our ideas. What you are really saying is YOUR idea of a Controller is coupled to MY idea of a View, by calling my idea of a View a Controller from your point of view. This mixing and matching doesn't make sense from either of our conceptions of MVC.

Anyway, thanks for the response, you definitely have some valid criticisms which I appreciate and I will have to think more about the proper way to do things. I have to figure out how to not couple business logic with my View while not depending on a Controller to function. I think this would be possible by removing the conditional logic from the View and instead allowing a Controller to 'veto' any actions which are not allowed. I agree that a strict MVC approach where you bind the events to the controller can be an elegant approach, granted you only want to work with one sort of wx View. It did clean up our code a lot and made it easy to work with, but later when we wanted to take our business logic elsewhere for another application, it was too coupled to a specific View.

I would just really like a nice way to have a portable business logic module (what I am calling a Controller), and then be able to (optionally) link Views to one side of it and Models to the other, and as long as they conform to the API, it all just works and the Controller ensures that the data flows as it should when it should and how it should.

Thanks again,
Mike

Mike Rooney wrote:

The entire purpose of the Controller is not to respond to messages from the Controller and View, it is to actually DO things (the business logic), and then let the View and Model know when to update themselves.

Ah -- here is the misunderstanding -- I think the Model is responsible for the business logic -- it more than a data store. It seems you are separating the data store from the logic, calling the data store the model, and putting the business logic in what you call the controller. In that case, yes, you'd want the controller sending messages.

However, I think it is key to MVC that the business logic be in the model. You MAY want to factor the data store out of a given model so that you can have multiple ways to do your data store, but it's still the model.

From your comments, however, you seem to be visualizing the controller as just passing messages around, but really in that case, why can't the view just send messages directly to the model and vice-versa?

Frankly, I've always been confused by that as well, I'm not sure how you can really de-couple the Controller from the view (or from the model, really -- you need one controller for each view-model pair.

and call all the methods you want to create and manage files in whatever is appropriate. This allows the application to be used from a command-prompt, PyShell, et cetera.

This is key, but I think you want the model to be usable this way, not the controller -- and, buy the way from test-code - perhaps the most important!

I have to figure out how to not couple business logic with my View while not depending on a Controller to function.

Maybe, but a view with no Model is kind of pointless isn't it? ( leaving out the controller for the moment...)

I've come to this conclusion:

The Model should be stand alone, and is very likely to to have multiple controllers attached to it, and it should know nothing of its views, except that they may need a message sent out when something is changed. Business logic should be in the model. Persistence is probably in the model, though in some cases persistence could be seen as another View (i.e. and XML file could be a view).

A View really does have to be coupled with the model -- it needs to know what data to present, what messages to send and receive, etc, etc. Sure, it may be able to function without a Model anywhere sending it messages, but it really isn't useful that way. I really can't imagine a truly generic View, though you could have more than one implementation of the Model, as long as it has the same API -- indeed, that's one reason for MVC -- you can re-write the model without messing with the Views.

A Controller facilitates communication between the Model and a View (or multiple views). I'm still confused what goes there, but I think it's code that needs to know specific details about both the Model and the View. I think you are likely to get a different Controller for each Model<->View Pairing, though they could all subclass from the same things to share code.

My thoughts....

-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

Hi Mike,

Hi Kevin,

Kevin Ollivier wrote:

No, if we're talking about MVC here, the view should not know how to represent a contact; the controller would store that logic. A view's sole purpose is to visualize data, and in order for the view to be as reusable as possible, it must know as little about the semantic meaning of that data as possible. A view should only know what type of data to draw (e.g. bool, string, number, custom) and where to draw it. In other words, a view should not know how to respond to a "CONTACT ADDED" message, because it should have no knowledge of the model, nor should it directly be passed data from the model like you suggest here. Instead, the "contact added" message should be sent from the model to the controller and the controller will do the work to add the contact to the view. (Or, the view will send a "Load data" message to the controller, and the controller will read through the model and populate the view with its data.)

Yes, I think you have some valid criticisms of my concepts. Maybe what I want is not MVC, but I don't like the idea of requiring a Controller for the View to be useful, and then coupling the Controller to that View. If you bind the events directly to the controller and then manipulate the wx objects from the controller (which I have done in one project), that becomes very awkward to me. Now if you want another sort of View, say Excel, HTML, text, et cetera, your Controller can't handle it. You have to make some meta-Controller which handles all of the controllers for each View, and has to know exactly how many Views and Controllers there are and are active at any given time. Manipulating Excel tables is only useful for an Excel View, why abstract non-abstract knowledge? You are just moving it for the sake of moving it.

I guess I just don't understand the point of taking logic out of the View which only pertains to the View. I would like Views which understand how to display the appropriate raw data, which the controller handles/generates, and the model stores.

The best way to think of the controller, IMHO, is to think of it as a translator. When something happens in the model, the controller translates it into terms the view can understand (e.g. a series of commands needed to visualize the change in the model), and when something happens in the view, the controller translates it into terms the model can understand (e.g. a series of data manipulations). I don't see the purpose of the controller sending out messages, as its entire purpose is to respond to messages from the model and view.

In many ways your description seems to match what I imagine as well. However I don't understand the criticism of the Controller sending messages. This is only barely different from the Controller calling View functions, which your concept does. This is exactly what sending the messages accomplishes anyway, except now it has been wrapped in such a way as to make the Controller agnostic to the *specific* View (not Views in general!) and how many of them there are, if any. The entire purpose of the Controller is not to respond to messages from the Controller and View, it is to actually DO things (the business logic), and then let the View and Model know when to update themselves. It doesn't need to know the nitty-gritty implementation-specific details of doing so.

From your comments, however, you seem to be visualizing the controller as just passing messages around, but really in that case, why can't the view just send messages directly to the model and vice-versa?

No, the Controller handles all the business logic. It knows what needs to be persisted and when; neither the View or the Model care about or understand this. It understands what actions are valid and when. With my idea of MVC, you can import the controller, and call all the methods you want to create and manage files in whatever is appropriate. This allows the application to be used from a command-prompt, PyShell, et cetera. If you have a View, you also get to see those changes happening (and perhaps interact with them there), and if you have a Model, those changes get persisted somewhere. But you shouldn't NEED either of these to perform business logic.

Okay, this is where the issue lies. Controller != business logic, at least not in MVC. Controller == View <-> Model translation/bridge. I think the reason this is all so awkward for you is that you're trying to figure out where in Model, View or Controller to store the business logic, whereas the answer is probably "none of the above". Note that none of those three are directly about data manipulation or calculations. MVC is just about a smooth integration between a data model and its view, it's not a general purpose framework to be used without GUIs.

Business logic would probably in most cases reside in its own Python module. It might go in the model sometimes too, but it depends on if the logic is specific to that model (e.g. data validation and/or conversions for loading/saving), or if it's reusable across several models (e.g. data manipulation, data analysis, etc.). You might certainly use business logic in the controller as you pass data back and forth between Model and View, but that doesn't mean the logic needs to reside in the Controller. Business logic should be as reusable as possible, and thus, should usually reside in its own modules which can be imported anywhere it's needed.

A wxPython control/view will not require an underlying controller, unless you're using MVC, of course. :wink: If you do want to use MVC, though, yes, you absolutely need all three parts - a Model, a View, and a Controller. I personally think that calling Bind to bind view events to the controller for handling is not only useful but necessary. You do have to write that code somewhere - the only question is where. If it's not in your Controller class, then you're either tying your view to your model, or vice-versa, and making both less reusable with other controls because the controller parts will need re-written for each view.

AFAICT, your goal seems to be cutting all connections between the three components, but the reason we have the controller in the first place is because there needs to be something that links the model and the view together, and thus that must have knowledge of both of them.

The controller does do this linking you say and has knowledge of both of them, just not SPECIFIC knowledge. It knows a View may be out there presenting data and allowing the user to manipulate it, and it knows there are ways to represent this data in a persistable way via a Model. It knows what sorts of things a View may be interested in, and what sorts of events and actions the Model may be interested in, and handles all the logic in between.

Now, you can merge the controller into the view (or the model) if you want, but the controller is still there (i.e. it's whatever code responds to "CONTACT ADDED"). The only difference is that you've now tied your view and model together, which IMHO is not a good thing if you want to reuse that code in another view.

But you are only saying I have tied the the Controller and View together because you are calling something a Controller which I am not, and mixing our views. It is perfectly fine to criticize why my View does too much or why my Controller does too little, but you can't say my Controller is coupled to the View and be consistent with either of our ideas. What you are really saying is YOUR idea of a Controller is coupled to MY idea of a View, by calling my idea of a View a Controller from your point of view. This mixing and matching doesn't make sense from either of our conceptions of MVC.

Anyway, thanks for the response, you definitely have some valid criticisms which I appreciate and I will have to think more about the proper way to do things. I have to figure out how to not couple business logic with my View while not depending on a Controller to function. I think this would be possible by removing the conditional logic from the View and instead allowing a Controller to 'veto' any actions which are not allowed. I agree that a strict MVC approach where you bind the events to the controller can be an elegant approach, granted you only want to work with one sort of wx View. It did clean up our code a lot and made it easy to work with, but later when we wanted to take our business logic elsewhere for another application, it was too coupled to a specific View.

I would just really like a nice way to have a portable business logic module (what I am calling a Controller),

Please don't call it that then, because that is totally different from MVC and is going to cause everyone a lot of confusion.

and then be able to (optionally) link Views to one side of it and Models to the other, and as long as they conform to the API, it all just works and the Controller ensures that the data flows as it should when it should and how it should.

This part is precisely what an MVC Controller should do. :slight_smile:

Thanks,

Kevin

···

On Jun 2, 2008, at 7:25 AM, Mike Rooney wrote:

Thanks again,
Mike
_______________________________________________
wxpython-dev mailing list
wxpython-dev@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

Christopher Barker wrote:

Mike Rooney wrote:

The entire purpose of the Controller is not to respond to messages from the Controller and View, it is to actually DO things (the business logic), and then let the View and Model know when to update themselves.

Ah -- here is the misunderstanding -- I think the Model is responsible for the business logic -- it more than a data store. It seems you are separating the data store from the logic, calling the data store the model, and putting the business logic in what you call the controller. In that case, yes, you'd want the controller sending messages.

However, I think it is key to MVC that the business logic be in the model. You MAY want to factor the data store out of a given model so that you can have multiple ways to do your data store, but it's still the model.

Interesting, I suppose that could make sense. In my view the controller wrapped the model functionality with validation of sorts, ensuring say, an account that was being added didn't already exist. But this is fair game for a Model?

This seems an unfortunate way to do it, to me, as then every time I add a new storage option (XML, sql, pickle), I have to re-implement ALL those checks! With this logic in the controller there is no duplication, I can just do something like (in the controller): if accountName not in model.getAccounts(): model.addAccount(accountName). Do you see where my unhappiness and confusion regarding why I would want this logic in the model is coming from? Or am I missing something?

Frankly, I've always been confused by that as well, I'm not sure how you can really de-couple the Controller from the view (or from the model, really -- you need one controller for each view-model pair.

and call all the methods you want to create and manage files in whatever is appropriate. This allows the application to be used from a command-prompt, PyShell, et cetera.

This is key, but I think you want the model to be usable this way, not the controller -- and, buy the way from test-code - perhaps the most important!

I see what you mean. Currently all my testing is done on the Controller, but if like you say I am treating it like the Model, I suppose this makes sense. But due to my above concern, I would be extremely hesitant to have this business logic in the Model, as I have to duplicate it over and over, don't I? What am I missing?

I have to figure out how to not couple business logic with my View while not depending on a Controller to function.

Maybe, but a view with no Model is kind of pointless isn't it? ( leaving out the controller for the moment...)

Sort of, not really. It makes it really easy to first develop a command line interface application (the Controller, which sends messages), and then throw a View (wxPython GUI, for example) on top of it trivially. It also means you could build the View first if you wanted, if it was important to get an idea of user interaction before designing the application. It ALSO makes it easy to debug and test the GUI by itself, making it easier to track down the source of problems.

Also, it makes it a lot easier to extract examples to send to wxPython-users :slight_smile:

I've come to this conclusion:

The Model should be stand alone, and is very likely to to have multiple controllers attached to it, and it should know nothing of its views, except that they may need a message sent out when something is changed. Business logic should be in the model. Persistence is probably in the model, though in some cases persistence could be seen as another View (i.e. and XML file could be a view).

A View really does have to be coupled with the model -- it needs to know what data to present, what messages to send and receive, etc, etc. Sure, it may be able to function without a Model anywhere sending it messages, but it really isn't useful that way. I really can't imagine a truly generic View, though you could have more than one implementation of the Model, as long as it has the same API -- indeed, that's one reason for MVC -- you can re-write the model without messing with the Views.

I agree partially, a View has to be at least partially idealogically coupled to the Model. Obviously a View for an email client isn't going to be useful for a Controller or Model of a blackjack game. They should be designed to work with the same data. But there is a difference between designed to represent the same data, and REQUIRING that underlying data or business logic to be present. That is what I am trying to avoid with modular components; I want them to be enhanced by other components lower or higher in the process, not require them to function.

A Controller facilitates communication between the Model and a View (or multiple views). I'm still confused what goes there, but I think it's code that needs to know specific details about both the Model and the View. I think you are likely to get a different Controller for each Model<->View Pairing, though they could all subclass from the same things to share code.

My thoughts....

-Chris

Thanks for your thoughts, I think it cleared up a few things for me perhaps. I think I am perhaps convinced that the Controller should be manipulating the View in any way that isn't specific to a certain View (as in, it seems fine for the Controller to have to call a View method to display some new piece of data, but not for the Controller to know the implementation of details of displaying it). However any clarification you can give me on my concerns regarding business logic in the Model would be wonderful.

Thanks for this great discussion,
Mike

Robin Dunn wrote:

You may also want to look at pubsub3. It's the next generation of pubsub forked off into its own project. I haven't had the time to integrate it back into wxPython but it should probably be done one of these days.

Robin,

Do you want to do that? Maybe one of us could help. I'd rather FloatCanvas didn't depend on too much other than wxPython, but if pubsub3 is going to get rolled in, then it may be the way to go.

However, the page says "pubsub3 is still alpha", and it doesn't look like there has been anything done since last November.

-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

Mike Rooney wrote:

Interesting, I suppose that could make sense. In my view the controller wrapped the model functionality with validation of sorts, ensuring say, an account that was being added didn't already exist. But this is fair game for a Model?

This is about vocabulary, really, but from Wikipedia:

"""
Model:
The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).

Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
"""

And I've seen similar language in lots of other places.

This seems an unfortunate way to do it, to me, as then every time I add a new storage option (XML, sql, pickle), I have to re-implement ALL those checks!

Ah, another confusion -- "Model" doesn't mean one simple class. I think Kevin said is well -- MVC is about the GUI structure, not a general purpose application framework. So yes, you do want to separate your business logic from the data store, but they are still both part of the Model as far as MVC and the View and Controller are concerned.

I would be extremely hesitant to have this business logic in the Model, as I have to duplicate it over and over, don't I? What am I missing?

That MVC doesn't cover your whole app. You'll still want to structure your Model well, with re-usable components.

Sort of, not really. It makes it really easy to first develop a command line interface application (the Controller, which sends messages), and then throw a View (wxPython GUI, for example) on top of it trivially. It also means you could build the View first if you wanted, if it was important to get an idea of user interaction before designing the application.

Well, maybe, but I'd expect that you'd need a stub do-little Model in there anyway.

However, as far as I can tell, MVC does force a duplication of data storage and some logic. The view needs to store at least a temporary view of some of the data, and it may need a bit of logic -- like making sure a phone number looks like a phone number before trying to submit a form.

These are some of my key questions about MVC -- where do things like input data validation go?

But there is a difference between designed to represent the same data, and REQUIRING that underlying data or business logic to be present. That is what I am trying to avoid with modular components; I want them to be enhanced by other components lower or higher in the process, not require them to function.

I think you've got it close. Your View is fine, but perhaps you've kind of merged the Model and the Controller.

The truth is, these clearly defined structures are fantasies -- when it comes down to a specific application, it's not always going to be obvious where a given piece of code needs to go.

-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

I see this thread is very popular… so I’ll just throw in some more gasoline. :slight_smile:

Obligatory link (MVC explained by its creator):
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

Evolution in the separation of responsibilities (I have the last drawing printed as big as possible for reference) :slight_smile:
http://www.wildcrest.com/Potel/Portfolio/mvp.pdf

Reading the original description and seeing the concept of a Tool I realized that I’ve never ever been able to reuse any of the code in my MVC/MVP designs. It was only a matter of separating the code. Coupling made it next to impossible to use a view in a different context. However, separation allowed for a lot of flexibility, especially if you properly design the model. Right now I’m playing with using Decorator Pattern to add extra functionality while keeping the API the same. :slight_smile:

Peter

···

On Tue, Jun 3, 2008 at 12:17 AM, Christopher Barker Chris.Barker@noaa.gov wrote:

The truth is, these clearly defined structures are fantasies – when it comes down to a specific application, it’s not always going to be obvious where a given piece of code needs to go.

-Chris


There is NO FATE, we are the creators.

Christopher Barker wrote:

Mike Rooney wrote:

Interesting, I suppose that could make sense. In my view the controller wrapped the model functionality with validation of sorts, ensuring say, an account that was being added didn't already exist. But this is fair game for a Model?

This is about vocabulary, really, but from Wikipedia:

"""
Model:
The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).

Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
"""

And I've seen similar language in lots of other places.

Thanks.

This seems an unfortunate way to do it, to me, as then every time I add a new storage option (XML, sql, pickle), I have to re-implement ALL those checks!

Ah, another confusion -- "Model" doesn't mean one simple class. I think Kevin said is well -- MVC is about the GUI structure, not a general purpose application framework. So yes, you do want to separate your business logic from the data store, but they are still both part of the Model as far as MVC and the View and Controller are concerned.

Ahh, I think I have it now. Basically I could create a BaseModel class which had the generic logic to call abstract methods to do validation, like my previous example of adding an account. In this case it could do "if accountName not in self.getAccounts(): self.addAccount(accountName)". Then I would subclass this for each storage mechanism which would just implement the methods which manipulate the data (like getAccounts and addAccount).

That will get me the abstraction of business logic that I want (is it proper to call that business logic?), while keeping it in the Model. I think this makes a lot of sense. Unfortunately I think this means my Controller doesn't do much after moving that sort of business logic, so I have to figure out what I have in the View that belongs there :]

I would be extremely hesitant to have this business logic in the Model, as I have to duplicate it over and over, don't I? What am I missing?

That MVC doesn't cover your whole app. You'll still want to structure your Model well, with re-usable components.

Sort of, not really. It makes it really easy to first develop a command line interface application (the Controller, which sends messages), and then throw a View (wxPython GUI, for example) on top of it trivially. It also means you could build the View first if you wanted, if it was important to get an idea of user interaction before designing the application.

Well, maybe, but I'd expect that you'd need a stub do-little Model in there anyway.

However, as far as I can tell, MVC does force a duplication of data storage and some logic. The view needs to store at least a temporary view of some of the data, and it may need a bit of logic -- like making sure a phone number looks like a phone number before trying to submit a form.

These are some of my key questions about MVC -- where do things like input data validation go?

Yes, that is a good question. That relates to my idea of the controller/model vetoing changes, I think. So the View can say "here, the user entered a phone number!" (I realize the View shouldn't say this but if we consider wxPython to be the View, then as previously discussed the best we can do is bind events to the controller), and then the Model can look and realize it isn't valid, and send some sort of veto back, which causes the View to show an error. This would really only work well synchronously I think, although wxEvents and pubsub both are.

But there is a difference between designed to represent the same data, and REQUIRING that underlying data or business logic to be present. That is what I am trying to avoid with modular components; I want them to be enhanced by other components lower or higher in the process, not require them to function.

I think you've got it close. Your View is fine, but perhaps you've kind of merged the Model and the Controller.

The truth is, these clearly defined structures are fantasies -- when it comes down to a specific application, it's not always going to be obvious where a given piece of code needs to go.

Unfortunately true :slight_smile:

Thanks for your input!

- Mike

Christopher Barker wrote:

Robin Dunn wrote:

You may also want to look at pubsub3. It's the next generation of pubsub forked off into its own project. I haven't had the time to integrate it back into wxPython but it should probably be done one of these days.

Robin,

Do you want to do that? Maybe one of us could help. I'd rather FloatCanvas didn't depend on too much other than wxPython, but if pubsub3 is going to get rolled in, then it may be the way to go.

Yeah, I would agree that FloatCanvas (or the MVC project) should only use pubsub3 if pubsub3 is ready to be rolled in to wxPython. If somebody wants to take the time to look at it from that perspective and level of detail I'd appreciate it.

However, the page says "pubsub3 is still alpha", and it doesn't look like there has been anything done since last November.

Probably not a good sign... On the other hand, if there are "low hanging fruit" in pubsub3 desired by the FC or MVC projects that could be easily integrated into our current pubsub then that would be a good approach to take too.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Mike Rooney wrote:

Ahh, I think I have it now. Basically I could create a BaseModel class which had the generic logic to call abstract methods to do validation, like my previous example of adding an account. In this case it could do "if accountName not in self.getAccounts(): self.addAccount(accountName)". Then I would subclass this for each storage mechanism which would just implement the methods which manipulate the data (like getAccounts and addAccount).

That will get me the abstraction of business logic that I want (is it proper to call that business logic?), while keeping it in the Model. I think this makes a lot of sense. Unfortunately I think this means my Controller doesn't do much after moving that sort of business logic, so I have to figure out what I have in the View that belongs there :]

Or take the abstraction one step further use a plugin type of approach for the data storage. In other words, think of the Model as being composed of two layers, the application (or business) logic layer, and the data storage layer, where the data storage layer is replaceable with some model method like SetStorageProvider(storage). Then I guess it would be a DsMVC pattern. :wink:

On the other hand, typically most of the DsM parts of the pattern are going to be what varies the most from application to application, or from developer to developer, so I think the main thrust of this project should be in the two other areas:

1. Add-ons, wrappers, delegates or whatever is needed for being able to use the existing or future wx widgets in a coherent and consistent View framework.

2. A set of components or leggo blocks that can be assembled together to represent the objects active in the view and that facilitates their interfacing with the Model. These components could technically be part of the view classes for each widget or collection of widgets, but they would plug themselves in to a framework where they cooperate together as the Controller. Another way to look at these component blocks is that they are what adapts the different data, event and display needs of each kind of view object into a form where communication to and from the model can take place.

Does that make sense? I think that there should be less emphasis on the overall model at this point because that is the part that is the most application specific and not really part of what wxPython should provide. wxPython should just facilitate the use of an application specific model and provide an interface for doing so.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hi,

I thought I would participate in this interesting thread, as I've
tried (yes we are quite a few!) to develop some MVC ideas around
wxPython.
The nature of wx callbacks makes it quite unnatural sometimes, and the
architecture makes it much easier to put business code in the
callbacks. Maybe a way to go to make wx more MVC friendly would be to
provide an easier access to custom event creation, and be able to bind
them to a Controller class that would have nothing to do with the
widgets. That way the usual widgets that inherit from wxWindow just
implement visual sweetness, while business code which lives a a
(Layered) Model and can be triggered from a controller.

Anyway, the implementation we chose makes heavy use of Louie
(pylouie.org), which seemed the best signal handling library around
(with no "alpha" disclaimer bundled!).
The good thing about Louie was the flexibility of its Signals, which
can be anything.

As well, some interesting ideas are to be found in Cocoa, with a nice
introduction in

Cheers,

Aloys

···

On Sat, Jun 7, 2008 at 9:35 AM, Robin Dunn <robin@alldunn.com> wrote:

Mike Rooney wrote:

Ahh, I think I have it now. Basically I could create a BaseModel class
which had the generic logic to call abstract methods to do validation, like
my previous example of adding an account. In this case it could do "if
accountName not in self.getAccounts(): self.addAccount(accountName)". Then I
would subclass this for each storage mechanism which would just implement
the methods which manipulate the data (like getAccounts and addAccount).

That will get me the abstraction of business logic that I want (is it
proper to call that business logic?), while keeping it in the Model. I think
this makes a lot of sense. Unfortunately I think this means my Controller
doesn't do much after moving that sort of business logic, so I have to
figure out what I have in the View that belongs there :]

Or take the abstraction one step further use a plugin type of approach for
the data storage. In other words, think of the Model as being composed of
two layers, the application (or business) logic layer, and the data storage
layer, where the data storage layer is replaceable with some model method
like SetStorageProvider(storage). Then I guess it would be a DsMVC pattern.
:wink:

On the other hand, typically most of the DsM parts of the pattern are going
to be what varies the most from application to application, or from
developer to developer, so I think the main thrust of this project should be
in the two other areas:

1. Add-ons, wrappers, delegates or whatever is needed for being able to use
the existing or future wx widgets in a coherent and consistent View
framework.

2. A set of components or leggo blocks that can be assembled together to
represent the objects active in the view and that facilitates their
interfacing with the Model. These components could technically be part of
the view classes for each widget or collection of widgets, but they would
plug themselves in to a framework where they cooperate together as the
Controller. Another way to look at these component blocks is that they are
what adapts the different data, event and display needs of each kind of view
object into a form where communication to and from the model can take place.

Does that make sense? I think that there should be less emphasis on the
overall model at this point because that is the part that is the most
application specific and not really part of what wxPython should provide.
wxPython should just facilitate the use of an application specific model
and provide an interface for doing so.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

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

--
Aloys Baillet
Research & Development - Animal Logic
--