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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Sep 23 16:20:52 UTC 2019


never close yourself, ask someone to close you ;)

Le lun. 23 sept. 2019 à 11:52, Marcel Taeumel <marcel.taeumel at hpi.de> a
écrit :

> > 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
>
> ==================== 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/61e2f201/attachment-0001.html>


More information about the Squeak-dev mailing list