How correctly implement own sublcass of Presenter

CONTENTS DELETED

Vladimir,

Just a guess.  Shouldn't the following

model: aPeriod
....
  fromDatePresenter model: (aPeriod aspectValue: #fromDate).
  toDatePresenter model: (aPeriod aspectValue: #toDate).

read

model: aPeriod
....
  fromDatePresenter model: (adaptor aspectValue: #fromDate).
  toDatePresenter model: (adaptor aspectValue: #toDate).


I haven't used a CompositeValuePresenter before though ... Indeed, I've
never even heard of it!

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

CONTENTS DELETED

CONTENTS DELETED

CONTENTS DELETED

Vladimir,

> Part of first problem  - in Dialog uses AspectBuffer for buffering
> model and implement user data input cancelling. AspectBuffer send
> message #copy to subject for create subjectCopy.

That sounds plausible.  If think that if you are using buffered dialogs then
the framework requires that your domain objects (Models) have correct
implementations of #copy.  The default implementation of #copy is a shallow
copy (which is rarely what you want, but is the only sensible default).

To implement a valid #copy for your domain objects, it is usually best to
override #postCopy.  In your case I suspect that the implementation of
OnetimeTransaction>>postCopy should read something like

    postCopy
        super postCopy.
        period := period copy.

Your other question was about validation.  I think that a lot depends on what
sort of user interface you want to provide.  Do you just want to disable the OK
button if an invalid period is defined ?  Do you want to add a text message to
your dialog to explain that the OK box is disabled because the from date is
after the to date ?  Do you want to highlight invalid periods (in red, say) ?
Do you want to fix up the period as the user edits it so that the to date is
never before the from date ?  Do you want to allow the user to press OK, and
then give them a pop-up stating that the period is incorrect ?  So many
options, it's difficult to give a generic answer ;-)

But what you decide on as your basic approach will affect how you design your
domain models.  The fundamental choice is between: Models that allow themselves
to enter an invalid state, and are capable of telling you so (with some sort of
#isValid method). Domain models that actively validate themselves (perhaps
throwing exceptions) in which case I don't /think/ the aspect adaptor framework
will work for you -- you'll have to do your own validation before sending, say,
#from: to a Period.  Or Domain models that actively keep themselves valid by
adjusting themselves as necessary.  My personal inclination would be to try the
first of those options.

    -- chris

Chris, Vladimir,

> But what you decide on as your basic approach will affect how you design your
> domain models.  The fundamental choice is between: Models that allow themselves
> to enter an invalid state, and are capable of telling you so (with some sort of
> #isValid method). Domain models that actively validate themselves (perhaps
> throwing exceptions) in which case I don't /think/ the aspect adaptor framework
> will work for you -- you'll have to do your own validation before sending, say,
> #from: to a Period.  Or Domain models that actively keep themselves valid by
> adjusting themselves as necessary.  My personal inclination would be to try the
> first of those options.

Agreed.  I ran into some problems with type of thing (actually causing
my software to crash! - at least on 9x machines).  Noting that my domain
objects were not all that different from Squeak Morphs, I studied them
and ended up with lots of #postCopy methods.  The crashes disappeared.
Note that your #postCopy (and tests) will need attention at each schema
change.  The compiler will alert you if you remove an instance variable,
but it won't be of any help if you add one; tests will help you as long
as you remember to "tell them about the new variable" - do that ASAP
after the change.  In fact, you can probably do it _before_ the change,
using selectors you expect to use.  The important thing is for the
test(s) to fail to draw your attention to it later.

I frequently disable dialog buffering and do my own copying; I a have a
NonBufferingDialog class for this purpose.  It forces me to do extra
work, but making it explicit has been easier than thinking through what
an aspect buffer would do in certain situations, especially when the
model of a dialog is itself a composite object.  I make sure I have a
good way to copy the model, do so, and apply changes on user
confirmation. YMMV.

You can disable ok if the model is in an invalid state.

Have a good one,

Bill


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