Too many wires?

Luke's Avatar

Luke

18 May, 2012 10:20 PM

Hello! I'm making something that I suspect to be an massive overkill, but well, I'm often falling into extreme :0 . I like the high granularity approach, and the effect is that I have almost 50 classes, and only one panel on the screen that shows article headers! How I did that? I wish to know... :D The panel is one view, inside of it is second view that shows a list of headers, below is third view that shows list of filters, and on the right is scrollbar. I'm also considering turning every header on the list into view. But this is not enough, I got the idea that I could turn into view also... scrollbar! Why would you ask? I would like the scrollbar to be somewhat independent, so I would be able to change a view that he is scrolling easily, and handle that transition with one scrollbar from one place, with clear interface (because of model, mediator etc). I would need to pass to it's view a reference to another view that would be scrolled. The question is - is it a good idea, or I just fell into madness? I like to have everything mediated but I must confess that I'm starting to getting lost in all that classes and wires... I'm a beginner so this post is something like a sanity check, there should be so many classes? Would you mediate each separate component visible on the screen? Someone tried to mediate something like a scrollbar? I feel quite lost, as I have constant doubts what to mediate...

  1. 1 Posted by kakarlus on 19 May, 2012 05:10 AM

    kakarlus's Avatar

    Hi, beginner here as well. I could ask the same question, does a signal/event have to go from view -> mediator -> command -> model -> mediator -> view process all te time? Even if there is no payload or update on the model's VO?

  2. Support Staff 2 Posted by Ondina D.F. on 21 May, 2012 11:48 AM

    Ondina D.F.'s Avatar

    Hi Luke and Carlos,

    Hello! I'm making something that I suspect to be an massive overkill, but well, I'm often falling into extreme :0 . I like the high granularity approach, and the effect is that I have almost 50 classes, and only one panel on the screen that shows article headers!

    Hehe, that’s indeed extremely granular, at least for my taste. But it’s really a matter of personal preferences. If you want it like this, so be it:)

    I like to have everything mediated but I must confess that I'm starting to getting lost in all that classes and wires...

    Exactly, that’s the result of an extreme granular design.
    Usually, I wouldn’t mediate each and every component. There might be scenarios where that would be indeed needed, but even then I’d start by mediating the main functional areas first, and then decide which sub-areas need to be loosely coupled and mediated.

    Say, a LoginView, a Panel containing a login form and buttons, would be paired to a LoginMediator. I wouldn’t mediate userName and userPassword (text fields) and loginButton separately. I’d let LoginMediator listen for the event (with the form’s data as a payload, usually in form of a VO) dispatched by loginButton and re-dispatch it to other parts of the application.

    If there was a UserNameMediator and a UserPasswordMediator and a LoginButtonMediator, and so on, how would you proceed?
    How would you gather the inputs data and pass it to the service that needs it? Would you let LoginButtonMediator communicate with UserPasswordMediator and UserNameMediator , which would access their views (text fields) and then re-dispatch an event with their data to … See? It becomes kind of convoluted.

    I’d like to talk more about this, but I don’t have much time right now (deadlines before going on vacation). Hopefully others will also share their point of view.

    As for the scrollbar, I don’t know what to say, because I don’t quite understand the use case.

    I suggest reading through the discussions on the forum to see different opinions on the matter.

    Hi, beginner here as well. I could ask the same question, does a signal/event have to go from view -> mediator -> command -> model -> mediator -> view process all te time?

    That’s also something of personal preference :) If you want to use rl in “strict modus”, you’d go the route you’ve described.

    Even if there is no payload or update on the model's VO?

    I don’t understand what you mean. If you don’t need to modify your model or you don’t need data from the model, why would you even try to access it, be it through events->commands or directly? Say more, a concrete use case, and I’ll tell you what I’d do:)
    Cheers,
    Ondina

  3. 3 Posted by kakarlus on 22 May, 2012 01:12 AM

    kakarlus's Avatar

    Hi Ondina thanks for clarifying. The latter question was connected to the previous one. Its already been answered though cheers!

  4. Support Staff 4 Posted by Ondina D.F. on 24 May, 2012 11:07 AM

    Ondina D.F.'s Avatar

    You’re welcome, Carlos!

  5. 5 Posted by Luke on 24 May, 2012 12:25 PM

    Luke's Avatar

    Thanks Ondina, Indeed I feel that I'm finally comfortable with that style. I think the whole project will have more than 100 classes, but I feel that in long run it's much easier to wrap head around the project that is so granulated. It just feel right for me, and is extremely easy to expand it and modify because every element is so independent. I think now that every element on the stage, that user can interact with, should be mediated. Because then the whole application can be aware of every action, and can dynamically adjusting itself as a whole. I hope that this is a good approach, but I'm feel comfortable with it finally :) . Thanks once more for ensuring me that I'm not crazy :D .

  6. Support Staff 6 Posted by Ondina D.F. on 25 May, 2012 03:23 PM

    Ondina D.F.'s Avatar

    No problem, Luke! You’re for sure not crazy :) Your concerns and questions are absolutely normal. And the most important thing is that you feel comfortable with your current approach.

  7. Ondina D.F. closed this discussion on 28 Jun, 2012 09:17 AM.

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