Hi Nate,
On Jan 12, 2009, at 4:29 AM, Nate Lowrie wrote:
> On Sun, Jan 11, 2009 at 2:48 PM, Michael Hipp <Michael@hipp.com>
> wrote:
>> Kevin Ollivier wrote:
>>>
>>> What do you mean by "patched-together" methods? And I think
>>> countless is
>>> probably at least a slight exaggeration. ;-)
>>
>> Hehe. Maybe not. I was just looking at one of my early
>> controller.py files
>> that had grown to 2400 lines and was no-where near finished. (That
>> app is in
>> dry dock right now for some serious refactoring.)
>>
>>> I think what you really mean to say is that you feel MVC creates a
>>> lot of
>>> unnecessary overhead, at least in 'simple' cases (which rarely
>>> stay that
>>> way, but I digress), but MVC is mostly just about changing where
>>> you put
>>> your code. You don't really have to write much extra code for MVC.
>>> It just
>>> looks extra because now it's clearly separated rather than being
>>> all tangled
>>> together.
>>
>> Good points. I think it /seems/ like I'm having to write code that
>> - if not
>> longer - is more complicated. In the app referenced above I've
>> ended up with
>> quite a number of views that need to hear from the model several
>> times (and
>> in different ways to do autocompletion, validation etc.) all during
>> the
>> course of what (to the user) is a single screen. So I end up with a
>> pretty
>> long list of event handlers that send messages and then a long list
>> of
>> subscriptions in the controller that all lead to different handlers
>> in the
>> controller which make calls into the model to get answers and then
>> those
>> answers must find their way back to the view.
>>
>> Anyways, it's a lot of routines and it all lacks
>> "encapsulation" (for want
>> of a better term) and the "flow" is very hard to follow and
>> document. It
>> adds yet another layer of "event driven" that doesn't always seem
>> welcome.
>>
>> I'm finding ways to improve on that sad condition. But I've learned
>> that
>> implementing controllers in the real world isn't always easy or
>> obvious.
>> Imagine that. ;-)
>>
>>> Anyway, here's the golden rule and core tenet behind MVC - the
>>> View should
>>> not directly touch the Model. I think once you decide you can't
>>> break this
>>> rule, all of a sudden where things go starts to become pretty clear.
>>
>> ...
>>>
>>> So long as your code does that, it is IMHO for all practical
>>> intents and
>>> purposes MVC. :-)
>>
>> Thanks for your insights, Kevin. I read that thru twice and
>> appreciate your
>> "principle driven" approach to the design.
>
> I think it is time for myself to weigh in here. I think MVC design
> shows it's true potential in a TDD environment.
Yes, I totally agree.
> I am a TDD
> practitioner and MVC is really the only way to allow me to test
> application logic. That is because I can decouple the controller
> logic with the wx code. Testing GUIs is darn near impossible.
Well, you can still test a lot, see the wxPython unit test suite. And
I someday do hope to finish the mouse and keyboard event simulator
I've gotten working on Mac to be cross-platform, so that you can
'fake' user interaction and thus test things like events. I don't know
if we'll ever be able to get to 100%, but I think we could probably
approach somewhere around 80% at least. There's no reason GUI code
needs excluded from testing - if anything, we just need some creative
thinking. ;-)
Of course, you'd still want the separation you mentioned anyway
because you should always test each component in isolation if possible
IMHO.
> If I
> have my application logic in a class that subclasses a wx widget, I
> can't even test it at all in isolation. This is because I can't mock
> out a superclass. It's impossible in Python. By separating the
> controller, I can instead inject a mock object in for the view
> completely eliminating the wx dependency. The controller doesn't
> care. It just cares that a object is there to pass it data. It may
> be extra code, but it is well worth the testability.
>
> Which brings me to my second point. Wx is a GUI library. It's
> functionality completely centers around the view which is OK.
> However, in order to realize the full potential of MVC and make it a
> joy to operate in, you need to work in the confines of a framework
> that centers around MVC design. A very good example of this is Rails.
> The Rails framework encourages MVC to the point of mandating it in
> designs. It also facilitates communication between the model,
> controller, and view so your application code is elegant yet still
> fully testable.
Cocoa is the same way, and I think you're totally right that the lack
of some defined framework for doing these things in wxPython is really
making it more difficult for people to work with MVC in wxPython apps.
I hope we can get another shot at it for this year's Google SoC, but
of course any contributions to help this project along would be
welcomed. :-)
Regards,
Kevin
> Until you can abstract the repetitive things into a
> framework, your code is going to be long and messy.
>
> MVC design is worth all of the hassle for the testability through
> decoupling it brings.
>
> Regards,
>
> Nate Lowrie
> _______________________________________________
> wxpython-users mailing list
> wxpython-users@lists.wxwidgets.org
> http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
-->