Mark Erbaugh escribió:
I've a design based on MVP, Model-View-Presenter --there's some about mvp in the wiki.
Jonhatten,
Thank you for your explanation. I had discovered the MVP write up in the
wiki and I am working through it. I noticed that Martin Fowler has
depricated the MVP pattern:Retirement note for Model View Presenter Pattern
and replaced it with Supervising Controller and Passive View patterns.
I haven't had time to study this yet.
This is the original draft of MVP, by Taligent, a subsidiary of IBM.
I see Both Supervising Controller & Passive View as flavours of MVP. That is, sometimes the presenter controls the view to the widget level (Passive View), sometimes, the view takes control over the view logic and the presenter acts at a higher abstraction level.
What I use to do is:
1) what I call "local bindings" (a bind done in the view itself)... to manage some basic logic. Ej: change the available options of a widget based on the value of other: if sex.GetValue() == 'male': kinships.SetValues('father', 'brother', 'son') else: kinships.SetValues('mother', 'sister', 'daughter')
2) Let the Presenter do the more complex operations, instructed by the event binding in the Interactor. As an example, after "country selection" in the View, the Interactor ask the Presenter to provide the View with the states of given country (the Presenter will ask the Model and when data is available, notify the corresponding window).
It naturally seems 1) is more like a Supervising Controller, 2) more as a Passive View. I haven't read deeply on SC and PV, but I feel comfortable with my rule of not letting the Presenter do trivial stuff on the View, and let the View do as much as it can in it's own concern with the available metadata.
-- jonhattan
···
On Thu, 2007-12-06 at 11:09 +0000, jonhattan wrote:
I think I have essentially implemented the functionality of your
interactor. Currently, it resides as a method in my view (wx.Frame)
class, but I have been thinking of separating it from there. Basically,
the wx.Frame descendent has a method, SetController that takes an
instance of the controller and then binds events from the wx.Frame to
methods in the controller.
One refinement I made was the ability to un-bind the controller before
cleanup. I found a case where, depending on the order that things were
destroyed, an event handler tried to update a widget that had already
been destroyed. Fortunately, I was able to come up with generic
un-binding code that uses the same code as SetController, so the the
un-bind method is generic. That means that you only have to hand-code
the binding of event, you don't have to hand-code the un-binding.As I mentioned, I've been thinking of moving SetController out of the
wx.Frame class. Actually, I'm thinking of moving the SetController
method to a sub-class of my wx.Frame sub-class. That way it would still
be able to access all the widgets via self. One reason I'm considering
this is I use a GUI design tool (wxGlade) to design the frame. By
splitting SetController and the other hand-coded routines into a
separate file, I can re-run wxGlade and allow it to completely re-write
it's Python output file. With the design I have now, I have to make sure
that wxGlade doesn't overwrite my hand-coded changes.
Mark