tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/114-best-use-of-model-mediator-view-when-using-flex-4-statesRobotlegs: Discussion 2018-10-18T16:35:10Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-30T15:48:30Z2010-03-30T15:48:30ZBest use of model->mediator->view when using Flex 4 States<div><p>With option 2 the memory usage would be extremely low and would
only be an issue f you had a LOT of mediated views. Option 3 could
be worked around via an updateDataProvider() on the view itself. So
the mediator pulls the current data and the mediator or view does a
comparison instead of replacing the entire DP. For a smaller app
I'd lean towards 2.</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-30T16:22:33Z2010-03-30T16:24:02ZBest use of model->mediator->view when using Flex 4 States<div><p>Thanks for the fast feedback Joel. The application is a smaller,
widget type app so I'll go with 2, but it's great to hear other
people's pov!</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-30T19:39:29Z2010-03-30T19:39:29ZBest use of model->mediator->view when using Flex 4 States<div><p>Joel, what's the best way to manually mediate views with Flex 4?
Do you have an example of this?</p>
<p>Do I still need to call mapView on the mediatorMap in my
application context and then manually create the mediator using
mediatorMap.createMediator? This is the method I'm using, but not
having much luck - my mediators aren't being created! Can you offer
any pointers?</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-30T20:02:02Z2010-03-30T20:02:02ZBest use of model->mediator->view when using Flex 4 States<div><p>Sorry, I should've said that I'm mapping my views via
interfaces. So in my context I have: <em>mediatorMap.mapView(
LoginView, LoginViewMediator, ILoginView, false, false );</em><br>
And in my ApplicationMediator, in the onRegister method, I have
<em>mediatorMap.createMediator( view.loginView );</em> where
<em>view.loginView</em> returns a <em>ILoginView</em> object, but
this doesn't seem to map a mediator.</p>
<p>What do you suggest?</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T13:10:58Z2010-03-31T13:10:58ZBest use of model->mediator->view when using Flex 4 States<div><p>injectViewAs might operate a little differently to how you'd
expect. The map still needs the concrete view in order to create
the mediator, it just injects that view as the interface when
satisfying the mediators dependencies. Have you tried:</p>
<pre>
mediatorMap.createMediator( view );
</pre></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T13:30:22Z2010-03-31T13:30:22ZBest use of model->mediator->view when using Flex 4 States<div><p>Hi Shaun,</p>
<p>I have tried that, but with no luck. I'm calling that method in
the application mediator.</p>
<p>I'm trying to build an application whereby my logic resides in
it's own Flex Library project and refers views via interfaces. This
means I can easily create multiple Flex projects that reference the
library project but can be targeted for different platforms; i.e.
web, desktop, mobile, etc. Each project only needs to have a
different context and view, the view's all implement the relevant
interfaces.</p>
<p>So, in the example above, <code>view.loginView</code> is a
public getter in the view class that returns an instance of
<code>ILoginView</code>. Is it not possible for the map to create
the mediator for an interface as opposed to a concrete class? This
is key to my workflow. Otherwise the mediators, which are in the
application logic, are tightly bound to the view and that's no good
to anyone! I'd have to have duplicate mediators in every
project.</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T13:53:36Z2010-03-31T13:53:36ZBest use of model->mediator->view when using Flex 4 States<div><p>Hmm.. check it out, for this to work:</p>
<pre>
mediatorMap.mapView( LoginView, LoginViewMediator, ILoginView, false, false );
mediatorMap.createMediator( view.loginView );
</pre>
<p>this must be true:</p>
<pre>
reflector.getFQCN( view.loginView ) == reflector.getFQCN( LoginView );
</pre>
<p>The Mediator doesn't need to be coupled to the concrete type at
all (all it cares about is the interface that gets injected), but
the mapping does. Could you try the test above and let me know the
results?</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T14:10:58Z2010-03-31T14:10:58ZBest use of model->mediator->view when using Flex 4 States<div><p>Thanks for your help Shaun, I'll take a look at it tonight and
let you know the results. It would be excellent to get this working
- there's nothing better than being able to code to interfaces (as
opposed to implementation)!</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T14:20:15Z2010-03-31T14:20:15ZBest use of model->mediator->view when using Flex 4 States<div><p>No problemo! I'm sure we'll get it sorted out. Cheers,</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T15:52:05Z2010-03-31T15:52:05ZBest use of model->mediator->view when using Flex 4 States<div><p>Actually, I'll try and create a test project and library so you
can see what I'm trying to achieve. Hopefully isolating the issue
will make it easier to solve!</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T18:46:45Z2010-03-31T18:46:45ZBest use of model->mediator->view when using Flex 4 States<div><p>Hi Shaun,</p>
<p>I've quickly tried:<br>
<code>reflector.getFQCN( view.loginView ) == reflector.getFQCN(
LoginView );</code> and it worked fine. So it must be another
issue. I'm going to create the test project and see if we can work
it out. It must be something else I'm doing wrong.</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T19:36:10Z2010-03-31T19:36:10ZBest use of model->mediator->view when using Flex 4 States<div><p>Hi Shaun,</p>
<p>I've created and attached a test project. There are two Flex 4
project files, one is the logic ( a Flex library) and the other the
view (a Flex AIR project). All the files you need should be there,
let me know if you're missing anything. Hopefully they are
structured in an obvious way and you can see what I'm trying to
do.</p>
<p>If you run the code you'll see that the two views aren't
mediated, even though they are being told to in the Application
mediator.</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T20:29:54Z2010-03-31T20:31:44ZBest use of model->mediator->view when using Flex 4 States<div><p>hi Mark!<br>
i don't think the problem is related to interface, it's just that
mediatorMap.createMediator( view.firstView ); is called before
mediatorMap.mapView( FirstView, FirstViewMediator, IFirstView,
false, false );</p>
<p>try to put the "mapViews" in this order:<br></p>
<pre>
<code>mediatorMap.mapView( FirstView, FirstViewMediator, IFirstView, false, false );
mediatorMap.mapView( SecondView, SecondViewMediator, ISecondView, false, false );
mediatorMap.mapView( InterfaceTestView, ApplicationMediator, IApplicationView );</code>
</pre>
<p>and it seems to work</p></div>sitronniertag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T20:51:26Z2010-03-31T20:51:26ZBest use of model->mediator->view when using Flex 4 States<div><p>Haha! That's excellent. Thanks sitronnier! I didn't know the
order of the mapping made a different - I'll make sure the
application mediators are mapped last from now on!</p>
<p>For bonus points, you don't happen to know how to change the
creation policy of the second view so that's instantly mediated too
do you?</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T21:25:32Z2010-03-31T21:25:32ZBest use of model->mediator->view when using Flex 4 States<div><p>nop sorry.. seems you can set itemCreationPolicy="immediate" but
it doesn't seem to work as advertised.<br>
the only hack i found is to define a first state as "configState"
and have both view includeIn="xxState, configState"... (and set
current state as firstState on creation complete for ex.) so that
both views get created on startup. But it's quite dirty! there must
be a better way<br>
starting to wonder if sol 3 is not better...</p></div>sitronniertag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T21:34:41Z2010-03-31T21:34:41ZBest use of model->mediator->view when using Flex 4 States<div><p>I'm glad I'm not the only one getting that result. That's what I
thought - have a state that displays all views and then instantly
change to the initial view on creation complete (or something
similar). But you're right - it feels very dirty!</p>
<p>For the time being I have actually implemented solution 3, but
have persisted with solution 2 because it would be a much more
elegant solution (especially as the application is quite small).
Hopefully someone that's a bit more familiar with the intricacies
of Flex 4 states can help us out on this one!</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-03-31T22:20:00Z2010-03-31T22:20:00ZBest use of model->mediator->view when using Flex 4 States<div><p>Indeed, the first problem is that you were bitten by a fug
(feature/bug), and for that I must apologize - if the view you are
mapping is the contextView, and autoCreate is true, the mediator
will be created immediately. Auto-mediation is triggered by view
components landing on the stage, but startup only runs once your
contextView is already on stage.. and people wanted auto-mediation
to work when mapping to the contextView in startup, so.. we added..
a fug. I should have listened to Robert:</p>
<p><a href=
"http://groups.google.com/group/robotlegs/browse_thread/thread/a6315e8d1cc6a638/c6a82cf1c0d56038?#c6a82cf1c0d56038">
http://groups.google.com/group/robotlegs/browse_thread/thread/a6315...</a></p>
<p>Anyhoo, moving along to the states stuff. One option is to leave
autoCreate on and turn autoRemove off. I'd remove
'creationPolicy="all"' from InterfaceTestView. And in
InterfaceTestViewContext startup() I'd have:</p>
<pre>
// Mediators will be created lazilly, but require manual removal
mediatorMap.mapView( FirstView, FirstViewMediator, IFirstView, true, false );
mediatorMap.mapView( SecondView, SecondViewMediator, ISecondView, true, false );
// This is going to create a mediator immediately because
// autoCreate is true and the contextView is already on stage
mediatorMap.mapView( InterfaceTestView, ApplicationMediator, IApplicationView );
</pre>
<p>I've modified the FXP (should contain both the AIR and Library
projects), attached.</p>
<p>Personally, I'd leave both autoCreate and autoRemove on, thereby
only updating the views when they are actually visible. But, it
seems that that is exactly what you are trying to avoid!</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-04-01T09:42:24Z2010-04-01T09:42:24ZBest use of model->mediator->view when using Flex 4 States<div><p>Hi Shaun,</p>
<p>Thanks for taking a look. I've learnt from this that I should
just do it properly in the first place! Like you said, only
mediating the views that are actually visible. So referring back to
my original post, I've implemented solution 3 and, as Joel
suggested, performed a comparison on the collection in the view; so
the collection in the view is updated rather than replaced. This
seems to be working well so far.</p>
<p>Thanks for the useful conversation guys - at least now know the
order in which I should map mediators to views (and how not to do
things) !</p>
<p>Cheers,</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-05-24T20:22:29Z2010-05-24T20:22:31ZBest use of model->mediator->view when using Flex 4 States<div><p>I'm up against this same issue, and I'm using solution 3, but
I'm not happy with it. My Mediators have handlers in their
eventMaps for framework events triggered by changes in the data
model, and if the Mediator were in existence when those events were
sent, that would suffice. AND the Mediators would never need a
reference to a Model or Proxy object, whether injected or not! So
just because the Flex 4 states don't properly implement
itemCreationPolicy, not only do my Mediators have to hold a
reference to a Proxy but they also have to duplicate code from
their framework event handlers in another handler for when the View
becomes ready.</p>
<p>It just don't seem right.</p></div>Alan Shawtag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-05-24T20:32:34Z2010-05-24T20:32:34ZBest use of model->mediator->view when using Flex 4 States<div><p>Furthermore, the Proxies now have to expose accessors for the
data the Mediator's gonna ask for to populate the View. Am I
completely misunderstanding this?</p></div>Alan Shawtag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-05-25T08:44:00Z2010-05-25T08:44:00ZBest use of model->mediator->view when using Flex 4 States<div><p>Hi Alan,</p>
<p>I don't think you're misunderstanding it, unless I am too. When
I implemented this, my mediators had to have reference to the model
objects and the model would have to have accessors to expose its
data. It becomes even trickier when you're using something like a
list and you want the scroll position to remain constant when
switching between states. It would be helpful if there was a
pattern, or util class, that could help in such situations. But I
agree, it just don't seem right!</p>
<p>Mark</p></div>Mark (markstar)tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-05-25T15:35:40Z2010-05-25T15:35:40ZBest use of model->mediator->view when using Flex 4 States<div><p>Apologies if you know all this already, but for the sake of
completeness:</p>
<p>Deferred instantiation is a big part of Flex. Resources, and
more importantly, potential network operations, should only occur
when a user navigates to an area that requires such
resources/operations.</p>
<p>Even without a framework, until you fully understand and embrace
deferred instantiation, you will constantly be battling against
components that are not quite ready to be programmatically
accessed.</p>
<p>The easy (and not recommended) way out is to force immediate
instantiation of all sub components. This is a waste of resources
but dramatically simplifies programmatic access of sub components -
the components are immediately accessible and ready to be
manipulated.</p>
<p>Another approach is to work <em>with</em> deferred
instantiation. This means taking into account the fact that things
aren't always ready in time for convenient programmatic access.</p>
<p>For example, you may have a list of users (model) that you'd
like to represent with a Flex list component (view), but only when
the user navigates to the appropriate part of the app. When the
user list (model) is created/updated you cannot guarantee that the
Flex list component is on-screen, instantiated and ready to be
used. You will, at minimum, be required to: 1. set the data on the
Flex list when it becomes ready, and 2. wire up an observer pattern
(or use binding) to keep the list in sync with the model.</p>
<p>RL simplifies this by giving you mediators that work
<em>with</em> the principles of deferred instantiation: you can be
sure that your component is ready to be manipulated when it's
mediator is registered, and likewise, you can perform any tear-down
when the view component is removed. There is usually little point
in keeping a view component synchronized with a model when that
view component is not on-screen. There are times when this is not
desired (like in Mark's case), in which case you have a number of
options regarding the life-cycle of the mediator that can be set
when mapping.</p>
<p>I'm attaching an example (similar to the one attached
previously, but simpler) that demonstrates mediators that are
automatically created but manually removed. Notice the trace
statements that show the order of registration and removal of
mediators.</p>
<p>I'm not sure that I've actually answered any of your questions
adequately.. it's possible I'm completely missing the point - in
which case I apologize. Perhaps some stripped down source that
demonstrates the problem would help.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-05-25T16:49:43Z2010-05-25T16:49:45ZBest use of model->mediator->view when using Flex 4 States<div><p>Thanks for the example.</p>
<p>I really wouldn't mind too much if my views existed from
application startup; I do want them to be properly updated when
they appear on screen, and I don't want to write redundant code in
my mediators or expose the data in my models to make this
happen.</p>
<p>Maybe this just means we should not be using States, but I'd
like to keep them in place because we're integrating SWFAddress to
manage the transitions.</p>
<p>If I could create the Mediators up front, before the Views are
needed, I could cache the data there when it comes from the
framework events; then at least I wouldn't have to pull it from the
Proxy when it's already been pushed. I could then populate the
Views when they come into existence on state changes.</p>
<p>I'm experimenting now with a separate Actor who will assemble
the data for the view (some of it may come in asynchronously), then
trigger the state change, then upon a request from the mediator
once the view is ready, provide the data. No need for accessors on
the model, no need for a reference to the model in the mediator. I
suspect that this may simply qualify as a better-designed Model
object. OR IS IT? Maybe it's a total perversion of the MVC
architecture.</p></div>Alan Shawtag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-10-06T11:55:14Z2010-10-06T12:12:03ZBest use of model->mediator->view when using Flex 4 States<div><p>Mediators are trashed when a component is removed from the stage in a state change, correct ?</p></div>Nikos tag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-10-06T12:07:45Z2010-10-06T12:07:45ZBest use of model->mediator->view when using Flex 4 States<div><p>If you have mapped them with "autoRemove" (the default), then yes:</p>
<p><a href="http://github.com/robotlegs/robotlegs-framework/blob/v1.3.0/src/org/robotlegs/core/IMediatorMap.as#L25">http://github.com/robotlegs/robotlegs-framework/blob/v1.3.0/src/org...</a></p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/13416262010-10-06T12:14:59Z2010-10-06T12:14:59ZBest use of model->mediator->view when using Flex 4 States<div><p>I see, so if its set to not remove then the mediator will still communicate with the object off the stage (to be added back to the stage on state chnage)?</p>
<p>This wouldn't be a problem for my app I think.</p></div>Nikos