Flash
 OOP

So ehh, all that stuff and still nothing about that gallery:
Fine, I’ll treat you on a diagram for your sore eyes then.

I took over Moock’s style for these diagrams, since I already had so much use from his book Essential Actionscript 2. You can see at the colors what pattern they belong to and how the gallery classes consists of these.
The two interfaces Observer and View define a set of functions for their patterns and AbstractView implements all of these to define the basic functionality for a view of the mvc pattern. This is to observe an observable object, the model, and to be able to communicate back to the model either directly to retrieve data or more commonly via the controller to request changes. GalleryView is such a view as is ControlsView.

GalleryView creates the interface of the gallery and ControlsView is part of that (with the previous and next buttons). First I had GalleryView as the only view, but then it was hard to communicate with the model, which only the GalleryView could do. So I made the controls also a view.

Then there is the Controller, who can directly talk to the model and optionally make changes. The GalleryController receives requests from both views and makes sure the model reacts accordingly. The buttons ask the model to activate the previous or next image, the thumbnails ask for a specific image and the GalleryView requests that the model loads the next image from xml after the thumbnails bar on the left has preloaded and shown the last thumbnail.

And then there is the observable, our model, which contains all the gallery data (title, image list, current activated image and percentage of total images loaded from xml).

Last is the GalleryUpdate class. This class contains all the data I just mentioned and the nature of the update. Or rather the state the model is in (starting up, loading images, viewing images etc.).

Here’s an image that shows the various classes.

These are all the custom classes in the gallery project. All the white classes are actually assets in the library with a class attached to them. These have the benefit to already have graphical stuff done and can easily be changed to alter the way the gallery looks. They actually have more objects, but they are all MovieClips which I haven’t listed here, but they are part of the white classes.

The GalleryView has a ViewArea, the main window where the image is viewed. Also has the NavBar, which contains the ThumbImages. GalleryView also has the ControlsView, which has the button previous and next. The NavBar also has the slider.
ViewArea and ThumbImage extend PreloadImage because they both have load an image from an url and both need to preload them before showing. Perhaps a poor choice of name, but it does the job. PreloadImage makes use of our custom preloader class, which is actually just a listener for a MovieClipLoader, as the cliploader calls methods on its listeners like onGetProgress().

So that’s it. I’m not going into the classes, that would be too much work, but I have commented them enough so you should be able to understand it. Look back at these diagrams to see how the classes relate.

Adding slideshow functionality:
Ok, when I said that this is easy to do, I didn’t lie. All you need to do is add a button to the Controls asset, and when that button is hit, it sends a request to the model telling it to slideshow the images. The model then updates the active image at an interval and sends an update to all the views each time.

Step by step:

1. Go to the GalleryModel class and add these two methods

[as]
private var id:Number = -1; // I did the assignment in the constructor

// switches the slideshow mode
public function switchSlideshow() {
  if (id == -1) {
  id = setInterval(this, “nextSlide”, 5000);
  } else {
  clearInterval(id);
  id = -1;
  }
}

// slide to next image, called on an interval if in slideshow mode
private function nextSlide() {
  cycleImage(1);
}
[/as]
2. Go to the GalleryController class and add this method

[as]
// makes the model show (activate) the next image in the imagelist
public function switchSlideshow() {
  GalleryModel(getModel()).switchSlideshow();
}
[/as]
3. Open up the controls mc asset in the library and add a button. Give the button the name “btn_slideshow”. I made it between the buttons previous and next.

4. Open the class Controls, and add the public variable btn_slideshow:MovieClip. Now we can use the button inside the class.

5. Open up the class ControlsView and add this method

[as]
private function switchSlideshow() {
  GalleryController(getController()).switchSlideshow();
}
[/as]
and in the constructor, add this line

[as]
controls.btn_slideshow.onRelease = Delegate.create(this, switchSlideshow);
[/as]
And you’re done! You could make the slideshow show random images by using this instead.

[as]
// slide to random image, called on an interval if in slideshow mode
private function nextSlide() {
  cycleImage(random(images.length));
}

[/as]
And all the views controls and stuff update correctly. See the thumbs highlighting with each image?

Wheyhey! Very nice, Codemonkey.

I haven’t read through it all in detail yet (I’m pulling an all-nighter so I’ll read it all later on) but it’s all looking good.

Let the battle of the Galleries begin.

A quick question for you…

As far as the MVC pattern goes, am I right in thinking that the Model only sends data to the View, and the Controller only sends data to the Model?

Originally posted by Nutrox
Wheyhey! Very nice, Codemonkey.

I haven’t read through it all in detail yet (I’m pulling an all-nighter so I’ll read it all later on) but it’s all looking good.

Let the battle of the Galleries begin.

A quick question for you…

As far as the MVC pattern goes, am I right in thinking that the Model only sends data to the View, and the Controller only sends data to the Model?

In my implementation yes. The model sends data to the view using an info object, and the controller pulls the strings in the model on requests by views. The only other way would be if the views used getter methods in the model instead of using the info object.

Thanks

very nice. i shall have to play around with this one a little later.

Wonderful, Codemonkey.

Very nice.

Thank you!

Another question for the Codemonkey.

Which class in the MVC pattern would handle the re-positioning of movie clips when the Stage was resized ( Stage.onResize ) ?

I imagine it’s the View class, but is it viable for something outside of the MVC pattern to deal with Stage resizes?

Yeah, I put it in the GalleryView (since that class is responsible of creating the interface). I could’ve included it in the function setupStage in the Gallery class, that’s is the jumpstart class for the application.

But wherever it is, it has to be able to get through to the gallery view, to be able to call its realignmethods.

Btw, did you hit the keyboard with your head yet?

Nice example monkey, I’m sure plenty of members will find it very helpful

In regards to the stage resizing, would it not be the case that a controller would be responsible for reacting to a stage resize event and calling an appropriate function of a custom stage object in the model to set it’s new state.

Using your chosen implementation of the MVC pattern, Views can then register with this custom stage object and position themselves according to the info object (data transfer object) sent to them.

If the stageresize had an impact on the actual data inside the model, I would say yes, the controller should update the model (or its stageobject) and then the model can update the views. But, since the stageresize is an aesthetic change only (not a change to match the model’s data), the controller is allowed to update the view directly.

As you said though, the controller should probably be watching the stage for resize events, not the view.

Originally posted by Codemonkey
...
Btw, did you hit the keyboard with your head yet?

Hehe… nope, not yet. I’ve done that thing where you stare at the screen for about 10 minutes in a mind-numbed state though.

You’ve actually got me interested in this whole MVC thing so I’m trying to structure something similar at the moment, but I’m including a class that handles audio as well ( Model, Display, Controller, Audio ). The Audio class isn’t part of the “chain” though really, it’s just connected to the Model class ( Model >> Audio | Model << Audio ).

I might also use a Global class that contains static pointers to the Model, Display, Controller, and Audio classes… and then simply import Global when one class needs to talk to another. I’ll see how it goes though.

Originally posted by Codemonkey
If the stageresize had an impact on the actual data inside the model, I would say yes, the controller should update the model (or its stageobject) and then the model can update the views. But, since the stageresize is an aesthetic change only (not a change to match the model’s data), the controller is allowed to update the view directly.

As you said though, the controller should probably be watching the stage for resize events, not the view.

I see where you’re coming from. Let me give some reasoning behind what I said.

I believe the controller should only directly update the view if there is no change to the related model’s state (data), say reordering your images into alphabetical order for example.

I would say the Stage itself should be represented in the model as it has a state (alignment..) and these can be changed. As such this should not be done directly by the controller.

WOW. Nice. You guys are awesome. For me it is a HUGE HELP!

Hats down to you!!!!!!!

Imre

Originally posted by BadSanta
I would say the Stage itself should be represented in the model as it has a state (alignment..) and these can be changed. As such this should not be done directly by the controller.

I see your point. Then the real question is: is the stage size ‘state’ part of the gallery data, or part of the interface that represents it?

Why do you feel the stagesize part of the galleries intrinsic properties if not of the interface?

Ah ok, I think I get what you’re saying (when you say interface I always think code ).

Well in this setup, your stage happens to only hold one view (GalleryView). Say the stage held 2 or more views at one time, then which one would have the stage size as their properties? Both, could be one answer but that’s not very scalable.

My current line of thought would be to have a singleton, say StageModel, that views can subscribe to (along with other views) through their controller.

Oh that’s another thing, it’s perfectly valid for a view to subscribe to more than one model at a time. You would have to refactor your code slightly to allow this.

I would also be tempted to put stage resize listener directly into this StageModel as the width and height properties are read only and could not be set through a controller anyway, only alignment etc. can… but that’s probably not the most “correct” thing to do for reasons stated previously (a controller should handle input events, but in this case the event has already update the stage x/y props, so what else would the controller need to do to the StageModel? Hmm but then again perhaps you would want the controller to perform some other custom action after a stage resize.. yeh I take it back in the controller is better! ).