tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/9745-mutiple-intialization-data-from-serverRobotlegs: Discussion 2014-03-11T08:48:29Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-11T14:32:57Z2014-02-11T14:32:57ZMutiple intialization data from server<div><p>Hi Angelo,</p>
<p>Not sure how far you are in the learning process. You can skip
the Basics part, or read it and excuse the redundancy, in case you
are more advanced already :)</p>
<h2><a class="anchor" href="#basics" name="basics" id=
"basics"></a>BASICS</h2>
<p>As a first step, I recommend reading the documents linked
bellow. They were written for robotlegs version 1, so the usage of
robotlegs classes is different from robotlegs 2, but the ways of
applying the MVCS design patterns are the same.</p>
<p><a href=
"https://github.com/robotlegs/robotlegs-framework/wiki/Overview">https://github.com/robotlegs/robotlegs-framework/wiki/Overview</a><br>
<a href=
"https://github.com/robotlegs/robotlegs-framework/wiki/best-practices">
https://github.com/robotlegs/robotlegs-framework/wiki/best-practices</a></p>
<p><a href=
"http://www.developria.com/2010/06/an-introduction-to-robotlegs-a.html">
http://www.developria.com/2010/06/an-introduction-to-robotlegs-a.html</a><br>
<a href=
"http://www.developria.com/2010/06/an-introduction-to-robotlegs-a-1.html">
http://www.developria.com/2010/06/an-introduction-to-robotlegs-a-1....</a><br>
<a href=
"http://www.developria.com/2010/06/an-introduction-to-robotlegs-a-2.html">
http://www.developria.com/2010/06/an-introduction-to-robotlegs-a-2....</a></p>
<p>If you can afford it, buy the robotlegs book: <a href=
"http://shop.oreilly.com/product/0636920021216.do">http://shop.oreilly.com/product/0636920021216.do</a></p>
<p><a href=
"https://github.com/robotlegs/robotlegs-framework/wiki/Robotlegs-Internals">
https://github.com/robotlegs/robotlegs-framework/wiki/Robotlegs-Int...</a></p>
<p>After understanding the basic principles of the MVCS and how
they can be implemented with robotlegs, and also how Dependency
Injection works, you can take a look at robotlegs v. 2
documentation:</p>
<p><a href=
"https://github.com/robotlegs/robotlegs-framework/blob/master/src/robotlegs/bender/readme.md">
https://github.com/robotlegs/robotlegs-framework/blob/master/src/ro...</a></p>
<p>Now, back to your use case. I'll present a generic workflow. Of
course, there may be several possible workflows, depending on your
project's structure and requirements.<br>
Because I don't know how exactly you're going to use the
comboboxes, I'll use them in my explanation as if they were 5
separate Views, each of them with its own Mediator. Also, because I
don't know whether loading the data for the comboboxes requires
multiple requests from the server or not, I'll simplify the example
by using a single server call and setting the data for just one
combobox.</p>
<p>[1] Create a robotlegs <strong>Context</strong> - preferably in
the root display object of your application</p>
<p>[2] After context initialization dispatch a custom event (on the
shared event dispatcher) triggering a <strong>Command</strong></p>
<p>[3] The Command accesses a <strong>Service's</strong> API</p>
<p>[4] The Service loads the data for the combobox</p>
<p>[5] When the data has been received, and has been parsed into
the desired format (or not), the Service can</p>
<pre>
<code>a. either **dispatch an event** with the data as a payload
b. or set the data directly on a Model</code>
</pre>
<p>[6] If the Server dispatches an event instead of accessing the
Model directly, that event can:</p>
<pre>
<code>a. either trigger a **Command** that would access a Model, setting the received data
b. or a Mediator, that has registered an event listener, could listen for that event</code>
</pre>
<p>[7] Assuming that you opted for the version where the Service
dispatched an event that triggered a Command, that accessed a
Model, after setting the data on the Model, the
<strong>Model</strong> dispatches an event with the data as a
payload</p>
<p>[8] The <strong>Mediator</strong> that has registered an event
listener for the event dispatched by the Model accesses its View's
API and passes the event's payload to the View</p>
<p>[9] The <strong>View</strong> uses that payload to set the data
provider of the combobox</p>
<p>Using a VO to transport data is a good practice. The Model
receiving the loaded data from the Service can wrap the data in a
VO and send it to the Mediator via a custom event.</p>
<p>The above flow simplified:</p>
<ul>
<li>
<p>custom Event->Command->Service->custom
Event->Command->Model->custom
Event->Mediator->View's API->combobox data provider</p>
</li>
<li>
<p>custom Event->Command->Service-> Model->custom
Event->Mediator->View's API->combobox data provider</p>
</li>
<li>
<p>custom Event->Command->Service->custom
Event->Mediator->View's API->combobox data provider
(without Model)</p>
</li>
</ul>
<p>In Joel's tutorials, you can see a different approach, where
Models are injected into Mediators.</p>
<p>You'll have to decide which approach is more suitable for your
application.</p>
<h2><a class="anchor" href="#your-question" name="your-question"
id="your-question"></a>YOUR QUESTION</h2>
<p>Are you asking how to manage <strong>multiple calls</strong> to
a server at start-up?<br>
Or, if loading the data requires just a <strong>single server
call</strong>, are you asking how to distribute the data to the
various Views?</p>
<p>See if these are of any use to you:</p>
<ul>
<li>
<p>Neil's state machine : <a href=
"https://github.com/AS3StateMachine">https://github.com/AS3StateMachine</a></p>
</li>
<li>
<p>Macro command utility for Robotlegs 2 which provides the ability
to execute batches of commands in sequential or parallel fashion:
<a href=
"https://github.com/alebianco/robotlegs-utilities-macrobot">https://github.com/alebianco/robotlegs-utilities-macrobot</a></p>
</li>
<li>
<p><a href=
"https://github.com/DavidWhittingham/robotlegs-utilities-DeferredCommandQueue">
https://github.com/DavidWhittingham/robotlegs-utilities-DeferredCom...</a></p>
</li>
<li>
<p><a href=
"https://github.com/DavidWhittingham/robotlegs-extensions-SignalStateMachine">
https://github.com/DavidWhittingham/robotlegs-extensions-SignalStat...</a></p>
</li>
<li>
<p>rl2's Command detain() and release() functionality</p>
</li>
</ul>
<p>Let me know what you've chosen :)</p>
<p>If I didn't answer your question, please go into details about
your use case or ask more specific questions.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-11T17:25:20Z2014-02-11T17:47:54ZMutiple intialization data from server<div><p>Thanks a LOT Ondina for your reply. Seeing a so compromised team
is what made me choose this framework. I remember my team saying to
me last week when I was presenting robotlegs to them "please, if we
are going to change from MATE to this new one promise that we will
stay on this for the next few years" ...and this is what I
hope...</p>
<p>Answering your questions:</p>
<p>BASICS - I think I am beyond the basics already. I studied a lot
different frameworks like cairmgorn and MATE and this one is not
any mistery. I also read the robotleg's book in a single day :D</p>
<hr>
<p>Generic Workflow - I implemented a singles generic workflow to
populate one combobox in this simples way:</p>
<p>[1] - Created a context on AppConfig</p>
<p>[2] - On Appconfig implements IConfig :</p>
<pre>
<code> ...eventCommandMap.map(Event.INIT).toCommand(LoadInitialDataCommand)
... context.afteriniInitializing(init)
public function init(){</code>
</pre>
<p>....dispatcher.dispachEvent(new Event(Event.INIT))</p>
<p>[3] - On LoadInitialDataCommand:</p>
<p>public function execute():void{ service.loadUsuarios()}</p>
<p>[4] - On UsuarioService:</p>
<p>public function loadUsuarios():void{<br>
a) read XML<br>
b) parse XML<br>
c) dispach event UsuarioSeriviceEvent with Arraycollection of
UsuarioVO as payload</p>
<p>[8] - Mediator of combobox listened the UsuarioServiceEvent and
updated the dataprovider with the Arraycollection carried by the
event as payload.</p>
<p>Until here....everything worked ok...but I am looking for the
best technique to solve my problem.</p>
<h2><a href=
"#i-am-giving-a-deep-look-inside-macrobot-right-now-because-i-think-the-parallelcommand-is-what-i-am-looking-for-the-signal-and-statemachine-i-am-still-trying-to-figure-what-it-is-and-the-use-"
class="anchor" name=
"i-am-giving-a-deep-look-inside-macrobot-right-now-because-i-think-the-parallelcommand-is-what-i-am-looking-for-the-signal-and-statemachine-i-am-still-trying-to-figure-what-it-is-and-the-use-"
id=
"i-am-giving-a-deep-look-inside-macrobot-right-now-because-i-think-the-parallelcommand-is-what-i-am-looking-for-the-signal-and-statemachine-i-am-still-trying-to-figure-what-it-is-and-the-use-">
</a>I am giving a deep look inside Macrobot right now because I
think the ParallelCommand is what I am looking for. The Signal and
StateMachine I am still trying to figure what it is and the
use.</h2>
<p>My scenario so you can understand better what solution I am
looking for.</p>
<p>Case: There is a single forms with many textimputs and 5
combobox that are populated on the application when it starts.<br>
For the combobox to be populated , 5 server requests are made, each
one bringing different data that I must parse and load into
different combobox. One for Usuarios, other for Linhas, other for
Modaidades and so on...</p>
<p>I am almost sure that this problem is not anything new on the
development community but I don't know the best practice in dealing
with it.</p>
<p>a) Should I dispatch one event that is mapped into a single
command that execute five calls on a service ?</p>
<p>b) Should I dispatch five events that are mapped into five
differente commands that execute a call on five different services
? One for example on UsuarioService, other for ModalidadeService,
and so...or just a single service called InitialDataService is
enought ?</p>
<p>c) Should I store all the service results on five different
models, one for Usuarios (UsuarioModel), one for Linhas
(LinhaModel) and so...or store all that on a singles Model ?</p>
<p>d) In fact should I store the service results on a Model , or
dispach the result inside a event as payload directly to the
Mediator like I did ?</p>
<p>I am simply getting crazy on these questions...I know the final
answer is "well, it depends"...but I would like an opinion for the
expert team what is the best practice and the most common one.</p>
<p>Thanks in advance for all support you guys are given to
me...</p></div>Angelotag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-11T18:17:54Z2014-02-11T18:17:54ZMutiple intialization data from server<div><p>Hehe, Angelo, I hope we are not 'compromised'. I think, you
meant something else, with a bit more positive connotation than
'compromised', when you translated 'compromisso', right? ;)</p>
<p>I'm going to address your questions tomorrow, since it's already
late here, where I live.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-11T20:32:05Z2014-02-11T20:32:08ZMutiple intialization data from server<div><p>Hahahaha, sorry I mean, a team "committed" with the project !!
:D</p>
<p>As you can see what I am trying to achieve is a strategy to deal
with the initial load of my application using RB2.</p>
<p>Problem: 5 combobox on a single forms need to be populated in
the beggining of the application. Each combobox has its own data.
For this 5 server requests are made, each one bringing different
data.</p>
<p>Solution:</p>
<ul>
<li>Multiple commands dispacthed after firing a single event ?</li>
<li>Best practice in terms of how many services and/or models do
deal with all that data.</li>
<li>Best aproach:</li>
</ul>
<p>a) custom Event->Command->Service-> Model->custom
Event->Mediator->View's API->combobox data provider</p>
<p>b) custom Event->Command->Service->custom
Event->Mediator->View's API->combobox data provider
(without Model)</p></div>Angelotag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-12T07:58:09Z2014-02-12T07:58:09ZMutiple intialization data from server<div><p>Hola :)</p>
<p>Signals are great :) I prefer them over events, but everything
is ok.</p>
<p>Here are some thoughts.</p>
<p>Using an MVC pattern is good if you want to scale your app one
time in the future.</p>
<p>I would do it like this (if I know the app will be extended
somehow):</p>
<p>One command CallAllServices<br>
inside that command I would dispatch 5 signals <em>or events, cause
I use SignalCommandMap</em> that will call 5 different commands,
one for each IService API call. That way, later if you want you can
dispatch just one signal to get the data for one <em>Usuario</em>
and not all, but you still have one command that does it all.</p>
<p>You use Interface for service and you map it like:<br>
injector.map(IService).toSingleton(Service)</p>
<p>I would make multiple models, and on each update of data in the
model, dispatch a event or signal that will update the views. This
way if you want to implement some push service, you will update
just one model, and inside the view you will not check for all five
models, since you are listening for each separate.<br>
Why models, and not directly to the view?<br>
Well, if you want to make your app work with some offline data, and
the models can have some functionality that is unique to the type
of data that it is handling. Also, they are reusable because they
only handle single type of data, that is likely to be reused.<br>
You can check AS3Vanilla library for parson your JSON objects to
strongly typed VOs easily.</p>
<p>I would personally go with one service in this case, unless you
will make other apps that will use only part of the service, than
it makes sense to decouple the service for reusabilty :)</p>
<p>I hope this helps a little :)</p></div>matejtag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-12T13:15:39Z2014-02-12T18:15:13ZMutiple intialization data from server<div><h2><a class="anchor" name="-links-" href=
"#-links-"></a>[LINKS]</h2>
<p>Firstly, I wanted to add a few more links to the list of
possible utilities regarding async, chaining-just for the sake of
completeness... I'm not sure if all of them are easy to implement
with rl2. At least, you can see that there is more than one way to
skin the cat :)</p>
<p><strong>SignalResponder</strong>:</p>
<p><a href=
"https://github.com/creynders/SignalResponder">https://github.com/creynders/SignalResponder</a><br>
<a href=
"https://github.com/creynders/RelaxedSignalsDemo">https://github.com/creynders/RelaxedSignalsDemo</a></p>
<p><strong>Bootstrap</strong>:</p>
<p><a href=
"https://github.com/creynders/robotlegs-demo-bootstrap">https://github.com/creynders/robotlegs-demo-bootstrap</a></p>
<p><strong>Promises</strong>:</p>
<p><a href=
"https://github.com/darscan/robotlegs-extensions-Oil">https://github.com/darscan/robotlegs-extensions-Oil</a></p>
<p><a href=
"http://knowledge.robotlegs.org/discussions/questions/115-using-the-asynccommand-with-services-callbacksdiscussion">
http://knowledge.robotlegs.org/discussions/questions/115-using-the-...</a><br>
There are more discussions on this topic on this forum. Search for
'Promises'.</p>
<p><a href=
"https://github.com/jonnyreeves/as3-async">https://github.com/jonnyreeves/as3-async</a></p>
<p><a href=
"https://github.com/CodeCatalyst/promise-as3">https://github.com/CodeCatalyst/promise-as3</a></p>
<p><a href=
"https://gist.github.com/darscan/4519372">https://gist.github.com/darscan/4519372</a></p>
<p><strong>DirectCommandMap</strong>:</p>
<p><a href=
"https://github.com/robotlegs/robotlegs-framework/tree/master/src/robotlegs/bender/extensions/directCommandMap">
https://github.com/robotlegs/robotlegs-framework/tree/master/src/ro...</a></p>
<h2><a class="anchor" name="-your-use-case-" href=
"#-your-use-case-"></a>[YOUR USE CASE]</h2>
<blockquote>
<p>There is a single forms with many textimputs and 5 combobox that
are populated on the application when it starts.</p>
</blockquote>
<p>The first question is: what kind of data are these 5 lists
presenting to the user? Is there a need for a Model or not?</p>
<p>Are the lists 'mutable' or 'immutable'?</p>
<p>To make my life easier, I'll talk about a simple ScribbleView
containing 3 comboboxes:<br>
colors, tools, shapes. The data for the dataproviders of those
lists has been loaded from a data base, where each list is a table,
containing a set of pre-defined colors, tools or shapes. These
lists will never change on the client side.</p>
<p>The ScribbleView has 4 properties scribble_id, color, tool and
shape, which will be sent to a database to be inserted into a
'scribbles' table.</p>
<p>In this simple scenario, ScribbleView would be mediated by a
ScribbleMediator. A ScribbleVO with scribble_id, color, tool and
shape is used to transport the View's data.<br>
The user chooses a color, a tool and a shape from the comboboxes,
the 3 properties are set to the corresponding list's selectedItem.
When the user wants to save the Scribble, the ScribbleView
dispatches an event with the ScribbleVO as a payload, and
....[insert the long way to the Service here] the Service sends the
data to the data base.</p>
<p>So, in this very simple scenario there is no need for Models for
the 3 comboboxes. Also, the 3 comboboxes don't need to be treated
as 3 separated Views and they also don't need to be mediated.</p>
<p>The question is, does ScribbleView need a ScribbleModel or not?
It depends;)</p>
<p>In a little bit more complex scenario, you'd probably want to
load one Scribble from the server or even all the Scribbles as a
list. The scribblesList would be mutable, i.e. every time you save
<em>one</em> Scribble from the ScribbleView, the list of scribbles
needs to be updated.</p>
<p>Now, we have 2 Views, a ScribbleView representing a single
Scribble and a ScribblesListView with a list of scribbles. A
ScribblesListMediator and a ScribblesListModel are also needed!</p>
<p>In a more complex scenario you'd probably have a ScribblingView
(for lack of a better name) as the parent view for :
ScribblesListView, AmateurArtistsView, and a RatingsView, all of
them with their own Models representing their states.</p>
<p>When their data is loaded from the server, their Models will
have to be updated. When the user changes their data on the client,
their Models need to be updated as well. Also, because, for
example, if the ScribblesListView and AmateurArtistsView would
depend on each other's data in some way, they'd need to be notified
about the state changes of their Models.</p>
<p>Now, back to your 5 comboboxes. Which ones of them need a Model?
Also, can they be treated as separate Views? Do they need a
Mediator? How do they interact with each other and to what extend
will a change in a list affect the state of the application?</p>
<p>[EDIT] I didn't notice that Matej has already posted while I was
writing my answer to your questions :) As you can see, we both
agree on the fact that you'd need Models for your comboboxes in
case they are "mutable" and not just a set of predefined properties
and if their state affects the state of the application, or if you
need to manipulate their data in a way or another.</p>
<p>How to load the data for your comboboxes?</p>
<p>1000 and one possible scenarios ;)</p>
<p>One of them is what Matej said.</p>
<p>But, here again, I'd say, it depends on the nature of your
comboboxes.<br>
On the receiving part, the question is which Mediator will respond
to a Service event (via Command, Model or directly). The Mediator
of the View containing the combos, or, if the combos were 5
mediated views, the mediators of those combos?</p>
<p>On the requesting part, one Service or 5 Services? One command
or 5 commands?</p>
<p>Sorry, I'll have to continue this later...have to do something
related to my projects....</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-12T18:08:41Z2014-02-12T18:08:41ZMutiple intialization data from server<div><p>What was I saying? Ah, yes... How many services and commands are
needed?</p>
<p>Firstly, you'll need to decide how many server calls are in fact
needed? Can you fetch the data for all comboboxes over one call to
the server or do you need to call the server repeatedly? Are the
operations on the server side similar for all the comboboxes (like
in having the corresponding DB tables in the same DB, same Server,
similar table structures etc?</p>
<p>Then, in case you want or need to make a request for each
combobox separately, do you need a separate Service for each of
them, or can you use a generic server ( like your
InitialDataService), and let the Server know what to do through the
arguments passed to the remote object ? (Just a note to myself, so
I don't forget to mention it later, you can use factories to
assemble the data needed for the server call, as well as the data
coming from server in order to populate your models with the
results)</p>
<p>Will you need to access the server again during your app's
life-cycle or do you need it just at start-up?</p>
<p>(a)A client can request data from multiple DB tables at
once:</p>
<p>[1] 1 service for 1 server call, without models.</p>
<ul>
<li>a. client makes just <strong>one</strong> request for
Scribble's data ( colors, tools and shapes )</li>
<li>b. on the server side, a script selects from the colors, tools
and shapes tables and sends the results as a collection with the
table names as keys</li>
<li>c. on the client side, ScribbleView (after receiving the data
via its ScribbleMediator) sets the data providers of the comboboxes
using the keys of the collection to differentiate between them</li>
</ul>
<p>[2] 1 service for 1 server call, with 3 Models for each
comboboxes, but just one Mediator (ScribbleMediator)</p>
<ul>
<li>a and b same as before</li>
<li>c. when the data arrives from server, each Model would be first
updated and would dispatch an event. ScribbleMediator would have to
register 3 different event types for the 3 models in order to pass
their data to the view</li>
</ul>
<p>[3] 1 service for 1 server call, with 1 Model (ScribbleModel)
and 1 Mediator</p>
<ul>
<li>a and b same as before</li>
<li>c. ScribbleModel is updated with the collection coming from
server, either 1 or 3 collections, and dispatches 1 or 3 events to
ScribbleMediator</li>
</ul>
<p>(b) A client makes multiple server calls: [4] 1 service, 3
server calls, one for each combobox - here you need to use one of
the mentioned approaches for chaining the calls. I'll go into more
details about the number of commands later on, after you answer
some of my questions above.</p>
<p>[5] each combobox is actually a View with a Mediator and a
Model, and is associated with its own Command(s) and a Service(s).
They could be separate Modules as well.</p>
<p>or</p>
<p>See Shaun's answer for a use case where Services are called
directly from Mediators:</p>
<p><a href=
"http://knowledge.robotlegs.org/discussions/questions/144-how-to-approach-view-command-service-view#comment_1571572">
http://knowledge.robotlegs.org/discussions/questions/144-how-to-app...</a></p>
<p>...</p>
<p>Again, I have to discontinue the discussion for now..</p>
<p>Till tomorrow,<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-13T14:18:15Z2014-02-13T14:18:15ZMutiple intialization data from server<div><p>A little elucidation on the terms 'View' and 'Component', which
are pretty ambiguous. When I say View, I mean a functional area in
an application that is dealing with the user interface. A Component
being any kind of display object, TextInput, Button, List,
DataGrid.. A View may consist of only one or many Components, or
Sub-Views. A View is a re-usable functional area. A View may 'want'
to communicate with a framework via a Mediator, but not always. A
View, as a functional area, could be just a Sub-View of a mediated
View, and the communication between them is through events from the
sub-view to the parent-view (Events UP), and from the parent-view
to its sub-view via sub-view's API (API DOWN). Same, for a View
containing sub-components. (Views can be non-visual as well)</p>
<p>The relation between Views and Models. Do I need a Model to
represent a View, or do I need it to represent the domain data and
logic? A Model used to persist and manipulate the domain data may
be presented to the user in form of a View, but not necessarily. If
a View is used to let the user have access to the data of a Model,
the View is not always a 1:1 representation of the Model. Also, a
Model, storing data from an external source like a DB, may or may
not be a 1:1 representation of the data stored on the server.</p>
<p>When designing a UI driven app, I find it to be helpful to start
from the 2 ends of the app: the external resources and the UI,
External data <--->View, and identify the parts of the
external data that need to be persistent, manipulated, or stateful
during the life of the app. Are the changes made to them affecting
the state of the application? Is any other functional area
interested in that data? Am I dealing with data for 'configuration'
purposes or assets? That helps me decide if a View is going to be a
representation of a domain Model or not. I wouldn't create a Model
for a list of colors names or a list of ZIP codes.</p>
<p>I just wanted to finish some thoughts from yesterday, but I'm
stopping here, because the topic is really very complex.<br>
We can talk about the number of commands needed, after you answer
the questions from the previous posts.</p>
<p>Not as a solution to your problem, but just so you know, you can
map multiple events to the same command.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-13T17:15:32Z2014-02-13T17:55:19ZMutiple intialization data from server<div><p>Hi everybody.</p>
<p>Thanks for the replys. My head is spinning right now trying to
absorve so much information. I will see the links carefully on the
first opportunity.</p>
<p>The more we answer, the more questions arises on this topic.
This is excellent oportunity for sharing knowledge.</p>
<p>Giving more information about my scenario:</p>
<p>a) Backend DB is Oracle, middle tier is PHP (WAMP), frontend is
FLEX 4.5</p>
<p>b) My team is responsable for the development of all these
layers from backend logic (tables, packages, ...) to frontend.</p>
<p>c) The same combobox can be used on more than one view so do I
need a mediator for each or one mediator for all ? They all follow
the same rule.</p>
<p>d) I was planning on creating an "administration" view where you
can CRUD the data retrived for those combobox but I imagined if a
better idea would be to split the</p>
<p>application in two, one for the users only and the other for
administration. In this scenario while the collections are
immutable on the "Users" application dispensing</p>
<p>the model, in the "Administrator" one I would store all the
retrived data from server on models where I would add, edit and
delete.</p>
<p>e) Usually we call five times the server in the application
start to retrieve the necessary data, but I believe a better
aproach would be just one call to a single</p>
<p>script that returns five selects at the same time. After
receiveing the singles raw package by using a helper class we
convert all that raw data into five</p>
<p>arraycollections of VO objects and dispach an event for each of
the combobox to listen and populate and be populate by payload.</p>
<p>f) Following the Scribble example, usually the color, tool and
shape entities on our database are three separate tables where tool
table is tool_id, tool, color table</p>
<p>is color_id, color, shape table is shape_id, shape ...Now the
retrived data carries all that information (including id) so it
facilitates on the reverse process where</p>
<p>whe need to insert a new Scribble on the scribble table that is
composed by scribble_id, tool_id,color_id and shape_id (foreign
keys). When I select a color on the</p>
<p>combobox, in the end I just send the color_id for the service to
insert on the database, is this the best aproach ?</p>
<p>g) By the way I didn´t understand what Signals are and the
use, can anyone give some more help ? I alredy read the
documentation.</p>
<p>h) Do you have any example of application source code using RB
to acess the server side using PHP and remote object ?</p>
<p>i) On our case and after all the ansers I belive the best
sollution on the start of the application:</p>
<p>1) Single event mapped in a single command that does a single
service call to the server.<br>
2) The service result containing 5 cursors are parsed into 5
arraycollection of VO´s and 5 service events are dispatched
carrying each one the respective collection as a payload.<br>
3) A single mediator mediating 5 combobox listen to those service
events and update the dataprovider of the respective combobox.</p>
<p>Is this a good solution ?</p>
<p>Best regards,<br>
Angelo</p></div>Angelotag:robotlegs.tenderapp.com,2009-10-18:Comment/315550122014-02-14T12:02:31Z2014-02-14T16:11:02ZMutiple intialization data from server<div><blockquote>
<p>c) The same combobox can be used on more than one view so do I
need a mediator for each or one mediator for all ? They all follow
the same rule.</p>
</blockquote>
<p>In the Scribble example, if the colors combobox is used in more
than one View just for setting a property of the parent View when
an item is selected, then you don't need to mediate the combobox.
In my example, the colors list's data provider is always the
same.</p>
<p>But, if another view, let's call it EditColorsView, would change
the list of colors, then every other View using the colors combobox
should be notified about the changes(via their mediators), in order
to update the dataprovider of the colors combobox.<br>
Now, if the Views using a colors combobox have a similar structure
and logic, like in having multiple ScribbleViews added to the stage
at the same time, it would suffice to let ScribbleMediator
communicate with the EditColorsMediator, or to react to an event as
a result of a CRUD operation on the server. In this simple
scenario, it would be an overkill to have a Mediator for each
combobox.</p>
<p>Though, depending on other criteria and on the flow and
structure of your app, it might be beneficial to have a
ColorsListView paired with a ColorsListMediator, which would handle
the communication with a service or other mediators, like
EditColorsMediator for example, so the mediators of the Views
containing a ColorsListView wouldn't have to care about the colors
dataprovider..</p>
<p>On the other hand, a ScribbleView which can be part of several
other Views, will always need its own ScribbleMediator.</p>
<p>Deciding which Component should become a View, and which View
needs a Mediator depends on lots of factors. How granular you want
to go with your mediators is often a matter of personal
preferences. You can approach the problem from the bottom up or
from the top down.<br>
From the <strong>bottom-up</strong>, you first assume that
<strong>every</strong> component should have its own mediator, and
then decide later which ones could in fact be grouped together to
form a View, so that they don't need individual mediation.</p>
<p>I prefer the <strong>top-down</strong> approach, because it
feels more natural when designing an application. You don't always
now how many components you need in the beginning. You start
creating the general functional areas and then break them down into
more granular pieces of functionality. If I decided that my app
should have an Intro, Login, Scribbling, and an Admin section, then
I'd firstly create the IntroView, LoginView, ScribblingView and
AdminView and their corresponding mediators. If the Login section
has just a username and a password as input fields and a send
button, I'm not going to create mediators for these components.
But, if the Login section becomes more complex than that, say, I
needed a CreateAccount functionality, then instead of adding more
components to the LoginView and more event listeners to the
LoginMediator, I'd create another CreateAccountView with its own
Mediator. Both, LoginView and CreateAccountView belong to a 'User'
section, so now, maybe I could create a parent View(say, UserView
paired to a UserMediator) to hold the 2 sub-views, where I add a
log in and a create account button, to switch between views. Of
course, that could be designed differently, for example, UserView
containing just the 2 buttons, and opening the LoginView or
CreateAccountView as popups.</p>
<p>Another approach could be to look at the components with the
intention in mind of creating Modules. Is it reasonable to create a
Module for the Send button of the LoginView?</p>
<p>After following the top-down path, it is indeed useful to use
the bottom-up approach, when Views become more complex and their
Mediators would have to do a lot more work. After knowing the
overall hierarchy of your app and identifying the main functional
areas, you can decide which Component needs to form another
functional area(a View), together with other Components or alone.
What are their responsibilities/roles, do they need to collaborate
with other parts of your app, are they re-usable in the sense that
their functionality is needed in more places..., then they probably
deserve having a Mediator. So, with this in mind, even a single
button might need its own Mediator under certain circumstances.</p>
<blockquote>
<p>d) I was planning on creating an "administration" view where you
can CRUD the data retrived for those combobox but I imagined if a
better idea would be to split the application in two, one for the
users only and the other for administration.</p>
</blockquote>
<p>Oh, that's for you to decide:) You are the one knowing all the
requirements and the flow of your app. Both would work, I
guess.<br>
Anyway, it sounds about right to have Models for CRUD operations.
As said before, if other parts of an app are interested in the
changes made to a set of data, Models could hold the state of that
data and inform every interested party about changes made to
it.<br>
There are other use cases as well. See this discussion on a similar
topic:<br>
<a href=
"http://knowledge.robotlegs.org/discussions/robotlegs-2/9319-mvcscrud-workflows-revisited">
http://knowledge.robotlegs.org/discussions/robotlegs-2/9319-mvcscru...</a></p>
<blockquote>
<p>e) ....but I believe a better aproach would be just one call to
a single...</p>
</blockquote>
<p>That sounds good. It is similar to one of the solutions I was
suggesting in one of my previous posts.<br>
But, as far as I remember, I also asked you if you needed to
retrieve the data more than once during the lifecycle of your app.
Say, if you needed to load the colors at startup together with the
tools and shapes, and then again in another View or Module just the
colors, then you need to decide what's better for you, having
separate server calls, one for each combobox, or using the remote
arguments to let the server script know which db table to access
(an array of one or more elements)</p>
<blockquote>
<p>f) Following the Scribble example.... When I select a color on
the combobox, in the end I just send the color_id for the service
to insert on the database, is this the best aproach ?</p>
</blockquote>
<p>Sure, why not. It depends on the structure of your db scribbles
table. Having color_id, tools_id and shape_id in the scribbles
table is a good db practice.</p>
<blockquote>
<p>g) By the way I didn´t understand what Signals are and the
use, can anyone give some more help ? I alredy read the
documentation.</p>
</blockquote>
<p>Well, that's an entirely new question:) You can see how your
short question in the beginning of the discussion ended up to be a
complex one, actually composed of many complex sub-questions, and
how much time it takes for both of us to talk about it. So, let's
concentrate on your original question(s)<br>
Signals are cool, don't get me wrong, but I'd recommend to get
acquainted with how rl2 works with events, for the time being, and
look at the Signals at a later point in time. As you said, there is
a lot of information to soak in, don't make your life harder than
it needs to be;)</p>
<blockquote>
<p>h) Do you have any example of application source code using RB
to acess the server side using PHP and remote object ?</p>
</blockquote>
<p>To see how you can use a RemoteObject with robotlegs take a look
at:<br>
<a href=
"https://github.com/joelhooks/robotlegs-examples-UnionPlatformChatClient">
https://github.com/joelhooks/robotlegs-examples-UnionPlatformChatCl...</a><br>
<a href=
"https://github.com/joelhooks/robotlegs-examples-UnionPlatformChatClient/blob/master/src/org/robotlegs/examples/bootstrap/controller/configuration/ConfigureServicesCommand.as">
https://github.com/joelhooks/robotlegs-examples-UnionPlatformChatCl...</a><br>
<a href=
"https://github.com/joelhooks/robotlegs-examples-UnionPlatformChatClient/blob/master/src/org/robotlegs/examples/bootstrap/service/UserService.as">
https://github.com/joelhooks/robotlegs-examples-UnionPlatformChatCl...</a><br>
It is a rl version 1 app, but I think that's not a problem for
you.</p>
<blockquote>
<p>i) On our case and after all the ansers I belive the best
sollution on the start of the application..</p>
</blockquote>
<p>Yes, it could work. Try it out and see how it feels. We've
discussed so many scenarios, already, but, of course, we can't
exhaust all the possible solutions. You'll know soon enough if you
need to re-factor your app.</p>
<p>Aahhh, now my head is spinning too:)</p>
<p>Ondina<br>
P.S.</p>
<h2><a class="anchor" name="commands" href="#commands" id=
"commands"></a>Commands</h2>
<p>I still owe you an answer regarding the use of Commands, but, I
guess, it should be clear by now, that the level of granularity on
each tier (Model, View, Controller) depends on many factors and on
personal preferences.</p>
<p>Whether you use 4 commands, one for every CRUD operation, or you
use a single command and let the Server side code decide what to do
based on the request parameters, it's up to you.</p>
<p>Whether every functional area in your app has its own set of
CRUD commands or it uses the more generic ones from above, it is
also a decision you'll have to make on your own, based on the
overall structure of your project.</p>
<p>Same with custom events. You'll be the one to decide whether
there is a need for a custom event for each functional area, as in
UserEvent, ScribbleEvent, AdminEvent, or you can use a more general
CRUDEvent for all of them, with different event types for different
actions: RETRIEVE_DATA, DATA_RETRIEVED, UPDATE_DATA, DATA_UPDATED,
DELETE_DATA, DATA_DELETED and so on.</p>
<p>In my experience, both scenarios work just fine.</p>
<p>Sometimes it is more advantageous, or easier to manage, if you
implement each functional area or Module having its own set of
commands, one for each CRUD operation paired to a corresponding
event type. UserEvent.DELETE_USER mapped to a DeleteUserCommand,
which would access a UserService's API delete() and so on.<br>
In other cases, you might want to have each Module communicate with
a single Service, residing in a parent context or in another
Module. But, here again, you'll have to know what's more
appropriate for your app.</p>
<p>In any case, I'd recommend starting with the design that is
easier for you to implement, using a reduced-scale application.
Easier to implement doesn't necessarily mean less code!<br>
I'd also recommend to look at your application from a modular point
of view, even if you're not going to use (Flex) Modules or multiple
contexts in your app. Or, from the perspective of putting some
common features into a library.<br>
Well, you actually know all of this already, I just got carried
away by the discussion :) Sorry.</p>
<p>On the subject of Services, I meant to give you a link to
Shaun's answer, but I forgot. Here it is:<br>
<a href=
"http://knowledge.robotlegs.org/discussions/robotlegs-2/38-service-with-a-large-api#comment_17269563">
http://knowledge.robotlegs.org/discussions/robotlegs-2/38-service-w...</a></p>
<p>Now, I hope, Matej and I have given you enough info to keep you
occupied for the next few days :P</p></div>Ondina D.F.