* Is this an API change, i.e., client code will have to change?
* Is there a significant behavioral change, i.e., something will not work as expected? - I don't think people should be relying on it allowing multiple Facades, since that's what MultiCore is for, but anything else?

Don't want to accept a pull request automatically if it might break client code, that's all.

-=Cliff>

Can you make a pull request for this on the PureMVC repo?

This should clearly be folded in.
Cheers,
-=Cliff>

Seems to work fine for me. I entered 50 and all the dark grey boxes jumped over to the right a bit when I clicked send. Perhaps try it on another computer? Maybe Flash isn't installed on the one you're using.

Try here: https://github.com/stolyarchukav/pureclipse

Yes, it appears you are correct. Good catch!

In the case of the demo, it doesn't really make much of a difference, since we only need to get the feed window exported from those modules, but if there were more shell to module communications that happened over time, we might find that those suddenly fail because of this. (That's probably why this has never shown up as a problem).

-=Cliff>

Imagine we'd like to extend the the PrattlerModule (from the PipeWorks demo) with more features.
For instance there is a navigation tree with some items that offers some more complex functions (in prattler context).
To be encapsulated we would like to build an own core for each function.
So here a function is something like a 'submodule' but of course each submodule should be independent and self-contained.

How we could solve this by using pipes?

I'm not fully sure I understand the question. Yes, you could extend a module and extend the classes used in that module. That's not pipes, that's just normal OOP. I don't fully understand each 'function' being a core, though. A core usually provides a number of related functions. You could separate every function to a core of its own, but that would mean an untenable amount of coding overhead for each function. You have to ask yourself why you're doing the separation and what the real, tangible benefit of that separation is first.

Would it basically a good idea that some cores are connected directly with each other without involving the shell?

You certainly can plumb cores together without them having to be plumbed to the shell. Have a look at this slide in the MultiCore Overview Presentation:
http://puremvc.tv/#P002/T235

-=Cliff>

Plumbing is what we call all the pipes and pipe fittings that connect sinks and showers and toilets the like so that water runs to them. In this case think of message flow as water flow.

But the pipes concept for modular software really came about with Unix, where you can 'pipe' the output of one command (like a directory listing) through another command (like a sort) and build a pipeline of commands that process the data that flows through it.

Cheers,
-=Cliff>

1) More than one shell core inside a multicore project?
There is a skeleton with some navigation buttons and common functions.
In multicore context this would be the 'shell', right?
Inside this 'shell' the user could open different tabs wich will be place inside a view stack.
A tab is like a module and provides different views with different functionalities and it's own tab related navigation. Should be each tab have it's own shell core? Or should each tab 'submodule' including the tab skeleton be represented by a core?

It all depends. Will each tab be massive, really different, and possibly only loaded sometimes? If so, probably make it a core of its own. But that's not the only reason to make something a separate core. Even if every section will be loaded each time, sometimes it's just easier to have each section be a core of its own because it simplifies the overall app. Inside a core, you usually only have to deal with the stuff in that core. This makes it easy for you to split the functionality across teams. You can have different teams working on different cores. Also, to answer the other question here, only one shell exists - the main app.

2) How granular-> how many cores in a multicore project?
I've read one benefit using multicore is to be able to create unit tests in a proper way.
But what should we define as a unit, my understanding is that one core represents a unit.
Within an application there could be tons of functions, modules, submodules... units after all.
As a result of this we would have tons of cores inside a project. Is there a limitation for the number of cores inside a project?

No, for unit testing, you don't have to have the core be the 'unit'. The benefit of MultiCore for unit testing is that with each test in the test suite, you can create a NEW facade for testing. With Standard, each test uses the one and only Facade, so you can't get back to a clean slate for the next test. You can test whatever you want. Look at the MultiCore framework unit tests to understand this better.

3) Shared proxies
In my application each tab has references to same proxies.
E.g. one tab provides a userlist and another tab displays detailed informations of one user. So both tabs have a reference to the 'UserCollectionProxy' and both could manipulate the proxy. How this works with the multicore version? Should this be done by using pipes?
I know the best way is to have 100% encapsulated modules, but I think this doesn't work in real life!?

Yes, this absolutely works in real life or there'd be no point in doing a modular approach at all!

The only thing that needs to be shared is data object classes and 'protocol' classes - i.e. custom message types.

All you have to change is your thinking. Don't have multiple cores 'share' a proxy, make a separate core (or cores) for talking to the service(s) and send that core a message (if you're using pipes to comm between cores) or invoke a method (if you're using interfaces and core references for comm). So your service core is the only one that has the proxy. Send it a message that says, give me the user list, and the core receives the message, executes a command to figure out what you're trying to do, and manipulates the proxy to make a call. It should use the async token pattern to remember what it was doing so that when the service responds, it can trigger a command that sends a message back (if using pipes) or calls a method on the other core (if using interfaces) to get the data back to the caller.

4) 'Dynamic' cores
To make sure that each view/mediator inside a tab handles the right notifications I make an extensive usage of notifications type parameter by passing an unique id with it. Sometimes this is a bit confusing.
Is it right that by using the multicore version I'll don't have to pay attention to this cause within multicore each core have an unique id?

Each core does have a unique ID. You still have to target the right core, and you'd be sending pipe messages instead of notes, (or making method calls if using interfaces). But your mediators wouldn't need to check for note type all the time.

5) EmployeeAdmin multicore demo?
For me it would be helpful if the EmployeeAdmin demo would be available as multicore demo.
Are there any examples like this out there?

Well, there is the PipeWorks demo, and the Modularity Demo for Flex. They should give you some idea.
https://github.com/PureMVC/puremvc-as3-demo-flex-pipeworks/wiki
https://github.com/PureMVC/puremvc-as3-demo-flex-modularity/wiki

Also you can see a real world example at http://seaofarrows.com + http://seaofarrows.com/srcview

Hope this helps!
-=Cliff>

All of the SVN history for the PureMVC projects was transferred over to GitHub.

For the PureMVC AS3 Standard Version, look here:
https://github.com/PureMVC/puremvc-as3-standard-framework/commits/master

For MultiCore:
https://github.com/PureMVC/puremvc-as3-multicore-framework/commits/master

I don't know if the SWC format has changed in the latest Flex version or not, but you might want to just try adding the PureMVC source tree to your project and see if that changes anything. Let me know what you find.

-=Cliff>

I must admit I never tried to generate docs for the ReverseText demo, only for the framework itself, since usually, docs for a demo aren't all that useful. I'm going to be pretty busy this week, but will try to get it sorted soon. For now, you might try removing docs from the demo until you find what character is throwing it, starting at the top of TextProxy.

-=Cliff>

Thanks for reporting this, Peter.

Fortunately, I was sitting on a pull request that had been made against the bleeding edge Dart distribution and waiting for it to hit the standard distribution. So I merged that, updated the pubspec.yaml, README and VERSION files, and tagged a new version 2.0.4 out at GitHub.

Of course, made sure the unit tests were all good, and then pushed a new version out to the Pub:
http://pub.dartlang.org/packages/puremvc

So, you can remove the pubspec.lock file on your project and do another pub update, and you should be able to pull down a working version and go.

Cheers,
-=Cliff>

PS: Thanks Adam Singer for the pull request and being ahead of the curve on this one, I really appreciate it.

Alright. The update is in to pub. To pull it in, you can just follow the instructions here:
http://pub.dartlang.org/packages/puremvc

Cheers,
-=Cliff>

Well, since this topic was posted, I've switched the framework back over to using the standard class and interface names. The only gotcha is you have to prefix, e.g., mvc.Mediator instead of MVCMediator.

Here's the request to update the hosted package on Pub.

http://code.google.com/p/dart/issues/detail?id=7796

-=Cliff>

Doh! It was pubspec.lock. Removed it and ran it again and it worked. Going to check this in and get the pubsters to pull in the new version.

Will post back here when it is done...
-=Cliff>