09 Oct. 2007 - Added references other people's related work
- Nutrox' Google public project Neondust base Framework
- wraevn's AS3 version of this web gallery
13 May. 2007 - Added references for further reasearch
-------
MVC Gallery in-depth

So after a night of coding Saturday I finished the mvc gallery project. After some more time I got everything commented as well. It got much more than I intended. I had something like Nutrox made in mind, to just demonstrate (and get myself familiar with) the mvc pattern, but I couldn't let it go . Anyway, if you would like to know what this gallery is all about read on, otherwise just download the source and see if you can use it. It’s not really a tutorial and it may or may not be very dry to plow through. I don't tell very well, but let’s just get down to it shall we?

demo
MVC Gallery source
image folder
note: I used Nutrox' html file from his tutorial (hope you don't mind )

First things first, what are those patterns and why we need them. If you are familiar with the principles of these design patterns, you might want to skip ahead to the second post. How to make the gallery do a slide show is in the third post.

Introduction Singleton pattern:
This is the smallest and easiest pattern I know. It involves only one class, and has little to no implementation. The point is to make a class so, that you can make only one instance of it. This is done using a static class method that stores an instance variable. Only if that instance variable is null or undefined, it will make a new instance of this class. More information here

Check out these discussions about singletons on Ultrashock as well:
Singleton pattern and globals
MVC with screen manager (singleton suggested to manage screen instances with)

Introduction Observer pattern:
The observer pattern is pretty simple. Its objective is to make sure everybody listening at a single object knows when that single objects has changed or is doing something they should know about. The observer pattern defines a few specified methods for an Observable and one method for the Observer. The observable object needs to do some registering and stuff to get all listeners together and the observers just need to implement a method called update, which is called by the observable. Check this link for some more information.

Introduction to MVC:
MVC isn’t really hard to understand, but the possible combinations can cloud things up. The basic principle is: the model is the data organizer and container. The view uses this data to create a (graphical) representation. If the view wants to changes anything to the model, like when you hit a button or something, the view has a controller in its arsenal to make it happen. Everything to preserve the distance between the model and the view. Even so much, the model prefers to send through data using a single info object and the view prefers to get it that way (otherwise the view would have to ask the model for information).

So how is the communication done between the model and the view? Through the observer pattern. It’s perfect, the model can be an observable, and the views are observers and so they can receive updates from the model. The observer pattern is perfect for this, because this is a relatively small project. A webgallary is nothing compared to an enterprise big company project. If it were such a project, we would need something more robust than observer, say an event delegation model.

For a very good walkthrough, check out Moock’s piece, most of what I know of the mvc came from there anyway.

For a very in-depth look at MVC, check out this site:
http://www.phpwact.org/pattern/model_view_controller

Why these patterns, you can do it without them!
Well… that’s true. But the bigger your project gets the more code and like you saw in my first attempt on this thread (not the very first though), you can see code is already clouding up on several layers. There is no order, no obvious ‘flow’, and everything can touch everything and so you are working one of those huge knots, like those you get your headphones in, except bigger. Sipher asked me if it was possible to add in sliding. Well, if I did it like before, then I would have to say I don’t know… probably, and not easily. I would have to look at the code to see ‘how I did it again’, but with this mvc version it is really, really simple. I’ll show you how when I explained how the gallery works.

XML is the glue of the future.
"Alkland's in Jeamland," I said. "Do you know what happened? I fell awake."

[Codemonkey]

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.

[Codemonkey]

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

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);
    } 

2. Go to the GalleryController class and add this method

// makes the model show (activate) the next image in the imagelist
    public function switchSlideshow() {
        GalleryModel(getModel()).switchSlideshow();
    } 

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

private function switchSlideshow() {
        GalleryController(getController()).switchSlideshow();
    } 

and in the constructor, add this line

controls.btn_slideshow.onRelease = Delegate.create(this, switchSlideshow); 

And you’re done! You could make the slideshow show random images by using this instead.

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

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

[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?

[Codemonkey]

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

[sentinels]

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

[Renjamin]

Wonderful, Codemonkey.

Very nice.

Thank you!

[Nutrox]

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?

[Codemonkey]

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?

[Mike]

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.

[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.

[Nutrox]

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.

[Mike]

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.

[imreimi]

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

Hats down to you!!!!!!!

Imre

[Codemonkey]

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?

[Mike]

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! ).

[Nutrox]

I've decided to put the Stage.onResize related stuff into the Controller.

The reason is that the user can click on a button to adjust the size of the GUI manually, and the Controller would need to catch that request and update the Model.

It makes more sense to me to have the Stage.onResize event call the Controller in the same way the View does when the user manually resizes the GUI, because both events are the same as far as the Controller and Model is concerned, and both events have exactly the same result ( the Model and View are updated ).

[Chaosfact]

I wish one day I could understand how the hell you did that.

[Codemonkey]

Originally posted by Nutrox
I've decided to put the Stage.onResize related stuff into the Controller.

The reason is that the user can click on a button to adjust the size of the GUI manually, and the Controller would need to catch that request and update the Model.

It makes more sense to me to have the Stage.onResize event call the Controller in the same way the View does when the user manually resizes the GUI, because both events are the same as far as the Controller and Model is concerned, and both events have exactly the same result ( the Model and View are updated ).

Yes, then you labeled the Stageresize event as a view itself that updates the model via the controller, like any other view. BadSanta wants it to be part of the model, or a completely separate model.. and I still don't know what I want

Originally posted by Chaosfact
I wish one day I could understand how the hell you did that.

Don't worry, I was where you are not so long ago

[sipher]

sorry to ask but .. how come the photogallery doesnt work in my comp it just give me alot of errors .. damn i feel dumb asking this

[Codemonkey]

I don't know?
Do you have AS2 turned on?

[sipher]

thanks CD
never mind it works now

[trikster00]

Wow Codemonkey... Most impressive. I cannot believe how many different AS files are here for this all to work. Is if even feasible to do (the final outcome; your demo) in one swf without having all the external AS files?

[Codemonkey]

Well, the .as classfiles you probably are referring to are compiled into the swf. So when publishing, all you need is the swf and the images in the gallery (and the html file).

[tcoulson]

First of all, I don't want to start on a negative note:
This is a great implementation. It is a very good example for learning MVC (which all of us can use) and is a great "tutorial" for learning how to extend classes and learn how interactions of classes may work. Outstanding work codemonkey!

My concerns are two fold:
1. Why not make more properties for the view available through the fla? My point being, this is very easy to create a new class, make a slideshow, and point it to an image folder. But if you passed this off to a "designer" they would have very few options available to them, to resize the piece, give information about layout of thumbnails, location of main image, size, background color, ect? I would think extra properties for the fla would make sense, to make this Gallery singleton very easy to change on the fly. Then making it a tool that can be used by anyone inside of the fla - then it can intermingle with other elements you create in the fla. It could even become a listener to other things going on in the root fla.

2. It is called "slideshow" but I see no timing elements in it? I have created a "Timer" class, which could probably be added to this to trigger a new image after a set amount of time passed. If you want this class, email me at todd@haleypro.com.

Otherwise, this rocks, can't wait to get deeper into it.

[Codemonkey]

I'll bite

1. You're right, the gallery should be as dynamic as possible and controllable by any developer. Which is exactly how I tried to create it. The whole point of MVC is to have one central model with all properties and changeable data. The model hinges on the xml file. This means that whatever the developer wants to change it just has to update the xml file and make sure the model uses it and passes more data to the views in the Update Object. Now as you can imagine I kept the xml file and the model quite simple for sake of overview, but if you truly want to make it dynamic you'll want to add sections to the xml for every part of the gallery, like navigation parts with buttons size position where to get the images of the interface from etc., categories for the images and whatnot.

2. It's not called slideshow, but webgallary.... but, I did add a slideshow option to it (did you read the "adding slideshow functionality" post?). See the two small buttons between previous and next? Those are slideshow normal, and slideshow random, both are timed at 5 seconds.

[tcoulson]

You're right, the gallery should be as dynamic as possible

It just seems like there needs to be more getter/setter methods or parameters for the singleton Gallery class to make those options available on the fla level, instead of a designer having to open actionscript code to create those permutations. That was my only point. I do think you have made this very changable and updatable, and it is very flexible.

It's not called slideshow, but webgallary

My bad, that serves me right for skimming the post.

[Codemonkey]

Originally posted by tcoulson
It just seems like there needs to be more getter/setter methods or parameters for the singleton Gallery class to make those options available on the fla level, instead of a designer having to open actionscript code to create those permutations.

Ahh, I think I misunderstood you before. Ok see, the setup is actually meant to contain everything possible within the webgallary, making setters/getters obsolete altogether. The idea is to make it as robust as possible so that any user really only needs to customize the existing attributes in the xml, but not update the gallery code itself. In the example, yes you need to dig into the code to actually make it robust, but mind you this isn't a release version right.

You could make it a setter/getter version on fla like you said, but doing that would make it some AS1-2 hybrid, which could be ok I guess. But then you would need to make the xml reading etc. also apart from the gallery itself, so you can call setters/getters according to the xml file. Is that what you meant?

[tcoulson]

making setters/getters obsolete altogether

I just don't think that is a good idea. I think a lot of coders get so wrapped up in making everything encapulated into AS files and a single keyframe on the timeline that they lose sight of how having code on the main timeline is not a detriment in all cases. This is why Macromedia brought back the Normal mode - terrible move, but they did it so that the program would be more designer friendly.

In the example, yes you need to dig into the code to actually make it robust

That is why I think it is a problem. To a designer - they won't dig through the code to make it three columns of pictures instead of two - they just wont. They won't dig through code to change the background color of the gallery. [/quote]

but mind you this isn't a release version right

Here is where I agree with you. It isn't a release version, it is a learning OOP exercise, this is why I think what you have done is fantastic, it is going to reinforce a lot of what I have thought about in the past. And it is a great piece of work. I am just making suggestions to make it ready for prime time.

but doing that would make it some AS1-2 hybrid

AS1 is not the devil if it makes your code usable to more people.

make the xml reading etc. also apart from the gallery itself

I am not suggesting touching the xml. I think the handling of that is perfect. But in the same vain, I think you should set up some default values, like number of columns, colors, buttons, ect that the user can set right along with the xml path parameter - then make some getter setter methods that they can change those parameters on the fly if they choose. That's all. Preserve the xml handling though, I like the way you are doing that - just handle a few more options in the same way.

[tcoulson]

PS- If I get some extra time this week, maybe I will extend it and show you what I mean.

[Codemonkey]

Originally posted by tcoulson
That is why I think it is a problem. To a designer - they won't dig through the code to make it three columns of pictures instead of two - they just wont. They won't dig through code to change the background color of the gallery.

That's just it, nobody needs to be digging in the code with a release version, that's the whole point of it. It's all in the xml file by then.

I understand what you mean, and for designers it's probably convenient to be able to run changes on the fly using getters and setters, but I'm not just copulating code here. The class Gallery is the application not the webgallery. The application creates the webgallery and so to change anything using setters/getters you do that in the application using setters and getters that are on the singleton webgallery instance inside the application class, not in the main timeline.

I guess its a matter of taste to treat the Gallery class with static run() as an application rather than the main timeline.

[tcoulson]

yeah, we are in an argument of taste. I always make getter and setters so that my designers around the office don't need to understand my code. Or even look at it for that matter. I would rather they assign values to create the makeup of it and not have to know xml or flash actionscript to create it. But like i said in the start, it is a preference not an absolute.

[Nutrox]

I will leave you two to continue to discuss this, the only input I have is:

I think getters and setters are a good thing is most situations, especially when you want to allow someone to change property values from withing Flash ( without touching the actual class code or other external files ).

Components are a classic example of where getters and setters can come in very handy, and most of the Macromedia classes use getters and setters in one way or another.

Don't forget we are not talking about C++ here. Trying to follow all of the C++ (etc) rules when using ActionScript just seems odd, and in the world of Flash it can sometimes also be limiting.

If we can create a class that extends the MovieClip class, and allow someone to change the appearance of the movie clip using getters/setters, then we shouldn't feel doing that is "bad" in any way. That's what Flash is all about, it's a kick ass dynamic/visual/code hybrid monster, and I love it for being that way.

[Mike]

Originally posted by Nutrox
If we can create a class that extends the MovieClip class, and allow someone to change the appearance of the movie clip using getters/setters, then we shouldn't feel doing that is "bad" in any way. That's what Flash is all about, it's a kick ass dynamic/visual/code hybrid monster, and I love it for being that way.

Agree entirely with this statement. It's a little like the code behind in C#. Separate the code from the view, but in this case we also allow the designer to set properties in the IDE during design. Very powerful, allowing the designer to focus on the design.

[Codemonkey]

Originally posted by Nutrox
If we can create a class that extends the MovieClip class, and allow someone to change the appearance of the movie clip using getters/setters, then we shouldn't feel doing that is "bad" in any way. That's what Flash is all about, it's a kick ass dynamic/visual/code hybrid monster, and I love it for being that way.

Nicely put. Well, I guess I'm being a little bit of a tightass here... maybe

[Nutrox]

Originally posted by Codemonkey
Nicely put. Well, I guess I'm being a little bit of a tightass here... maybe

No, not at all. The Codemonkey is not a tightass.

I've been looking at C++ recently, preparing myself to learn it this year (gulp!), and I will definitely be walking the proper MVC route once I start putting code together.

With Flash though, I just think that we have the luxury of approaching things from a slightly different angle while still keeping a lot of the visual mechanics separate from the data, and making life a little easier for those who aren't too code-savvy.

[tcoulson]

as am I. Like we said, its a matter of choice and opinion.

If it makes you feel any better - flex seems to be more encapsulated like your code was created. At least that is my limited understanding of it.

[tcoulson]

I hate beeing doom and gloom, so...
...CM- I was just going through your files today, and I wanted to let you and the ultrashock world know that this is the clearest pure flash example of how design patterns can be implemented that I have seen. Really good example. Thanks for that.

[Codemonkey]

Originally posted by tcoulson
I hate beeing doom and gloom, so...
...CM- I was just going through your files today, and I wanted to let you and the ultrashock world know that this is the clearest pure flash example of how design patterns can be implemented that I have seen. Really good example. Thanks for that.

Well, you're making me blush now (and sentimental)

I think agree with you now about the setters/getters thing. Sometimes I forget the spirit in which flash was intended and get all strict and stuff. It really is a kick ass dynamic/visual/code hybrid monster
See what you are doing to me? Smiley’s all over the place

[RAMPAGE201]

Very Cool Codemonkey. I love the graphics. (I did a little tweek edit to fix the image next to url thing so you can read it without scrolling horizontally.. aparently it needed a crlf in there).