Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Seeking MVC Wisdom

by coreolyn (Parson)
on Sep 02, 2001 at 21:56 UTC ( #109765=perlquestion: print w/replies, xml ) Need Help??
coreolyn has asked for the wisdom of the Perl Monks concerning the following question:

This node is forcing me to expose some basic ignorance. I run into the Model-View-Controller (MVC) paradigm frequently and need a better working understanding of it.

While I understand it theoretically I often feel I'm missing things when it comes to implementation. Does anyone have good code/documentation to point me at? I don't know why but if I see it in Perl I grok it in other languages, whereas the reverse just doesn't seem to do it for me. If I just continue to keep my business logic abstracted from my presentation I seem to be ok to some extent, but it is in the knowing of when and where to implement the 'Controller' functionality that seems to lose me.

coreolyn If ignorance is bliss why am I continually embarrased by it?

Replies are listed 'Best First'.
Re: Seeking MVC Wisdom
by bikeNomad (Priest) on Sep 02, 2001 at 23:30 UTC
    MVC is actually quite simple. What complicates discussions of it with respect to old Smalltalk systems is that it was tied up into the UI paradigm of the time. You have three actors in typical MVC:
    • the model: the actual object of interest (I would say "business objects" but that's too limiting, of course). These have no idea how they're being watched or controlled, just that they may be. They notify interested Views of potentially interesting changes to themselves.
    • the view: what gets notified when the model says that it's changed
    • the controller: this is what (in Smalltalk MVC systems) translates user input events (mouse/keyboard, etc.) into actions on the model.
    Many newer UI systems based on windowing systems merge the view and controller into a single widget. So the C in MVC is mostly not useful. This is why (for instance) the Observer pattern in Design Patterns only has two participants (once you get past the C++ inheritance crap). The important idea is this: the model notifies views when it changes. The views then can update themselves as needed. The easiest implementation of this is to have each model keep a list of views. Upon a change, the model sends a message to each of the views saying that it's changed. Some systems include an indication of what has changed.

    package Model; # mix in to model classes that are # implemented as blessed hashes # This is called by a View sub addDependent { my $self = shift; my $dependent = shift; my $dependents = (self->{dependents} ||= []); push @$dependents, $dependent; } # This is called by a View sub removeDependent { my $self = shift; my $dependent = shift; my $dependents = $self->{dependents} || return; @$dependents = grep { $_ != $dependent } @$dependents; } # This is called by the Model # you can pass additional data as needed sub _changed { my $self = shift; my $dependents = $self->{dependents} || return; foreach my $dependent ( @$dependents ) { $dependent->update($self, @_); } } package View; # mix in to observer classes of any kind sub update # stub: do nothing { my ($self, $model, @aspectData) = @_; }
    Then this gets used like this (in a Model class):

    package MyModel; @MyModel::ISA = qw(SomethingElse Model); sub changeSomething { my $self = shift; my $value = shift; $self->{something} = $value; $self->_changed('something', $value); } package MyView; sub update { my ($self, $model, $aspect, $otherStuff) = @_; # hey! $model has changed its $aspect! } package main; my $view = bless {}, 'MyView'; my $model = bless {}, 'MyModel'; $model->addDependent($view); # now the following # calls $view->update($model, 'something', 123); $model->changeSomething(123);
    The passing of the new value is an optimzation, and is not strictly necessary.

    update: added more sample code

      Man I had to be AFK for a bit and I finally got back to this node -- and the lightbulb is finally lit! Man this is an awesome site -- thanks all :)

Re: Seeking MVC Wisdom
by Masem (Monsignor) on Sep 02, 2001 at 22:36 UTC
    Unfortunately, I don't think you're going to find a lot of good MVC-based code yet in perl as most of the GUI toolkits don't have a strong MVC base (that's coming around, but it's not quite there yet). Most of these toolkits tend to be built around the global event loop, and while MVC can be written to fit that, it's typically not a perfect match.

    If anything, a good Java book may be the best way to understand the MVC concept better, particularly one focused on Swing components.

    Dr. Michael K. Neylon - || "You've left the lens cap of your mind on again, Pinky" - The Brain
    It's not what you know, but knowing how to find it if you don't know that's important

Re: Seeking MVC Wisdom
by princepawn (Parson) on Sep 02, 2001 at 22:50 UTC
    In this node I give a tutorial on MVC-based dynamic HTML development.

    The module I give the tutorial on is withdrawn from CPAN, but I rewrote his module and will upload it in about 1 month under that name Apache::Seamstress.

    Once I have a whole website done entirely with it, I will feel it is sufficiently debugged for public use.

Re: Seeking MVC Wisdom
by princepawn (Parson) on Sep 03, 2001 at 01:22 UTC
    and of course, we need to consider what Terence Mathers calls his MVCC (model-view-content-controller) paradigm, where model is business objects, view can by any of PDF, WML, HTML, content is XML and controller is Apache::PageKit

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://109765]
Approved by root
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (9)
As of 2017-03-25 12:52 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (311 votes). Check out past polls.