Ups, I was a bit overhastly. The undo does nothing using the multicore version.
After taking a look at the code I found that (for comprehensible reasons) the multitonKey is empty after instantiating the command that has to be undone. But it's crucial to have a valid multitonKey here.
So i tried to pass it using the "initializeNotifier(multitonKey)" method and it seems that it works now.

Olaf

:

// Inject the multitonKey
commandInstance.initializeNotifier(multitonKey);


UndoableCommandBase.undo():

:

/**
* Calls the undo command setting its note type to
* <code>UndoableCommandTypeEnum.NON_RECORDABLE_COMMAND</code> so that it won't get recorded into the history
* since it is already in the history
*/
public function undo():void
{
if ( undoCmdClass == null )
throw new Error("Undo command not set. Could not undo. Use 'registerUndoCommand' to register an undo command");

/** The type of the notification is used as a flag,
* indicating wheather to save the command into the history, or not.
* The undo command, shold not be recorded into the history,
* and its notification type is set to <code>UndoableCommandEnum.NON_RECORDABLE_COMMAND</code>
**/
var oldType:String = _note.getType();
_note.setType( UndoableCommandTypeEnum.NON_RECORDABLE_COMMAND );

try
{
var commandInstance : ICommand = new undoCmdClass();
// Inject the multitonKey
commandInstance.initializeNotifier(multitonKey);
commandInstance.execute( _note );
}
catch ( err:Error )
{
trace("Could not call undo on " + this + ". " + err.getStackTrace() );
}

_note.setType( oldType );
}
Olaf

I've just replaced the standard imports by the multicore ones and it seems that it just work!
I'll test it a bit more and will publish the multicore version of the "Undo Utility" at github next days.

Thanks,
Olaf

Hi,
I've just stumpled over the "Undo Utility" and took a quick look inside it.
To get it work, is the only thing to take care of the extension of the "UndoableCommandBase" for undoable commands?

If I'd like to use it with multicore, is it sufficient to replace the libs standard imports by the multicore ones?

Thanks for help,
Olaf

Hey Christian,
I've just seen your post, it sounds good!
I hope I'll get some time to check it out... will give you some feedback then!


Thanks!

Olaf

Cause we're currently only two PureMVC developers I'll risk it cause it's so easy to use.
But I have always the danger in the eye;-)

Thanks Cliff!

I mean this post:
http://forums.puremvc.org/index.php?topic=2093.0

Hi,
I'm not sure if I understood what you wrote but it sounds like your're searching for other ways for inter-core communication?
If so, please take a look at my post above.
Olaf

Hi,
I'm still struggling with inter-core communication and just wondering if we not could simply add a "sendMessage()" method to the Facade.as.
This method forwards it's message by calling the sendNotication() method for the passed or all registered cores. At the end each core could listen to notifications(messages) that was triggered by other cores.
To avoid conflicts between notification names and message names we coud define a seperate common file for the message constants with it's own "namespace":

MessageConstants.as:

:

public class MessageConstants
{
public static const TEST1:String   = 'msg/Test1';
public static const TEST2:String  = 'msg/Test2';
}

The modified org.puremvc.as3.multicore.patterns.facade.Facade.as:

:

/**
* Send notification (message) to other cores
* @param notificationName the name of the notiification to send
* @param body the body of the notification (optional)
* @param type the type of the notification (optional)
* @param coreId the multitonKey of the receiver core, sends message to all registered cores by default (optional)
*/
public  function sendMessage(messageName:String, body:Object, type:String, coreId:String="*"):void
{
if(coreId=="*"){
for(var multitonKey:String in instanceMap)
{
                        // Send notification to each core
instanceMap[multitonKey].sendNotification(messageName, body, type);
}
}
else{
if(hasCore(coreId))
{
// Send notification to passed core
instanceMap[coreId].sendNotification(messageName, body, type);
}
}
}

Usage:

:

// Send message to all registered cores
facade.sendMessage(MessageConstants.TEST1, "I am a message for all cores");

// Send message to core "Test"
facade.sendMessage(MessageConstants.TEST1, "I am a message for the 'Test' core only", null, Test.NAME);

What do you think about it?

Thanks
Olaf

After study the Modularity demo again and again I think I've got it... at the end it's simple.
Seems that using Interfaces for core communincation is more usable for me than pipes.
Perhaps a mixture of both is the silver bullet.

Thanks, Olaf

Hi,
I use the PipesUtil a lot and my experience is, that for me it is very hard to keep the survey.
Moreover the addidtional code is a bit annoying.
In general my impression is that by using the standard PureMVC version it is hard to keep the survey over all the notifications and by using the muticore version it is hard to keep the survey over all the plumbing and module communication.

So I asked myself what is the "smaller evil" and do I really need the multicore architecture?
At least I don't need "real modules" that behave like an application or could execute standalone and I don't need 100% decoupled modules.
But I definitely like it to split my applications in differents cores and have all the other benefits of the multicore architecture.

So I'm searching for an easier way to communicate with modules, perhaps by using interfaces?
I've take a look at the modularity demo but I don't feel comfortable with it.
Probably my programming experience is not enough to understand all the things inside.

My understanding is as following:
Module A provides an interface e.g. "IModuleA.as".
Module B would like to communicate with Module A and so it has to implemet "IModuleA.as".
But wich component of Module B should implement the interface?
Should it be a view component or should it be an own class like the "Pipes JunctionMediator" acting as
an class that handles the communication only?

Thanks for help!
Olaf

Hello,
does anybody know, if the Pureclipse extension is still available?
It seems that the project website http://www.slide.name/pureclipse/ is offline.

Olaf

Hello again,
while debugging the pipeworks demo again and again to understand all the things inside I'm wondering if there's a bug in the PrattlerModuleMediator.as.

My understanding is that after the FeedWindow's close event was fired we should only remove the module mediator of this concrete instance.
But the notification handler removes all registered instances?!

:

/**
* Handle PrattlerModule related Notifications.
* </P>
* Remove the application-level references to the module instance.
* Note that the module itself will also be listening for the
* window close and will do it's own internal cleanup to ensure
* that the instance can be garbage collected.</P>
*/
override public function handleNotification( note:INotification ):void
{
switch( note.getName() )
{
case  ApplicationFacade.REMOVE_FEED_WINDOW:
viewComponent = null;
var mediatorName:String = this.getMediatorName();
facade.removeMediator(mediatorName);
sendNotification(LogMessage.SEND_TO_LOG,"Removed window from shell.",LogMessage.LEVELS[LogMessage.DEBUG]);
break;
}
}


Should do something like this instead of the origin coding, or am I on the wrong track?:

:

/**
* Handle PrattlerModule related Notifications.
* </P>
* Remove the application-level references to the module instance.
* Note that the module itself will also be listening for the
* window close and will do it's own internal cleanup to ensure
* that the instance can be garbage collected.</P>
*/
override public function handleNotification( note:INotification ):void
{
switch( note.getName() )
{
case  ApplicationFacade.REMOVE_FEED_WINDOW:

if(viewComponent.getID() == note.getBody().moduleName as String)
{
viewComponent = null;
var mediatorName:String = this.getMediatorName();
facade.removeMediator(mediatorName);
sendNotification(LogMessage.SEND_TO_LOG,"Removed window from shell.",LogMessage.LEVELS[LogMessage.DEBUG]);
}
break;
}
}

Thanks for help!
Olaf

Hi Cliff,
sorry for the confusing question, maybe I'm confused by myself
I should think about my formulations before posting.
Seems that I've not understand the pipes concept completely.

Of course I don't want to separate every function to a core of its own.

The question was regarding the arrangement of modules and if it's a appropriate way to place 'submodules'
inside a 'mainmodule' and if all these modules could talk to each other without involving the shell.
Perhaps the differentiation in 'main-/submodules' is completely rubbish, I should think about it!

But sometimes I tend to think too much about whether the things the 'right' are.
Instead of thinking and asking too much I should just implement my ideas to see if it works and dispel doubts ;-)

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

Yes, that's it... don't know why I don't registered this slide before.

Now I'll try to install my pipes to get the cores connected;-)

Thanks for help!
Olaf

Hi,
after switching to Multicore and adding the PipesUtility by implementing the ideas of the PipeWorks demo
there remain some questions regarding 'submodules'.
I've read a lot in this forum regarding this issue but at least I don't understand it.

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?

Is this a appropriate way:
A PrattlerSkeletonModule implements the 'main' module frame including the navigation.
A PrattlerModuleX implements the current PrattlerModule features as 'submodule'.
A PrattlerModuleY implements new Prattler feature(s) as 'submodule'.
A PrattlerModuleZ implements more new Prattler feature(s) as 'submodule'.
...

By requesting the Prattler from the shell, the PrattlerSkeletonModule is delivered.
After this the PrattlerSkeletonModule request the default module, e.g. PrattlerModuleX from the shell and displays it.
By clickling a navigation item inside the PrattlerSkeletonModule the suitable module is requested by the PrattlerSkeletonModule and the shell will deliver this to the PrattlerSkeletonModule to display it.
(Or should the PrattlerSkeletonModule deliver the requested module directly, without involving the shell? )
Each Module(core in this case) is connected by own pipes from the shell to itself and vice versa.

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

Thanks for help!

Olaf


 

I've got it Cliff, thanks!

In the meantime I've moved my application to multicore by doing all the necessary stuff.
That was a little work but pretty easy:-)

Now I'll try to understand the PipesUtility... perhaps there will be some questions soon;-)