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  PureMVC Manifold / MultiCore Version / Re: Rat Experiments: Studying the Limitations of Multicore Using Interfaces on: November 02, 2009, 06:00:53
Really very good. It looks like I'll be able to get all of this to work.

Thank you both very much for the time you spent helping me out on these issues.

David
2  PureMVC Manifold / MultiCore Version / Re: Rat Experiments: Studying the Limitations of Multicore Using Interfaces on: November 01, 2009, 10:10:22
Wow, very very good. Thank you Tek!

I was able to resolve #1 above by replacing the code inside app's ApplicationMediator.as starting at line 65:

:
// load a rat swf
var url:String = "http://localhost.rat.com/rat.swf";
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener( Event.COMPLETE, completeHandler );
loader.contentLoaderInfo.addEventListener( IOErrorEvent.IO_ERROR, ioErrorHandler );
var context : LoaderContext = new LoaderContext(true);
context.securityDomain = SecurityDomain.currentDomain;
context.applicationDomain = ApplicationDomain.currentDomain;
loader.load( new URLRequest(url), context );

It also requires a crossdomain.xml file be placed inside of localhost.rat.com. Also, it won't work unless app.swf is actually being loaded inside of an HTML object tag and served to the browser accessing it via the domain. It will not work inside of a browser loading it locally. (in other words, the browser must point to http://localhost.app.com/app.html and will not work when accessing it from the filesystem file:///C:/.../localhost.app.com/app.html)

I am still investigating solutions to #2 and #3, but it looks like I'm on the right track now and #2 and #3 are merely inconveniences, not show stoppers. :)

Thanks again!
3  PureMVC Manifold / MultiCore Version / Rat Experiments: Studying the Limitations of Multicore Using Interfaces on: October 31, 2009, 02:41:44
It is easier for me to visualize cores when they are completely separate SWF files. The separate SWF approach also makes pieces of the program more modular and allows different development teams to focus on their piece without the clutter of the other pieces.

I have taken Chandima's Move the Cheese (link) example and split it into two separate projects and changed the names of folders to make everything easier to examine.
- A separate project for the rat
- A separate project for the application

I have prepared a zip file for your download (link) of all project files used in the examples below.

Here we have the folder structure and swf locations of the projects where everything is working well:




Limitation #1: Both swf files must reside in the same folder. rat.swf cannot be loaded from a separate domain. If rat.swf is loaded from a separate domain, I get a Type Coercion failure at runtime.



:
TypeError: Error #1034: Type Coercion failed: cannot convert Rat@140a791 to interfaces.IActor.
at view::ApplicationMediator/completeHandler()[C:\...\app_source\src\view\ApplicationMediator.as:91]

Please note: You will find that I added Security.allowDomain("*"); inside of the Rat constructor because I thought that could have been the root of the problem, but the runtime error is the same. Adding a trace inside of the constructor will confirm that it is executed before the type coercion failure happens.


Limitation #2: The interface files must be found in the exact same package structure in both app and rat for it to work. If the package structure for interface files do not match in both projects, Type Coercion failure happens at runtime.



:
TypeError: Error #1034: Type Coercion failed: cannot convert Rat@153eaf1 to interfaces.IActor.
at view::ApplicationMediator/completeHandler()[C:\...\app_source\src\view\ApplicationMediator.as:91]


Limitation #3: While the interface files must be found in the same package structure (#2 above), the StartupCommand.as file cannot. I suspect this is because separate cores share the same filename space or something. If StartupCommand.as exists in analogous packages across the different projects, I get a null object reference error at runtime.



:
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at view::ApplicationMediator/onRegister()[C:\...\app_source\src\view\ApplicationMediator.as:55]
...
at RatFacade/startup()[C:\...\rat_source\src\RatFacade.as:41]
at Rat/init()[C:\...\rat_source\src\Rat.as:40]
at view::ApplicationMediator/completeHandler()[C:\...\app_source\src\view\ApplicationMediator.as:92]


While limitations #2 and #3 are inconvenient, limitation #1 is crippling (for me). Is there a way around any of these?

I genuinely appreciate anyone's help on the matter.
4  PureMVC Manifold / Standard Version / Re: Problem with applications that use multiple SWFs? on: October 07, 2009, 04:53:10
This is what the MultiCore version is for.

-=Cliff>

Really!? On to MultiCore then!

Thanks a million!

David
5  PureMVC Manifold / Standard Version / Problem with applications that use multiple SWFs? on: October 06, 2009, 05:23:42
I came across an overly negative article about frameworks in general and took it with a grain of salt. The only issue that was brought up that troubles me is the following:

As convenient as it is to use, a Central Dispatcher is a really bad idea. Another Singleton effectively. Pop two apps into the same SWF and watch, with excitement and glee, all the cross-talk that occurs – both apps responding to each other’s events. Oh noes!

Is this a problem for PureMVC notifications?

I have plans for an application that requires the loading of separate PureMVC powered SWF files. This is necessary because as my product develops, different sets of users of legacy versions will still need access to multiple versions of the legacy program (SWF) for about a month before their need for the legacy version expires and they can start on the latest version of the program. These different SWF versions need to work in tandem with a main menu area that is itself a separate SWF inside of the same application. (So the common main menu SWF needs to be able to load any version of the other SWF at any time.)

So, I was wondering if the cross-talk problem would occur in PureMVC under these conditions, and if so, what steps can be taken to avoid problems from happening.

Thank you much for the help!

David
6  Announcements and General Discussion / Getting Started / Re: Big Picture Question about Views on: September 29, 2009, 07:02:35
Okay, so once I have my custom panel class with all the gadgets ready for action, I want my view to inherit from this panel class. Is this the best way to go? In all the examples I've seen so far (not a whole lot), the view always inherits from Sprite. But it's okay for the view class itself to inherit from another class, right?
7  Announcements and General Discussion / Getting Started / Big Picture Question about Views on: September 29, 2009, 04:44:09
Hello Everyone

Beginner question here.

If I want a view of a panel with a large list of items that needs a scrollbar, the whole thing should be one view, right? The scrollbar should not be its own separate view, but rather be a part of the same view as the panel and the items inside of that panel. Granted, the scrollbar would exist in its own class. (I'm guessing Flex has a scrollbar, but I'm more interested in pure actionscript.)

So a view is used to represent a chunk of interface functionality where several widgets are related to the same task and are working together. We should not have a separate view for every single widget in the assembly.

So, do I have all this understood correctly?

Thanks!
David
Pages: [1]