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

agree and yes it's appropriate to do in module while add or remove happens in shell.

Thanks,
Saad 

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>

Hi Cliff,

Yes that's exactly what I've been thinking for and thanks for making it more clear and cut.

Further I intend to link domain logic that's reusable across modules under the light of "Reusing the Model Tier" topic from PureMVC book while this complex "View" (in a submodule) can have it's own internal "Controller" and "Model" as well depending upon the need. The shell can further steward this viewComponent after addition and mediator registration etc.

The ultimate objective is to have each "Complex viewComponent" developed from different team members while giving them an independent clean slate (their own small manageable module, scripts, .fla, .xib etc.) to work on and then getting all of those complex viewComponents assembled within the shell as per your guidelines hence leading to less bulky "View" of the shell.

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>

Thanks Cliff. The idea was to have parts (complex nested components) of "View" to be developed across modules instead of compressing everything within the shell while also maintaining the hierarchical relationship and mediation in shell.

Thanks again for a very comprehensive discussion on large scale enterprise development under PureMVC.

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>

Thanks Cliff for the enlightenment and an improved workflow. It's good to learn how Mediator can mediate it's viewComponent as well as it's nested components.

Building on the thread and pushing "View" related discussion a bit, let's say those twenty or more viewComponents are split across modules/cores. The primary purpose is so that different individuals/teams can work independently on assigned viewComponents without the need to access or share the shell's root file (.fla in flash, .xib in iOS etc.).

Just like in the Pipes Demo, the prattler module gets it's own clean slate for development, UI related components, it's own controller and model, and is piped to the shell where it gets added there along with it's Mediator registration.

Please add your gems for a case when we have several complex components like prattler or more distributed across modules and dev teams in a large scale app.

Thanks again.