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.

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.

Hi there,

I read in the best practice guide that you should call a 'destroy' method before removing a Mediator from the Facade. This of course makes perfect sense, since a removed Mediator probably has quite a few view component dependencies that need cleaning up.

My main question is - why isn't that 'destroy' method part of the architecture?

Second question: Is there a chance in future updates that 'removeMediator' could return the instance that was removed? At the moment, to call 'destroy()', I need to retrieve the instance, then call destroy(), then remove the instance, whereas it could all go into one line:

facade.removeMediator(name).destroy();

Or am I missing something important?

cheers - Nils.

Hi all,

very simply put:

- what is the Notification 'type' property for?



cheers - Nils.