When adding many Views of the same type to the stage, View and Mediators order can get mixed up.
Gist: I am working on a little Flex tool with a VGroup and I'm adding on little components to that VGroup. Here is the problem, the onRegister() events seem to happen in sequence that I added the views but often the views and mediators are mis-matched.
Here's the verbose version:
I hate having to hand instance data ( like an ID ) to the 'view'
and then have the Mediator come online some time later and take
that ID and then set itself up. A friend suggested making a View
Model with an array, push the ID to that array, then have each
mediator that comes online pull their ID from the View Model. This
WORKS, and I don't have to hand data via the 'view' but I now have
a sorting problem. My objects are added to the view in alphabetical
order and the Mediators come online respecting that order, but the
Views are completely mismatched to the Mediators.
If I take the same code, stuff the ID of the object into the 'view' and then pull the ID out of the 'view' in the mediators onRegister() command the objects are correctly sorted.
To my questions are thus:
A: Is there a better way to hand a Payload (ID, etc) to a
Mediator?
B: Is the View -> Mediator mix up a bug?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Stray on 12 Jan, 2012 06:18 PM
Hi Hays,
In 2 years + of working with Robotlegs I haven't heard of a 'bug' in relation to this at the Robotlegs side - but I think you're trying to rely on order-of-operations here in a way that is potentially flaky - especially as onRegister waits for creationComplete in flex UIComponents, and I couldn't begin to vouch for the flex internals ordering on that - events should generally be considered to be asynchronous (there are a couple of key exceptions such as reparenting).
My 'sanity' rule of thumb is that I never rely on strings or order-of-ops when another simple solution will let me be specific about what I want to happen.
I don't have a problem with the passing around of an ID from the model to the view then to the mediator - it always works and the code involved is minimal. More importantly, it makes the situation completely opaque to some developer who is trying to work with your code while you're off sick or taking the holiday of your life :)
I realise that might not be the answer you were hoping for, someone else may have a more VGroup specific suggestion, but the ID solution is a solid one IMO.
hth,
Stray
Ondina D.F. closed this discussion on 02 Feb, 2012 10:32 AM.