Need help again with patterns, dropdownlists and VOs...

Angelo's Avatar


04 May, 2014 07:31 PM

Hi everybody, you guys can remember me from this topic here:

Now I returned with a lot more questions and challenges won from the first round. I hope Ondina and the other friends can help me one more time. My questions now are more concerned about techniques using robotlegs 2 and server requests best practices, so let’s start!

After following all the previous tips I am now with a program having around 50+ classes and I know that if don’t take the proper care or advice I will end up in an uncontrollable chaos! So…

1 – On my previous post I asked about populating various DropDownLists when starting the application.
The solution I implemented: Each DropDownList dispatches a start event from it’s mediator that does a server requests, fill a model and return the values to the data provider so there is no need of this initial load anymore. I think this is a better approach than loading all that data without the need. The RB2 sequence for each DropDownList:
a) Mediator from the DropDownList dispatches a .LOAD event.
b) .LOAD event is mapped into a command that calls a service method from an interface.
c) A model inside the service is load with VO’s from the service call and inside it dispatches a model.LOADED event.
d) The mediator listens for the model.LOADED event and with the model injected on the mediator the dataprovider is filled with the loaded VO’s
I copied this pattern from the CRUD Address book application is this the best approach? I know that you can transport all the VO’s inside the model.LOAD event instead of the model injection on the mediator so what is the recommended pattern ?
I saw on some topics the people commenting on calling the service directly inside the mediator. If I use this pattern I believe that I can save a lot of code but is this correct? When should I use this pattern ?

2 – I have a lot of CRUD interfaces inside it so I need to create a lot of classes to deal with all the options. Can I use just a single command to deal with all the different events of the same topic ?
Instead of having:
just have one command where an can select the eventype and execute the appropriate service call ?
3 – Another big challenge I am having is with a view that has three DropDownLists mediated by a single mediator that work in cascade where depending on the selected item on the parent I have a specific list of items on the child. For solving this I did this approach:
a) When a LinhaVO is selected on the first DDL a LinhaSELECTED event is dispatched and this item is updated on the LinhaModel.
b) The LinhaSELECTED event is triggers an EquipamentosLoadcommand that makes a service call and bring a list of EquipamentosVO that is stored in the EquipamentosModel, dispatches an EquipamentosLOADED event and populates the second DDL.
c) When a equipamentoVO is selected on the second DDL it triggers a EquipamentoSELECTED event updating the EquipamentosModel and triggering an DispositivosLoadcommand that makes a service call and brings a list of DispositivosVO that is stored in the DispositivosModel, dispatches a DispositivosLOADED event and populates the third DDL.
The approach above works fine but is this the best to do this ?

4 – Still considering the above view I am have a big problem when I do a service call to bring the main object of my database that is an OcorrenciaVO. An ocorrenciaVO has a linha, an equipamento, a dispositivo and a lot more dropdownlist options that I need to update on different components when it arrives from server into the OcorrenciaModel.

To create/update an ocorrenciaVO I do it all on an object inside the view and then I dispatch a save event with the object inside as a payload but having different views that has each one a part of the ocorrenciaVO should I be doing this inside a the view itself or each change to theses all different views should update an ocorrenciaVO inside the model that than is used to be saved on the database ?
Also when I bring an ocorrenciaVO from the server should I just receive inside it just the id’s of the objects that populates the dropdownlists or the full object ?

I hope you understand that put all my doubts inside a single post and try to explain it is really difficult without an online conference but all the help is more than welcomed!

If needed I can upload part of the software without any problems...

Best Regards,

  1. Support Staff 1 Posted by Shaun Smith on 10 May, 2014 04:55 PM

    Shaun Smith's Avatar

    Hello Angelo,

    There aren't many people left on the forum these days, and personally I don't have enough time to properly address all your issues. So here's some general advice that might help:

    Always aim for clarity. If something looks wrong, it probably is.

    50+ classes to load some dropdown data sounds wrong to me.

    Solve the problem without a framework first. Do the simplest thing that could possibly work. Write a draft, review it, rewrite it.

    If you're using Flex then it is easy to load data from a web service and bind to it.

    If you're having trouble building an app without using a framework then adding one in is only going to make things worse. Much worse.

    Bring in an application framework only when everything is working and you want extra control over the configuration of your app, or you want to split the app up into modules.

    To answer some of your questions (but without going into too much detail):

    1 - Lazy loading vs Eager loading.

    It depends. You need to look at your HTTP traffic patterns. If some data is always required then it might be good to load it up front. But if that data can go stale, or if it is only needed much later in the application, then load it on demand.

    I definitely wouldn't go Mediator -> Event -> Command -> Service -> Event -> Model -> Event -> Mediator -> View for loading data. Madness.

    2 - CRUD boilerplate.

    If you design a proper service layer for CRUD stuff, instead of using events and commands, then things become much simpler:

    Low level service (handles the raw data transfer, might deal with serialisation etc). E.g. HTTPService, RemoteObject, whatever.

    High level services. These use the low level service, but provide domain related APIs. E.g. UserService, CommentService, etc.

    See this comment for more details:

    3 & 4 - Data Binding, Synchronisation etc.

    There are tons of ways to design this depending on your needs. You could create a bindable model object and let the dropdowns bind directly to it. But this stuff is really up to you and out of the scope of this framework.

    At the end of the day Robotlegs is kinda low level. It's a set of tools for wiring objects together in useful ways. But it doesn't address higher level concerns like remote data synchronisation and presentation.

  2. Ondina D.F. closed this discussion on 22 Jul, 2014 01:09 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac