Board index » delphi » MVP - Realistic "Simple" RFE

MVP - Realistic "Simple" RFE

Request for Example<g>

Jim Cooper pointed out that showing something beyond a trivial example is
essentially doing someone's work for them.  I'm working on something right
now that can be simplified to a trivial GUI example.

Note: I'm currently working on a separate solution and the actual problem is
significantly larger, so this is NOT asking anyone to do my work for me.  I
am offering this as a trivial but non-trivial MVP problem.

If anyone wishes to attempt an MVP solution, you may refactor any way you
wish with the sole exception that the Rules outlined must be observed.

Also note that the user specified GUI description can be assumed to be _one_
possible way of implementing the view.  It is currently the user desired
way.

========

We have domain that I will simplify as follows (accessors omitted for
brevity):

TBillableType = (btInvalid, btServices, btDiscount);
{ BillableTypes: 'Invalid', 'Services', 'Discount' }
{ AmountDisplayText: 'Invalid', 'Price', 'Discount' }

IBillableType = interface
  property Type : TBillableType
  function AsString : string;
  function AmountDisplayText : string;
end;

IBillableItem = interface
  property Name : string;
  property Type : IBillableType;
  property Amount : currency;
end;

At the other end of the world, we have a user specified request for a GUI:

Rules and user requirements:

1.  Type will be presented in a dropdown list box

2.  When type changes, the display text above the Amount will change

3.  Name is a required field.  If Name is left blank on exit, the control
will be highlighted yellow and focus will return.  It is desired that
_immediate_ feedback be supplied, as well as when attempting to save

4.  If the user clicks Cancel, Name can be blank

5.  Amount must be a number

6.  The GUI will have an OK and Cancel Button

7.  On Ok, the billable item instance is updated and the GUI closes

8.  The workflow order is Type, Name, Amount

If anyone in the MVP expert world is interested in using this as an example
of a trivlal-but-non-trivial example of MVP...go for it.  Feel free to ask
for any clarification questions.

John Elrick

 

Re:MVP - Realistic "Simple" RFE


"John Elrick" <jelr...@adelphia.net> schreef in bericht
news:3eb27c45$1@newsgroups.borland.com...

Quote
> If anyone in the MVP expert world is interested in using this as an
example
> of a trivlal-but-non-trivial example of MVP...go for it.  Feel free to ask
> for any clarification questions.

I suppose plain old MVC is not good enough?

Regards,

Dirk.

Re:MVP - Realistic "Simple" RFE


"John Elrick" <jelr...@adelphia.net> wrote in
news:3eb27c45$1@newsgroups.borland.com:

Quote
> Request for Example<g>

I think the problem with a non-trivial trivial example is you end up
developing a framework that would be "good-enough" for real world work.  

--
Iman

There appear to be absolutely no rules in Hollywood. It is anarchy.
Hollywood is essentially Thunder Dome with fake {*word*12}. - Peter DeWolf

Re:MVP - Realistic "Simple" RFE


Quote
"Dirk" <Dirk.Andr...@PantaRhei.be> wrote in message

news:3eb287e2@newsgroups.borland.com...

Quote
> "John Elrick" <jelr...@adelphia.net> schreef in bericht
> news:3eb27c45$1@newsgroups.borland.com...

> > If anyone in the MVP expert world is interested in using this as an
> example
> > of a trivlal-but-non-trivial example of MVP...go for it.  Feel free to
ask
> > for any clarification questions.

> I suppose plain old MVC is not good enough?

Sure...why not...

John

Re:MVP - Realistic "Simple" RFE


"Iman L Crawford" <ilcrawford.at.hotmail.dot.com> wrote in message
news:Xns936F68343278ilcrwfrd@207.105.83.65...

Quote
> "John Elrick" <jelr...@adelphia.net> wrote in
> news:3eb27c45$1@newsgroups.borland.com:
> > Request for Example<g>

> I think the problem with a non-trivial trivial example is you end up
> developing a framework that would be "good-enough" for real world work.

Naw...it would be good enough for a sub-set of the real world work.

If I wanted someone to do the work for me I'd add in the other two dozen
rules...one of which is that Name must be unique and must be validated
against a persistent store...immediately.

Dirk commented that he wanted an article that was non-trivial.  Jim
commented that non-trivial meant doing someone's work for them.

Well, here is a tiny example with some hard logic, but it's hardly more than
a fractional set of a real-world example.

If she wants a toughy to demonstrate, Joanna could take this one for her
book.

I'm attempting a "Humble Dialog" solution, BTW...using Test First Design.

I've also started formulating a pattern:

D - DAL - PMAL - VAL - V

View
ViewAbstractionLayer
PresentationMediatorAbstractionLayer
DomainAbstractionLayer
Domain

As part of this work.

This dumps the MVC/MVP triad, which I think introduces testing overhead, and
replaces it with a straightforward layering system.  Each layer can only
speak to its neighbor.  That means each test case requires only two
objects...the one being tested and a mock of the layer we are testing
against.

I'm still self-arguing about the existance of PMAL...

If it actually works, I'll post it.  If someone else has already seen this
type of approach...let me know.

John

Re:MVP - Realistic "Simple" RFE


Hi John,

Quote
> If it actually works, I'll post it.  If someone else has already seen this
> type of approach...let me know.

Where can I found more about this kind of Type???

Regards,

Cesar Romero

Re:MVP - Realistic "Simple" RFE


Quote
"Cesar Romero" <ce...@liws.com.br> wrote in message

news:3ebd43da@newsgroups.borland.com...

Quote
> Hi John,

> > If it actually works, I'll post it.  If someone else has already seen
this
> > type of approach...let me know.

> Where can I found more about this kind of Type???

Which one...Humble Dialog or the pattern I'm proposing?

John

Re:MVP - Realistic "Simple" RFE


Quote
> Which one...Humble Dialog or the pattern I'm proposing?

Pattern.

:-)

[]'s

Cesar

Re:MVP - Realistic "Simple" RFE


Quote
"Cesar Romero" <ce...@liws.com.br> wrote in message

news:3ebebb50$1@newsgroups.borland.com...

Quote
> > Which one...Humble Dialog or the pattern I'm proposing?

> Pattern.

Right now...in my head.  However, here's the quick rundown on what I'm
thinking of and why.

MVC/MVP runs a triad, where the View is an Observer of the Model and the
Presenter is a two way mediator between the Model and the View.

There was something that didn't sit right about the View having knowledge of
the Model...even as an observer.  This was made more intense by The Humble
Dialog Pattern, which makes the View about as dumb and impotent as you can
possibly imagine.  This also tends to complicate Test Driven Design, since
the three tend to be difficult to fake with Mock Objects (Server Stubs).

My theoretical solution is simply:

Domain <- Controller -> View

The Domain is a layer which offers access to the data by whatever means or
pattern you desire.  It's basically just an interface to the business data.

The Controller is a very enhanced version of the MVC Controller.  Rather
than being just a mediator, the Controller actually runs the view.  It
pushes data to the View, pulls data from the View, is responsible for all
communications to/from the Domain as well.

Now, my expanded theory is:

Domain <-> Domain Socket <- Controller -> View
"          <-> Domain Socket <- Controller -> View

Where a Socket or Adapter is the Observer of the Domain.  The Controller
serves as above, handling all transmissions to and from the Domain Socket
and View.

My primary goal was to simplify MPV for testing purposes...meaning that we
can have:

MockDomain <- Controller -> MockView

and test the heck out of the Controller fairly easily.

FWIW

John

Other Threads