#name of top-level view - does it make sense now?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

#name of top-level view - does it make sense now?

Schwab,Wilhelm K
Andy, Blair,

Some of my more useful editable views start with a container view that
has one subview and a proportional layout manager that sizes the subview
to fill the top-level container.  The container view itself, and a
proportional layout manager are arguably "wasted".  This could be poor
design on my part, or it might be limitation of MVP.

An alternative would be to derive from the embedded presenter class.
However, that sounds a lot like the beginner's error of using
inheritance when containment/delegation is appropriate.

Some time ago, I observed that being able to set the #name of a
top-level view _might_ eliminate some gratuitous container views.  IIRC,
you made a good argument that it didn't make sense to name a top-level
view.  That might still be the case, but given that CompositePresenter
is gone (all presenters are composites), maybe not??

Any thoughts on whether I might be missing something?  Failing that, how
hard would it be to name a top-level view?  I probably do not need to
mention that given that capability, something else might present as a
show-stopper, making the whole exercise a waste of time.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: #name of top-level view - does it make sense now?

Chris Uppal-3
Bill Schwab wrote:

> Some of my more useful editable views start with a container view that
> has one subview and a proportional layout manager that sizes the subview
> to fill the top-level container.

I'd be interested to know /why/ you do that ?  It's not something that I've
needed to do, so presumably I'm either using MVP is a slightly different
"style" or have been lucky to have avoided whatever issues (bugs?) have
affected you.

If you want to compare approaches then the code for the various Presenters in
Ghoul is fairly typical of how I do things.


> Failing that, how
> hard would it be to name a top-level view?

A little tricky, I'd have thought, since a View's name is stored in (and
managed by) its parent.

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: #name of top-level view - does it make sense now?

Schwab,Wilhelm K
Chris,

> I'd be interested to know /why/ you do that ?  It's not something that I've
> needed to do, so presumably I'm either using MVP is a slightly different
> "style" or have been lucky to have avoided whatever issues (bugs?) have
> affected you.

It might be poor design on my part.  Some of the views are effectively
new "controls" and might be happier treated some other way.  Others
probably had syblings at one point, and with simplication/redesign, find
themselves conspicuously alone.


> If you want to compare approaches then the code for the various Presenters in
> Ghoul is fairly typical of how I do things.

Ok, I will take a look.


>>Failing that, how
>>hard would it be to name a top-level view?
>
> A little tricky, I'd have thought, since a View's name is stored in (and
> managed by) its parent.

Which is what I am revisiting, given how much MVP has evolved.  Just
curious.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]