Need help again with patterns, dropdownlists and VOs...
Hi everybody, you guys can remember me from this topic here:
http://knowledge.robotlegs.org/discussions/robotlegs-2/9745-mutiple...
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:
commandMap.map(AtividadeEvent.LOAD).toCommand(LoadAtividadeCommand)
commandMap.map(AtividadeEvent.SAVE).toCommand(SaveAtividadeCommand)
commandMap.map(AtividadeEvent.SELECT).toCommand(SelectAtividadeCommand)
commandMap.map(AtividadeEvent.REMOVE).toCommand(RemoveAtividadeCommand)
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,
Angelo
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | 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
Support Staff 1 Posted by Shaun Smith on 10 May, 2014 04:55 PM
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: http://knowledge.robotlegs.org/discussions/robotlegs-2/38-service-w...
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.
Ondina D.F. closed this discussion on 22 Jul, 2014 01:09 PM.