Starting with PureMVC

[ahmednuaman]

Hey all,

I'm new to AS3 MVC, but not the MVC concept or AS3. I've had a look at the best practice guide and set up my app:

Base.fla
Base.as (Base.fla's document class)
com
> domain
>> app
>>> ApplicationFacade.as
>>> models
>>> views
>>> controllers

That's just a basic idea of the current directory structure.

So looking good? Cool, I do a quick launch to test the movie in the Flash IDE and it returns errors regarding the code I copied from the best practices guide on ApplicationFacade.as. The errors are to do with the 'registerCommand()' functions where StartupCommand, LoginCommand and GetPresCommand don't exists.

So should then? If not, what should be inside them and where should I create them?

[lingie]

Hi,

It looks like you're on the right track!   The registerCommand() function calls take the command string and the name of the command.  So in the case of ApplicationFacade.as from the best practices guide, there needs to be three command classes: StartupCommand, LoginCommand, and GetPrefsCommand.  You would create these in your controller(s) directory.

There are a few helpful demo applications that you might want to look at: Application Skeleton (AppSkeleton) is nice for showing how to setup directories & files.  EmployeeAdmin is from the courseware (I think) that is often mentioned around here.  That's a really helpful example for showing how everything works together.

[ahmednuaman]

Right I see, so the commands StartupCommand and so on are only examples and not mandatory right? Would I create a command, let's say Init within a class called Init and call that using the registerCommand? And I assume Init will begin to load everything? So then what's the facade connection?

[puremvc]

I would suggest reading the Framework overview doc at a minimum, followed by Best Practices. Trust me it'll help.

-=Cliff>

[cddin]

hi.. i'm new to pureMVC..

I follow this idea..

Base.fla
Base.as (Base.fla's document class)
com
> domain
>> app
>>> ApplicationFacade.as
>>> models
>>> views
>>> controllers

but.. where should I put another class.. for example I want to create
utils(folder)..
Events(folder)

can anyone give suggestion?

[puremvc]

You can put things anywhere of course, and the size of your app may often dictate one or more separate library projects, particulay when building MultiCore apps.

But usually I try to let the MVC tiers guide me.


For instance, those events are most likely going to be used by custom view components. So an events folder that is a sibling to components under view is a common place for custom events.

What sort of utils are you talking about? Something called by a command tocombine or transform some data before presentation? In that case, controller/utils works.

A factory for value objects? Try model/util

-=Cliff>

[cddin]

Utils folder.. my plan is to put something like ArrayUtils.as, DateUtils.as (have a method like stringToDate), currencyConverterUtils.as..

tocombine or transform some data before presentation?

yup .. It will use by component view and proxy or VO..

for example.. I have DateUtils.as class file. And in that class file have two method..
1. stringToDate - will use by proxy/vo to store it in datasource or sent to web service to save in database.
2. dateToString - will use by componentView to show data in Component.

so.. should I create two class and one of it put  inside model/utils and another one in view/utils? or just put DateUtils.as inside controller/utils?


this type of example also may apply to currencyConverterUtils.as

[puremvc]

Since you'll be using date utils in your proxy classes, I'd put that under model/utils.

-=Cliff>

[cddin]

thanks..

another question:

I have a animation folder that contain tween class, animation1 class

where to put the  class that control animation? in view folder? or the folder not suppose a part of mvc?

[puremvc]

That, I would put under view/utils.

You'll find that most anything you'll do in a basic app could be filed into model, view or controller. The whole concept of MVC really breaks down to splitting the app into these three piles.

Of course in a more complex app your packaging may become more complex, and by no means is this a dictum that must be applied in order to use the framework, but it will definitely help when other developers become involved.

Some folks feel this is too simplistic and or cramps their style, but adhereing to convention can go a long way toward making your app more maintainable.

-=Cliff>

[pHk]

This is probably not the best place to put it, but I'll go ahead anyway.

I've noticed a few irregularities so far while going through the Best Practices document (I'm in the process of exploring/learning PureMVC to hopefully apply it in the real world soon). I've went through the document up until around the Mediators chapter(s), and noticed the following while trying to compile my own test project in Flex 3 based on the code in the BP document:

- page 11, MyApp.mxml - the concrete Facade is instantiated using "= ApplicationFacade.getInstance();", but this didn't compile in my project and threw an "implicit coercion" error. I had to explicitly cast the instance, as such "= ApplicationFacade.getInstance() as ApplicationFacade;"

- page 32, LoginPanel.mxml - two issues here; a "<mx:MetaData" element is used but is spelled with an upper-case D (instead of lower-case d), resulting in a "Could not resolve" error. The second issues is another typo (I presume) where there's a rogue semicolon after the "[Event()]" meta data, resulting in a very vague error.

It's worth noting that I'm not experienced with Flex at all, so while these issues may seem trivial to the experienced Flex/AS developer, they are potentially very annoying for new developers looking to get into the framework based on the BP document. Mea culpa; I did try to cross-check the code with some of the sample source code but failed to notice these fairly apparent differences