[lively-kernel] Lively IDE Mockups

[Steve Wart]

Hi Robert

This is very helpful. Thank you.

Steve
On Wed, Jun 23, 2010 at 9:58 AM, Robert Krahn <
robert.krahn at student.hpi.uni-potsdam.de> wrote:

> Hi, Steve --
>
>   What are the main organizational concepts in Lively? What are Areas,
> Workspaces, Packages and Classes?
>
>  I am somewhat bemused by the way Javascript builds class-instance
> behaviour on top of a prototype system (although it's been a while since I
> read much about it, so I might be mistaken). Does Lively retain the idea of
> classes or is it purely a prototype system?
>
>
> *Modules*
> *
> *
> The main package entity for source cod in Lively is what we call a module.
> A module integrates several things:
> - It has a name and this name is used as a namespace when the module is
> loaded
> - A module can be loaded asynchronously on demand simply by referencing
> them with their name
> - A module include class definitions (also function and object definitions
> but we want to stick to the class concept whenever possible)
> (Note: Since a module namespace can be currently extended from anywhere,
> modules do not enforce encapsulation)
>
>
>  *Module Example*
>
> module('lively.ide').requires('lively.Tools',
> 'lively.Ometa').toRun(function() {
> // Code depending on lively.Tools and lively.Ometa
> }); // end of module
>
> This definition does two things:
>
> a) Define the module lively.ide. The module can then be required from
> somewhere else:
> require('lively.ide').toRun(function() { new
> lively.ide.SystemBrowser().open() })
> Evaluating this will let the system:
> 1. Check if lively.ide is loaded. If not then the module name is translated
> to an URL: {Config.codeBase}/lively/ide.js. That URL will be used to load
> the file ide.js asynchronously. *
> 2. When the file is loaded run the code of toRun()
>
> b) Define the namespace lively.ide.
> That means that if the module is there you can access it's members in
> JavaScript. For example the class lively.ide.SystemBrowser is such a member.
> **
>
> For more information (module-file-mapping, how to get started in the wiki,
> etc.) please read:
>
> http://lists.hpi.uni-potsdam.de/archive/lively-kernel/2010-April/000347.html
>
> http://lists.hpi.uni-potsdam.de/archive/lively-kernel/2010-April/000360.html
>
>
> *Classes*
> *
> *
> Lively implements it's own class system implementation that was inspired by
> Prototype's class system.
>
> e.g.
> Object.subclass('Foo', {
> method: function() { return 23 },
> });
> new Foo().method() // --> 23
>
>
> *IDE*
> *
> *
> *Lively implements a complete JavaScript IDE, it's main part is the System
> code browser. It can be opened using the WorldMenu.*
>  *
> *
>
> A friend suggested that Lively might be a good environment to learn
> Javascript but I'd like to have a better idea of how people manage
> dependencies among various libraries. It seems that managing a pool of *.js
> files also needs to represented. Does Lively let you mix and match other
> Javascript libraries? If so, would it be possible to add visual tools to
> help with this or is the fundamental browser model too restrictive for that?
>
>
> It's definitely better to learn JavaScript in Lively than using in-place
> HTML scripting since Lively gives you immediate feedback (evaluate any
> expression in a Workspace or any other TextMorph with CMD+d (CMD+p to print
> the result).
>
> Managing files: see modules.
>
> Best,
> Robert
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hpi.uni-potsdam.de/archive/lively-kernel/attachments/20100623/557333cc/attachment-0001.htm