Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

* | |

  Show Posts
Pages: [1]
1  PureMVC Manifold / Bug Report / Re: asdoc broken in Flex 4 on: March 17, 2009, 10:10:10
Ah no, PureMVC multi-core works perfectly in Flex 4 (build 4.0.0.4932), but asdoc has started playing up, it's even complaining about using < after an @param (replaced with &lt;).

It seems you now need to use the -lenient flag to treat invalid HTML as just warnings not fatal errors. Also if you have -strict=false, remove that as it will conflict and silently fail to recognise the new -lenient.
2  PureMVC Manifold / Bug Report / [ WARNING ] asdoc broken in Flex 4 on: March 17, 2009, 09:29:53
Not really a bug, just a quick FYI. It seems the latest version of asdoc (as per Flex 4) chokes and "FATAL ERROR"s on the missing closing P-tags in the header comments for several of the classes, you have to open the log file to see which because the stdout errors don't give enough info.

Not sure why this has started happening, and whether you're experiencing it with asdoc already when you generate for the current builds, but this may start happening. I'm closing these tags manually in my version so I can generate docs for inclusion with my own.
3  Announcements and General Discussion / Architecture / Re: Implementing Undoable commands in PureMVC on: January 13, 2009, 07:53:23
Thanks Dracos I think I'll give that a try now, I don't see why that wouldn't work for me, and you're right, I had essentially the same code in the undo command.
4  Announcements and General Discussion / Architecture / Re: Implementing Undoable commands in PureMVC on: January 12, 2009, 10:59:16
Thank guys, I've got a long way to go before I can really report anything interesting, but the Undo is working as it should, any user or programmable actions such as selecting an item on screen, moving/scaling an item and so on are turned into a "action Command" (mostly this is a SetPropertyCommand or SelectItemCommand) and a params object which feeds it the right data and also whether the command is to be recorded in the history stack.

This "action command" just calls methods on the proxies to do its work as per normal PureMVC. In order to actually instantiate and execute this there's actually a PerformActionCommand which creates an instance of the action command class and feeds it the relevant data from the notification body. It's all quite generesized so it's quite hard to describe well. This is the bit I'm not too happy on as I'm having to dynamically construct a Command instance myself and initialize it with the multiton key. I can't really think up a better way of chaining up this command sequence ahead of runtime.

When it comes to the undo... upon sending a CommandHistoryProxy.UNDO_LAST notification (a notification I added) the controller is executing a generic UndoLastCommand command (the naming should be UndoLastCommandCommand to be honest but that looks ugly). This simply checks CommandHistoryProxy.canUndo and then calls getPrevious() to call pop the last IUndoableCommand off the stack in order to finally call undo() on that, again in my case this is usually an UndoSetPropertyCommand or UndoSelectItemCommand.
5  Announcements and General Discussion / Architecture / Re: Implementing Undoable commands in PureMVC on: January 09, 2009, 07:59:12
Hi all,

Apologies for resurrecting this thread after one year now, I'm currently building a pretty huge AIR app in fact split into 5 Flex projects (1 AIR, 3 Flex and one Zinc3, all using the same codebase) and PureMVC is really enforcing some good design.

Anyway I'm just using the contributed Undo module, I've done the relevant renaming to get it working in multicore, but of course I'm experiencing an issue and I'm not keen on my workaround, and wonder if you have any better ideas?

The most common issue I've encountered in multicore of course is the use of the facade reference in INotifiers before they are registered (and therefore have the multiton key, which in my case is never accessible outside of the Facade subclass).

One example of this is in a Command class. Generally this is not a problem because the Commands are registered in your facade class and automatically given the multiton key before you use them. But... in the case of undo this appears to break down a little because the undo command is never given the multiton key.

The simple fix is to modify UndoableCommandBase to include one line (line 2 of these 3 lines):

:
var commandInstance : ICommand = new undoCmdClass();
commandInstance.initializeNotifier(multitonKey);
commandInstance.execute( _note );

Would that be a reasonable thing to do or is this bad practice because I'm re-using the multiton key directly?

Thanks and glad to have found this extension.
Pages: [1]