I'm one of the unlucky ones that won't be able to make it to the conference but I can't wait to see what else Adobe has under their belt.

I had a few hours to spare the other day and I created the diagram (sketch) above trying to understand Colin Moock's take in the subject. One post won't cover all the ins and outs of this Design Pattern but its more of a review and study of the author's view.

If we follow closely the diagram (sketch) this are the steps that should be taken:

1 View sends user input to the Controller.
2 Controller receives the information that the View has sent to the Controller.
3 The Controller modifies the Model.
4 Now the Model changes itself using the information received.
5 The Model notifies the View of the changes
6 The View updates itself to reflect the changes requested.

Couple of things to note:

With this set up the Model might receive information directly and notify the View of those changes, for example a Database request or a XML load to the model. This might be a little different to other setups where the Controller always receives the information, even if it comes from an outside source.

Another thing to note is that sometimes the information that the View has sent to the Controller might be enough to update itself so the step to modify the Model is skipped completely.

Now, accordingly to the book point of view the Model and View can never live without each other, meaning that if you create a View it must have a Model for that specific view but if you decide to switch a View you must switch its Model as well and vice-versa. Now that is a little bit different to what the GOF describe in their book but that is a whole different post.

Short Notes:

Model: Data & Logic
View: Interface
Controller: Process Information

Long Notes:

Model:

• Stores properties
• Implements application methods
• provides methods to register current View(s)
• notify View(s) of changes
• implements application logic

View:

• creates interface
• Updates interface when Model changes

Controller:

• Cosmetic changes
• Updates View
• Translates user input to change the Model

I had the opportunity to work on Out of the Box mini site for UPS at T-3. I had the chance to do all the Flash actionscripting after receiving the comps from the Art Director, and this is what we came up with...

Link: outofthebox.ups.com.

Thats right, Starcraft II is finally in the works. After almost 10 years after the first release of Starcraft they finally decided to put their act together and get us the new version. Can't Wait!

Link: www.starcraft2.com

What I mean is this:

1. Select a word
2. Run the Macro
3. the word you selected will appear in the next line as follows:

trace("the Word You Selected = " + the Word You Selected);

Neat uh?

Bind that to a short cut (in my case CMD-E) and anytime you need to trace a variable or an object you are set to go.

Interested in the macro?

Main entry continued

So the regular way of using arrays is:

var myArray:Array = new Array();
myArray.push ("this", "this one", "this two");
myArray.push ("that", "that one", "that two");

so lets say you do a simple trace

trace( myArray);

you get a nice long list with all the items you have pushed into the array ("this,this one,this two,that,that one,that two"). So you want to organize the arrays in a way that you want to access "this one", well you can certainly do

trace(myArray[1]);

now lets try to get "that one"...

trace (myArray[4]);

That is because we know that the position of "that one" is the 4th position in the array. But all of the sudden you are running down your scripts trying to figure out the best way to access the information in your array without having to memorize the position of each of them. So then what do you do? You can create an array for each one of the items you need. like this:

var thisA:Array = new Array();
thisA = ["this one", "this two"];

var thatA:Array = new Array();
thatB = ["that one", "that two"];

Now lets say we need "this one" we can access that value by doing the following:

trace(thisA[0])

That is an easier way to know what we want and now we can refer to each array by their name. But lets pause for a second and think that maybe... MAYBE 3000 lines down your code you find yourself stranded trying to figure out if thisA[0] was "that one" or if it was thisA[1]... so what if we could name each one of those arrays with a specific name that we could remember later....

Hummmm... now we are talking.

lets do the following

var thisA:Array = new Array();
thisA = [{positionone: "this one", positiontwo: "this two"}];

eh?... lets taste it...

trace(thisA[0]["positionone"]);

and it works! So do I mean that if I want to access position two all i have to do is remember the name of the array "thisA" and the name of the value I am trying to access? of course... lets try the secnd one

trace(thisA[0]["positiontwo"]);

Sweet! there you have it, go wild! go crazy in the mean time I will find out how much processor we are eating with this approach.

Main entry continued

Granted UserName and Password verification shouldn't be taken slightly, but many times you just want to make a section of your site "Pass Protected with flash", and in reality this is a very simple verification that should be used against the average joe, not the average geek-joe who knows about flash-deconstruction and such.

So have your Password-Protected flash site in 3 steps;

1. Download the class from here:

2. unzip the files in the directory where you are building your flash movie, so the file structure should look like this:

-root directory
--com
---helmutgranda
----PasswordProtect.as
3. on the root timeline of your flash movie write the following:

Please do not write telling me geek-joe was able to break into my site! because this is not a bullet proof password verification, this is just a quick way of keeping the average joe from looking into any "secure" section of your site. I might write a more robust version with some PHP/mySQL/flash combo but for now this will do.

This should be the continuation of the post

Multimedia247 - http://www.multimedia247.com

9th March 2006
By CBR Staff Writer

Seeking to ride the Ajax wave, Adobe Systems is to announce that it wants to make friends, rather than compete with, the increasingly popular grassroots rich internet client framework.

Adobe will release FABridge, which stands for Flash-Ajax bridge. Specifically, FABridge will allow JavaScript routines to call rich graphic objects supported in the Adobe Flash player. Later this year, it will also make available a client for data services in its Flex framework to which Ajax clients can connect.

Read More