MVP design question

Hello all,

Consider a time presenter that is a composite built for pen users; it's
littered with buttons, among which is one labeled Now.  Also consider a
time stamp presenter which includes the above and a date/time picker in
the drop-down calendar mode.

Obviously[*], the Now button needs to set the date when it is part of a
time stamp presenter.  The question is how to do it.  Options include
triggering an event and command routing.  Any preferences?

[*] it only took us 3 years to realize what was happening ~:0

Have a good one,

Bill

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

Bill,

What does the Now button do? I'm not quite sure from your description - does
it set or get the current timestamp.

> Obviously[*], the Now button needs to set the date when it is part of a
> time stamp presenter.  The question is how to do it.  Options include
> triggering an event and command routing.  Any preferences?

I think I'd trigger an event in the #now method and register for that event
in the time stamp presenters #createSchematicWiring method.  That would seem
to be the "normal" way to do it and avoids any complication that could occur
when trying to adjust the command routing.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Bill,

> Consider a time presenter that is a composite built for pen users; it's
> littered with buttons, among which is one labeled Now.  Also consider a
> time stamp presenter which includes the above and a date/time picker in
> the drop-down calendar mode.
>
> Obviously[*], the Now button needs to set the date when it is part of a
> time stamp presenter.  The question is how to do it.  Options include
> triggering an event and command routing.  Any preferences?

So, if I understand you, you have a button that should invoke one action in the
default context, but if the button's presenter is used in a different context
then it should do something (slightly) different ?

Like Ian, I think that I'd avoid the complexities of command routing here
(although its a perfectly valid technical solution, I think).  Some ideas, in
roughly increasing order of complexity (and generality):

1) (The /really/ simple suggestion) Make your button always generate a
TimeStamp (date-time pair), and let the context discard (or ignore) whatever
extra data it didn't need.

2) Give the time presenter a pluggable aspect #timestampBlock (or
#timestampFactory) which is
    [Time now]
by default, but which can be replaced by
    [TimeStamp now]
(or whatever) if needed.  The button's command would evaluate the block and <do
something> with the result.

3) Make the button invoke a generic #timestamp command which is /not/
implemented in the time presenter, but which must be provided by the context in
which it is embedded.

4) Ian's suggestion (slightly exotic, IMO, if I'm understanding it correctly).

5) (Another slighly exotic possibility)  Make the button's command a public
"aspect" of the time presenter, thus allowing you to plug in a different
command with a different effect -- perhaps an instance of
ClosedCommandDescription.

Without understanding your problem in detail, I suspect that I'd use (1) or
(2)...

    -- chris

Chris,

> 4) Ian's suggestion (slightly exotic, IMO, if I'm understanding it
> correctly).

Reading through your comments I think I may have misunderstood Bill's
question.

I thought he was talking about having a presenter/view that contained a
button.  When pressed the button's command performed some action within the
presenter.  This presenter/view /may/ also be embedded as a subview within
another presenter/view and, when pressed, the command should then perform an
action both within it's own presenter and it's parent presenter.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian, Chris,

> What does the Now button do? I'm not quite sure from your description - does
> it set or get the current timestamp.

The idea is to make a containing dialog's value equal to the current
time, and when the dialog is editing a time stamp, it further needs to
set the date in the model.


> I think I'd trigger an event in the #now method and register for that event
> in the time stamp presenters #createSchematicWiring method.  That would seem
> to be the "normal" way to do it and avoids any complication that could occur
> when trying to adjust the command routing.

That seems reasonable, and was my first thought.  However, I've had some
very good results with command routing in (loosely) similar situations,
which is why I posted the question.  Chris' ideas are interesting,
especially the one about raising a time stamp and letting the particular
subpresenter pick up the part of interest to it.

Have a good one,

Bill

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