Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
November 25, 2017, 12:33:12 AM
Home Help Search Login Register
News: Please DM @puremvc on Twitter to gain forum access. Spambots are why we can't have nice things.
  Show Posts
Pages: 1 [2] 3 4 ... 188
16  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>
17  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>
18  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>
19  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>


20  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>
21  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.
22  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>
23  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>
24  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>
25  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>
26  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>
27  Announcements and General Discussion / Architecture / Re: Bulky Modules on: December 14, 2015, 08:13:00 AM
Hi Saad,

If I get the gist of your last response, you could message up more than one view component from various modules, and have a Command in the Shell do the insertion of those views into the hierarchy, and mediate one or more of them at that time. Is that more along the lines of what you were thinking? Of course the components would still need to implement interfaces, and expose methods for accepting the children this Command would pass them for assembly.

Cheers,
-=Cliff>
28  Announcements and General Discussion / Architecture / Re: Bulky Modules on: December 11, 2015, 12:46:41 PM
So, if the Mediator lives in the shell, and you want to mediate a view component that lives in a module, then you need only:

1) Make the view component implement an interface known to both the shell and the module,
2) Send a pipe message to the shell containing the view component to be mediated,
3) Respond in the shell by registering a new instance of the Mediator subclass, giving it the component.

Make sense?

Cheers,
-=Cliff>
29  Announcements and General Discussion / Architecture / Re: Bulky Modules on: October 08, 2015, 09:04:14 AM
Quote
...when I've several view/components in an app (let's say Header, nav and their associated pages, login and profile panels and several others), I see explosion of mediator and viewComponent classes.

The rules of thumb for factoring view components down into smaller and smaller units is the same regardless of framework usage. Don't build god objects. Break it down. Remember that reuse is a by-product of this process, not the goal or the arbitrating factor in the decision to decompose further. The goal is make each component simple enough to be able to do its function clearly so that when someone needs to modify it, it's an easy task, and no cycles are spent trying to understand how everything is wired up. The component should expose an api of properties and events that make it obvious what its external dependencies are and what things about its state it will communicate to the rest of the app.

Since view components are arranged in a hierarchy, the parent view component can and should act like a mediator to its children. PureMVC Mediators are not code-behind constructs intended to push you toward developing "dumb" components. They only provide framework mediation with chosen parts of the display list. Every component doesn't have to be mediated. You might have twenty view components but only three Mediators. The mediator can pass data to its view component, which passes it to its children, and in turn they pass it down to their children. Those grandchildren can send events up the display list that, if need be, eventually make it to  a mediator via the grandparent.

You can even have the view component implement an interface so that it can pass itself along in the event, and the mediator sets data directly on that requesting grandchild component rather than on the component it actually mediates.

A mix of data being passed from a mediator to a component and from there down the display list AND mediators communicating with arbitrary interface-implementing components is good. In the right balance, a mediator can service a lot of components, the data flow in the display list doesn't get too complex, and the mediator's responsibilities aren't overwhelming.

So, decompose your interface, then look for appropriate points to mediate. Find that sweet spot where the display list, the individual components, and the mediators are all at a comfortable level of complexity.

Cheers,
-=Cliff>
30  Announcements and General Discussion / Architecture / Re: Using PureMVC to build SDKs, Libraries and Frameworks on: September 03, 2015, 05:27:15 PM
Let the shell expose an interface. It can act as a mediator between the modules and the outer framework.
Pages: 1 [2] 3 4 ... 188