On 2/26/12 9:13 AM, Arved Sandstrom wrote:
On 12-02-24 07:36 PM, Daniel Pitts wrote:
On 2/24/12 2:07 PM, sclaflin@webucator.com wrote:
On Friday, February 24, 2012 3:03:56 PM UTC-5, Lew wrote:
On 02/24/2012 11:12 AM, sclaflin wrote:
Perhaps the circularity is necessary, but I've worked with my fellows
on a few
hairy generics issues where circularity seemed necessary, and it
never was.
Each time it turned out that an acyclic type graph did the trick, and
better
than the initial circular approach.
Of course since you can't share any of the relevant details we have
no way of
helping you see if there is an acyclic approach. Still, I cannot
accept your
simple declaration that there isn't. The odds are just too strongly
against it.
Lew,
You could well be right. I based my structure on a framework that had
Presenter<V> and View, but then the view didn't know how to talk to
the presenter. So, they add in ReverseView<P> separately. I was
trying to combine them both, and with those dual sorts of situations
I've always ended up with circularity.
You guessed that I've got proprietary code that I can't share, and I'm
supposed to be spending time on that, not general-purpose things.
But, if I can come up with a minimal but complete example, I'll post
it.
In what way is a Presenter different from a "controller". View's should
never know about Controllers, only about models. Controllers know about
specific views and specific models. Models know about generic
listeners, if you need to have an active view (non web-app stuff).
For what it's worth, Daniel, JSF is arguably [1] MVP
(Model-View-Presenter) and not MVC (Model-View-Controller). There have
been many attempts to characterize JSF as MVC, and that's what most
folks think JSF is, but a body has to jump through some hoops in order
to define what the V and the C are in JSF in order to make that label
stick. MVP on the other hand is a much better description.
I've just read the original Taligent, Inc. PDF on what MVP is, and it
looks like its little more than a clarification of MVC, with some new
concepts pulled out. Things that were inferred in the "controller" are
now their own concepts.
In that case, my original advice still stands. View shouldn't know about
the Presenter, only about the Model, and event listeners. The Model
shouldn't know about the View or Presenter, only about observers, and
the Presenter is basically knows about everything.
As such, you can't easily have a Generic Presenter. Also, as such, you
needn't have the view have any information about the "type" of the
Presenter. The View also only needs the interface type of the Model, not
the specific type. The Model needs only to know only interface types as
well.
This allows you to completely remove the circular type dependencies,
which is one of the main benefits of MVC and MVP architectures in the
first place.
In MVC and MVP, the GUI/View , Presenter/Controller, and Model are drawn as a triad. While the Model is loosely coupled to the View (it only knows the View as an Observer type), the View, however is more tighly coupled with the Model in order to be able to pull values from it. To reduce this coupling, you could create a Facade of the Model that only exposes methods to obtain values that the View requires (and hide methods that modify the Model, as that is the Controller's job), but it is still somewhat tightly coupled.