tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/1134-right-way-to-handle-the-logic-inside-the-view-especially-when-mediator-only-has-access-to-the-modelRobotlegs: Discussion 2018-10-18T16:35:43Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/194560022012-10-09T07:46:53Z2012-10-09T07:46:53ZRight way to handle the logic inside the view, especially when mediator only has access to the model ?<div><p>I have noticed this problem many times.<br>
Also went through this : <a href=
"http://knowledge.robotlegs.org/discussions/questions/433-if-i-dont-handle-view-logic-in-my-mediator-than-where">
http://knowledge.robotlegs.org/discussions/questions/433-if-i-dont-...</a><br>
however yet a doubt in mind</p>
<p>It's mentioned there in the Robotlegs knowledge base "Mediator
should not contain the logic". But the problem i face is that many
times much of the logic inside the view is dependdent upon many of
the variables inside statsModel.<br>
The way i handle is to make an initView function in mediator ( that
is called when mediator is created), that passes all useful
variables from statsmodel into the view. This way all the useful
variables can be accessed by view.</p>
<p>However this can't be done everytime, and i end up with a logic
inside mediator that uses mediator variables to decide the fate of
view.</p>
<p>I want to know what's the right way to handle the situation.</p>
<p>Thanks<br>
V.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/194560022012-10-09T12:24:43Z2012-10-09T12:24:43ZRight way to handle the logic inside the view, especially when mediator only has access to the model ?<div><p>I usually either have changeable logic as compositable classes
that can be set on the view, or some form of adaptor that wraps the
view, does its stuff, then dispatches to the mediator to pass
on.</p></div>neiltag:robotlegs.tenderapp.com,2009-10-18:Comment/194560022012-10-18T14:04:54Z2012-10-18T14:04:56ZRight way to handle the logic inside the view, especially when mediator only has access to the model ?<div><p>I have a similar issue. Say my service executes, and updates my
model. My mediator stufs the model data into the view.</p>
<p>However, what if I want to use the same data in another view,
but the format of the data required by the view is slightly
different. Maybe I need to compute a "total" for a datagrid or the
data should be alpha vs numeric or it wants percentage as 0.15 vs
15</p>
<p>Because the "orientation" of the data is really view specific,
it would seem to me that this logic should not be in the model. The
natural place seems to be in the mediator?</p></div>Brucetag:robotlegs.tenderapp.com,2009-10-18:Comment/194560022012-10-18T14:23:18Z2012-10-18T14:23:18ZRight way to handle the logic inside the view, especially when mediator only has access to the model ?<div><p>@bruce if a total field uses a different algorithm for each
view, then maybe it should be in the view?</p>
<p>or again you could encapsulate that logic in a function or class
that can be passed into the view.</p></div>neiltag:robotlegs.tenderapp.com,2009-10-18:Comment/194560022012-10-19T18:45:57Z2012-10-19T18:45:58ZRight way to handle the logic inside the view, especially when mediator only has access to the model ?<div><p>Yeah, I have the logic in the view now ... seemed like the most
sensible place for it ..</p></div>Brucetag:robotlegs.tenderapp.com,2009-10-18:Comment/194560022012-10-23T17:10:19Z2012-10-23T17:10:19ZRight way to handle the logic inside the view, especially when mediator only has access to the model ?<div><p>can this thread be closed now?</p></div>neil