MVP, and multilanguage question

Hello,

I'm new to Smalltalk. Evaluating Dolphin I failed to use CompositePresenter
as a "component" within Dialog.



I have two MVP triads for Insurance application:



1) Model: Partner, CompositePresenter: ParnerPresenter, Partner Presenter
default view.



2) Model: Policy, Dialog: PolicyDialog , PolicyDialog default View.



Instance of aPolicy contains aInsurer (aInsurer: Partner new.).

PolicyDialog default View contains reference to Partner view.

In real insurance application we have dozen of partners playing different
roles in policy (holder, insured person, ... ) it is useful to have logic
associated with general Partner coded in one MVP triad. Rest of application
uses this component as black box.



We extensively used this method with Gupta SQLWindows. Evaluating Dolphin I
followed "Personal Money" example and wrote:



PARTNER MODEL:

Model subclass: #Partner

            instanceVariableNames: 'name'

            classVariableNames: ''

            poolDictionaries: ''

            classInstanceVariableNames: '

POLICY MODEL:



Model subclass: #Policy

            instanceVariableNames: 'number insurer'

            classVariableNames: ''

            poolDictionaries: ''

            classInstanceVariableNames: ''



PARTNER PRESENTER:



CompositePresenter subclass: #PartnerPresenter

            instanceVariableNames: 'namePresenter'

            classVariableNames: ''

            poolDictionaries: ''

            classInstanceVariableNames: ''



PartnerPresenter>>model

model: aPartner

| aspectModel |

super model: aPartner.

aspectModel:= self model.

namePresenter model: (aspectModel aspectValue: #name).



PartnerPresenter>>createComponents

super createComponents.

namePresenter:=self add: TextPresenter new name: 'partnerName'.





POLICY PRESENTER:



Dialog subclass: #PolicyDialog

            instanceVariableNames: 'numberPresenter partnerPresenter'

            classVariableNames: ''

            poolDictionaries: ''

            classInstanceVariableNames: ''



PolicyDialog>>createComponents

            "Create the presenters contained by the receiver"



            super createComponents.

            numberPresenter := self add: NumberPresenter new name: 'number'.

            partnerPresenter:= self add: PartnerPresenter new name:
'insurer'



PolicyDialog>>model: aPolicy

            "Set the model associated with the receiver."



            | aspectBuffer |



            super model: aPolicy.



            aspectBuffer := self model.

            numberPresenter model: (aspectBuffer aspectValue: #number).

            partnerPresenter model: (aspectBuffer aspectValue: #insurer).



Evaluating

PolicyDialog showOn: Policy new

I got:

ValueAspectAdaptor(Object)>>doesNotUnderstand: #name



Also, I have problems with Lithuanian characters. They simply disappear.
After evaluating in Workspace

aName:='aceeisuuz', becomes aName:='?????s??z'.



So, could some one explain how to do things like above with Dolphin?

Thank you,



Vaidotas Didzbalis

Vaidotas,

The main problem is the following line where you set the model for your
PartnerPresenter to a Partner wrapped up in an AspectBuffer.
PartnerPresenter, which is expecting a simple unwrapped instance of Partner
as it's model,  tries to send #name to this wrapper - which fails.

    partnerPresenter model: (aspectBuffer aspectValue: #insurer)

There are a number of changes you need to make to get this working.....

Add a #defaultModel _class_ method to both your PolicyDialog and
PartnerPresenter classes - as in

PolicyDialog class>>defaultModel
    ^Policy new

PartnerPresenter class>>defaultModel
    ^Partner new

This ensures that whenever an instance of either class is created is always
has a correct default model. You can always dynamically replace this model
with another if required - when you want to edit an existing instance rather
than creating a new one for example.

It also makes things easier to test....

Test the PartnetPresenter by evaluating the following in a workspace.

PartnerPresenter show

You get a walkback telling you that Partner doesn't understand #name.  The
message #name is being sent to the newly created Partner instance (from the
last line in PartnerPresenter>>model). Partner has an instanceVariable named
'name' but it is private to that class, not exposed to the rest of the
world. We have to add getter and setter methods to Partner to make it
visible and accessible.

Partner>>name
    ^name

Partner>>name: aString
    ^name

We don't want to allow nil as a value either so we also have to initialise
'name'

Partner>>initialize
    super initialize.
    name := 'Fred'

Add those three methods and try the above test again - it should now work
(assuming you have created the view correctly?)

You need to do the same for the Policy class as well

Policy>>number
    ^number

Policy>>number: aNumber
    number := aNumber

Policy>>insurer
    ^insurer

Policy>>insurer: aPartner
    insurer := aPartner

Policy>>initialize
    super initialize.
    insurer := Partner new.
    number := 1234

The following  change is a bit more questionable.  Using the default
buffering mechanism on an object that doesn't expect to be buffered
(ListModel is another example) can be a bit awkward.  The following works
but there are other ways.

PolicyDialog>>model: aPolicy
    | aspectBuffer |
    super model: aPolicy.
    aspectBuffer := self model.
    numberPresenter model: (aspectBuffer aspectValue: #number).
    partnerPresenter model: aspectBuffer insurer copy

PolicyDialog>>apply
    super apply.
    self model subject insurer: partnerPresenter model

This is just doing your own buffering for partnerPresenter. You use a copy
of the input Partner instance for the model in the Dialog and only copy the
edited version back if the user presses OK (#apply is only called when the
Dialog. is closed using the OK button)

Test it by inspecting the following in a workspace

PolicyDialog showModal.

This opens a dialog up on the default values and, if the user presses OK,
answers a new Policy instance.

partner := Partner new.
partner name: 'Bert'.
policy := Policy new.
policy
    number: 9876;
    insurer: partner.
PolicyDialog showModalOn: policy.

This creates a new Policy and then edits it in the Dialog. If the user
presses Cancel then the original is left unchanged. If the user presses OK
then policy's values are updated..

Hope this helps
    Ian

Ian,

Thank you, it works. A bit strange, that this machinery is not handled by
library: a few more lines for developer to write (regarding manual
buffering).

Have anyone comments regarding national character sets? I have problems with
Lithuanian specific characters. They simply disappear after evaluating in
Workspace. String made of them appears as '???????'.
Vaidotas Didzbalis

"Ian Bartholomew" <[hidden email]> wrote in message
news:yT8N8.6369$VP6.515603@stones...
> Vaidotas,
>
> The main problem is the following line where you set the model for your
> PartnerPresenter to a Partner wrapped up in an AspectBuffer.
> PartnerPresenter, which is expecting a simple unwrapped instance of
Partner always
> has a correct default model. You can always dynamically replace this model
> with another if required - when you want to edit an existing instance
rather the
> last line in PartnerPresenter>>model). Partner has an instanceVariable
named the

Vaidas,

> Have anyone comments regarding national character sets? I have problems
with
> Lithuanian specific characters. They simply disappear after evaluating in
> Workspace. String made of them appears as '???????'.

I have no first hand knowledge of this as I just use the Western code page
and have no trouble displaying the available 256 characters but I checked
through the archive and came across the following posts, reproduced in full.
The problem described (especially paragraph 3) seems to the same, or
similar, to yours but I can't say more than that.

The locale that Davorin mentions is maintained internally by a Dolphin class
called Locale. If you evaluate the following you can see what the default is
set to - it may indicate something that is incorrect?

Locale default

Ian

~-~-~-~- Original post from Davorin Mestric - 13/6/2000

under windows 2000 i can not display characters from code pages other than
default, western.  the Character class method 'codePoint:' documents that
only first 255 code points are supported at the moment and Unicode will be
supported in the future.  this is fine, but even if i select a font with
different code page (or 'script'), this script attribute of the font is
ignored, probably by windows 2000.

font selector dialog works fine, the font returned has the correct dwCharSet
field.  i select the font into a 'static text' control, the font gets
changed ok, if i ask it again from the control, i still get the correct
charset.

the entry of international characters in the rich text control works in
unicode, and higher characters get lost (replaced with the '?'), but for
testing i forced the right characters into a string with numeric values, in
correct code page, the same i select for the control.  so, i'm sure the
information is lost in one of those two places:

1. dolphin, when representing strings to the windows, uses wrong code page
for translation, so my text is assumed 'western'.  i don't know how i would
check this.  also, dolphin can not have the code page information for my
strng other than from the currently active 'locale' for the application, but
this also has no effect.

2. windows 2000 ignores the code page selected in the font, and only knows
how to work with unicode.  then why does the 'script' field still exist in
the select font dialog?

~-~-~-~- Davorin's follow up post

i solved my own problem.  window 2000 looks at 'system locale' when
converting non-unicode text, (and changing that system locale is the first
operation i found that required a reboot).  after changing systel locale,
croatian characters are displayed ok.

~-~-~-~-

I solved that changing font used in for RichTextEdit.
Thank you, Ian


"Ian Bartholomew" <[hidden email]> wrote in message
news:3d068c3b@tobjects....
> Vaidas,
>
> > Have anyone comments regarding national character sets? I have problems
> with
> > Lithuanian specific characters. They simply disappear after evaluating
in
> > Workspace. String made of them appears as '???????'.
>
> I have no first hand knowledge of this as I just use the Western code page
> and have no trouble displaying the available 256 characters but I checked
> through the archive and came across the following posts, reproduced in
full.
> The problem described (especially paragraph 3) seems to the same, or
> similar, to yours but I can't say more than that.
>
> The locale that Davorin mentions is maintained internally by a Dolphin
class
> called Locale. If you evaluate the following you can see what the default
is dwCharSet
> field.  i select the font into a 'static text' control, the font gets
> changed ok, if i ask it again from the control, i still get the correct
> charset.
>
> the entry of international characters in the rich text control works in
> unicode, and higher characters get lost (replaced with the '?'), but for
> testing i forced the right characters into a string with numeric values,
in
> correct code page, the same i select for the control.  so, i'm sure the
> information is lost in one of those two places:
>
> 1. dolphin, when representing strings to the windows, uses wrong code page
> for translation, so my text is assumed 'western'.  i don't know how i
would
> check this.  also, dolphin can not have the code page information for my
> strng other than from the currently active 'locale' for the application,
but