View/Model Separation

Conventional wisdom cautions against mixing view and model related code. It seems that the examples I dig into have all the code in the Morph.

- What has been your experience in understandability/testability writing them this way?
- Is it just because they are examples? Or would you write production code that way too?
- If you had a separate model and view, how would they communicate? Is there something like a change/update or announcements framework?

Thanks,
Sean

Hi, Sean

we experimented with various approaches of software engineering to separate UI from Domain models. Starting by classical Models that send a changed method to the View in the first version of Lively [1]. Then having Widgets classes that connect Active Records with User Interface Object using observer / plug mechanisms].  For Webwerkstatt we took a more end-user programming approach and not separating the models from the view, because it made everything so much simpler to edit at runtime. Using persistent instance-specific behavior, we build our applications and tools out of existing parts. These parts come with their own scripts and sub-morphs. They can be reused, adapted, and composited and shared in a PartsBin [2]. This allows us to change the objects / applications / tools as we are using them
without having to find the right place in a abstract class / module. You see the difference of those two approaches when you try to understand the classic system code editor:
(A) http://lively-kernel.org/repository/webwerkstatt/documentation/livedoc/Tools/SCB.xhtml
and the scripted versions:
http://lively-kernel.org/repository/webwerkstatt/demos/CodeBrowserFabrikLike.xhtml
(B) a version using the class objects (non-persistent) similar to the one presented in [1]
(C) a version using the static (and persistent) AST / SourceDB.

Version (A) uses a browser framework, that classically separates model from UI, making it hard to understand (starting from an instance) and easier to understand browsing its static source code (its genotype) [4].

(B) and (C) do not have a source code representation, but like all our "Parts" a are copied every time a new instance is needed, inheriting all changes to the phenotype this way. Since all behavior was created starting from the UI the users interact with, the behavior is usually not hidden deeply in the objects, prototypes or classes, but it is kept easily reachable through Halos the top pane. For example, you will see that the behavior of the browser consists only of a lists of scripts in the „ClassBrowserPane“ morph: "browseCategory, browseClass, browseMethod, browseModule, reset, searchClass, showMethodPath, updateClasses, updateModulesList"
The scripts are connected with each other and the user interface (the lists and buttons) through a general bindings / connection mechanism [2, 3].

The comparison is a bit unfair, since there are also approaches to implement a simpler browser with in a class based approach [5] and tools like the ObjectEditor that is build out of scripted parts became also bigger and more complex with every feature we put in. The difference is, that we can still explore and adapt its behavior starting from any open instance. We also often start to build new tools by taking other tools apart and using their components, rewire them, and publish them as a new tool.

I hope this helped you better understand how the applications and tools are currently build in Lively. Working directly on objects feels very immediate and a lot of fun, but there are also a lot of open problems and an future work to do. But for co-evolving content, applications and tools in a self-supporting Wiki-like programming environment like Webwerkstatt this approach was less problematic compared to having all application behavior separated in classes as we started out with.

Best,
Jens

References:

[1] Dan Ingalls, Krzysztof Palacz, Stephen Uhler, Antero Taivalsaari, Tommi Mikkonen. The Lively Kernel -- A Self-Supporting System on a Web Page. In Proceedings of the Workshop on Self-Sustaining Systems (S3) 2008, Springer LNCS 5146, pages 31-50, Potsdam, Germany, May 15-16, 2008, Springer.

[2] Jens Lincke, Robert Krahn, Dan Ingalls, Marko Röder, and Robert Hirschfeld. The Lively PartsBin: A Cloud-based Repository for Collaborative Development of Active Web Content. In Proceedings of Collaboration Systems and Technology Track at the Hawaii International Conference on System Sciences (HICSS) 2012, Grand Wailea, Maui, Hawaii, USA, January 4-7, 2012, IEEE Computer.

[3] http://lively-kernel.org/repository/webwerkstatt/documentation/HowConnectWorks.xhtml

[4] https://github.com/LivelyKernel/LivelyKernel/blob/master/core/lively/ide/SystemCodeBrowser.js

[5] https://github.com/LivelyKernel/LivelyKernel/blob/master/core/lively/ide/SimpleBrowser.js

Am 06.02.2014 um 22:26 schrieb Sean P. DeNigris <[hidden email]>:

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

Thanks for the detailed reply!

Lincke, Jens wrote

We also often start to build new tools by taking other tools apart and using their components, rewire them, and publish them as a new tool.

That is intriguing. Is there an example i.e. two tools I can look at where one was built from the other? This is a killer feature and would make a great case study or little screencast :)

Lincke, Jens wrote

[3] http://lively-kernel.org/repository/webwerkstatt/documentation/HowConnectWorks.xhtml

Great link… I was wondering how that worked.

It makes sense that programming in a different way would favor different designs - our artifacts are reflections of our tools. I can see with the scripted version when digging in via halos how much easier it is to get directly to the relevant code. Have you had any experience with this style and multiple views? Or would you go back to model/view if that was required?