MVP frustration

I want to vent off my frustration with MVP. Why is it so convoluted to
implement a simple view to display data and get user input?

With MVP it is too much work to put views together unless I do
everything right. Having to deal with all the intricacies of
Presenters, Views, Models, AspectAccessors, ValueHolders  and so on is
frustrating.

I have designed an application that I did not subclass from Model. It
has a couple of instance variables that I need to display on a view. I
added onchange triggers to these variables inside the class.

I also designed a View with VC and added a ListPresenter and
TextPresenter controls to display data from my model.  I subclassed it
from Shell.

I then create createComponents inst.method in my shell subclass. (I
left out the super stuff)

Shellsub>>createComponents
  statusInfoPresenter := self add: ListPresenter new name:
'statusInfo'.
        pathNamePresenter := self add: textPresenter new name:
'pathName'.


Where I am lost is when I have to make the #model: message.
Since I did not create my model under the Model class, what object do
I pass to the #model: message? I am supposed to do something like:

ShellSub>>model: ??? <- What is passed here?
        statusInfoPresenter model: ??????  <- What do I put here?
        pathNamePresenter model: ??????

ShellSub>>createSchematicWiring
        statusInfoPresenter when: ?????? send: #displayInfo to: self.

My model has two variables. statusInfo which is a SharedQueue and the
other a pathName which is a String.

What am I missing here?

Thanks

Costas

P.S. I studied the PersonalMoney docs.

> ShellSub>>model: ??? <- What is passed here?
> statusInfoPresenter model: ??????  <- What do I put here?
> pathNamePresenter model: ??????

model: aModel

statusInfoPresenter model:(all status infos asOrderedCollection).
pathNamePresenter model:(aModel aspectValue:#some attribute). "this connect
your part of your model (#some attribute) with your presenter"

> ShellSub>>createSchematicWiring
> statusInfoPresenter when: ?????? send: #displayInfo to: self.

statusPresenter when:#selectionChanged send:#displayInfo to: self.

Keep trying !!!

When you understand the whole MVP you 'll realize that MVP is geat !!!

> Keep trying !!!
>
> When you understand the whole MVP you 'll realize that MVP is geat !!!

But is this like some kind of junior doctor thing? Everyone made to work
hard because that's the way it's always been?

I've been programming over ten years in C, C++ and Java (oh go on, I'll even
admit to VB), but I found, and am still finding, MVP very difficult.
Smalltalk is hard to read for newcomers, and there is too little
documentation with Dolphin, way too litlle.

When I started with Dolphin, I was dead impredded (and even bought the
commercial version), but as soon as I wanted to put a GUI on my app, I just
lost steam, and now I'm drifing away.

OK, so I did the application three times quicker in St than I could in Java,
but I could build the Java GUI in an afternoon, an two weeks in with
Dolphin, I still can't figure it all out.

Darned shame, really.

If someone writes a tutorial that really explains MVP, I mean explains the
purpose and consequences of every method, and how to do those odd little
things you need to do now and then, I will gladly pay.

I really empathise with Costas, there are too many elements involved (and it
changed from Dolphin 2. to 4.0, without ANY documentation of the fact) for
brief overview of one example app (PersonalMoney) to really be enough. Maybe
I'm just impatient. I think if I spent a good few hours at it (but more than
10, which is more than two weeks), I could get it. But I want to spend those
hours developing my app, not figuring out the basics. I only get one hour a
day to do this stuff, because I work in Java in real life. Please help me
use Smalltalk. I really, really want to, but I'm really soon going to have
to throw it away.

Rant over.

Sorry

Costas,
> I want to vent off my frustration with MVP. Why is it so convoluted to
> implement a simple view to display data and get user input?
>
> With MVP it is too much work to put views together unless I do
> everything right. Having to deal with all the intricacies of
> Presenters, Views, Models, AspectAccessors, ValueHolders  and so on is
> frustrating.

It sounds like you're going too deeply into it, and that is what is causing
the confusion. Take the MyClass/MyModel pair in the attached package. It
provides a Shell containing a TextEdit and a model containing an instVar
which is displayed in the TextEdit. When you edit the view (and move focus
away from the edit) the instVar is updated. When you programatically change
the instVar then the view reflects the change. I've added two buttons -
"check" just displays the current state of the models instVar and "Set" sets
the instVar to the current time.

I think the above covers you're pathName scenario. The ListView is more
difficult as a SharedQueue is not suitable to be used in a ListModel
(SharedQueue is not even a member of the Collection hierarchy). The
ListPresenter (or rather the ListModel associated with it) has to have some
way of getting at the list of objects it has to display - and SharedQueue
doesn't provide a means of doing that.

The second demo (MyListShell/MyListDemoModel) shows how you can display a
list (an OrderedCollection contained within a ListModel) by sharing the
ListModel between your model and the ListPresenter. When your model updates
the ListModel the ListPresenter automatically reflects the change.

I've tried to keep them both as simple as possible to show the basic
mechanism involved - any help?

Ian

























begin 666 Demo.zip
M4$L#!!0````(``"RC2F=DZXC+@P``&1&```(````1&5M;RYP86/M6>MOVT82
M_YP`^1_6[@?9AU/!Y9LN+H#E1Q @28O:S9>B!6B)MGFA1%6DX[C7^]]O9G=G
MEV])?ER;-*!E4;NSL_/XS<P^_F#+>/HAODK8'R^>T^O!O]@/ZG41SY,#-CI.
MYOGH6T.QC#^]3U9%FB\.F/7=B^?/+N(BG1[E\WFR*('^[=W9=9)EK+C.;U\\
M?_'\[=V;M"A-&_(RW,1@-:-F.Y(TNX>S&2NO$RUG,5VER[+8K75.L[@HA+#%
M/UF6YT7"YDEYG<^H[2K++^*,?JV2(K]93:5ZR(J8"S[OL!%TBF>S`_:-%!T-
M\#:?)=EWC0ZA4[6Q1:4I[F#.(LDN:[I+,6G*3A(I^R )*=1)M#M)%_'JCKV2
M-GC7T/E"]+XRDQRPO;.D9(ODML)I'UCM_DAV:_*(L^S'J@@U%BUSL?%+A-1E
M?).5[&.:W(Y:]NHFJ0I3A<8J626_W:1%6K9=6B3E#Y5^%.WU#%":EG<-$4?'
M>;:\3A<=4REF.V+:(P$V$"Y=I"5@M=@5[=]?_#N9EJRXN1 H:D,'N*:+HHP7
MT^1]O$KCBXR,-9H+2D$U`C+!H$F#'<L\SX[3*<X*O;I9T+_NX3W:Z99MO4S(
M$5J?1"*5"YK&$LT#0F5 \_^29YTL9?()H54`F)*G,=+N&Y'*WHH<H6"V>[*8
ML?Q2Y\.9QJ'L-^E6`X]-=6(>[73U7]VD@/^]5S^]/F:7JWQ^5J[2Q160_^>8
M'YZ<A%XT#DXB=^P>>2?CZ&CBC"?'[J'GGX03]V3RW]&^X+K3FC8NDZL<%3[-
M5R)J=GY:"*73RS29[;"=CD$R(>((P10B\SQ'"K"7"/@80Y9!),]9F8OPSW3L
M?,M>E^PV!4>"`E=7R8K%"Y9\!-6!,$86HO,"4D8Z_9#,V,V27=P))LA#.U,4
MEV>5H&0@QINX``N>IW/(,?DM))UT44I#"4&GU_'B*CG*8?RB+(2TV6U\5S#9
M(<N4ZD7_T:2*/SAUD9>-UK3$%-26!J,`(+HW>@>EE(UN$_AW'7_$KU6RS.)I
M,H-7X(6=UWF&WR)R]EE<?+^:03J<'>59E@A("O$K[%'V-_'O:7;'!++B+/T]
MV6V(D!;O4OA_>;ZZ@07"S]4N6#Z8'^"L7T0*??9KA:8YY0$80.8HG/Q=CEF[
M!,MB8<EOP5%Q`<9@M_E--F,7JR3^(#V?+CZ -\O;)%F(!AA=<Z2P:\VF(,NS
MLR1A=7>Q?,%@68*(JKEKOLR2,A'VEEY ?[#K."N[P5M#/'A(HW?G'^.;*O27
M-Q=9.MV,25W4AW"J>B">3A/@`>@%)'\$PJU9'/3PH!S4EWO6Y9PC]]@+W1-K
M[%C.X=AU3X_'(>?!.'!.C]WPQ+.]0ZN2<[;*-9TY1E>Z`>0KBC;NJ0-0/WHM
M!S&IR\@`GXCJT]507^-$[9+![CG6)D3D;;[*9B*7B9^I&G$=4YJ9L;T"T*V*
MU\N7<]1W?Y>0J]*B\*.:[DB.JQNH[75%W0^;-0/7@447_YYB)?OZ01.%)X%G
M19/Q,9],QNZA98W#B7,\]D+//8+.TU/OL%&HU'2;%RDY8*! "1O/J6"HR.\L
M#A7*1G@+<LAP)33-E_F"!MPL(9TU.S";87)"S B68B%;3X%8+M4V3M0`B4&5
M==M+5#E13[_$HYBQAX)5<TS+=@_(C]T,MLV-/5P:9KTO'VF3@='-\6(GT0#4
M3.YZR!^_-@T,_NR01'!JRE-E-2B5C+.^^%L7>\&I=1AQ?CAV)JX]=F'!. Z=
M8#*&].UX0>#QT#NIQ-Y6<=<9<]/K9/H!;/,6$@JL@2?Y)UP\I9=W!ZP26"9I
M;1U3M:5]/;C.:UV5X,(QS>#J"ZI*,.V>B7PM6B!?F]IPF:]$DE<Y&VR]VY),
M<=S;(YZP4%I"W7@?9UB>3/K=5QWGDEG140&D?V#A54]/%8DZU[XU/[7#$QPU
M'$V/$9'WC,;>D6"$=4&\50"W`O=1@I8UCW9HATA',>KW'OV6YQ[ :,74+K>:
M0O117^70!6%3I%<+@)@Z0L#(EY.>E?DJF=SAD<J+Y]_\[#@LA#^7^3YS;.:&
M^#^PF,VXS2S&X8-/Z#-N>?#AC/.(A;9ZA2:.WP%\7!9%HME2#[1PYO@XG*88
M'JC)X(_;V.V+=M\35((R$#W0`F/4,,F-.+HLM!0Y_+0M04\B>2[\B^"S=@8T
MC!C2;:$0>J6%B+71L6&K?FF "]C#J=I96P"DL$(AC-)NG5;*SD(CI$,1.,KG
ML$#1^:$<;N$W>J)"YOJ**#*B2 (U`#X-S1PTD(=\6]:S72U<_>$1]=C4@A\/
M)A!OV!J1*,W'AVZ<3YB"&]FY&<!=3QD3_.:(ET!/M=D#6MC,KL$V0%M82G%+
MH<:3WXC&4/Q$..H>21E)?"/1@/^XW920^T8:4HZ'ZN4QI&G[(6K982.I"%L!
M324%P?@B3?54G(CIT9YNBR,P+2(,.)/@EB.T1@-HQ;EN1A(]%3QN)&RAVF N
M:7'(;HY .4W5$#T(%+HL#7ZC-@8L_JX%*L64^/ NRS_<^=K.D3(%`8!"U-I0
M%&/JYH-SV6*.88"%TMQ1)7>[)B8-^BI*-I\F$-8]/ B5]S1.7&D$VT8QHFW-
MZ/LZMTIIF_B%QE#_4IF-K*EX.#0C-G%,3 B=2D'"&10V0X(H0I>HK&;%M#V+
MU8W&?073=H1 .0(>F\UJ"5L9>Z# R,\4+4>F!2N2>DM/#L'6V%17#H*FPD:E
MM/K,DX 4;"AN%;:PJZ6=[3;]Z=+DG%[:-+9'?2",[-1Q;W/#G:B;+1U($460
M4Z1Y`F@ZEKB$$9C*C];KQAO?6C0-H## X .P0^*"2(>?H<A/8$2(;I@CD/]#
M=!L)O?FBQJ5!KAE=%\GVO(=]M%#$V*4WSR5']*/<#=5+V[4\<EIOIH]>M/^T
MS55"HE"V-GSZ<U>#SO4[4+5Q$+=!::EERR8AH2-A("0Z5D2Z[&X7$E0',4D8
MC <ZE[K=:*?'%'O79W4/8GJ7+?T(I>>A"-5P)'Z6@6JT'J%&/U)!1_$]5U!F
M!R'-*8N2*Y=0*H]RG[7K]S;+J78!%?5+KA:)UJWV=CT/+]N@-?=A>6VC0A&N
MQ5RYH-)5C18QD2Q&`:/JY8>ZS.E*@S%ML^82AYXA,%/&$.E;3A#*1-]8"9@A
MY'#,JVI(7Y;0<7F_[$ S/2P[Z&K-'2J&'>DA("J_C8,M2Z9N4N;#FBBW'9%9
MDJ+9.O.$8S2YW_PZCJD&JWK<78.'W&HDN%^N>JQJJBWJ4V:*2,EH@UQEJBGL
MQQM::/S7)<?'4Q1/EF= FN%"_.AY!O!'AI//((Z)B=K:Z!PD5].4H:H[4'K'
MG*'YZ.^@B\U?.W7H3<FVN4/[MBT`P%%V#<7^P'A,]7T,-K6ZX?]G1S9QU*'-
MP\>.[8&N`,,<E:-^V':(JEJOH)5IU8LX`<'XK&T=*X>-.L]7UBR?R1DH)1%]
M>BD.0J+:CEH=8)-<M%:0.@>6_*E,$$@+1)&FI7WD8VS 25K23+A/'931J1#E
M):+EY.[UI[NN_$F@0+\[O.:>YH[7973(B-P&3_K5&DMHZFYZ2JJ5, L.J]^9
MEN0$<0)_GBWUL;2VBNLO^^LO6[Y>M#SE10M(]O6BY7.^:#%O7V]:.J1YM)L6
M$BI46%&Y%].PD%')999&3>\^X6V+C<+QSNN6ON?A:_P(%]N .=L34>)3C",A
M#W0PU=;KH9:]6K=ZYU3?J,NC'/#S+^H"2>^<_V8W$?J204O1L8/2UQ7F2H)"
M@@L85*FYUVHQ6IES#542!F!B-S<\G8<?Z# $83.TA85#6L*1*/K<O?'[P?JH
M8Z)&0JO=OZ+&-M/%<.W9T9=XI6+L12_Z3L6A%\!?W=X^.:!]W_MX=RN$&^4Y
M:\-GN#"8IZG3)DKJU4X;D[[52_W0JQ7S9HKL5D'QI=^MF+=-G/C%7:U8C>/'
MYO.97:P,(;EZB*6V->(UZ*!19W15FAK7"G_U?9^4H'/;`U-"I%/"0-WO.!/5
M)^K;E4G=I,KD/6]3[C?[/>]2^AVKQ?A3CUUUX33)PJ$WG6/Z,64.5/&&:-,;
M%32;(GFJ_(+B#-??1\\PHB;5APS@R<0@'6OX';UZE]"_>?Q+)0)S3;+QQ:I4
MN2V!K^\EAB]&^\;C%KR/P:"A*TS_&J%I]H<F-LW;`X-SH.OKE0A^?[T2T3OL
MO_>5R/\`4$L!`A0`% ````@``+*-*9V3KB,N# ``9$8```@``````````0`@
E`+:!`````$1E;6\N<&%C4$L%!@`````!``$`-@```%0,````````
`
end

"Phil Lewis" <[hidden email]> wrote:

<snip>.....
>I really empathise with Costas, there are too many elements involved (and it
>changed from Dolphin 2. to 4.0, without ANY documentation of the fact) for
>brief overview of one example app (PersonalMoney) to really be enough. Maybe
>I'm just impatient. I think if I spent a good few hours at it (but more than
>10, which is more than two weeks), I could get it. But I want to spend those
>hours developing my app, not figuring out the basics. I only get one hour a
>day to do this stuff, because I work in Java in real life. Please help me
>use Smalltalk. I really, really want to, but I'm really soon going to have
>to throw it away.

Phil,

Thanks for the empathy. I believe the issue is not MVP itself. It is a
good framewark to go by and not just for Smalltalk. I use this concept
when I program with Visual Foxpro for example (well I try, where the
language allows me to).  However the tools provided is where the
weakness lies.

I think for example the MVP framework should be built with the View
Composer. I should even be able to get an inexperienced VB developer
to design it for me. What a great intro to Smalltalk that would be.
After all but what is MVP but a means to visually communicate back and
forth with the user.  

I am sure I am not the first who has thought about a proper MVP tool
but I believe this is where Dolphin really has a weakness (and the
docs as you point out, the never ending docs battle).

However I also believe Dolphin is not far from being a very
competitive development environment with just a small enhancement in
the development tools.

I hope Andy and Blair are listening.

Costas

Costas Menico <[hidden email]> wrote in message
news:[hidden email]...
>...
> I think for example the MVP framework should be built with the View
> Composer. I should even be able to get an inexperienced VB developer
> to design it for me. What a great intro to Smalltalk that would be.
> After all but what is MVP but a means to visually communicate back and
> forth with the user.
>...

I too found MVP a little challenging.  It is not something I could casually
learn.  I had to study it a bit before I began to feel comfortable.  I don't
have enough experience with it yet to feel totally comfortable.  I can make
it to what I want, but I am not sure that I am doing everything the "right"
way.  Maybe I am cheating, but I have not directly used many classes bellow
Model.

I like the power that MVP offers, but it does take some getting used to.
Dolphin UI's tend to require planning, it is not so easy just to experiment.
You need to pick good view names in advance, because they are hard to
change.  I suspect that some of the confusion relates to the level of
separation between the View and the Presenter.  Most of my UI's (so far)
only have one View and  Presenter.  I find myself going back and forth
between my View and Presenter a lot.  If the view composer had more
interaction between the View and the Presenter it might make simple UI's a
bit easier.  Some automated code generation or view code reference pickers
might be handy as well.

I can't be too negative about the MVP implementation in Dolphin.  It does
work, and it is very powerful.  However there may be ways of automating and
simplifying certain aspects of it.

These are some suggestions for new VC features off the top of my head:
1. Better tool box.  I don't want to see a list of every view/presenter in
the system.  Some kind of categorized view would make it much easier to use.
2. Add a "goto code" button for the #command aspect of buttons that would
open a class browser on the method it referenced.
3. A hot key in the method editor that would bring up a selection list of
all named sub views in a Presenter's default view.  Selecting the view in
the list box would insert reference text (ex: (self view viewNamed:
'pickedView')).  IBM VAST has something like this.  This could even be
expanded to select a reference to a sub view's events or attributes (ex:
(self view viewNamed: 'pickedView') when: #selectionChanged send:
#yourMessage to: self.
4. Maybe even a menu item for template method creation for the most common
Presenter methods we override. For example createSchematicWiring would
automatically call super createSchematicWiring, and there would be no typos
in the method names.

That's all I can think of for now.  I am interested in anything that saves
typing and assists in making the different parts of the triad connect
without having to bounce around in separate browsers.

Chris

Costas,
> I want to vent off my frustration with MVP. Why is it so convoluted to
> implement a simple view to display data and get user input?
>
> With MVP it is too much work to put views together unless I do
> everything right. Having to deal with all the intricacies of
> Presenters, Views, Models, AspectAccessors, ValueHolders  and so on is
> frustrating.

It sounds like you're going too deeply into it, and that is what is causing
the confusion. Take the MyClass/MyModel pair in the following package. It
provides a Shell containing a TextEdit and a model containing an instVar
which is displayed in the TextEdit. When you edit the view (and move focus
away from the edit) the instVar is updated. When you programatically change
the instVar then the view reflects the change. I've added two buttons -
"check" just displays the current state of the models instVar and "Set" sets
the instVar to the current time.

I think the above covers you're pathName scenario. The ListView is more
difficult as a SharedQueue is not suitable to be used in a ListModel
(SharedQueue is not even a member of the Collection hierarchy). The
ListPresenter (or rather the ListModel associated with it) has to have some
way of getting at the list of objects it has to display - and SharedQueue
doesn't provide a means of doing that.

The second demo (MyListShell/MyListDemoModel) shows how you can display a
list (an OrderedCollection contained within a ListModel) by sharing the
ListModel between your model and the ListPresenter. When your model updates
the ListModel the ListPresenter automatically reflects the change.

The package is available at the following URL (it's only about 4K)
http://www.iandb.org.uk/~iandb/demo.zip

I've tried to keep them both as simple as possible to show the basic
mechanism involved - any help?

Ian

Because of ISP problems this post may (or may not) appear twice - sorry all.

Christopher,

First of all, I'd like to say that we are aware of a number of  improvements
we can make to the MVP tools to reduce the amount of boilerplate code that
has to be typed. It is our intention to work on these for a forthcoming
release of Dolphin.

In addition to the tools the other seemingly uphill struggle is to get the
MVP concepts across. In order to do this we are rewriting the MVP chapter in
the help documentation and trying to bring the MVP patterns up-to-date.
Hopefully, these documentation improvements should become available fairly
early in the New Year.

As I have mentioned before, we are also intending to release the
documentation as a "paper" manual (well, PDF) which should make it easier to
read through in a linear fashion.

> I too found MVP a little challenging.  It is not something I could
casually
> learn.  I had to study it a bit before I began to feel comfortable.  I
don't
> have enough experience with it yet to feel totally comfortable.  I can
make
> it to what I want, but I am not sure that I am doing everything the
"right"
> way.  Maybe I am cheating, but I have not directly used many classes
bellow
> Model.

It is certainly not necessary to subclass Model when creating your own model
classes. There is only a minor advantage to doing this which occurs because
Model implements its own events collection (see the class comment in Model
for more details).

> These are some suggestions for new VC features off the top of my head:
> 1. Better tool box.  I don't want to see a list of every view/presenter in
> the system.  Some kind of categorized view would make it much easier to
use.

Yes, I couldn't agree more.

> 2. Add a "goto code" button for the #command aspect of buttons that would
> open a class browser on the method it referenced.

Because of the command routing that takes place within the MVP framework it
is not simply a matter of adding a "go to code" button since it is not
immediately obvious where the command should be implemented. However,
something similar to the "Implement in" menu command in the debugger might
well be appropriate. This would give you a choice of implementation
locations along the standard command route where a method could be added.

> 3. A hot key in the method editor that would bring up a selection list of
> all named sub views in a Presenter's default view.  Selecting the view in
> the list box would insert reference text (ex: (self view viewNamed:
> 'pickedView')).  IBM VAST has something like this.  This could even be
> expanded to select a reference to a sub view's events or attributes (ex:
> (self view viewNamed: 'pickedView') when: #selectionChanged send:
> #yourMessage to: self.

Do you use this sort of view reference code a lot? It's not something that I
have found a need for.

> 4. Maybe even a menu item for template method creation for the most common
> Presenter methods we override. For example createSchematicWiring would
> automatically call super createSchematicWiring, and there would be no
typos
> in the method names.

Yes, we've been thinking of several ways to automatically generate the code
for methods such as #createSchematicWiring and #createComponents.

Best Regards,

Andy Bower
Dolphin Support

Phil,

> I've been programming over ten years in C, C++ and Java (oh go on, I'll
even
> admit to VB), but I found, and am still finding, MVP very difficult.
> Smalltalk is hard to read for newcomers, and there is too little
> documentation with Dolphin, way too litlle.
>
> When I started with Dolphin, I was dead impredded (and even bought the
> commercial version), but as soon as I wanted to put a GUI on my app, I
just
> lost steam, and now I'm drifing away.
>
> OK, so I did the application three times quicker in St than I could in
Java,
> but I could build the Java GUI in an afternoon, an two weeks in with
> Dolphin, I still can't figure it all out.

As I mentioned in another reply in this thread, we are currently working on
improved documentation for MVP. The difficulty, of course, is understanding
where beginners have problems when the author is no longer a beginner
himself. Hence I'd like to use this forum for a question and answer session
on MVP to get an idea where the sticking points are. Apart from helping
people out right now, we can then look back over the messages and
incorporate the relevant information in the new documents.

Anyway, to this end, I'm going to start a new thread, "MVP Night School" and
we can go from there.

Best Regards,

Andy Bower
Dolphin Support

Hi Andy,

Like I said in another post to you under my other guise as
[hidden email], I wish I got this level of service from all my
software suppliers!

I've tried to be as positive as possible in my comments here, because
Dolphin is a brilliant product, and because you make such a great effort to
help out. If I keep going on about things, please always remember regardless
of how the tone may sound in email, I am appreciative, and eager to learn.

OK.

So what is hard for beginners.

What I haven't managed to find is a description of the responsibilities of
the classes involved in MVP, and some explaination of why messages are
called when and where they are, and what messages should be called in which
situations. Maybe I will in your reading list (though I get an error opening
the 'twisting the triad' pdf).

For example, remember my summary thing with a scrollbar, and the textbox was
not updating when I moved from 2.1 to 4.0? And you sorted that out.

Well, the summary is a simple string property of my model class. I have
since added an integer property, and as far as I can see, I have done
exactly the same code for this as I have for the string, but the view of the
integer does not update in the UI. This can only possibly be happening
because there is something different between what I did for one and the
other. But I can't find the difference. That implies that I don't know where
to look, which implies I don't understand something. Sadly, I don't even
know what it is that I don't understand.

I have tried to trace the code (in the debugger) when making a change to a
view, to see how the model is updated, but I can never get anywhere, I seem
to get lost in all kinds of weird locks and semaphores.

And I can't figure out what this thing is with triggersEvent (or is it
eventTriggersUpdate?). You seem to have to pass a message name, but where is
the method that responds to that message implemented? I had it in my
presenter class, but I noticed it was never called. I deleted it, and it
still worked. Now (I'm not at the right computer, so I can't be precise), it
looks to me like I'm raising an event that has nothing to capture it, but
somehow the event is being handled! Is this some reflection trick? does this
mean I have to be careful how I name accessors and events (could this be why
my integer is not updating...I'll go and try that one!).

Going further, once I suss the basics, and feel as happy with this as I do
the, say, Swing, I'd like to know a few tricks. Eg, I have a need to
dynamically add widgets (views?) at run time. Ideally, I'd like to be able
to drag widgets around a shell. At the moment, i couldn't begin to do either
of these things because I don't understand views or mouse events.

As I said, I don't want to sound like I'm whining. I won't really chuck
Dolphin in, but I might end up using it for just prototyping in a workspace
(hope not, I bought the pro version today, for the web deployment and exe
maker).

I will work hard in your night school, but as a techy in real life, I work
10-12 hours a day 5 days a week, then ~4 hours a day at weekend doing stuff
I need for the day job, so an hour a day is my max for Smalltalk.

Thanks for all the effort you are exerting in helping us get the most out of
Dolphin. I'm still here trying for the single reason that I love the product
so much (and I tried quite a few before choosing Dolphin).

Phil



"Andy Bower" <[hidden email]> wrote in message
news:91ajet$3bc5e$[hidden email]... on
> improved documentation for MVP. The difficulty, of course, is
understanding
> where beginners have problems when the author is no longer a beginner
> himself. Hence I'd like to use this forum for a question and answer
session
> on MVP to get an idea where the sticking points are. Apart from helping
> people out right now, we can then look back over the messages and
> incorporate the relevant information in the new documents.
>
> Anyway, to this end, I'm going to start a new thread, "MVP Night School"
and
> we can go from there.
>
> Best Regards,
>
> Andy Bower
> Dolphin Support
>
>

Phil,

> And I can't figure out what this thing is with triggersEvent (or is it
> eventTriggersUpdate?). You seem to have to pass a message name, but where
is
> the method that responds to that message implemented? I had it in my
> presenter class, but I noticed it was never called. I deleted it, and it
> still worked. Now (I'm not at the right computer, so I can't be precise),
it
> looks to me like I'm raising an event that has nothing to capture it, but
> somehow the event is being handled! Is this some reflection trick? does
this
> mean I have to be careful how I name accessors and events (could this be
why
> my integer is not updating...I'll go and try that one!).

Say you add this line to the #model: method in your Shell

aViewMVP model: ((aModel aspectValue: #fred) aspectTriggers: #fredChanged)

You are telling the ValueAspectAdaptor answered by "(aModel aspectValue:
#fred)" that when aModel changes the fred value programmatically, i.e. the
model's instVar is changed, then it will also trigger a #fredChanged event
(you have to add the code to trigger this event yourself in your model's
accessor)

The ValueAspectAdaptors response to the #aspectTriggers: message is to
register itself as a receiver for the #fredChanged event so that whenever
the model changes fred then the VAA will know.(see
ValueAspectAdaptor>>aspectTriggers)

When the VAA is informed that this event has occurred it then itself
triggers a #valueChanged event. (see the previous method and it's target,
ValueModel>>notifyChanged)

Any other MVP triad that has the VAA as it's model (don't forget that the
above code set aViewMVP's model) will respond to a #valueChanged event from
the VAA by updating it's view (see ValueConvertingControlView>>connectModel
which is evaluated as a result of sending #model: to aViewMVP in the above
code)

The reason for the extra step is that your model could have any number of
instanceVariables that need to notify somebody that they have changed. If
they all just triggered a #valueChanged event then it would get confusing to
say the least.

The change between Dolphin 2/3 and Dolphin 4 was that the name of the event
that was triggered in the earlier versions was fixed, 'Changed' was appended
 to the aspect's name to create the event name. In D4 you can now select the
name yourself via #aspectTriggers. #aspectTriggersUpdates was used in D2 for
a different, albeit related, purpose - to prevent an automatic update (via
#xxxChanged) being performed if the aspect already triggered it's own update
event.

So (omitting all unrelated code)

MyModel>>fred: aValue
    fred := aValue.
    self trigger: #fredChanged

MyShell>>createComponents
    fredPresenter := self add: NumberPresenter new name: 'fred'

MyShell>>model: aMyModel
    fredPresenter model: ((aMyModel aspectValue: #fred) aspectTriggers:
#fredChanged)

Any help?
Ian

"Phil Lewis" <[hidden email]> wrote:

I had the same problem. Upgrade  to the new acrobat reader to take
care of it.

Costas

>As I mentioned in another reply in this thread, we are currently working on
>improved documentation for MVP. The difficulty, of course, is understanding
>where beginners have problems when the author is no longer a beginner
>himself. Hence I'd like to use this forum for a question and answer session
>on MVP to get an idea where the sticking points are. Apart from helping
>people out right now, we can then look back over the messages and
>incorporate the relevant information in the new documents.
>

Ian had sent me a sample demo that was so simple it finally made
sense.

The tough part I had was understanding how to setup the model to talk
to the presenter. I guess just the name "model" was enough to confuse
me. Maybe it should be called "data model".  

The fact remains that there are too many ways to do the same thing and
I just want to know the right way.

I think what is needed is a basic framework that tells beginners of
MVP the exact steps of displaying/updating data of any object variable
in a simple and concise mannaer. There should be strict naming rules
to follow for all possibilites on a view.  There should be strict
placement of methods. This way we can all speak the same language and
stray when we are comfortable.

Costas

Andy,

> As I mentioned in another reply in this thread, we are currently working
on
> improved documentation for MVP. The difficulty, of course, is
understanding
> where beginners have problems when the author is no longer a beginner
> himself.

Some time ago I wrote a very long post trying to describe the difficulties
I'd had learning MVP.  I don't know if you remember it, but it might be
worth your while looking it over again.  See my post of 23rd March 99 (in
the "MVP framework reference material" thread).  It's in Ian's archive.

It took me a whole day to write, so I'd like to think you were getting some
value from it ;-)

    -- chris

Andy Bower <[hidden email]> wrote in message
news:91agc1$3jaj5$[hidden email]...
>
> > 2. Add a "goto code" button for the #command aspect of buttons that
would
> > open a class browser on the method it referenced.
>
> Because of the command routing that takes place within the MVP framework
it
> is not simply a matter of adding a "go to code" button since it is not
> immediately obvious where the command should be implemented. However,
> something similar to the "Implement in" menu command in the debugger might
> well be appropriate. This would give you a choice of implementation
> locations along the standard command route where a method could be added.

This sounds good.  Especially since I thought commands were simply
implemented in the presenter.  This feature would demonstrate where else
they could be.

> > 3. A hot key in the method editor that would bring up a selection list
of
> > all named sub views in a Presenter's default view.  Selecting the view
in\
>
> Do you use this sort of view reference code a lot? It's not something that
I
> have found a need for.

I do use it (self view viewNamed: 'blah') quite a bit.  Maybe I should not
be. ;)  I don't create instance variables for my sub views or presenters.  I
don't mess with presenters unless I need them.  I tend to just stick text in
a text box views and pull it out again.  I used to use the Actor programming
language, and it used windows resource dialogs with getItemText, and
setItemText, etc...  I guess I am just doing the same kind of thing with
Dolphin.  It looks like I need to hit the MVP books some more. ;)

> > 4. Maybe even a menu item for template method creation for the most
common
>
> Yes, we've been thinking of several ways to automatically generate the
code
> for methods such as #createSchematicWiring and #createComponents.

It sounds like there will be some pretty good GUI builder improvements
coming in future versions of Dolphin.  Dolphin is a great system, and it
just keeps getting better.

Chris