You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by Christofer Dutz <ch...@c-ware.de> on 2015/09/09 12:27:54 UTC
Parseley and [MessageHandler]
Hi Guys ...
today I have a question for you, hoping someone will be able to help me :-)
I am playing around with Parseley 3.0 and am pretty satisfied with it. One thing that is bugging me at the moment is the messaging. As long as I use the [MessageHandler] Metadata in classes that are managed by parseley by the context.mxml all is working fine. Unfortunately I have quite a lot of mxml classes using my services by <parseley:Configure/> in the fx:Declaration section of the component. Unfortunately I couldn't manage to get Parseley to call my handlers. The only option I found was to add an [Init] method and to use the Message API to manually register a handler using this code:
var registry:MessageReceiverRegistry = context.scopeManager.getScope(ScopeName.GLOBAL).messageReceivers;
var info:MessageReceiverInfo = new MessageReceiverInfo();
info.type = ClassInfo.forClass(ConferenceDataChangedEvent);
var handler:DefaultMessageHandler = new DefaultMessageHandler(info);
handler.init(Provider.forInstance(this), ClassInfo.forInstance(this).getMethod("onConferenceDataChanged"));
registry.addTarget(handler);
What do I have to do in order to use the normal MetaData approach?
Or would you completely recommend a different IoT framework? To me it seemed as they are all declared dead, so I thought ... "pick your zombie" and Parseley looked nicest to mee.
Chris
Re: Parseley and [MessageHandler]
Posted by Davori <do...@gmail.com>.
Hi Christofer,
We're still using parsley and as another poster said we only fast inject
presentation model classes into our views. eg LoginPM, this Login PM
instance would live in the Parsley Context, be fastInjected into your .mxml
and your [MessageHandlers] could live in your PM, with the PM.results bound
to variables in your MXML files by having something like this in your mxml
file:
<fx:Binding destination="bindablePropertyTargetInMXML"
source="pM.bindablePropertySourceInPM"/>
It's a better separation of concerns and a relatively easy refactor.
Hope that helps and if you get the chance can you have a look at the issue
I've encountered with optimising my modules with flexmojos ;-).
Regards,
Lyndon
The posts are under Davori,
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Parseley-and-MessageHandler-tp11158p11168.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
RE: AW: Parseley and [MessageHandler]
Posted by Frédéric THOMAS <we...@hotmail.com>.
> Having a short glance at robotlegs It does look similar and
eventually more lightweight, but it seems to mix MetaData configuration
with naming conventions ... in the examlple it looked as if there were
special function names "configure", "initialize" and so on ... I rather
prefer explicitly defining stuff like that or having some sort of
"RobotlegsComponent" interface.
I never seen it used that way but there is a mvcs extension that make use of interfaces to ease some injections in an mvc contect but it is not mandatory to use though and also extensions so you can plug the feature your app needs, it is like "pay as you go".
And what I like the most, is you can use the mvc pattern you like, pureMvc style (with mediator) or presenter pattern like in Parsley for example.
Also, you can you standard flex event and / or Signals.
Frédéric THOMAS
> From: christofer.dutz@c-ware.de
> To: users@flex.apache.org
> Subject: AW: Parseley and [MessageHandler]
> Date: Thu, 10 Sep 2015 07:30:22 +0000
>
> Having a short glance at robotlegs It does look similar and eventually more lightweight, but it seems to mix MetaData configuration with naming conventions ... in the examlple it looked as if there were special function names "configure", "initialize" and so on ... I rather prefer explicitly defining stuff like that or having some sort of "RobotlegsComponent" interface.
>
> Will have a deeper look into this .. but thanks for the pointer :-)
>
> Chris
>
> ________________________________________
> Von: After24 <vi...@after24.net>
> Gesendet: Donnerstag, 10. September 2015 09:19
> An: users@flex.apache.org
> Betreff: RE: Parseley and [MessageHandler]
>
> Hello Thomas,
>
> Yes, Robotleg is excellent too and it's lighter, I used it in a project with
> FeatherUI and as3 signal and it works great. What makes Parsley my favorite
> choice is the powerful command framework that handles synchronous and
> asynchronous commands, command groups, command flows etc...
>
> Cheers.
>
>
>
> --
> View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Parseley-and-MessageHandler-tp11158p11162.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.
AW: Parseley and [MessageHandler]
Posted by Christofer Dutz <ch...@c-ware.de>.
Having a short glance at robotlegs It does look similar and eventually more lightweight, but it seems to mix MetaData configuration with naming conventions ... in the examlple it looked as if there were special function names "configure", "initialize" and so on ... I rather prefer explicitly defining stuff like that or having some sort of "RobotlegsComponent" interface.
Will have a deeper look into this .. but thanks for the pointer :-)
Chris
________________________________________
Von: After24 <vi...@after24.net>
Gesendet: Donnerstag, 10. September 2015 09:19
An: users@flex.apache.org
Betreff: RE: Parseley and [MessageHandler]
Hello Thomas,
Yes, Robotleg is excellent too and it's lighter, I used it in a project with
FeatherUI and as3 signal and it works great. What makes Parsley my favorite
choice is the powerful command framework that handles synchronous and
asynchronous commands, command groups, command flows etc...
Cheers.
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Parseley-and-MessageHandler-tp11158p11162.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
RE: Parseley and [MessageHandler]
Posted by After24 <vi...@after24.net>.
Hello Thomas,
Yes, Robotleg is excellent too and it's lighter, I used it in a project with
FeatherUI and as3 signal and it works great. What makes Parsley my favorite
choice is the powerful command framework that handles synchronous and
asynchronous commands, command groups, command flows etc...
Cheers.
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Parseley-and-MessageHandler-tp11158p11162.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
RE: Parseley and [MessageHandler]
Posted by Frédéric THOMAS <we...@hotmail.com>.
I agree with you Vincent, just to mention I usually use the Configure tag only for the main application / modules mxml file, FastInject for the rest.
Robotleg is also a fantastic option, I've been using Parsley for a while, it is built to be extended quiet easily and I wanted the best for the large company applications I've been developed, now if I would reconsider my choice, I would opt for Robotleg, it does everything you need 99% of the time, is much lighter and also open source, well tested and constructed.
My 2 cents.
Frédéric THOMAS
> Date: Wed, 9 Sep 2015 04:32:25 -0700
> From: vincent@after24.net
> To: users@flex.apache.org
> Subject: Re: Parseley and [MessageHandler]
>
> Hi Christofer,
>
> You picked the right zombie, Parsley is a fantastic ioc framework,
> especially since version 3.0 which added the new command framework.
>
> I don't think that you can use the [MessageHandler] tag in a class that
> hasn't been added the context, except by using the messaging API like you
> do.
>
> But it’s not a limitation the way I use Parsley (which is definitely not the
> only way but it has proven to work great with large projects) :
>
> Views are never added to the context because reflection costs a lot
> especially with complex UI. So instead of using the <Configure> tag, I’m
> just injecting the view mediator (which is added to the context) directly in
> the view using the <FastInject> tag. This way, messages can be be directly
> handled in the view mediator which update the view when needed.
>
> Hope it helps.
>
>
>
> --
> View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Parseley-and-MessageHandler-tp11158p11159.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Parseley and [MessageHandler]
Posted by After24 <vi...@after24.net>.
Hi Christofer,
You picked the right zombie, Parsley is a fantastic ioc framework,
especially since version 3.0 which added the new command framework.
I don't think that you can use the [MessageHandler] tag in a class that
hasn't been added the context, except by using the messaging API like you
do.
But it’s not a limitation the way I use Parsley (which is definitely not the
only way but it has proven to work great with large projects) :
Views are never added to the context because reflection costs a lot
especially with complex UI. So instead of using the <Configure> tag, I’m
just injecting the view mediator (which is added to the context) directly in
the view using the <FastInject> tag. This way, messages can be be directly
handled in the view mediator which update the view when needed.
Hope it helps.
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Parseley-and-MessageHandler-tp11158p11159.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.