[squeak-dev] The Inbox: Morphic-ct.1537.mcz

Marcel Taeumel marcel.taeumel at hpi.de
Mon Sep 23 09:52:34 UTC 2019


> Is there any special reason why we do not have a simple ProjectViewModel with ToolBuilder and dedicated #okToClose implementation? 

That's because the best case is to use the domain model directly as the view model, which is the Morphic project in this case. Any extra wrapper around the domain model -- the view/tool model -- implies implementation overhead. :-)

In fact, Project inherits from Model, which already combines the two roles of both domain and view model. Having an extra ProjectViewModel would make things even more complicated. An extra Project(View)Model would only make sense if Project would inherit directly from Object again.

Then, again, Object has several methods for being a view/tool model such as #okToChange, #okToClose, #hasUnacceptedEdits, ...

> Add support for closing the current project. In this case, we do not want to suppress the user confirmation.

Yes, the check "self parent ~~ Project current" is strange. I would rather check whether the current project has a parent at all and whether the current project is a top project. You need to find a project to enter after closing the current project.

Best,
Marcel
Am 21.09.2019 21:02:05 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Does anyone remember for what scenarios this method was written here? Why should it be specific to Morphic?

The one scenario I could think of was a ProjectViewMorph pointing to its own project. But in this case, the current Trunk implementation actually does not work but gives you an infinite number of security checks.
>From my point of view, this condition should not be handled in a Project, but in the corresponding ProjectViewMorph, which decides whether to actually delete the project or only the view. Would you agree with that?


I wonder how we can make this check in the view because usually (at least in Morphic), a ProjectViewMorph is wrapped by an "anonymous" SystemWindow where the latter sends #okToClose to the model. Is there any special reason why we do not have a simple ProjectViewModel with ToolBuilder and dedicated #okToClose implementation? This would make things so much easier ... Hypothetically, one could then rewrite the current ProjectViewMorph as a wrapper for the ProjectViewModel, just for compatibility reasons.


I would be glad to hear your opinions :)

Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von commits at source.squeak.org <commits at source.squeak.org>
Gesendet: Samstag, 21. September 2019 20:33:53
An: squeak-dev at lists.squeakfoundation.org
Betreff: [squeak-dev] The Inbox: Morphic-ct.1537.mcz
 
A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-ct.1537.mcz [http://source.squeak.org/inbox/Morphic-ct.1537.mcz]

==================== Summary ====================

Name: Morphic-ct.1537
Author: ct
Time: 21 September 2019, 8:33:43.718935 pm
UUID: d13309f1-8b1d-5742-8d85-81ed5a803904
Ancestors: Morphic-mt.1526

Add support for closing the current project. In this case, we do not want to suppress the user confirmation.

=============== Diff against Morphic-mt.1526 ===============

Item was removed:
- ----- Method: MorphicProject>>okToChange (in category 'release') -----
- okToChange
-        "If the view is from somewhere else than the current project, just delete it."
-       
-        ^ self parent ~~ Project current
-                or: [super okToChange]!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190923/d26e59c9/attachment.html>


More information about the Squeak-dev mailing list