Home → Robotlegs 2 →

Mutiple intialization data from server

• Edit

Angelo

11 Feb, 2014 10:31 AM

Hi everybody, I am working hard on learning RB2. I spend a whole day just in examples and so to figure how it works...

Right now I am developing with my team a web application with multiple data that need to be retreived from a server and populate 5 combobox during initialization

Can anyone recomend a flow for this ? What is the best practice in this situations ? Also do I need to create multiple models to store all that data (UsuarioVo,LinhaVo,ClasseVo,CategoriaVo,EquipamentoVo,...) ?

I am new to RB framework and being trying to move from Mate to this one...

1. Support Staff 1 Posted by Ondina D.F. on 11 Feb, 2014 02:32 PM

   

   Hi Angelo,

   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 :)

   BASICS

   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.

   https://github.com/robotlegs/robotlegs-framework/wiki/Overview
   https://github.com/robotlegs/robotlegs-framework/wiki/best-practices

   http://www.developria.com/2010/06/an-introduction-to-robotlegs-a.html
   http://www.developria.com/2010/06/an-introduction-to-robotlegs-a-1....
   http://www.developria.com/2010/06/an-introduction-to-robotlegs-a-2....

   If you can afford it, buy the robotlegs book: http://shop.oreilly.com/product/0636920021216.do

   https://github.com/robotlegs/robotlegs-framework/wiki/Robotlegs-Int...

   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:

   https://github.com/robotlegs/robotlegs-framework/blob/master/src/ro...

   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.
   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.

   [1] Create a robotlegs Context - preferably in the root display object of your application

   [2] After context initialization dispatch a custom event (on the shared event dispatcher) triggering a Command

   [3] The Command accesses a Service's API

   [4] The Service loads the data for the combobox

   [5] When the data has been received, and has been parsed into the desired format (or not), the Service can

   a. either **dispatch an event** with the data as a payload
   b. or set the data directly on a Model
   

   [6] If the Server dispatches an event instead of accessing the Model directly, that event can:

   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
   

   [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 Model dispatches an event with the data as a payload

   [8] The Mediator 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

   [9] The View uses that payload to set the data provider of the combobox

   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.

   The above flow simplified:

   • custom Event->Command->Service->custom Event->Command->Model->custom Event->Mediator->View's API->combobox data provider

   • custom Event->Command->Service-> Model->custom Event->Mediator->View's API->combobox data provider

   • custom Event->Command->Service->custom Event->Mediator->View's API->combobox data provider (without Model)

   In Joel's tutorials, you can see a different approach, where Models are injected into Mediators.

   You'll have to decide which approach is more suitable for your application.

   YOUR QUESTION

   Are you asking how to manage multiple calls to a server at start-up?
   Or, if loading the data requires just a single server call, are you asking how to distribute the data to the various Views?

   See if these are of any use to you:

   • Neil's state machine : https://github.com/AS3StateMachine

   • Macro command utility for Robotlegs 2 which provides the ability to execute batches of commands in sequential or parallel fashion: https://github.com/alebianco/robotlegs-utilities-macrobot

   • https://github.com/DavidWhittingham/robotlegs-utilities-DeferredCom...

   • https://github.com/DavidWhittingham/robotlegs-extensions-SignalStat...

   • rl2's Command detain() and release() functionality

   Let me know what you've chosen :)

   If I didn't answer your question, please go into details about your use case or ask more specific questions.

   Ondina

   • Edit

2. 2 Posted by Angelo on 11 Feb, 2014 05:25 PM

   

   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...

   Answering your questions:

   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

   ---

   Generic Workflow - I implemented a singles generic workflow to populate one combobox in this simples way:

   [1] - Created a context on AppConfig

   [2] - On Appconfig implements IConfig :

      ...eventCommandMap.map(Event.INIT).toCommand(LoadInitialDataCommand)
     ... context.afteriniInitializing(init)
     public function init(){
   

   ....dispatcher.dispachEvent(new Event(Event.INIT))

   [3] - On LoadInitialDataCommand:

   public function execute():void{ service.loadUsuarios()}

   [4] - On UsuarioService:

   public function loadUsuarios():void{
   a) read XML
   b) parse XML
   c) dispach event UsuarioSeriviceEvent with Arraycollection of UsuarioVO as payload

   [8] - Mediator of combobox listened the UsuarioServiceEvent and updated the dataprovider with the Arraycollection carried by the event as payload.

   Until here....everything worked ok...but I am looking for the best technique to solve my problem.

   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.

   My scenario so you can understand better what solution I am looking for.

   Case: There is a single forms with many textimputs and 5 combobox that are populated on the application when it starts.
   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...

   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.

   a) Should I dispatch one event that is mapped into a single command that execute five calls on a service ?

   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 ?

   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 ?

   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 ?

   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.

   Thanks in advance for all support you guys are given to me...

   • Edit

3. Support Staff 3 Posted by Ondina D.F. on 11 Feb, 2014 06:17 PM

   

   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? ;)

   I'm going to address your questions tomorrow, since it's already late here, where I live.

   • Edit

4. 4 Posted by Angelo on 11 Feb, 2014 08:32 PM

   

   Hahahaha, sorry I mean, a team "committed" with the project !! :D

   As you can see what I am trying to achieve is a strategy to deal with the initial load of my application using RB2.

   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.

   Solution:

   • Multiple commands dispacthed after firing a single event ?
   • Best practice in terms of how many services and/or models do deal with all that data.
   • Best aproach:

   a) custom Event->Command->Service-> Model->custom Event->Mediator->View's API->combobox data provider

   b) custom Event->Command->Service->custom Event->Mediator->View's API->combobox data provider (without Model)

   • Edit

5. 5 Posted by matej on 12 Feb, 2014 07:58 AM

   

   Hola :)

   Signals are great :) I prefer them over events, but everything is ok.

   Here are some thoughts.

   Using an MVC pattern is good if you want to scale your app one time in the future.

   I would do it like this (if I know the app will be extended somehow):

   One command CallAllServices
   inside that command I would dispatch 5 signals *or events, cause I use SignalCommandMap* 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 *Usuario* and not all, but you still have one command that does it all.

   You use Interface for service and you map it like:
   injector.map(IService).toSingleton(Service)

   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.
   Why models, and not directly to the view?
   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.
   You can check AS3Vanilla library for parson your JSON objects to strongly typed VOs easily.

   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 :)

   I hope this helps a little :)

   • Edit

6. Support Staff 6 Posted by Ondina D.F. on 12 Feb, 2014 01:15 PM

   

   [LINKS]

   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 :)

   SignalResponder:

   https://github.com/creynders/SignalResponder
   https://github.com/creynders/RelaxedSignalsDemo

   Bootstrap:

   https://github.com/creynders/robotlegs-demo-bootstrap

   Promises:

   https://github.com/darscan/robotlegs-extensions-Oil

   http://knowledge.robotlegs.org/discussions/questions/115-using-the-...
   There are more discussions on this topic on this forum. Search for 'Promises'.

   https://github.com/jonnyreeves/as3-async

   https://github.com/CodeCatalyst/promise-as3

   https://gist.github.com/darscan/4519372

   DirectCommandMap:

   https://github.com/robotlegs/robotlegs-framework/tree/master/src/ro...

   [YOUR USE CASE]

   There is a single forms with many textimputs and 5 combobox that are populated on the application when it starts.

   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?

   Are the lists 'mutable' or 'immutable'?

   To make my life easier, I'll talk about a simple ScribbleView containing 3 comboboxes:
   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.

   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.

   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.
   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.

   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.

   The question is, does ScribbleView need a ScribbleModel or not? It depends;)

   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 one Scribble from the ScribbleView, the list of scribbles needs to be updated.

   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!

   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.

   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.

   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?

   [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.

   How to load the data for your comboboxes?

   1000 and one possible scenarios ;)

   One of them is what Matej said.

   But, here again, I'd say, it depends on the nature of your comboboxes.
   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?

   On the requesting part, one Service or 5 Services? One command or 5 commands?

   Sorry, I'll have to continue this later...have to do something related to my projects....

   • Edit

7. Support Staff 7 Posted by Ondina D.F. on 12 Feb, 2014 06:08 PM

   

   What was I saying? Ah, yes... How many services and commands are needed?

   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?

   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)

   Will you need to access the server again during your app's life-cycle or do you need it just at start-up?

   (a)A client can request data from multiple DB tables at once:

   [1] 1 service for 1 server call, without models.

   • a. client makes just one request for Scribble's data ( colors, tools and shapes )
   • 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
   • 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

   [2] 1 service for 1 server call, with 3 Models for each comboboxes, but just one Mediator (ScribbleMediator)

   • a and b same as before
   • 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

   [3] 1 service for 1 server call, with 1 Model (ScribbleModel) and 1 Mediator

   • a and b same as before
   • c. ScribbleModel is updated with the collection coming from server, either 1 or 3 collections, and dispatches 1 or 3 events to ScribbleMediator

   (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.

   [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.

   or

   See Shaun's answer for a use case where Services are called directly from Mediators:

   http://knowledge.robotlegs.org/discussions/questions/144-how-to-app...

   ...

   Again, I have to discontinue the discussion for now..

   Till tomorrow,
   Ondina

   • Edit

8. Support Staff 8 Posted by Ondina D.F. on 13 Feb, 2014 02:18 PM

   

   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)

   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.

   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.

   I just wanted to finish some thoughts from yesterday, but I'm stopping here, because the topic is really very complex.
   We can talk about the number of commands needed, after you answer the questions from the previous posts.

   Not as a solution to your problem, but just so you know, you can map multiple events to the same command.

   • Edit

9. 9 Posted by Angelo on 13 Feb, 2014 05:15 PM

   

   Hi everybody.

   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.

   The more we answer, the more questions arises on this topic. This is excellent oportunity for sharing knowledge.

   Giving more information about my scenario:

   a) Backend DB is Oracle, middle tier is PHP (WAMP), frontend is FLEX 4.5

   b) My team is responsable for the development of all these layers from backend logic (tables, packages, ...) to frontend.

   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.

   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. In this scenario while the collections are immutable on the "Users" application dispensing

   the model, in the "Administrator" one I would store all the retrived data from server on models where I would add, edit and delete.

   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

   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

   arraycollections of VO objects and dispach an event for each of the combobox to listen and populate and be populate by payload.

   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

   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

   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

   combobox, in the end I just send the color_id for the service to insert on the database, is this the best aproach ?

   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.

   h) Do you have any example of application source code using RB to acess the server side using PHP and remote object ?

   i) On our case and after all the ansers I belive the best sollution on the start of the application:

   1) Single event mapped in a single command that does a single service call to the server.
   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.
   3) A single mediator mediating 5 combobox listen to those service events and update the dataprovider of the respective combobox.

   Is this a good solution ?

   Best regards,
   Angelo

   • Edit

10. Support Staff 10 Posted by Ondina D.F. on 14 Feb, 2014 12:02 PM

    

    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.

    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.

    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.
    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.

    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..

    On the other hand, a ScribbleView which can be part of several other Views, will always need its own ScribbleMediator.

    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.
    From the bottom-up, you first assume that every 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.

    I prefer the top-down 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.

    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?

    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.

    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.

    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.
    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.
    There are other use cases as well. See this discussion on a similar topic:
    http://knowledge.robotlegs.org/discussions/robotlegs-2/9319-mvcscru...

    e) ....but I believe a better aproach would be just one call to a single...

    That sounds good. It is similar to one of the solutions I was suggesting in one of my previous posts.
    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)

    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 ?

    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.

    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.

    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)
    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;)

    h) Do you have any example of application source code using RB to acess the server side using PHP and remote object ?

    To see how you can use a RemoteObject with robotlegs take a look at:
    https://github.com/joelhooks/robotlegs-examples-UnionPlatformChatCl...
    https://github.com/joelhooks/robotlegs-examples-UnionPlatformChatCl...
    https://github.com/joelhooks/robotlegs-examples-UnionPlatformChatCl...
    It is a rl version 1 app, but I think that's not a problem for you.

    i) On our case and after all the ansers I belive the best sollution on the start of the application..

    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.

    Aahhh, now my head is spinning too:)

    Ondina
    P.S.

    Commands

    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.

    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.

    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.

    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.

    In my experience, both scenarios work just fine.

    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.
    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.

    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!
    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.
    Well, you actually know all of this already, I just got carried away by the discussion :) Sorry.

    On the subject of Services, I meant to give you a link to Shaun's answer, but I forgot. Here it is:
    http://knowledge.robotlegs.org/discussions/robotlegs-2/38-service-w...

    Now, I hope, Matej and I have given you enough info to keep you occupied for the next few days :P

    • Edit

11. Ondina D.F. closed this discussion on 11 Mar, 2014 08:48 AM.