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

Show Posts

* | |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / Fabrication / Re: Trouble strongly typing custom Notifications on: March 23, 2009, 10:00:35

Magic, I got it working and your explanation makes perfect sense. Cheers for the quick response too!

Kind Regards,

Rob
2  Announcements and General Discussion / Fabrication / Trouble strongly typing custom Notifications on: March 23, 2009, 05:55:51

Hi all, first of all this is an amazing library thank you so much Darshan for your excellent work.

I'm studying http://code.google.com/p/fabrication/wiki/ReflexiveNotificationInterests but having trouble strongly typing my notifications as it won't compile. The error I get is:

:
"Incompatible types String and ContextMenuNotification. 'newContextMenuNotification(ContextMenuNotification.ADD_MENU)'"

Here is the Command code that the error happens in:

:
public class BossStartupCommand extends SimpleFabricationCommand {
        registerMediator( new BossMediator( notification.getBody() ) );

// WORKS
// sendNotification( ContextMenuNotification.ADD_MENU );
// DOES NOT WORK
sendNotification( new ContextMenuNotification( ContextMenuNotification.ADD_MENU ) );


}

In my Mediator I have a respondTo function which works fine with INotification as the argument & a vanilla Notification is sent but never gets called when I swap it for my strongly typed version:

:

// OK - public function respondToAddMenu( args : INotification ) : void {
// NEVER CALLED - custom notification for strong typing
public function respondToAddMenu( args : ContextMenuNotification ) : void {
trace("add the menu");
}


My Notification is simple and is extending the Fabrication version, here's the code:

:

package {
import org.puremvc.as3.multicore.utilities.fabrication.patterns.observer.FabricationNotification;

public class ContextMenuNotification extends FabricationNotification
{
public static const ADD_MENU:String = "addMenu";

public function ContextMenuNotification (__evtType : String = "undefined")
{
super( __evtType );
}
}
}


I am using the latest versions of PureMVC Multicore, Pipes & Fabrication with Flash (Not Flex) in FDT. Can anyone point out what I'm doing wrong please? Many thanks :)
3  PureMVC Manifold / Standard Version / Re: Command & View Abstraction for 3rd party 3D Engines & Maps 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
4  PureMVC Manifold / Standard Version / Re: Command & View Abstraction for 3rd party 3D Engines & Maps 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
5  PureMVC Manifold / Standard Version / Command & View Abstraction for 3rd party 3D Engines & Maps 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
Pages: [1]