How to indicate the loading of services?

mazatwork's Avatar

mazatwork

08 Aug, 2011 08:26 PM

We are building an app with the robotlegs framework and we are following robotlegs' specification using events, models and services.
For most parts of the app this is a nice architecture.

But we also have some forms mainly with read and update functionality. The number of classes for events and command is increasing as we progress. In my opinion the code gets harder to grasp. How would one deal with this?

Should we just use services, events, models if appropriate and otherwise fall back to RemoteObjects in Mxml-Components for trivial cases?

What if a single form needs a lot of different collections (ArrayLists) for several DropDownLists? How is this handled the robotlegs way? Are there many classes or is the functionality merged into one call?
And how should we give information to the user, that a certain service is loading or that an operation has succeeded or failed?

Thank you, maz

  1. Support Staff 2 Posted by creynders on 09 Aug, 2011 08:02 AM

    creynders's Avatar

    That's a lot of questions :)

    The number of classes for events and command is increasing as we progress. In my opinion the code gets harder to grasp. How would one deal with this?

    Organisation. Structure your packages neatly. The best practice recommendations for file structuring are a bit limited, you need to find a structure that suits you best.
    I structure my packages as follows:

    -functionality
    ---model
    -----actors
    -----signals/events/messages (last one is if I go for a mix) 
    -----vos
    -----helpers
    -----constants
    ---service
    -----actors
    -----delegates
    -----signals/...
    -----vos
    -----parsers
    ---controller
    -----commands
    -----signals/...
    -----helpers
    ---view
    -----mediators
    -----components
    -----signals/...
    

    Obviously I only create a package if it contains classes, in other words it will happen seldom that I have all the above directories for one functional domain.

    Should we just use services, events, models if appropriate and otherwise fall back to RemoteObjects in Mxml-Components for trivial cases?

    I'd definitely not start using a mix of both, it will make it a lot harder to maintain, debug and to get an overview of what is happening where.

    What if a single form needs a lot of different collections (ArrayLists) for several DropDownLists? How is this handled the robotlegs way? Are there many classes or is the functionality merged into one call?

    It depends on a number of factors: will all those collections readily be available when the form needs them? Or will they be loaded on a request-basis? (Which is preferable IMO) Let's say they are all populated from constants (in other words, readily available) then it's perfectly acceptable that a command sends a VO with all the collections in them.
    If you choose option 2 however, one solution would be to let the mediator send requests for each collection separately and separate commands fetch the appropriate collections and send them back.
    Or you could make sure that all collections are loaded and stored in models before the view is instantiated and then let the mediator access the corresponding models onRegister. It's a matter of preference. The former is more flexible and allows for lazy loading, the latter is faster to set up, but ties your mediator to your models.

    And how should we give information to the user, that a certain service is loading or that an operation has succeeded or failed?

    Again it depends on what you want to achieve. If I have a single "spinner" or other central loading feedback view, I create a mediator which listens to all the separate service events: SomeServiceEvent.START_LOADING, SomeServiceEvent.LOADING_COMPLETE and update the view state accordingly.
    Or if the loading sequence is far more complex (service calls depending on data from previous service calls for instance, or with concurrent service calls) chances are that I have some kind of state machine to sequence the calls and which dispatches state change events. In that case the loading feedback view's mediator will listen for the (appropriate) state change events and change view state accordingly.
    If however you want each view to be responsible for showing bootstrapping/loading state, then each specific mediator should be listening to the appropriate service events or state machine state change events.

  2. 3 Posted by mazatwork on 12 Aug, 2011 08:13 PM

    mazatwork's Avatar

    Your post is even longer :) thanks again, creynders.

    I am still not sure about the RemoteObjects because those events and services and commands mean a lot more work. We should keep software simple.

    Anyway, why is there no facade in robotlegs? Maybe this would save us some events and commands. Events with payload vs "real" methods, the latter i like more.

  3. Support Staff 4 Posted by creynders on 13 Aug, 2011 09:22 AM

    creynders's Avatar

    Simple doesn't mean necessarily less work ;)
    And I don't agree that it's more work. If you got a good IDE, which is mandatory, and know how to use it, creating the extra necessary classes shouldn't be taking any more time than creating the RemoteObjects. Obviously learning a new way of working will take more time in the beginning than following methodologies you already know, that's the nature of learning. But that time you will be regaining later on, when you need to modify things, because user requirements or remote service implementations have changed.
    This setup IS simple, it just doesn't feel that way yet. It's very easy to make changes, add steps in between, change presentation logic, etc.

    "Real" methods mean direct calling and responding, which means no other actors are able to respond to what's happening. It creates 1-to-1 relationships that will make it harder to accomodate for changes in the future, in other words less flexible. Let's say for instance you call a service method directly from a mediator. But later on you realize (or because the client requests a change) that something else needs to happen before that service call, let's say a different service call, then you'll be adding that service call to your mediator too, making it more complex already since it'll have async call chaining. But what if the results of the first (new) service call have nothing to do with that mediator? Or those results need to be stored in a model? Your mediator will be transforming into some kind of controller-like hybrid and will be responsible for things that have no relation to it at all. That makes for happy hunting when you have to return to this project 6 months later on and something needs to change.

    And an application facade is like global variables: evil. It will tie your actors to your application, defeating the whole purpose: reusability and flexibility. And your facade ends up being this huge monolithic application controlling monster.

  4. 5 Posted by Yennick Trevels on 16 Aug, 2011 08:22 AM

    Yennick Trevels's Avatar

    Anyway, why is there no facade in robotlegs? Maybe this would save us some events and commands. Events with payload vs "real" methods, the latter i like more.

    This thread on the Robotlegs Convore site discusses a way to eliminate some of the event "overload". I started this thread because I also like "real" methods more then events flying around without knowing where they will be handled.
    Joel Hooks made a really good suggestion there. You basically have a controller (with an interface) for a group of functionality, and each method in the controller delegates to a command. Both the command and the controller methods return async tokens (if you're not using signals). This way it's much easier to debug and step through the application, while keeping the reusability of the commands and the controller won't be a huge beast with 1000+ lines of code.

  5. 6 Posted by Yennick Trevels on 16 Aug, 2011 08:47 AM

    Yennick Trevels's Avatar

    Woops, forgot the link, here it is: https://convore.com/robotlegs/robotlegs-events/

  6. Ondina D.F. closed this discussion on 02 Nov, 2011 06:14 PM.

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