Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
March 26, 2017, 12:10:13 AM
Home Help Search Login Register
News: ATTENTION: Spambots must die! Humans must visit http://contact.futurescale.com to request forum access.
  Show Posts
Pages: [1] 2 3 ... 187
1  PureMVC Manifold / Demos and Utilities / Re: StateMachine - A PureMVC Swift Utility on: December 28, 2016, 07:24:07 AM
That would be really cool.
2  PureMVC Manifold / MultiCore Version / Swift 3.0 support now available on: December 11, 2016, 11:00:16 AM
Thanks a ton to Saad Shams for taking time from his busy schedule to bring the port up to date.
3  PureMVC Manifold / Standard Version / Swift 3.0 support now available on: December 11, 2016, 10:59:36 AM
Thanks a ton to Saad Shams for taking time from his busy schedule to bring the port up to date.
4  Announcements and General Discussion / Architecture / Re: Module->Core: Sharing instances vs. sharing classes across cores on: August 30, 2016, 11:03:16 AM
Thats the ticket.  Smiley
5  Announcements and General Discussion / Architecture / Re: Module->Core: Sharing instances vs. sharing classes across cores on: August 27, 2016, 07:19:23 AM
If you package your model in a separate library, then each core can use it. You could make the LoginProxy have a class property that holds the ProfileVO. That would let you register it in every core, retrieve it, and be able to access the login info that was fetched by the instance in the shell. Make it 'protected static' and add a getter for it.

Cheers,
-=Cliff>
6  Announcements and General Discussion / Architecture / Re: Notify cores from shell by sending a notification using its particular facade on: August 20, 2016, 08:11:22 AM
Nope, that's pretty much it. If you control all the modules that will ever run in the app, and come up with a scheme that ensures the notification type values are all unique to the core they're intended for (eg., VIZ_CORE_STARTUP = "Core/Visualizer/Startup", or ALL_CORES_LOGOUT_RESET = "Core/All/ResetAfterLogout"), what you want to do will work.

Like pipe messaging, you'll want to create a common notification constants library used by all modules. Define all your notifications there instead of inside the individual Cores, that way they're all reading from the same page when it comes to intercore communications.


Cheers,
-=Cliff>
7  Announcements and General Discussion / General Discussion / Re: New designed web page on: August 14, 2016, 03:05:59 PM
Thanks Olaf. For a few years I filled all my extra minutes writing a novel. When I got that out the door, I also found myself executing a transition to HTML5, and figured it was time for me to do something about this ancient site. I'll also be taking a more active role with the JavaScript port now as well.

Cheers,
-=Cliff>
8  PureMVC Manifold / Demos and Utilities / Re: StateMachine - A PureMVC Swift Utility on: August 01, 2016, 07:53:36 AM
Hey Saad,

Just received the following email from William Rena at Arcanys Inc.:

Quote
Hi guys. You are doing great with your PureMVC Framework. I used this when I was in Flash Development. I"m a great fan with this framework especially the new PureMVC Swift. I'm currently exploring and learning to adapt this framework and use it in our team. Do you have an example how to use the Pipes and State Machine in Swift?

Do you have any code or notes up your sleeve on this subject?

Cheers,
-=Cliff>


9  Announcements and General Discussion / Architecture / Re: Multicore PureMVC with Routing on: July 28, 2016, 06:27:15 AM
I think the broadcast option is best, since you never know what coordination patterns may be needed between various modules when a hash change occurs. And by trying to put all the knowledge in the shell about what modules need to respond to what hashes, you sort of defeat the encapsulation of a modular system.

You could, of course have each module, upon connection, or in response to a broadcast pipe message, respond with a list of 'subscriptions'. So that the shell is then able to realize on a given hash change which modules to send the message to.

Cheers,
-=Cliff>
10  Announcements and General Discussion / General Discussion / Re: Usage of Undo Utility on: April 05, 2016, 08:04:17 AM
I would say clone the repo with the standard version and add a multicore tree. You should be able to temporarily change the library project settings to point to the muliticore sources and compile a swc. As I recall that was the way i had to do the statemachine swcs.
11  Announcements and General Discussion / General Discussion / Re: Mediator: How to get rid of the flash.events.Event dependency? on: March 23, 2016, 07:36:38 AM
The Mediator class doesn't depend on the Event class. It is merely an idiom for it to add event listeners to its component. So there's no need to rewrite Mediator.

The component could just as well use a PureMVC Notifier instance (or extend notifier). and the Mediator would receive notifications from the components just like it receives them from other parts of the PureMVC system: Notifications.

This is usually not done, because A) we already have events in Flex/Flash, and B) to keep the component unaware of the PureMVC apparatus. However, in your case you're trying to make it so that the code is implemented the same way for JS as for Flash, and in that case you're going to have to make some compromises, and I'd say using the Notifier class which is common to both apps using PureMVC would be a reasonable way to do it.

Cheers,
-=Cliff>
12  Announcements and General Discussion / General Discussion / Re: Usage of Undo Utility on: March 23, 2016, 07:29:01 AM
No, you can only use multicore version in a multicore project, and standard in standard. The project just contains the source of both.

Cheers,
-=Cliff>
13  Announcements and General Discussion / General Discussion / Re: Usage of Undo Utility on: February 14, 2016, 09:26:04 AM
Hi Olaf,

If you create a pull request, please have a look at https://github.com/PureMVC/puremvc-as3-util-statemachine which has both a standard and multicore version in the same repo. If you can make the project structure similar, it will be helpful.

Cheers,
-=Cliff>
14  Announcements and General Discussion / General Discussion / Re: Usage of Undo Utility on: February 03, 2016, 02:56:31 PM
Hi Olaf,

Right. This utility unfortunately hasn't been ported to Multicore. However, it shouldn't be much of a problem to do that. To do this properly all you'd need to do is change the imports. If you are of a mind to do so, I'd be happy to create the GitHub repo and all that for the Multicore version.

Cheers,
-=Cliff>
15  Announcements and General Discussion / Architecture / Re: Bulky Modules on: December 14, 2015, 10:29:15 AM
Also, the modules that message up the view components could mediate them locally, while the shell only has the responsibility of inserting them into the view hierarchy. That would probably be more appropriate.

-=Cliff>
Pages: [1] 2 3 ... 187