318 reputation
17
bio website viridium.ro
location
age
visits member for 3 years, 4 months
seen Oct 28 at 12:24

Oct
28
comment Is XHTML5 dead or is it just an synonym of HTML5?
A terrible decision. We threw away the XSL tooling that would have been available with XML.
Apr
23
comment Loose Coupling Presenter to View in MVP
Regarding #1, can we not use data binding with classic MVP? Could you elaborate on #3? Can't we have a many-to-one between view and presenter in MVP? Regarding #2, I'm trying to understand what gives you that extra testability. Certainly whether you can test the UI controls is orthogonal to your choice of MVP or MVVM. Why couldn't we test everything but the UI controls if we elect MVP, effectively achieving the same level of testability as MVVM?
Jan
30
comment Loose Coupling Presenter to View in MVP
Vaadin introduces an abstraction layer that enables you to write your application much like a Swing application. So for the purposes of this conversation, you can safely abstract out the web context of this application.
Jan
28
comment Loose Coupling Presenter to View in MVP
@Gus: yes, this is a web application, using an inhouse MVP on top of Vaadin. No MVVM here, no. The suggestion is that we adjust our MVP; one way is for the presenter to send data to the view only through events, exactly like the ViewModel in MVVM.
Jan
16
awarded  Student
Jan
16
asked Loose Coupling Presenter to View in MVP
Jan
1
awarded  Critic
Jan
1
comment Choosing the type of Index Variables
Please adjust your answer; not everyone reading it will also read the comments.
Jan
1
comment Choosing the type of Index Variables
Ouch, that's ugly! I'm finding more and more enjoyment in C++ by the day, for all the wrong reasons.
Jul
7
comment Which style to use for repetitive code (in java)
I agree. Grouping by object being worked on lets you think at a higher level of abstraction, by letting you think of a group of statements as a single more abstract operation being performed on multiple objects.
Jun
16
comment Unit test cases(JUnit), not by developer but other team members
I would have accepted this answer. Pinpoints the problem perfectly. Unit tests may drive the APIs, so to send them to another coder either slows down the evolution of the API or forces you to have the API ready before you start writing any code, including unit tests. It sounds like an inflexible proposition for me.
Jun
12
comment OOP Design - Possible wrong approach makes it impossible to implement it in code
Desktop applications are typically (if not always) single user applications. In such applications, it is not as important for your handlers to be stateless. They can still be, depending on the kind of purism that you have a sweet tooth for. For the second part, of course, if your handler only stores state, then it is more a Repository (as in the pattern). But in a web application handlers are there to receive commands in the form of web requests, so handlers may well be warranted. Your browser could also call straight into web services, so your handlers are on your client - now a fat client.
Jun
11
comment OOP Design - Possible wrong approach makes it impossible to implement it in code
Seth is correct. In web environments, the place to store this information is the session, not the handler. Handlers tend to be rather stateless. (In a single user desktop application it doesn't matter as much.) Web frameworks come with their own session management, but nothing prevents you from rolling your own, or even extending the framework's capabilities, for example by storing session in a relational database.
Jun
11
answered OOP Design - Possible wrong approach makes it impossible to implement it in code
Mar
26
awarded  Yearling
Mar
26
revised Hating your own code - for good or bad, how do you deal with it?
rephrasing
Mar
26
answered Hating your own code - for good or bad, how do you deal with it?
Feb
25
awarded  Caucus
Feb
4
comment Is it a good idea to register views and view models as singletons in an IOC container?
Yes, in your case, the view can be a singleton, barring multiple stateful views opened by the same user on her desktop. But beware view reuse, as reinitializing views just to recycle singletons can get messy. Either way, don't let your view consumers (controllers and what have you) know that they are singletons. Best to hide that detail behind a registry or a factory. Focus closely on what the view must promise about its lifecycle (e.g., that there's only one at any given time, e.g. due to statefulness, multiple users) and that pretty much tells you if it can be a singleton.
Feb
4
awarded  Commentator