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: Command & View Abstraction for 3rd party 3D Engines & Maps  (Read 19437 times)
robmccardle
Newbie
*
Posts: 5


View Profile Email
« on: February 18, 2009, 06:00:45 »


Greetings one and all,

I'm pretty new to PMVC but have read all the docs & am comfortable with the majority of the framework. Most of it is very clear however I have some questions regarding what logic to split into Commands and what belongs embedded within it's own ViewComponent specifically regarding 3rd party 3D & Maps Engines that already have their own predefined API's (e.g. PaperVision/Away3D/GoogleMaps/Yahoo Maps)

I am building a weather display app. The main structure is done but I want to create a ViewComponent that contains a 3D model of some terrain and is capable of simple 3D transformations. I have not yet decided on which 3D engine to use (Papervision or Away3D - because PV is easy but I may add Flint support later and this renders much faster in Away) and want to delay this decision and reduce the reliance of the application to any particular 3rd party engine & require the minimum amount of code modification were I to switch 3D engine half way through development.


...so I seek the forums advice on how best to abstract the 3D engine out and reduce coupling as much as possible. For best practice; would you recommend I:

1.) Just keep all the rotation control and view within one complex Mediator per 3D engine for simplicity:
...view
PVisionMediator
Away3DMediator


2.) Have a Mediator for each engine and a Command for each transformation that is NOT engine specific:
...view
PVisionMediator
Away3DMediator
...controller
3DRotateCommand
3DLookAtCommand


3.) Have a Mediator for each engine and a Command for each transformation that is engine specific:
...view
PVisionMediator
Away3DMediator
...controller
PVisionRotateCommand
Away3DRotateCommand
PVisionLookAtCommand
Away3DLookAtCommand

I am also intrigued as a relative newbie:
- Am I being too ambitious in terms of the level of abstraction?
- Am I misunderstanding the type of logic (domain/business)which should be in Commands?

My first post on the forum! Thanks so much for reading, sorry it took a while to explain,

Warm Regards,

Rob
www.robmccardle.com
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #1 on: February 18, 2009, 07:31:12 »

I'm sure Cliff will have more to say on this, but, I would personally try and keep a majority of the view code within the component itself. You are essentially building a view widget. I'd have a mediator feed any data the widget needs to render, and have the widget pass back any data it needs to save. The rest can happen within the component which exposes an API to the mediator. Make that API generic enough that you can swap an Away 3d map component with a PV based one. Both should require roughly the same data inputs, assuming they perform the same task.

Granted I know little about these 3d library, and I may be missing some import insight about their use and construction, but the above is how I treat things like a tween library and any other view related libraries. They are just tools used to construct a component. They have little to do with my business or domain logic.

If these are very complex widgets, with many parts that will be sending around notifications, you might consider making them modules that can be loaded in at runtime. Then you could have a PV module and an Away 3d module. Just a thought.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: February 18, 2009, 08:58:51 »

Here's my 2 cents:

A big complex mediator for the whole engine is analagous to having a single mediator for a whole Flex app. While you may have an ApplicationMediator tending the reference to the mxml app, you'll also break it down to have mediators for major components. For a typical granularity in Flex check out the EmployeeAdmin demo.

Now metaphorically map a scene created by a 3D engine onto a view component hierarchy generated from mxml.

You probably want mediators for the camara(s) and the objects that move around or generate events.

Take a look at the HelloFlash demo, which although it isn't 3D, has these self-directed sprites that move around. You can drag any of them and they'll emit more, each with a mediator of its own. This will give you a good idea about splitting encapsulation of behavior in the view component.

Beware making massive mediators that know too much about their children or take on responsibilities that make the child less portable. Imagine these components you use will be reused in another app that doesn't use PureMVC.

I definitely need to get a 3D demo up soon.

Hope this helps,
-=Cliff>
Logged
robmccardle
Newbie
*
Posts: 5


View Profile Email
« Reply #3 on: February 18, 2009, 09:26:55 »


Hi Jason, what you're saying makes sense to me; these controls are very tightly connected to that particular View & they don't seem to warrant any Commands. When I design a PureMVC architecture on paper so far I seem to end up with a tiny handful of Commands & a disproportionately high number of Mediators & Proxies however which makes me feel like perhaps I'm underusing them or missing something about their intended purpose. You're reply was most useful, ta.


Hello Cliff too, thanks a lot for the reply; I respect what you'd be trying to achieve by having a Mediator for each 3D plane/Camera etc but I don't think it would be maintainable to make these common across 3D engines due to their different implementations of World space/cameras etc.. It seems like there isn't going to be an enormous amount of shared code I can reuse between them at this level of implementation so I'm just hunting for the right high level abstraction... I haven't looked through the source for the HelloFlash Demo you mentioned yet though so I will do that and come back and eat my words later!

I'm currently thinking that perhaps I'll create an Interface I3DVCModel that my ViewComponent classes (One for Papervision, one for Away3D, another for Sandy etc...) implement that would specify a series of public methods common to each viewComponent for rotateMesh() lookAtPoint() etc which it is possible to achieve in all the engines. The actual transform calls via the 3D API will then all be handled internally by each VC. The one generic 3DModelMediator will then call the implemented functions ignorant of the underlying 3D API used (which feels nicely decoupled to me) and deal with the communications to the rest of the framework. Giving it more thought at present but I wanted to share my evolving thought train as I find other posts on this forum most useful as a learning resource when people explain their thinking; however wrong or right.


I'm very interested in the 'Module' approach you mention Jason although I'm not sure exactly what you mean by a "Module" in this context, is this an official PureMVC construct? I'm assuming that you mean keeping the assets and code needed for each ViewComponent in a separate SWF and loading that when needed. I'm yet to settle on a coherent loading strategy and this will be a nice way of achieving this so my next question regarding this is; in order to keep the overall structure of the code clean do I need to be using the Multicore version and create these external swf's with their own M, V & C Multitons (treating the 3D model viewComponent efectively as a separate PureMVC project) or can I just create a SWF that implements I3DVCModel outside the framework and use this as a ViewComponent?

I've read some interesting things about using Fabrication to architect PureMVC Multicore modular apps http://code.google.com/p/fabrication/ but all the examples I've seen so far are Flex not Flash (I like FDT & FlashIDE & avoid MXML wherever possible) which I can deal with but slows me down and I don't want to run before I can walk regarding framework learning so I'd appreciate any insights from others on this or good links before I delve deeper.

In any case, you've both given me a massive nudge in the right direction and explaining things has helped me clarify the situation in my own mind too so thanks again for your precious time,

Cheers,

Rob
www.robmccardle.com
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #4 on: February 18, 2009, 09:58:35 »

By module I meant using the Multi-Core version and creating separate modules as widgets  like the Modularity demo does. This is the approach I would take if my widgets become overly complex, containing many mediators, proxy's and commands. It keeps the code cleaner and allows you to load the desired widget on demand. Then you can choose which 3d library to load without having to load them all every time.

You could also build them like a third-party component, being completely self contained swf's (no PMVC inside) that expose a common interface. You would load them like you would any other third-party component. Though I prefer the module approach over this since with pipes, or Fabrication, you can send anonymous messages back and forth. With modules your interface becomes the type of messages the modules respond to from the shell or other modules.

Also I use Fabrication with Flash in all my projects and use the same set-up as you (Flash IDE and FlashDevlop). I'll admit it isn't as straight forward as with Flex - you have to build your own module loader classes, see the Flash demo Darshan has in svn - but there are less differences than you might suspect.

When I design a PureMVC architecture on paper so far I seem to end up with a tiny handful of Commands & a disproportionately high number of Mediators & Proxies however which makes me feel like perhaps I'm underusing them or missing something about their intended purpose

THat is pretty normal. Commands should handle things that are overly complex, like start-up and shutdown, and anything that will be reused by multiple actors. The end result is that you end up with fewer than you would in other frameworks like Cairngorm where you tend to end up with 3-4 times the number of commands to everything else. Simple gets and sets of data can be made directly from a mediator to a proxy thus eliminating tons of tiny commands.
« Last Edit: February 18, 2009, 10:05:29 by Jason MacDonald » Logged
robmccardle
Newbie
*
Posts: 5


View Profile Email
« Reply #5 on: February 18, 2009, 10:31:33 »

Super, really appreciate all the feedback and good to know I'm on the right track after all with regards to Commands. I will go through the PureMVC HelloFlash & Modularity demos + Darshan's fabrication for Flash one and keep investigating before I dive in any further on this build. If I find anything else relevant of note I will repost it here for reference, this is a great forum :)

All the best,

Rob
www.robmccardle.com
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #6 on: February 18, 2009, 10:38:42 »

...tiny handful of Commands & a disproportionately high number of Mediators & Proxies however which makes me feel like perhaps I'm underusing them or missing something about their intended purpose.

No worries, that's about how it shakes out. The commands just aren't needed so much in a PureMVC system. If you want to be hardcore and make every view->model update happen as view->controller->model, you certainly can, and that will start ramping up your command count quickly. Many people do this because that's what the classic MVC diagram shows.

However the introduction of the Mediator pattern in the view performs the critical decoupling of the view component from the model (i.e. the VC doesn't have bindings to the model, the data is spoonfed to it by a mediator, and the model has no knowledge of the view component or mediator, and merely sends notifications to them). What this means is that you can often react to a button press at the view by having the mediator retrieve and update the proxy. This is the short-circuit that reduces the number of Commands while still decoupling the view and model.

Reuse is always a great goal, but Mediators are not the place to look for major code reuse in a PureMVC system. Not that it can't happen, but you'll get more real-world reuse in the view components themselves and in the Proxies. Mediators tend to be the least reusable parts because they adapt wildly diverse, usually custom view components, to the system. Proxies should be written in such a way that you expect most of the domain model to be reused in another app (such as browser, mobile and desktop versions of the same app with different use cases and UIs).

On the Modular tip, if you're wanting to build generic handling for multiple 3D engines, really that's the way to go. Flex Modules or loaded SWFs, written in MultiCore can all be loaded into the same VM and interact with each other via interfaces or pipe messages.

-=Cliff>
Logged
Pages: [1]
Print