ColorEditor updated
Locked
12
12
 
|
Hi all,
I updated Morphic-ColorEditor for simpler layout and font preferences updating. I also updated Morphic-Misc1 for font preferences update. Dan, note that the Morphic-ColorEditor uses #when:send:to: for updates. You can file it in and check senders. Bugs to /dev/null, er, I mean to me. ;^) Cheers, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
On 29 Oct 2015 at 16:56, KenD wrote:
> Hi all,
>
> I updated Morphic-ColorEditor for simpler layout and font
> preferences updating.
>
> I also updated Morphic-Misc1 for font preferences update.
>
> Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> updates. You can file it in and check senders.
>
I've done that and I see that messages to SystemChangeNotifier are not required in order to
use the method.
Also, the dependency mechanism itself uses
#when:send:to:.
Any object can use
#when:send:to: because it is an Object instance method.
So, should this be named a different mechanism or is it just a different use of the
dependency mechanism?
If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#FeatureComparison
- Dan
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Sat, 31 Oct 2015 22:01:06 -0400
"Dan Norton" <[hidden email]> wrote: > On 29 Oct 2015 at 16:56, KenD wrote: .. > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for > > updates. You can file it in and check senders. .. > I've done that and I see that messages to SystemChangeNotifier are not required in order to use the method. > > Also, the dependency mechanism itself uses #when:send:to:. > > Any object can use #when:send:to: because it is an Object instance method. > > So, should this be named a different mechanism or is it just a different use of the > dependency mechanism? > > If it's a different mechanism, is "Signals" the right name? This by Marcel Taeumel: > > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/signals#Featu > reComparison Hi Dan. I took a look at the Signals implementation some time ago and my recollection is that I found the implementation to be complex and less useful than I had hoped. For my limited uses, I prefer #when:send:to: Simplicity wins. In the longer term I hope somebody gets a chance to rewrite the older #changed: code to use the #when:send:to: mechanism so that we can remove #changed: . I agree that having two update mechanisms is one too many. Adding a third dependency update, Signals, would be going in the wrong direction IMHO. $0.02 -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
|
Hi Ken,
Comments in line.
On 1 Nov 2015 at 20:52, KenD wrote:
> On Sat, 31 Oct 2015 22:01:06 -0400
> "Dan Norton" <[hidden email]> wrote:
>
> > On 29 Oct 2015 at 16:56, KenD wrote:
> ..
> > > Dan, note that the Morphic-ColorEditor uses #when:send:to: for
> > > updates. You can file it in and check senders.
> ..
> > I've done that and I see that messages to SystemChangeNotifier are
> not required in order to use the method.
> >
> > Also, the dependency mechanism itself uses #when:send:to:.
> >
> > Any object can use #when:send:to: because it is an Object
> instance method.
> >
> > So, should this be named a different mechanism or is it just a
> different use of the
> > dependency mechanism?
> >
> > If it's a different mechanism, is "Signals" the right name? This
> by Marcel Taeumel:
> >
> >
> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjec
> ts/wiki/signals#Featu
> > reComparison
>
> Hi Dan.
>
> I took a look at the Signals implementation some time ago and my
> recollection is that I found the implementation to be complex and
> less useful than I had hoped.
>
> For my limited uses, I prefer #when:send:to:
>
> Simplicity wins.
+1
In the longer term I hope somebody gets a chance
> to rewrite the older #changed: code to use the #when:send:to:
> mechanism so that we can remove #changed: .
>
> I agree that having two update mechanisms is one too many. Adding a
> third dependency update, Signals, would be going in the wrong
> direction IMHO.
>
That's fine. I was casting about for some name besides "
#when:send:to: mechanism" for
use in a brief essay on PluggableListMorph Principles of Operation when I came across
Signals. I already wrote a paragraph on Dependency Mechanism.
So, the simple principle here is to just use
#when:send:to: and forget about or maybe
deprecate #changed: and #update:? The advantage IIUC is
#when:send:to:
can be sent by any object,
the receiver can be any object,
the to: parameter can be any object, and
the send: parameter doesn't necessarily have to exist because WeakMessageSend
is used!
What a deal :).
However, I see a problem common to dependency and
#when:send:to: which is the
identification and explanation of the various symbols which are communicated as the
parameters for
send: or changed: . When you're trying to design a model or view similar to
something already in existence, the tools are not much help with that.
I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant>
Would appreciate any thoughts.
- Dan
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On Mon, 02 Nov 2015 15:58:26 -0500
"Dan Norton" <[hidden email]> wrote: >.. I was casting about for some name besides " #when:send:to: mechanism" for > use in a brief essay on PluggableListMorph Principles of Operation when I came across > Signals. I already wrote a paragraph on Dependency Mechanism. I would talk about #when:send:to: as implementing the Observer Pattern. > So, the simple principle here is to just use #when:send:to: and forget about or maybe > deprecate #changed: and #update:? Yes. Let us work to eliminate #changed: ! > However, I see a problem common to dependency and #when:send:to: which is the > identification and explanation of the various symbols which are communicated as the > parameters for send: or changed: . When you're trying to design a model or view similar to > something already in existence, the tools are not much help with that. > > I'm thinking maybe: document in comments? <rant>Nah. We don't do comments.</rant> We should certainly add clarifying comments! Your Comment Browser is a big help here. Once people start using it more, comments will appear. I suggest sending Juan a code update with an added "Open Comment Browser" Help menu item which autoloads the same way as TerseGuide. However, class comments are not usually where design patterns show up. 8^| In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes. What constitutes good style? What code patterns help? Think "Useful Code Patterns" to augment "Useful Expressions". You can do your own example, but looking at the ColorEditor: ColorEditor>>buildMorphicWindow "Create a useful ColorEditor window" self layoutMorph beRow; " A row of columns" separation: 6; addMorph: self buildColorPaneColumn; addMorph: self buildSliderColumn; addMorph: self buildRadioButtonColumn; color: self backgroundColor. self model when: #colorChanged send: #refreshColor to: self. ^ self So trying for good style (hey, I need to improve here too!) one uses: [Class]>buildMorphicWindow [Add (construct each pane).. to layout] [Add self or panes as observers] ^ self Suggest Smalltalk browseAllImplementorsOf: #buildMorphicWindow to see specific usage examples. Of course, we will suffer some embarrassment as our real code is less than ideal. 8^( But this is a great motivator to making our code better! ;^) $0.02 -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
On 11/3/15, KenD <[hidden email]> wrote:
> On Mon, 02 Nov 2015 15:58:26 -0500 > "Dan Norton" <[hidden email]> wrote: > >>.. I was casting about for some name besides " #when:send:to: mechanism" >> for >> use in a brief essay on PluggableListMorph Principles of Operation when I >> came across >> Signals. I already wrote a paragraph on Dependency Mechanism. > > I would talk about #when:send:to: as implementing the Observer Pattern. > >> So, the simple principle here is to just use #when:send:to: and forget >> about or maybe >> deprecate #changed: and #update:? > > Yes. Let us work to eliminate #changed: ! > >> However, I see a problem common to dependency and #when:send:to: which is >> the >> identification and explanation of the various symbols which are >> communicated as the >> parameters for send: or changed: . When you're trying to design a model or >> view similar to >> something already in existence, the tools are not much help with that. >> >> I'm thinking maybe: document in comments? <rant>Nah. We don't do >> comments.</rant> > > We should certainly add clarifying comments! > > Your Comment Browser is a big help here. Once people start using it more, > comments will appear. > > I suggest sending Juan a code update with an added "Open Comment Browser" > Help menu item which autoloads the same way as TerseGuide. > > However, class comments are not usually where design patterns show up. 8^| > > In the case of #when:send:to: I suggest a slightly larger discussion around > building paned windows which update dependent panes. > > What constitutes good style? What code patterns help? > > Think "Useful Code Patterns" to augment "Useful Expressions". +1 > You can do your own example, but looking at the ColorEditor: > > ColorEditor>>buildMorphicWindow > "Create a useful ColorEditor window" > > self layoutMorph beRow; " A row of columns" > separation: 6; > addMorph: self buildColorPaneColumn; > addMorph: self buildSliderColumn; > addMorph: self buildRadioButtonColumn; > color: self backgroundColor. > > self model when: #colorChanged send: #refreshColor to: self. > > ^ self > > So trying for good style (hey, I need to improve here too!) one uses: > > [Class]>buildMorphicWindow > [Add (construct each pane).. to layout] > [Add self or panes as observers] > ^ self > > Suggest > Smalltalk browseAllImplementorsOf: #buildMorphicWindow > to see specific usage examples. > > Of course, we will suffer some embarrassment as our real code is less than > ideal. 8^( > > But this is a great motivator to making our code better! ;^) > > > $0.02 > -KenD > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by KenDickey
Ran across this comment for ActiveModel and thought it was interesting, historically.
Part of update 5005u16-Events.cs: "Change Set: Events Date: 11 February 2002 Author: Rob Withers et al. Published to 3.3a as 4756Events.cs The NuBlue events code. Finally..." The new event model, originally from VisualSmalltalk. This includes #when:send:to: and friends, in Object (generic implementation) and ActiveModel (optimized implementation). It renders the old change/update mechanism in Object and Model as obsolete, although still used. - Dan On 2 Nov 2015 at 15:27, KenD wrote: > On Mon, 02 Nov 2015 15:58:26 -0500 > "Dan Norton" <[hidden email]> wrote: > > >.. I was casting about for some name besides " #when:send:to: > mechanism" for > > use in a brief essay on PluggableListMorph Principles of Operation > when I came across > > Signals. I already wrote a paragraph on Dependency Mechanism. > > I would talk about #when:send:to: as implementing the Observer > Pattern. > > > So, the simple principle here is to just use #when:send:to: and > forget about or maybe > > deprecate #changed: and #update:? > > Yes. Let us work to eliminate #changed: ! > > > However, I see a problem common to dependency and #when:send:to: > which is the > > identification and explanation of the various symbols which are > communicated as the > > parameters for send: or changed: . When you're trying to design a > model or view similar to > > something already in existence, the tools are not much help with > that. > > > > I'm thinking maybe: document in comments? <rant>Nah. We don't do > comments.</rant> > > We should certainly add clarifying comments! > > Your Comment Browser is a big help here. Once people start using it > more, comments will appear. > > I suggest sending Juan a code update with an added "Open Comment > Browser" Help menu item which autoloads the same way as > TerseGuide. > > > However, class comments are not usually where design patterns show > up. 8^| > > In the case of #when:send:to: I suggest a slightly larger discussion > around building paned windows which update dependent panes. > > What constitutes good style? What code patterns help? > > Think "Useful Code Patterns" to augment "Useful Expressions". > > You can do your own example, but looking at the ColorEditor: > > ColorEditor>>buildMorphicWindow > "Create a useful ColorEditor window" > > self layoutMorph beRow; " A row of columns" > separation: 6; > addMorph: self buildColorPaneColumn; > addMorph: self buildSliderColumn; > addMorph: self buildRadioButtonColumn; > color: self backgroundColor. > > self model when: #colorChanged send: #refreshColor to: self. > > ^ self > > So trying for good style (hey, I need to improve here too!) one > uses: > > [Class]>buildMorphicWindow > [Add (construct each pane).. to layout] > [Add self or panes as observers] > ^ self > > Suggest > Smalltalk browseAllImplementorsOf: #buildMorphicWindow > to see specific usage examples. > > Of course, we will suffer some embarrassment as our real code is > less than ideal. 8^( > > But this is a great motivator to making our code better! ;^) > > > $0.02 > -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Dan Norton
(inline)
On 11/2/2015 5:58 PM, Dan Norton wrote:
Well, doing senders on any symbol (method selectors, but also event names) shows all references to it. I don't think it is that bad, but, do you have ideas for improvements on this?
Let me disagree. Cuis includes 204019 characters in class comments. That would be like 2000 to 4000 lines, right? For a system with less than 100kLOC. Top 10 classes with extensive class comments are: BitBlt SmartRefStream Float ClosureScanner Color ContentPack Monitor AndreasSystemProfiler EventSensor ReferenceStream. Just check them. Several of these are rather recent, some were written specifically for Cuis. We also have 27058 bytes of comments at the top of methods. Some methods with great comments are #vmParameterAt: #entriesIn: #eliotsClosureMeasurements2On: #getCurrentWorkingDirectory #whatIsAPrimitive #asUtf8: #howToModifyPrimitives #applySimpleGamma:to: #linearTosRGBGamma: #localMicrosecondClock #findBinaryIndex:do:ifNone: #findBinary:do:ifNone: #spyAllOn: , etc. There is a lot to be learnt about the system from reading comments. And we want to improve. (BTW, querying the system to find this out took me less time than writing this email)
I think that both comments and tools are useful and should be enhanced. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by KenDickey
Hi Ken,
On 11/2/2015 8:27 PM, KenD wrote: > ... > > However, class comments are not usually where design patterns show up. 8^| > > In the case of #when:send:to: I suggest a slightly larger discussion around building paned windows which update dependent panes. > > What constitutes good style? What code patterns help? > > Think "Useful Code Patterns" to augment "Useful Expressions". In 2009 I wrote http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgramming.txt and http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.txt . I've had the idea of making all the GUI code in Cuis follow this style. But time is always short... Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On 6 Nov 2015 at 15:28, Juan Vuletich wrote Re: [Cuis] ColorEditor updated:
> Hi Ken,
>
> On 11/2/2015 8:27 PM, KenD wrote:
> > ...
> >
> > However, class comments are not usually where design patterns show
> up. 8^|
> >
> > In the case of #when:send:to: I suggest a slightly larger
> discussion around building paned windows which update dependent
> panes.
> >
> > What constitutes good style? What code patterns help?
> >
> > Think "Useful Code Patterns" to augment "Useful Expressions".
>
> In 2009 I wrote
> http://www.jvuletich.org/LightWidgets/AnExampleOfLightWidgetsProgram
> ming.txt
> and
> http://www.jvuletich.org/LightWidgets/ProgrammingWithLightWidgets.tx
> t .
> I've had the idea of making all the GUI code in Cuis follow this
> style.
> But time is always short...
>
As one who benefits greatly from studying other people's code ;-) I favor copy and paste over
reading prose. The most useful "Useful Code Patterns" would be something in a code
window like "Useful Expressions" IMO. But where UE is code line oriented, it needs to be
class and method orented. It would be heavily commented as to what is on a line, or in a
method, and why, because this is a big problem with Smalltalk in many cases. Once pasted,
the comments would be customized or removed.
I started a package with a model and a view, trying to be minimalist about getting them to
simply put up a window without bringing up the debugger. There are lots of comments.
Please take a look and give me yours.
https://github.com/dhnorton/Cuis-Smalltalk-patterns
It tries to be the most efficient, direct, and simple pattern for opening a view on a model in
Cuis. It's deliberately not glitzy. Glitz is added by the user. Next, I plan to incorporate
#when:send:to: fundamentals.
- Dan
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Excelent, this exampe has exactly what I wanted yesterday. Models should implement #open for instance creation. Also, all the different ways we are currently using to open windows should be cleaned up and unified... but I'll be happy with #open in every model at least (and always returning the window). Also Smalltalk|save, saveAs, quit. I don't use menues much, I rather doIt ;) Luciano On Mon, Nov 16, 2015 at 10:30 PM, Dan Norton <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Dan Norton
Hi Dan,
On 16/11/2015 07:30 p.m., Dan Norton wrote:
Ok, it is a good idea.
Well, I don't like the #open method in the model. The idea of View / Model separation is that views know about models, but models don't know about views. A Model should exist independently of being used from Morphic, MVC, Seaside, or any other UI framework. It could live, for example, in a Gemstone database with no UI at all. Or ir could travel to and from other systems, like VA Smalltalk, where the UI framework is completely different from Cuis'. I think it is better for the View to start it all. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
2015-11-16 22:06 GMT-03:00 Juan Vuletich <[hidden email]>:
Interesting, really I never heard of the use of #open at the model or I do not remember it at all, but I think similar to Juan.
+1 _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Le 17/11/2015 02:47, Germán Arduino a écrit :
> > > 2015-11-16 22:06 GMT-03:00 Juan Vuletich <[hidden email] > <mailto:[hidden email]>>: > > __ > > Well, I don't like the #open method in the model. The idea of View / > Model separation is that views know about models, but models don't > know about views. A Model should exist independently of being used > from Morphic, MVC, Seaside, or any other UI framework. It could > live, for example, in a Gemstone database with no UI at all. Or ir > could travel to and from other systems, like VA Smalltalk, where the > UI framework is completely different from Cuis'. > > > Interesting, really I never heard of the use of #open at the model or I > do not remember it at all, but I think similar to Juan. Hum, #open has to go somewhere, so... Either it goes into a sort of Application Model, which regroup the duties associated with the application (the view + model + whatever is necessary in environment X), or it goes into an Application View which then has model concerns in it (it knows how to start or connect to the model, it knows what the model is composed of to connect subviews to model elements, etc...). > I think it is better for the View to start it all. > > > +1 I prefer to model an Application concept in the target desktop environment if I want to model highly portable stuff. That application concern can be folded into a dedicated view if that is the preferred convention in the target environment. Regards, Thierry > > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Hi Thierry,
On 11/17/2015 1:42 AM, Thierry Goubier wrote: > Le 17/11/2015 02:47, Germán Arduino a écrit : >> >> >> 2015-11-16 22:06 GMT-03:00 Juan Vuletich <[hidden email] >> <mailto:[hidden email]>>: >> >> __ >> >> Well, I don't like the #open method in the model. The idea of View / >> Model separation is that views know about models, but models don't >> know about views. A Model should exist independently of being used >> from Morphic, MVC, Seaside, or any other UI framework. It could >> live, for example, in a Gemstone database with no UI at all. Or ir >> could travel to and from other systems, like VA Smalltalk, where the >> UI framework is completely different from Cuis'. >> >> >> Interesting, really I never heard of the use of #open at the model or I >> do not remember it at all, but I think similar to Juan. > > Hum, #open has to go somewhere, so... > > Either it goes into a sort of Application Model, which regroup the > duties associated with the application (the view + model + whatever is > necessary in environment X), or it goes into an Application View which > then has model concerns in it (it knows how to start or connect to the > model, it knows what the model is composed of to connect subviews to > model elements, etc...). > The idea of view / model separation is pretty well explained in "Inside Smalltalk Vol II" 1.3 to 1.3.4, pages 7 to 11. I agree that an Application object or such might make sense when you are building an application, especially if you need to deal with en external environment. But here we were talking about whether the Model classes should know about Morphs or not. >> I think it is better for the View to start it all. >> >> >> +1 > > I prefer to model an Application concept in the target desktop > environment if I want to model highly portable stuff. > > That application concern can be folded into a dedicated view if that > is the preferred convention in the target environment. > > Regards, > > Thierry I wonder how would this result in practice. Do you have some examples to share? Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
2015-11-17 15:00 GMT+01:00 Juan Vuletich <[hidden email]>: Hi Thierry, Sadly, that view / model separation encounters pragmatic issues when dealing with things more complex than standard widgets, such as your typical domain drawing editor. This is the fundamental reason for me to consider that Morphic departed from that model, and that the pinacle of that M / V separation is the M2VC of VisualWorks. Newer models in the literature around those years such as PAC proposed better abstractions, but they were never implemented. Now, it's interesting to see you advocate that model on top of Morphic.
In theory, no. In practice, if you want a well tuned gui, I consider that yes, they need to be aware of them. So the most elegant way I've used is the two models: a pure, abstract model, totally view independent. And a pragmatic, closer to the view / aware of the view, application model as an mediator.
I have a complex example, a system browser, would that fit? Regards, Thierry _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
On 11/17/2015 11:32 AM, Thierry Goubier wrote:
This is the first time I hear this. Can you elaborate or provide references? I worked on several mid-size to large projects that did strict view / model separation, and I never saw "pragmatic issues" (that couldn't be solved by a good design).
PluggableMorphs attempted to follow this model (and give model compatibility between Morphic and MVC). Etoys (if I remember correctly) do the same, only that calling the model a "Player" and the view a "Costume". Later, people forgot about view / model separation, and Squeak became legacy software, in part because of that.
Please elaborate, or provide references.
Sure.
Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Hi Juan,
2015-11-17 16:16 GMT+01:00 Juan Vuletich <[hidden email]>:
I would give HotDraw, and some of the original design pattern work on editors, especially the parts derived from the InterViews toolkit. Now, I used to be pretty up to date on the literature and some of the criticism of the MVC model (especially the division between V and C) but my memory of that time is all fuzzy.
Maybe. I'm not sure of that particular factor. I have the feeling that there is no clear and honest analysis on the state of GUI toolkits in that universe, for present and future ones.
What would you think of a drag and drop feedback which is dependent of the type of the model elements?
Well, a short estimate on that particular application is that, linked with the pluggable morphs, 10 to 20% of the code in the application model is: - widget creation, setup, layout - dynamic morph addition / removal when activating certain functions on the model - workarounds the pluggable morphs api to: - dynamically refresh parts of the inside of widgets - disconnect then reconnect links between widgets so that the model-triggered update of one does not change the state of the other one (i.e. protect the model from unwanted view triggered updates when the model is changing part of its contents). This application model uses mainly two widgets. I do have a long term plan to port that to Cuis, and I expect I will have to write that very same code somewhere (maybe more, maybe less). Regards, Thierry
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Hi Thierry,
On 11/17/2015 1:51 PM, Thierry Goubier wrote:
Uh, it is not easy to find stuff about that, so I can't really comment.
Well, in my opinion View / Model separation is a great property of the design of an application. Controller is more of a requirement of the ST-80 MVC framework. In principle, I see no problem in merging Controller into View. But, in Cuis, it can be argued that the Editor hierarchy is essentially a hierarchy of Controllers, and that's ok if the decomposition of responsibilities makes sense. In View / Model separation there are two restrictions that need to be honored: - The Model doesn't know about the possible Views. This means, for instance, that it could provide all its services, and exercise all its functionality, even if the GUI framework is completely absent. Model code should never fail because of this. This is great for moving models from and two different runtimes (client, server, gemstone, various dialects, etc) and also for writing tests. - Model behavior should not leak into Views. This means that if the views are removed (maybe to be replaced by some others, in the same or in another framework), Model should not lose state nor behavior. Model must be complete by itself. So, the idea is essentially to protect the integrity and consistency of Models.
Well, lets assume a Model with 2 collections of elements. To make it sound a bit more concrete, lets call them Orders and Assets. And lets assume that the UI has some place(s) from where the user can drag many kinds of objects, like Orders, Assets, between others. Now, the user drags an Asset and wants to drop it into the Orders list. Given that the widget for the Orders list supports dropping, lets assume that its 'dropActionSelector' is #addOrder:. This #addOrder: model method would be called with an Asset. So, #addOrder: could answer false, to let sender know that the addition was rejected (because it was not an Order!). It makes sense to have the method in ListWidget that calls 'dropSelector' check for the result, and if it is false, let the user know that the drop was rejected, for instance, by keeping the dragged object in the hand.
"View model" is a bit a misleading name. I'd say all this belongs in the Views world. Besides, the method called to update Views after Model changes should not modify the Model. In this way, there would be no extra Model events triggered, and spurious updates would not occur. This might require enhancing the Views framework, if not mature enough.
Hopefully, it will be less :) Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Hi Juan,
Le 17/11/2015 18:36, Juan Vuletich a écrit : > Hi Thierry, > >> >> >> I would give HotDraw, and some of the original design pattern work on >> editors, especially the parts derived from the InterViews toolkit. > > Uh, it is not easy to find stuff about that, so I can't really comment. InterViews was kept alive as the ivtools for long, very long after InterViews lost to Motif as the X Window toolkit. Fresco, InterViews successor, was also very interesting. HotDraw is old as well. But I did some cool stuff with it (a hypermedia system, in 1993). >> Now, I used to be pretty up to date on the literature and some of the >> criticism of the MVC model (especially the division between V and C) >> but my memory of that time is all fuzzy. > > Well, in my opinion View / Model separation is a great property of the > design of an application. Controller is more of a requirement of the > ST-80 MVC framework. In principle, I see no problem in merging > Controller into View. But, in Cuis, it can be argued that the Editor > hierarchy is essentially a hierarchy of Controllers, and that's ok if > the decomposition of responsibilities makes sense. > > In View / Model separation there are two restrictions that need to be > honored: > - The Model doesn't know about the possible Views. This means, for > instance, that it could provide all its services, and exercise all its > functionality, even if the GUI framework is completely absent. Model > code should never fail because of this. This is great for moving models > from and two different runtimes (client, server, gemstone, various > dialects, etc) and also for writing tests. > - Model behavior should not leak into Views. This means that if the > views are removed (maybe to be replaced by some others, in the same or > in another framework), Model should not lose state nor behavior. Model > must be complete by itself. > So, the idea is essentially to protect the integrity and consistency of > Models. I do agree with that objective, but, in practice, what I find as a result is that an additional layer (model mediation or the M2 of MMVC) helps immensely by: - regrouping certain model features which are introduced to satisfy view requirements... - For example a pure model can just have a copy or save to file operation, but a view would like to have a feedback on the length of the operation. In non gui mode, having the model expose that sort of information is a needless waste of code and resources. This would better be carried by a layer on top (which is still a model IMHO, since it maintain a certain level of decoupling with a view). - Expose explicitely certain adaptations which are made for a specific toolkit (they are in that model). - Allow for user-features oriented models to appear on top of the pure, abstract model - In a browser, one can imagine scoped models of the code as a user-oriented feature that a disconnected mode doesn't need to integrate. Nothing really grandiose or earth-shattering, mind you. Just convenient. >> What would you think of a drag and drop feedback which is dependent of >> the type of the model elements? > > Well, lets assume a Model with 2 collections of elements. To make it > sound a bit more concrete, lets call them Orders and Assets. And lets > assume that the UI has some place(s) from where the user can drag many > kinds of objects, like Orders, Assets, between others. Now, the user > drags an Asset and wants to drop it into the Orders list. Given that the > widget for the Orders list supports dropping, lets assume that its > 'dropActionSelector' is #addOrder:. This #addOrder: model method would > be called with an Asset. So, #addOrder: could answer false, to let > sender know that the addition was rejected (because it was not an > Order!). It makes sense to have the method in ListWidget that calls > 'dropSelector' check for the result, and if it is false, let the user > know that the drop was rejected, for instance, by keeping the dragged > object in the hand. Hum, I was more thinking of what I am dealing with at the moment, which is a drop in the Orders list is a drop on a specific order item, which has to tell: - during the drag, if a drop would be honored - after the drop, if it is accepted or rejected - and, if accepted, that specific order item changes state and is shown as such (and may also change the number of order items, etc...) I found, when doing that, to have an intermediate model on top of my Asset/Order object to mediate with the drag and drop API very usefull (that is, what is displayed and dragged are Views on AssetModels which are themselves observers of Assets). > >> >> >>> So the most elegant way I've used is the two models: a pure, >>> abstract model, totally view independent. And a pragmatic, closer >>> to the view / aware of the view, application model as an mediator. >>> >>> >>> >>> I think it is better for the View to start it all. >>> >>> >>> +1 >>> >>> >>> I prefer to model an Application concept in the target >>> desktop environment if I want to model highly portable stuff. >>> >>> That application concern can be folded into a dedicated >>> view if that is the preferred convention in the target >>> environment. >>> >>> Regards, >>> >>> Thierry >>> >>> >>> I wonder how would this result in practice. Do you have some >>> examples to share? >>> >>> >>> I have a complex example, a system browser, would that fit? >> >> Sure. >> >> >> Well, a short estimate on that particular application is that, linked >> with the pluggable morphs, 10 to 20% of the code in the application >> model is: >> - widget creation, setup, layout >> - dynamic morph addition / removal when activating certain functions >> on the model >> - workarounds the pluggable morphs api to: >> - dynamically refresh parts of the inside of widgets >> - disconnect then reconnect links between widgets so that the >> model-triggered update of one does not change the state of the other >> one (i.e. protect the model from unwanted view triggered updates when >> the model is changing part of its contents). > > "View model" is a bit a misleading name. I'd say all this belongs in the > Views world. As I said, it may be moved into the View world, in the sense that it holds view-related concerns. But, at the same time, it has Model like decoupling from the Views. > Besides, the method called to update Views after Model changes should > not modify the Model. In this way, there would be no extra Model events > triggered, and spurious updates would not occur. This might require > enhancing the Views framework, if not mature enough. I'll let you have a try at that :) >> >> This application model uses mainly two widgets. >> >> I do have a long term plan to port that to Cuis, and I expect I will >> have to write that very same code somewhere (maybe more, maybe less). >> >> Regards, >> >> Thierry > > Hopefully, it will be less :) I'm certainly looking forward to it. Regards, Thierry _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |