Still assuming that Client is the request class, it is not composed of the other classes; it makes requests from them. The difficulty for me is that the MVC does not show any particular relationship to a Client class in a class diagram outside of those that are made by developers. In Figure 2 above, my Client used MVC objects, but that is not part of a design pattern. Rather, it’s how I decided to use the MVC for that particular application. Now, compare that with say the Proxy pattern. The Proxy shows where the Client is implied and the relationship it holds with the Subject participant.

If I’m not mistaken, you want to use the Client to attend to several different chores that you do not see as belonging to the M, V or C. In this particular case, I believe that the View would be in charge of setting up listeners; so no, that would not be the job of the Client.

The best summary of the jobs of the MVC is the one Chandima did on page 429. Everything is broken down for you. Take a look at it, and let me know if that helps more than I did (or failed to do!).

Kindest regards,
Bill

I think if I give you a better example it’d be easier for you to answer me.

Say I have an class, let’s call it Client, that is being composed of 3 other ‘objects’, each of which is broken down into it’s own MVC triad. So would the Client class have 9 classes in total, i.e. object1Model, object1View, object1Controller, etc.??

On top of that, say when object1’s model gets updated and it has to affect object2’s view and model. I’m almost positive the Client class would be in charge of setting up the listeners as object1 would have no knowledge of object2 and vice versa.

Hopefully that makes things less broad.

Thanks again.

For me, the Client class is always the class that makes requests. Sometimes the Client is part of the design pattern (shown in the class diagram), sometimes it is implied (shown in the class diagram as ‘ghosted’ in gray), and sometimes you don’t see it at all in the diagram.

Strictly speaking, the MVC is not part of the original set of design patterns. Rather, I see it as a heuristic device to help understand design patterns. However, since the publication of the Gang of Four’s book, it seems to have taken on a life of its own and developers use it for different things. (Chandima is the real MVC expert.)

Most programmers seem to use the name Main for their Client class—I have as well on occasion. So if you look at some MVCs, dig up Main.as and you’ll probably be seeing what GoF reference as the Client. You can see a good example of this with the MVC on page 436 of our book.

Let me know if this explains what you need.

Kindest regards,
Bill

Thanks!

I see what you mean. Take a look at the Mouse properties and see if you can slip in a value in one of its properties from the TextField–using one of the Focus events to pass it to the button and then on to an event handler in the Controller.

I’m pretty sure you can do it, but it will take can artful dodging and might be a little hacky. It sounds like a fun little project, though. If I have time, it’s something that I’ll play around with, but don’t let me have all the fun!

Take care,
Bill

A text field would work fine using a button and MouseEvent. Just change the event handler function (newDirection) to the following:

1
2
3
4
5

public function newDirection(e:MouseEvent):void
{
      var dirNow:Number=Number(myText.text);
      model.setDir(dirNow);
}

It’s just data and how it gets to the compass shouldn’t matter.

Kindest regards,
Bill

Best
W.

I’d be very interested in hearing what you have to say about the MVC (and other Design Patterns) from the PHP perspective. I’ve worked with PHP for years, and I really like the language, and Chandima and I have begun some work on DPs and PHP.

What would you say is the main difference between the MVC in PHP and ActionScript 3.0? Take a look at Part IV of this MVC series and see if that increases or reduces the difference between PHP and ActionScript 3.0 use of MVC.

Thanks and hope to hear from you more,
Bill