Hairy generics question

Discussion in 'Java' started by sclaflin, Feb 21, 2012.

  1. sclaflin

    sclaflin Guest

    I have a number of sets of matched parameterized classes: a bean, a
    presenter, and a view.
    The presenters and views have parallel inheritance hierarchies (where
    T is the bean type, P the presenter type, and V is the view type):

    public class CompA extends CompItem<AInfo, CompA, CompAView>
    public class CompB extends CompItem<BInfo, CompB, CompBView>

    public class CompAView extends CompItemView<AInfo, CompA, CompAView>
    public class CompBView extends CompItemView<BInfo, CompB, CompBView>

    public class CompItemView<T extends CompItemInfo,
    P extends AbstractCompItem<T, P, V>,
    V extends CompItemViewInterface<T, P,
    V>>
    extends AbstractCompItemView<T, P, V>
    implements CompItemViewInterface<T, P, V>

    public abstract class CompItem<T extends CompItemInfo,
    P extends AbstractCompItem<T, P, V>,
    V extends CompItemViewInterface<T,
    P, V>>
    extends AbstractCompItem<T, P, V>
    implements CompWidget<T>

    Many of the views are the same, so I wanted to just use the base view
    class instead of creating a separate view class for each presenter.
    So I tried:

    public class CompA extends CompItem<AInfo, CompA, CompItemView>

    But I get an error that says "The type CompItemView is not a valid
    substitute for the bounded parameter <V extends
    CompItemViewInterface<T,P,V>> of the type CompItem<T,P,V>.
    Why can I use a class that extends CompItemView for the V type, and
    not CompItemView itself?
     
    sclaflin, Feb 21, 2012
    #1
    1. Advertising

  2. sclaflin

    Lew Guest

    On 02/21/2012 06:30 AM, sclaflin wrote:
    > I have a number of sets of matched parameterized classes: a bean, a
    > presenter, and a view.
    > The presenters and views have parallel inheritance hierarchies (where
    > T is the bean type, P the presenter type, and V is the view type):
    >
    > public class CompA extends CompItem<AInfo, CompA, CompAView>
    > public class CompB extends CompItem<BInfo, CompB, CompBView>
    >
    > public class CompAView extends CompItemView<AInfo, CompA, CompAView>
    > public class CompBView extends CompItemView<BInfo, CompB, CompBView>
    >
    > public class CompItemView<T extends CompItemInfo,
    > P extends AbstractCompItem<T, P, V>,
    > V extends CompItemViewInterface<T, P,
    > V>>
    > extends AbstractCompItemView<T, P, V>
    > implements CompItemViewInterface<T, P, V>
    >
    > public abstract class CompItem<T extends CompItemInfo,
    > P extends AbstractCompItem<T, P, V>,
    > V extends CompItemViewInterface<T,
    > P, V>>
    > extends AbstractCompItem<T, P, V>
    > implements CompWidget<T>
    >
    > Many of the views are the same, so I wanted to just use the base view
    > class instead of creating a separate view class for each presenter.
    > So I tried:
    >
    > public class CompA extends CompItem<AInfo, CompA, CompItemView>
    >
    > But I get an error that says "The type CompItemView is not a valid
    > substitute for the bounded parameter<V extends
    > CompItemViewInterface<T,P,V>> of the type CompItem<T,P,V>.
    > Why can I use a class that extends CompItemView for the V type, and
    > not CompItemView itself?


    Your generics assertions have 'P' extend an 'AbstractCompItem' that depends on
    'P'. This type of generics circularity has a place, but it's often the result
    of confusion also. Which is it for you? Why does 'P' extend its own type?
    (Similarly for 'V'.)

    As for covariance, you need to study the generics tutorial
    <http://docs.oracle.com/javase/tutorial/extra/generics/index.html>
    and Angelika Langer's site.

    The combination is likely what's killing you. Remember that 'Foo extends Bar'
    does not imply (cannot imply) that 'Baz<Foo> extends Baz<Bar>'.

    If you remove the circularity - if feasible, but please do explain why it's
    there at all - and do your covariance correctly your problem should vanish. I
    think perhaps you've overcomplicated your generics.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, Feb 21, 2012
    #2
    1. Advertising

  3. sclaflin

    Roedy Green Guest

    On Tue, 21 Feb 2012 06:30:51 -0800 (PST), sclaflin
    <> wrote, quoted or indirectly quoted someone
    who said :

    >Why can I use a class that extends CompItemView for the V type, and
    >not CompItemView itself?


    Possibly because it thinks you are trying to implement multiple
    abstract classes not Interfaces. Generics don't use the term
    "extends" consistently which sows confusion. I did not follow your
    details. I am just throwing that out.

    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    One of the most useful comments you can put in a program is
    "If you change this, remember to change ?XXX? too".
     
    Roedy Green, Feb 21, 2012
    #3
  4. sclaflin

    Daniel Pitts Guest

    On 2/21/12 6:30 AM, sclaflin wrote:
    > I have a number of sets of matched parameterized classes: a bean, a
    > presenter, and a view.
    > The presenters and views have parallel inheritance hierarchies (where
    > T is the bean type, P the presenter type, and V is the view type):
    >
    > public class CompA extends CompItem<AInfo, CompA, CompAView>
    > public class CompB extends CompItem<BInfo, CompB, CompBView>
    >
    > public class CompAView extends CompItemView<AInfo, CompA, CompAView>
    > public class CompBView extends CompItemView<BInfo, CompB, CompBView>
    >
    > public class CompItemView<T extends CompItemInfo,
    > P extends AbstractCompItem<T, P, V>,
    > V extends CompItemViewInterface<T, P,
    > V>>
    > extends AbstractCompItemView<T, P, V>
    > implements CompItemViewInterface<T, P, V>
    >
    > public abstract class CompItem<T extends CompItemInfo,
    > P extends AbstractCompItem<T, P, V>,
    > V extends CompItemViewInterface<T,
    > P, V>>
    > extends AbstractCompItem<T, P, V>
    > implements CompWidget<T>
    >
    > Many of the views are the same, so I wanted to just use the base view
    > class instead of creating a separate view class for each presenter.
    > So I tried:
    >
    > public class CompA extends CompItem<AInfo, CompA, CompItemView>
    >
    > But I get an error that says "The type CompItemView is not a valid
    > substitute for the bounded parameter<V extends
    > CompItemViewInterface<T,P,V>> of the type CompItem<T,P,V>.
    > Why can I use a class that extends CompItemView for the V type, and
    > not CompItemView itself?


    I'll try to propose a way to fix your type declarations, but then I'll
    make a better suggestion, please read through ;-)

    I think what you'll need to do is have generic parameter to CompA:

    public class CompA<View extends CompItemViewInterface<AInfo,
    CompA<View>, View>> extends CompItem<AInfo, CompA<View>, View>

    The better suggestion that I have for you is to try to find a better way
    of handling this generic-type interdependency. I once wrote something
    very similar, and it is a headache to maintain. Especially when I needed
    to add in (I'm making up names to match your example) CompItemAccessor.
    And then later CompItemValidator. And so on. I eventually ended up with
    one class ContentTypeMetadata<X,Y,Z,A,B,C> which contained all the basic
    information for each content type, and the class types didn't really
    have to know much about each other.

    Ask yourself, do all these objects really need to know the exact type of
    all the other objects, or can they just know about some shared base
    interface?
     
    Daniel Pitts, Feb 22, 2012
    #4
  5. sclaflin

    Lew Guest

    Daniel Pitts wrote:
    > The better suggestion that I have for you is to try to find a better way of
    > handling this generic-type interdependency. I once wrote something very
    > similar, and it is a headache to maintain. Especially when I needed to add in
    > (I'm making up names to match your example) CompItemAccessor. And then later
    > CompItemValidator. And so on. I eventually ended up with one class
    > ContentTypeMetadata<X,Y,Z,A,B,C> which contained all the basic information for
    > each content type, and the class types didn't really have to know much about
    > each other.
    >
    > Ask yourself, do all these objects really need to know the exact type of all
    > the other objects, or can they just know about some shared base interface?


    Or some bunch of non-generic interfaces?

    And do they really all need to implement all these interfaces, or can they
    compose elements that do?

    "Favor composition over inheritance".
    - Joshua Bloch, /Effective Java/

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, Feb 22, 2012
    #5
  6. On 22/02/12 02:04, Daniel Pitts wrote:
    > I think what you'll need to do is have generic parameter to CompA:
    >
    > public class CompA<View extends CompItemViewInterface<AInfo,
    > CompA<View>, View>> extends CompItem<AInfo, CompA<View>, View>


    I think you then have to do the same for your AInfo, with corresponding
    changes to CompA's declaration:

    class CompA<View extends CompItemViewInterface<AInfo<View>,
    CompA<View>, View>>
    extends CompItem<AInfo<View>, CompA<View>, View> { }
    class AInfo<View extends CompItemViewInterface<AInfo<View>,
    CompA<View>, View>>
    extends CompItemInfo<AInfo<View>, CompA<View>, View> { }



    For the interested, here's an SSCCE, with CompC as the special case, and
    CompA and CompB defined as before (and a few bits guessed):

    interface CompWidget<T> { }

    class CompItemInfo
    <T extends CompItemInfo<T, P, V>,
    P extends AbstractCompItem<T, P, V>,
    V extends CompItemViewInterface<T, P, V>> { }

    interface CompItemViewInterface
    <T extends CompItemInfo<T, P, V>,
    P extends AbstractCompItem<T, P, V>,
    V extends CompItemViewInterface<T, P, V>> { }

    abstract class AbstractCompItem
    <T extends CompItemInfo<T, P, V>,
    P extends AbstractCompItem<T, P, V>,
    V extends CompItemViewInterface<T, P, V>> { }

    abstract class CompItem
    <T extends CompItemInfo<T, P, V>,
    P extends AbstractCompItem<T, P, V>,
    V extends CompItemViewInterface<T, P, V>>
    extends AbstractCompItem<T, P, V>
    implements CompWidget<T> { }

    class CompItemView
    <T extends CompItemInfo<T, P, V>,
    P extends AbstractCompItem<T, P, V>,
    V extends CompItemViewInterface<T, P, V>>
    extends AbstractCompItemView<T, P, V>
    implements CompItemViewInterface<T, P, V> { }

    abstract class AbstractCompItemView
    <T extends CompItemInfo<T, P, V>,
    P extends AbstractCompItem<T, P, V>,
    V extends CompItemViewInterface<T, P, V>> { }



    class CompA extends CompItem<AInfo, CompA, CompAView> { }

    class AInfo extends CompItemInfo<AInfo, CompA, CompAView> { }

    class CompAView implements CompItemViewInterface<AInfo, CompA, CompAView> { }



    class CompB extends CompItem<BInfo, CompB, CompBView> { }

    class BInfo extends CompItemInfo<BInfo, CompB, CompBView> { }

    class CompBView implements CompItemViewInterface<BInfo, CompB, CompBView> { }



    class CompC<View extends CompItemViewInterface<CInfo<View>,
    CompC<View>, View>>
    extends CompItem<CInfo<View>, CompC<View>, View> { }


    class CInfo<View extends CompItemViewInterface<CInfo<View>,
    CompC<View>, View>>
    extends CompItemInfo<CInfo<View>, CompC<View>, View> { }





    --
    ss at comp dot lancs dot ac dot uk
     
    Steven Simpson, Feb 22, 2012
    #6
  7. sclaflin

    Guest

    Well, after writing a long response addressing the more structure-related comments, my submission got lost in the ether.

    Suffice to say, I believe that the circularity is necessary at the deeper levels of my framework. My endpoint presenters act as widgets to the outside world, where I have indeed removed most of the types, except the bean type. But, any individual presenter is intimately tied to a view, since both need to invoke specific methods on the other. Some views need to know P, and presenters need to know V. In order to have abstract base views and presenters, the self-parametrization arose - this is a presenter for V, but only those V that support at least this P.

    Unfortunately, when I tried to come up with a reduced set of declarations to post, I oversimplified and left out some of the nested parametrization. And, when I went to put those back in, I realized the issue. Once I lock in the base view, the V disappears.

    So, the real issue was not with the class that I found the error in, which was trying to use CompItemView, but in CompItemView itself, when I left in the V parameter. It should be:

    public class CompItemView<
    T extends CompInfo,
    P extends AbstractCompItem<T, P, CompItemView<T, P>>>
    extends AbstractCompItemView<T, P, CompItemView<T, P>>
    implements CompItemViewInterface<T, P, CompItemView<T, P>>

    after removing the V from the CompItemView parametrization.
     
    , Feb 24, 2012
    #7
  8. sclaflin

    Lew Guest

    On 02/24/2012 11:12 AM, wrote:
    > Well, after writing a long response addressing the more structure-related comments, my submission got lost in the ether.
    >
    > Suffice to say, I believe that the circularity is necessary at the deeper levels of my framework. My endpoint presenters act as widgets to the outside world, where I have indeed removed most of the types, except the bean type. But, any individual presenter is intimately tied to a view, since both need to invoke specific methods on the other. Some views need to know P, and presenters need to know V. In order to have abstract base views and presenters, the self-parametrization arose - this is a presenter for V, but only those V that support at least this P.


    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.

    > Unfortunately, when I tried to come up with a reduced set of declarations to post, I oversimplified and left out some of the nested parametrization. And, when I went to put those back in, I realized the issue. Once I lock in the base view, the V disappears.
    >
    > So, the real issue was not with the class that I found the error in, which was trying to use CompItemView, but in CompItemView itself, when I left in the V parameter. It should be:
    >
    > public class CompItemView<
    > T extends CompInfo,
    > P extends AbstractCompItem<T, P, CompItemView<T, P>>>
    > extends AbstractCompItemView<T, P, CompItemView<T, P>>
    > implements CompItemViewInterface<T, P, CompItemView<T, P>>
    >
    > after removing the V from the CompItemView parametrization.


    That's a step in circularity reduction. How is it necessary when your own
    experience shows that its removal helped? I'm confused.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, Feb 24, 2012
    #8
  9. sclaflin

    Guest

    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.

    > > Unfortunately, when I tried to come up with a reduced set of declarations to post, I oversimplified and left out some of the nested parametrization. And, when I went to put those back in, I realized the issue. Once I lock in the base view, the V disappears.
    > >
    > > So, the real issue was not with the class that I found the error in, which was trying to use CompItemView, but in CompItemView itself, when I leftin the V parameter. It should be:
    > >
    > > public class CompItemView<
    > > T extends CompInfo,
    > > P extends AbstractCompItem<T, P, CompItemView<T, P>>>
    > > extends AbstractCompItemView<T, P, CompItemView<T, P>>
    > > implements CompItemViewInterface<T, P, CompItemView<T, P>>
    > >
    > > after removing the V from the CompItemView parametrization.

    >
    > That's a step in circularity reduction. How is it necessary when your own
    > experience shows that its removal helped? I'm confused.
    >

    I have minimal circularity in the classes that finally get instantiated -- it's the middle levels of concrete and abstract base classes that have the hairy generic stuff. The intent of the particular code I posted was to reuse one view class for a number of presenters where the view could render the bean from its toString method. But I've been operating under the belief that I would still need to have those circular mid-level classes available to extend matched views and presenters for unique cases.
     
    , Feb 24, 2012
    #9
  10. sclaflin

    Daniel Pitts Guest

    On 2/24/12 2:07 PM, 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).
     
    Daniel Pitts, Feb 24, 2012
    #10
  11. sclaflin

    Guest

    On Friday, February 24, 2012 6:36:37 PM UTC-5, Daniel Pitts wrote:

    > 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).


    In my preferred concept of MVP, a view doesn't work directly with the model, which is why I suffixed my T type with Info. It's possible for the view to not know about the presenter, and a lot of MVP is done that way. But thatrequires the view to fire events that the presenter then registers to handle.

    My problem with that approach is twofold:

    1. It burdens a global event bus with lots of events that were only meant to be one source to one handler. Especially in my app, where most of my views would fire events like editRequested or deleteRequested (most of these widgets are display-only, the edits are done via a popup). So, the global event manager is going to have to hold a list of handlers for each event forall these views, and then iterate through the appropriate list each time to find the handler that matches the event source. While intellectually pleasing from a maximum decoupling perspective, it's not very efficient.

    2. It exposes what ought to private publicly, that being the event registration methods. The view shouldn't be visible to anything but its presenter,but public void addEditRequestedHandler could be called from anywhere thathas a reference to the view. Granted, that reference shouldn't be held anywhere but in the presenter, but I could see someone that perceives MVP differently passing the reference outside the presenter.
     
    , Feb 25, 2012
    #11
  12. On 12-02-24 07:36 PM, Daniel Pitts wrote:
    > On 2/24/12 2:07 PM, 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.

    Struts is an MVC framework, JSF is MVP. Many folks (including Sun back
    in the day) would have it that JSF is more of an MVC 2 framework using
    front controllers, but IMHO it's really MVP. Using the duck test...

    I myself don't lose much sleep over whether or not something is actually
    classic MVC, new-model MVC, MVP or MVVM, or other named permutations
    thereof. As Martin Fowler puts it, Separated Presentation is the the
    notion we got from classic MVC, and all of the later variants give us
    that. Provided that you're observing the proper separations and using
    good OOP, why get religious? Not to knock MVVM, but just as an example
    I've read through some threads about tiny little nuances of what is, and
    isn't, MVVM, and I wonder why the posters don't go out there and get
    some real work done instead of engaging in hairsplitting. :)

    I'm laying this stuff out there simply to indicate that despite all the
    terminology, much of it redundant and confusing and artificial, that MVC
    and MVP are usefully different and real architectures, and that
    Presenter is definitely not Controller.

    AHS

    1. A number of people have argued this point. :)
    --
    -- Gaiety is the most outstanding feature of the Soviet Union.
    Josef Stalin, November 1935
     
    Arved Sandstrom, Feb 26, 2012
    #12
  13. sclaflin

    Daniel Pitts Guest

    What is Model View Presenter. (Was: Hairy generics question)

    On 2/26/12 9:13 AM, Arved Sandstrom wrote:
    > I'm laying this stuff out there simply to indicate that despite all the
    > terminology, much of it redundant and confusing and artificial, that MVC
    > and MVP are usefully different and real architectures, and that
    > Presenter is definitely not Controller.


    I guess I had never heard of MVP, and just assumed the OP was recreating
    MVC without clearly understanding the concept. This apparently was
    hubris on my part, and I humbly apologize for that.

    I'm going to do a web search to learn more about MVP architecture later
    today, but I want to know what it means to people in this group as well,
    X-Posting to clj.gui, since it seems relevant.

    So, fellow Java engineers and Pragmatic Programmers, how would you
    compare and contrast MVC vs MVP? Are there design/clarity benefits to
    one over the other? That does "Presenter" mean to you?

    Thanks,
    Daniel.
     
    Daniel Pitts, Feb 26, 2012
    #13
  14. sclaflin

    Lew Guest

    Re: What is Model View Presenter. (Was: Hairy generics question)

    On 02/26/2012 10:22 AM, Daniel Pitts wrote:
    > On 2/26/12 9:13 AM, Arved Sandstrom wrote:
    >> I'm laying this stuff out there simply to indicate that despite all the
    >> terminology, much of it redundant and confusing and artificial, that MVC
    >> and MVP are usefully different and real architectures, and that
    >> Presenter is definitely not Controller.

    >
    > I guess I had never heard of MVP, and just assumed the OP was recreating MVC
    > without clearly understanding the concept. This apparently was hubris on my
    > part, and I humbly apologize for that.
    >
    > I'm going to do a web search to learn more about MVP architecture later today,
    > but I want to know what it means to people in this group as well, X-Posting to
    > clj.gui, since it seems relevant.
    >
    > So, fellow Java engineers and Pragmatic Programmers, how would you compare and
    > contrast MVC vs MVP? Are there design/clarity benefits to one over the other?
    > That does "Presenter" mean to you?


    Only what I find on the Web:
    <http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter>

    According to the fully authoritative and always-correct Wikipedia, it's a
    particular variant of MVC, much as the front-controller pattern is a
    particular variant of MVC.

    Apropos of which, someone somewhere around these newsgroups complained that
    MVC was bad for them because it centralized the controller. That's only the
    one flavor of MVC that does that - it's not an essential feature of MVC that
    there be only one controller.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, Feb 26, 2012
    #14
  15. Re: What is Model View Presenter. (Was: Hairy generics question)

    On 2/26/2012 4:08 PM, Lew wrote:
    > On 02/26/2012 10:22 AM, Daniel Pitts wrote:
    >> On 2/26/12 9:13 AM, Arved Sandstrom wrote:
    >>> I'm laying this stuff out there simply to indicate that despite all the
    >>> terminology, much of it redundant and confusing and artificial, that MVC
    >>> and MVP are usefully different and real architectures, and that
    >>> Presenter is definitely not Controller.

    >>
    >> I guess I had never heard of MVP, and just assumed the OP was
    >> recreating MVC
    >> without clearly understanding the concept. This apparently was hubris
    >> on my
    >> part, and I humbly apologize for that.
    >>
    >> I'm going to do a web search to learn more about MVP architecture
    >> later today,
    >> but I want to know what it means to people in this group as well,
    >> X-Posting to
    >> clj.gui, since it seems relevant.
    >>
    >> So, fellow Java engineers and Pragmatic Programmers, how would you
    >> compare and
    >> contrast MVC vs MVP? Are there design/clarity benefits to one over the
    >> other?
    >> That does "Presenter" mean to you?

    >
    > Only what I find on the Web:
    > <http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter>
    >
    > According to the fully authoritative and always-correct Wikipedia, it's
    > a particular variant of MVC,


    It do say:
    Model–view–presenter (MVP) is a derivative of the
    model–view–controller (MVC) software pattern

    But I would more call it a brother or cousin than a son.

    > much as the front-controller pattern is a
    > particular variant of MVC.
    >
    > Apropos of which, someone somewhere around these newsgroups complained
    > that MVC was bad for them because it centralized the controller. That's
    > only the one flavor of MVC that does that - it's not an essential
    > feature of MVC that there be only one controller.


    I don't even think it is that common. Struts 1 is probably the most
    widely used true MVC framework out there and it has multiple actions
    (and actions are controller not model!).

    Arne
     
    Arne Vajhøj, Feb 26, 2012
    #15
  16. sclaflin

    Guest

    Re: What is Model View Presenter. (Was: Hairy generics question)

    My app is a GWT app, and Google is promoting their variant of MVP as a goodarchitecture for GWT apps. For those not familiar with GWT, it compiles client Java code to JavaScript for use in a browser in a web app.

    In GWT, the view should be something for which a mock can be injected for unit testing, where the mock can be implemented with pure Java code, so thatthe testing doesn't have to be done using Javascript or a browser (the initialization of the test case when an actual browser is involved takes much longer). To accomplish this without jumping through a lot of hoops, the view needs to be pretty "dumb". There's a good presentation of this at http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html
     
    , Feb 28, 2012
    #16
  17. sclaflin

    Daniel Pitts Guest

    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, 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.
     
    Daniel Pitts, Feb 28, 2012
    #17
  18. sclaflin

    Daniel Pitts Guest

    On 2/28/12 9:46 AM, Daniel Pitts wrote:
    > 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, 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.

    And to further back up my point, a reference:

    From: <http://c2.com/cgi/wiki?ModelViewPresenter>
    > 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.
     
    Daniel Pitts, Feb 28, 2012
    #18
  19. sclaflin

    Lew Guest

    Daniel Pitts wrote:
    > 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.


    Other references make a similar point, or conversely take great pains to
    distinguish MVP (most valuable player) from MVC. Such care would be
    unnecessary were the concepts actually so different.

    "MVC" is a pretty loose term, which accounts for some of the controversy. In
    large terms it means no more than "model-view-controller" and the principle of
    separation of concerns imply. Really, the taxonomy dispute is by the wayside.
    Personally, I recognize "MVC" as the species, like the first "lupus" in "canis
    lupus lupus", and subspecies, like the second "lupus". Then "MVP" would be
    another subspecies, like the "familiaris" in "canis lupus familiaris".

    Life - Domain - Kingdom - Phylum -
    Engineering - Computer - Software - Programming -

    Class - Order - Family - Genus - Species - Sub
    Architecture - Patterns - Modular - Acyclic - MVC - MVC
    Architecture - Patterns - Modular - Acyclic - MVC - MVP

    So MVC is the wolf, and MVP the dog.

    That's just an offhand metaphor, a "Lewnnaeus" classification, if you will.
    Perhaps it will help some of you.

    > 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.


    The pattern itself is acyclic, which accounts for how it accomplishes that:
    "knows about":
    P |- V |- M
    |- M

    This translates almost directly into type dependencies.

    I don't usually make the Controller (or Presenter) generic. It works just fine
    with non-generic 'Screen' (a View artifact) and 'Handler' types sorta like
    this (pseudocode):

    public class Controller
    {
    static enum Outcome {SUCCESS, FAILURE, ERROR};
    private final Map<Screen, Handler> handlers = loadHandlerMap();
    private final Map<Screen, Map<Outcome, Screen>> navigations
    = loadNavigations();

    public void process(Request request, Response response)
    {
    Screen screen = request.getScreen();
    Handler handler = handlers.get(screen);
    Outcome outcome = handler.handle(request, response);
    Screen next = navigations.get(screen).get(outcome);
    forward(next, request, response);
    }
    // etc.
    }

    Of course, this is just one way to do the pattern. It's what I use for Web
    apps if I'm hand-rolling, and not dissimilar to how Struts does things;
    however, I've been doing this since before Struts was available.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, Feb 28, 2012
    #19
  20. On 12-02-28 01:46 PM, Daniel Pitts wrote:
    > 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, 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.


    Let me put it this way. Like I said above, if you're going to make a
    distinction between MVC and MVP at all (and a lot of people don't,
    because they've never heard of MVP, or they choose not to worry about
    the distinction), then MVP describes JSF better than MVC does.

    If you choose to think of JSF as MVC - let's say because you aren't
    interested in breaking out MVP as a derivative of MVC - then that's fine
    too. I have no problem with that, it's what I actually do myself,
    because most folks haven't heard of MVP anyway so why confuse them? I
    would like it though if people who "knowledgeably" classify JSF as being
    MVC could identify what the Controller is in JSF: I've run across more
    people than not who either think it's the FacesServlet or just don't know.

    AHS
    --
    -- Gaiety is the most outstanding feature of the Soviet Union.
    Josef Stalin, November 1935
     
    Arved Sandstrom, Feb 29, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. geoffrey wall

    question on generics, constants in vhdl

    geoffrey wall, Oct 1, 2005, in forum: VHDL
    Replies:
    1
    Views:
    655
    Mike Treseler
    Oct 1, 2005
  2. Juergen Berchtel
    Replies:
    1
    Views:
    6,095
    John C. Bollinger
    May 20, 2005
  3. desktop
    Replies:
    6
    Views:
    630
    desktop
    Jun 13, 2007
  4. Hairy brainstorm

    , Feb 16, 2008, in forum: Python
    Replies:
    2
    Views:
    253
  5. Soul
    Replies:
    0
    Views:
    550
Loading...

Share This Page