ENTERING / EXITING in addition to CHANGE notifications

I'm just in the middle of writing some code to manage a state history and it occurred to me that it would be useful to have generic ENTERING / EXITING notifications sent by StateMachine, which also contains the additional notification body that is sent when sending the state-specific 'entering', 'exiting' notifications.

At the moment, you can only retrieve the state instance itself by listening to the StateMachine.CHANGED notification - but you can't record what additional information was sent when entering the state.

My question is: Is there a trick for retrieving that information when the CHANGED notification is received?

Just in the middle of coding, sorry if the post doesn't make much sense

Hi Neil,

thanks for the super-quick reply (esp on a Sunday).

I'll cast the viewComponent, that's easy enough. Don't know whether Fabrication uses FSM but communicating with pipes shouldn't be too hard. I'm also too busy to work on anything like that - but thanks for the suggestion

Cheers - Nils.

Quick questions regarding the StateMachine:

Why is the 'currentState' getter on StateMachine protected, rather than public?

(Enjoying working with it, by the way, but this has thrown up some problems for me.)

Thanks - Nils.

[Edit: Question about multicore removed - found it in ZIP file]

Hi Cliff,

thanks for the quick response.

I didn't really see the need for centrally-defined pipe names at all, since that seemed to limit the flexibility.

Your example's helped - after all, if you did connect several output pipes to the same module, the module still wouldn't know which pipe to use to send messages on, if it weren't for the centrally-defined pipe names. So this piece of shared knowledge is necessary after all.

Thanks for the clarification,

- Nils.

Hi jgervin,

I recently changed a fairly large app over to multicore. Your mileage may of course vary but it took about 30 minutes of global search/replace action.

Another good debugging tool is the free PureMVC Console from KapIT which will show you which mediators are still registered so you can track whether or not things get removed during the TEARDOWN.

(http://labs.kapit.fr/display/puremvcconsole/PureMVC+Console)

- Nils.

Hi everybody,

there's something in the currently 'approved' usage of Pipes and the various demos out there that has been bugging me and I thought I'd open it up for discussion here.

I'll try and get my point across as clearly as possible.

The crux of the matter is that all code I've seen is assuming that modules have a single output Pipe named PipeConstants.STDOUT and that, to some extent, this assumption seems also to be built in to JunctionMediator (on a subconscious level, if you like). This contrasts with the generic way that the IPipeAware interface requires a pipe name as its first argument and the fact that JunctionMediator and Junction can handle any number of output pipes.

What I am wondering is whether the use of STDOUT has developed as an easy workaround to this slight discrepancy in the framework?

So, currently, this is the workflow:

• Module-to-shell pipe is created
• Module-to-shell pipe is passed to module using STDOUT name
• Module-to-shell pipe is registered by JunctionMediator
• To send a message to shell, the module uses the STDOUT name to specify the output pipe

That last step is what's bugging me, as it seems to be unnecessarily inferring knowledge of the shell architecture. It also limits the flexibility of JunctionMediator because although any number of output pipes are supported, the sendMessage() code always reverts to just a single pipe.

Since the module doesn't really know in advance what pipes it will be connected to, I reckon it would make more sense to send messages to all available output pipes.

The problem is compounded in some way by the fact that Junction provides no method for retrieving all output pipes and JunctionMediator doesn't store the output pipe names when they are registered, so this information isn't accessible.

To improve flexibility, it would be enough to add a single method to Junction, which would send messages to all available output pipes.

Does anyone else have any thoughts on this matter?

Cheers - Nils.

Hi everybody!

I've been knee-deep in PureMVC for a while now and it's occurred to me that it would be very useful for Mediators (and perhaps other elements) to be notified when they become registered with the Facade.

I'm working with Mediator instances that get registered and removed from the Facade at various points - but at the moment they have no knowledge of what's happening to them.

It's essential that they update their child-component's content again once they're re-registered, since they will have missed out on various notifications in the meantime.

[my use-case is a ViewStack, where it's not efficient to update views that are not visible]

Just wanted to open this up for discussion...

cheers - Nils.

Much appreciated - thanks!

- Nils.

Morning Cliff,

thanks for the detailed reply - as always

My concern with every suggestion for framework change is striking the balance between the opposing perceptions of full-featuredness for advanced users and overwhelming and daunting to new users.

I completely agree with and strongly support that point of view. I wasn't really suggesting you add the method - I mainly wanted to check whether there was a better way of implementing my code.

I'm happy to extend IMediator - in due course, maybe this would make a good addition to the library you mentioned elsewhere.

cheers - Nils.

I just wanted to revisit this subject now that I've had more experience with PureMVC. In my current code a 'destroy()' method for Mediators is essential and, since Cliff doesn't see it the same way, I was wondering whether there is a better way to implement my Mediators.

When user navigates to a section, I do this:

- create the section's container view component
- create the section's Mediator and add it to the facade
- the Mediator then creates other Mediators to handle specific components that are exposed by the section's container component (eg. a MenuBar or a List)

When the user navigates away from the section, I remove the Mediator and call its 'destroy()' method, which in turn removes child elements, event listeners and the other Mediators it has created.

That seems like a straightforward strategy to me but it makes 'destroy()' essential, so I was wondering how others implement Mediators without the 'destroy()' method.

Thanks for any input,

Nils.

I guess there's nothing 'wrong' with it - it just means that the command becomes dependent on a particular Facade implementation. I really like the use of interfaces in PureMVC and would prefer not to have to break them here.

cheers - Nils.

Hi Cedric,

I just started writing a reply but it got more and more complex, so I guess the answer is "It depends on the requirements"

I think for the usage you are describing, you could use a value object as the Notification body, that includes an error code, the error description and the notifications to send on 'ok' and 'cancel'. You have to be careful though because you don't want to include any view information in there - so the type of alert to show should be determined in the Mediator (and the error descriptions should probably come from another Proxy).

In a simpler case, where no command/proxy interaction is required, you could just handle the entire process inside a single Mediator - after a particular user gesture, the Mediator pops up the Alert and only sends a Notification if 'ok' was clicked for example.

Getting long again - I'd better stop here

- Nils.

Hi Toby,

expanding on what Cliff wrote, here is a solution using a single Notification name and different types to differentiate between the stages of the operation:

- Notification fires, no type set - LoadCategoryCommand starts loading CategoryProxy XML and exits

- CategoryProxy XML finishes loading data - and fires the same Notification but with type set to 'categoryLoaded'

- LoadCategoryCommand executes again, sees the new 'type' identifier and a) displays the page or b) triggers the ProductProxy to load data - and then exits

- Finally, ProductProxy finishes loading data - and fires the same Notification but with type set to 'productLoaded'

- LoadCategoryCommand executes again, sees the new 'type' identifier and displays the appropriate page

Might seem complicated but you end up using a single Notification and a single command that encapsulates the entire logic for displaying the category.

Any good for you?

- Nils.

Hi all,

I'm quite often faced with having to check whether a proxy of a particular type has already been registered.

For example, different parts of the application can embed a shopping module, which initialises its own proxies. If the proxies already exist in the Facade, I don't re-create them.

At the moment I've added methods to my Facade implementation:

hasProxy(name:String):Boolean
hasMediator(name:String):Boolean

but that requires casting the 'facade' property, so it creates an unwanted dependency in the commands.

Is there a chance that such methods could be added to future iterations of the framework?

Maybe there is also a more efficient way to implement as a native part of the framework rather than attempting to retrieve the object and checking whether the result is null.

Does anybody have any thoughts or other suggestions?

cheers - Nils.

Thanks all for the detailed response!

I'm very happy to hear that this has been added Cliff - cheers. I'm thinking that a generic Mediator subclass that includes an stub destroy() method might be a good addition to the PureMVC utilities library that you mentioned elsewhere.

- Nils.