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

Angelo

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!

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.

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.