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.