Is Robotlegs overkill for what I'm doing?
David Jones
via web
Hi,
Sorry if my post seems a bit naive, I'm new to the whole MVC framework approach. I've been considering using Robotlegs combined with Signals in a project over the last few days, and I'm wondering if it is overkill, I seem to be creating loads of class files and am having to write lots of code to accomplish very simple things. I understand that things do have to become more complex to provide decoupling, but I can see my application becoming overly complex if I continue.
For example, I am creating a layer panel (much like in Photoshop) where layers can be dragged around to change their corresponding visual elements index on the display list. The more layers that get added, the larger the draggable area for each layer needs to be. So if I am to keep a record of the size of this area, I should be updating this in the model, and then return that size from the model to each of the layers which will then know the bounds within which it can be dragged.
The flow looks like this: LayerHolder -> LayerHolderMediator -> UpdateModelCommand -> Model -> LayerMediator -> Layer
For this purpose using Signals I have to create 3 new classes: UpdateDragAreaSignal, UpdateDragAreaCommand, DragAreaUpdatedSignal.
Previously I would have a getInstance() method in the singleton LayerHolder class to access it, and a getDragBounds method that returns what I need.
I fear that when my colleagues attempt to understand the project if I build the whole thing with RL and Signals, then they will find it to be too complex. I guess my reason for wanting to use a framework would have been a bad move if that is the case.
Do I really need to update the model with the drag area size and relay that info to each layer, or would it make more sense to code the internal workings of the layer panel in a more simple (but less MVC) way, and then only use RL to communicate with other areas of the application?
Thank you.
Comments are currently closed for this discussion. You can start a new one.
2 Posted by Jos Yule on 09 Apr, 2010 03:06 PM
It does help to define what "areas" are self-contained components. This part might make sense to that - so it controls its own parts. So, think about the API that this component would need:
addLayer
removeLayer
and some event/signal when you rearrange layers.
everything else can be handled by the component itself...
This makes sense regardless of the framework/work flow. Partition the work into self-contained chunks. Think about the public API and events that chunk needs to talk to and respond to the rest of the app.
good luck!
jos
Support Staff 3 Posted by Joel Hooks on 09 Apr, 2010 03:28 PM
the DragAreaUpdated signal could trigger a command and/or be received by the LayerMediators to updated them directly. It isn't strictly necessary to hold this value in a model and might be clearer if the mediators within this component structure just speak directly.
Stray closed this discussion on 16 Feb, 2011 09:04 PM.