Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: the use of pop-up screens  (Read 7603 times)
Ramon.Proficter
Newbie
*
Posts: 1


View Profile Email
« on: January 28, 2009, 03:47:29 »

I am relatively new to the pureMVC framework, also fairly new to Flex so bare with me if you will.

In the examples that I've seen until now, almost always a Viewstack-construction is used for different screens. I will be needing a fair amount of pop-up screens, or screens that appear on top of other screens to do some CRUD-stuff on the data that is seen on the underlying screen. How would you guys do this, using pureMVC?

Also, I am using this fwk to build the frontend for a relatively big application (approx. 100 screens). How would you organize a big amount of screens, their mediators and proxies and what-have-you's, so that it's all manageable? What are your experiences with this?

Thanx in advance for all the help you'll offer me!

R@mon
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #1 on: January 28, 2009, 07:15:23 »

http://forums.puremvc.org/index.php?topic=105.0

Here is a discussion about popups.

As to organizing your package structure.. I like to break my applications down into sections and build my packages up like that. Each section will have a model/view/controller package and its appropriate bits underneath those.
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
JJfutbol
Sr. Member
****
Posts: 53


View Profile WWW Email
« Reply #2 on: January 29, 2009, 11:43:50 »

Regarding packaging I've never liked the PureMVC standard of throwing everything in a high level model, view and controller packages. It's to limiting and I prefer much more organization. If you are building Flex and AIR apps I highly recommend following the Flex package naming. I find myself having much better organization this way and helps others jump into my project since if they know Flex I follow the same standards (ASDoc, naming conventions, etc.).

PureMVC does a great job defining the view, model and controller with the following patterns: Mediator, Proxy and Commands. So in the view folder I would only have mediators, in the model only proxies, etc. I then break up my components into other more meaningful named packages such as "containers", "controls", "utils", "core", etc. I've found this immensely useful and much easier to work with at one level. Hope this helps.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: January 31, 2009, 08:46:17 »

The reason for having only three folders stems from the fact that the goal of MVC is to separate code into three tiers.

Underneath those each of those tiers, each represented by a folder of the same name (for absolute simplicity and zero doubt about which tier a piece of code belongs to) then fall any number of folders for denizens of that tier.

Of course if you're building a really massive application this ultra simple scheme still holds up but requires more subdivision, and can better be handled by breaking the app into broad sections each represented by a folder and with model, view and controller folders underneath at a normal, managable granularity.

In the latter case, you are also likely to benefit from using MultiCore and breaking your app into modules or loaded swfs, which map to those broad sections.

Packaging-wise, that let's you split those sections into separate projects, each of which now looks like the 'mother' application and its siblings in structure.

Of course there are always cross-cutting concerns which don't fit into these categories, and these generally go into their own library, which may be highly specific to the application  or highly generic and reusable, like the Pipes utility for MultiCore.

Regardless, cluttering the app with a ton of sibling folders outside the MVC tiers just makes it hard for a new person on the team to grok what's going on and how these things relate to the big picture, which the team may or may not have taken time to actually draw and keep up to date.

The nice thing about the PureMVC advocated structure is that it forces simplicity. When the app gets big enough to go modular its easy to refactor and apps always look the same, so its easy to look at a new app and understand what's going on.

My apps used to look like the plant-monster in Little Shop of Horrors. Now they all appear to come from the same strain of clover. And rarely is there a 4, 5 or 10 leaf mutant. Sure there are dandilions mixed in here and there and they look great alongside the clover. But the dandilions are dandilions and the clover are clover, dig?

-=Cliff>
Logged
Pages: [1]
Print