go to 'Controller'

Suggestions for Improvement

When it comes to programming, I believe a great way to learn is to take something that already works and add to or improve upon its functionality. There are many ways to architect an application like this portfolio viewer or implement sections of the existing architecture.

Beyond the fact that the base graphics really suck, here are some suggestions for improving the application.

LayoutItem

This class is a real hack. A cleaner implementation might start with something like a UIWidget class that extends MovieClip. A base component class would be built from UIWidget and components like SimpleButton, Label, TextArea, etc. would all derive from the base component class.

You may also consider adding hooks for using third-party components in the layout items.

Skinning

The Style Manager contains properties for basic style information, but no facility to modify skins for low-level items like the UIScrollBar. In fact, there is no way to change the appearance of the SCROLLER item. As you modify the base display capability, at some point it becomes necessary to support skinning in the XML file. Consider modifying the Style Manager to hold skinning information.

Error Handling

The fundamental approach to to error handling is the same everywhere in the application -- dispatch an 'error' event and return. Sometimes, returning from a method results in the application calling another method and then another method. An existing error might cause a ripple effect in the application. Every new error message is displayed in the SimpleAlert message area, so only the last error in sequence is seen.

Consider modifying major blocks of code so that they can not be executed if an error condition exists. The error condition is set in the error handler.

Error Screen

That SimpleAlert is pretty ugly. Either skin the components and make it look nicer or replace it with a better-designed error screen. I generally only use SimpleAlert in the early stages of application development until artist-supplied error screens are delivered.

Compact Handlers

Some of the handlers are holdovers from earlier implementations of the portfolio viewer. I mentioned one (__onClilck) in the View section. Instead of defining individual properties in the event Object, substitute a reference to the PortItem class so that the handler can extract any required information from PortItem.

Modify the MVC and Thumbnailer Implementation

Currently, the Model data never changes (and probably would not as this application is a viewer of static data). Since the View handles some of the low-level interactivity, how about merging the View and Controller? This modification compacts the code base and makes some of the logic easier to understand. On the other hand, the Controller becomes larger and future changes might impact larger sections of code. Recall that the Controller was designed to be a lightweight manager and broker between the driver, Model, and View.

In a typical MVC architecture, the Model is exposed to the View and the Controller modifies the Model based on user-interaction. How might the Model be modified in this application? Perhaps the layout consists of multiple Views, and the thumbnailer is not displayed and loaded until the user selects from a category such as 'Illustrations' or 'Videos'. In this case, there might be multiple portfolio files, viewed with multiple possible layouts.

In this case, the thumnbailer needs the ability to clear the current set of Glyphs and redraw itself based on a new layout. You may wish to compare the current thumbnailer code with the following: www.2112fx.com/blog/pivot/entry.php?id=16 (look at the Glyph removal code).

Parsing

The XML parsing in the Model is at a very low level. Use XPath or some other mechanism to compact the code. There is a lot of error checking during parsing. Although it is nice to catch errors as early as possible, the error checking could be moved into the setter functions for all container classes. In fact, many setters already have checks in place.

The parser code could be made much more efficient if all the error checking was removed and placed downstream in the application.

Glyphs

Currently, glyph symbols must exist in the Library. What about allowing them to be loaded externally in .SWF's ? It is also possible to create class instances based on MovieClip without a symbol in the library. If memory serves, this was first discussed by Peter Joel and there is an article on OSFlash (time for a Google search).

Alignment

The current alignment specifications are very simple. What about more complex alignment, such as centering one component horizontally or vertically between two other components or between an edge of one component and the Stage boundary?

These are just a few suggestions. Even if you don't use the viewer or implement any of the improvements, I hope you at least find a low-level utility class that is useful in future projects.

go to 'Controller'