[ANN] Nemo 0.1.0 + Wee 0.4.0

[Michael Neumann]

Hi Rubyists,

We (Kevin and Michael) are proud to release the first public version of
Nemo and a new version of Wee simultaneously.

Nemo is a Ruby port of Mewa

http://www.adrian-lienhard.ch/files/mewa.pdf

using Michael Neumann's Wee as the Seaside2 equivalent.

Nemo is a web-application platform that uses object metadata to
automatically construct web-interfaces (Editors and Viewers). It is
highly object-oriented with strong emphasis on reusable components.

What's Wee? Please read the URL below:

http://www.ntecs.de/viewcvs/viewcvs/*checkout*/Wee/trunk/doc/rdoc/index.html

== Installation

gem install wee
gem install nemo

== Hello World in Wee

require 'rubygems'
require 'wee'
require 'wee/adaptors/webrick'
require 'wee/utils/helper'

class HelloWorld < Wee::Component
def initialize
super
add_decoration(Wee:ageDecoration.new("Hello World"))
end

def render
r.h1 "Hello World from Wee!"
end
end

Wee::WEBrickAdaptor.register(
'/app' => Wee::Helper.app_for(HelloWorld)).start

== Running Advanced Examples

Nemo example:

cd `gem environment gemdir`/gems/nemo-0.1.0/test
ruby -rubygems person_editor.rb
# Point your browser to http://localhost:2000/app

Wee example:

cd `gem environment gemdir`/gems/wee-0.4.0/examples
ruby -rubygems example.rb
# Point your browser to http://localhost:2000/app

== Project pages

http://rubyforge.org/projects/nemo
http://rubyforge.org/projects/wee

== News in Wee 0.4.0

* Can be used with or without continuations
* renamed render_on to render.
* session now get removed when they are no longer alive.
* lots of other additions.

Regards,

Michael

 

[Michael Neumann]

Hi Rubyists,

We (Kevin and Michael) are proud to release the first public version of
Nemo and a new version of Wee simultaneously.

Just to clarify: Kevin Howe wrote Nemo, not I ;-)

Regards,

Michael

 

[George Moschovitis]

Can be used with or without continuations
this is a killer

hope to see Wee+Nemo+Og in the future

George

 

[Michael Neumann]

this is a killer

hope to see Wee+Nemo+Og in the future

you know, I'm working on it ;-)

Regards,

Michael

 

[Michael Neumann]

this is a killer

It's very easy to rip out the continuation stuff. Only a few lines have
to be rewritten (I've those lines already, as Wee started to be
non-continuation based). Indeed, the Session class would become much
easier, as it's no longer using it's own thread. Currently, I do not use
continuations much in my programs, and Nemo does not use them much
either (only one occurence).... But I'm waiting until there's real need.
You know, without continuations, Wee is again marshallable (despite it's
use of callback blocks, which are BTW optional, too).

What I'd like to see, is an implementation of IOWA on top of Wee...

Regards,

Michael

 

[George Moschovitis]

Will you arrange for Nemo to work off the same metadata as Og?

Og's meta-data are not DB specific, they can be used to build forms. An
example is the FormBuilder included in Nitro that will be integrated in
the scaffolding code. The latest version adds validation meta-data
support. And more metadata is coming soon.

Be the way the FormBuilder along with a TableBuilder (under
construction) will be integrated with the programmatic renderer, which
in turn will be integrated in the standard Nitro renderer.
Coming soon!

George

 

[Leslie Hensley]

Just started looking at the demo ... very nice.

Do you have the XmlHttpRequest thing working? If so would it be possible for
Nemo to create smooth rich-client interfaces without page refreshes? e.g.
combine the view & edit pages into one:
- person edit-components <div>s are CSS-hidden until you click on Edit
- list Add component is a hidden <div> until click Add
- both the above are included (hidden) in the list view page
- Edit, Add just make visible the corresponding editable <divs>
- The Save/Cancel (and 'Delete') buttons do a XmlHttp request
- The response simply updates part of the DOM
- No page refreshes at all (in this interaction)

You could use Avi's Javascript to do the XmlHttp round-trip. It would take a
little additional Javascript, with a tweak to the css, to do the hide/show.

Or is there some underlying design of sessions, continuations, URLs, ids of
edited objects, the back button, etc. that would make this difficult?

I would like to second the request for enhancing Nemo with DHTML and
humbly suggest as a starting point for the client side my fork of
Avi's javascript library
http://cvs.sourceforge.net/viewcvs.py/lakeshore/lakeshore/resources/liveUpdater.js?view=markup
(which is part of a port of Seaside2 to Java
http://lakeshore.sourceforge.net/).

I've been wanting to look into Mewa for a while now. Thank you Howard
for letting me do it without having to fire up squeak

Leslie Hensley

 

[Kevin Howe]

You could use Avi's Javascript to do the XmlHttp round-trip. It would take
a

little additional Javascript, with a tweak to the css, to do the hide/show.

Or is there some underlying design of sessions, continuations, URLs, ids of
edited objects, the back button, etc. that would make this difficult?

I actually experimented with using XmlHttp for realtime field validation in
Nemo a little while back. There was an issue concerning the way that Wee
keeps it's page history, but I never looked into it deeply since it was just
a side-experiment. I'll see if I can dig up the code.

- Kevin

 

[Michael Neumann]

Wonderful!




Are you recommending that continuations not be used? due to gc issues? other
reasons?

Exactly! Especially for nested calls, memory (on my configuration) is no
more reclaimed, due to continuations (I guess).
Other disadvantages of continations are:

* Each session must have it's own thread (due to the inability to
call continuations across threads)

* you can't marshal threads nor continations. especially in
combination with memory leaks, this is critical!

Regards,

Michael

 

[Michael Neumann]

Is the only alternative an explicit request/response style, or is there some
other way you discovered to get a "straight-line code" style even without
continuations?

Everything Wee currently supports works without continuations, except
what I describe below.

I'm not sure whether it is possible to implement the live-updates
without continuations as I've not yet gave this a thought. But there's
no problem to register a direct-handler of a component, which gets
called by a URL directly (not traversing the components tree) and which
returns a response. That should be super easy.

How about the browser-back button? Works without continuations?

Works without continuations. The only thing continuations are currently
used for is:

der render
r.anchor.callback { do_something }.with('click here')
end

def do_something
if call(ConfirmDialog.new('Really Quit?'))
call InformDialog.new('Bye bye')
else
call InformDialog.new('Continue working')
end
end

Without continuations, you have to write:

def do_something
call(ConfirmDialog.new('Really Quit?'), :confirm)
end

def confirm(quit)
if quit
call InformDialog.new('Bye bye')
else
call InformDialog.new('Continue working')
end
end

This example above is just fine without continations, but image a more
complex example.

And what features from IOWA do you miss in Wee?

Well, I'm not missing anything in Wee ;-)
But I could need some support, especially writing components.
Wee's model is a bit more expensive I guess, but on the other hand, IOWA
could profit from Wee's clean model. And Wee could profit from IOWA, if
there are more people using it ;-)

Regards,

Michael

 

[Michael Neumann]

I actually experimented with using XmlHttp for realtime field validation in
Nemo a little while back. There was an issue concerning the way that Wee
keeps it's page history, but I never looked into it deeply since it was just
a side-experiment. I'll see if I can dig up the code.

Well, using live-update could change the current components state, but
it would not modify snapshotted state. This means, that a live-update
should not change state that is beeing backtracked, as a live-update
does not generate a new page. With this in mind, there should be no
problem with Wee's pagecache.

Regards,

Michael

 

[Michael Neumann]

Is generation of a new page necessarily tied to being able to backtrack?

You need to understand what a "page" is: It's the snapshots of one state
of the components + registered callbacks. You need the snapshots to go
back to a particular state. And the callbacks, to make sure that you
don't invoke a callback on a state of a components-tree for which it was
not registered.

So it's neccessary for backtracking, but also for being able to invoke a
callback.

On the server: Could live_update components override
Component#backtrack_state to have the back-button work even without
page-reloads?

backtracking would work anyway, but not for the live_updated changes.
but I've not yet thought too much about it, so I can't say that for
sure. I'll have to talk to Avi on this topic, how he has solved this in
Seaside2.

On the client: Will the browser's history need to be manipulated to make the
back button work with live updates?

The requests sent by the javascript has nothing to do with the
page-history managed by the browser. So, you won't be able to use the
browsers back-button. But I wouldn't use live-updates too extensivly.
For some purposes it's fine, but I think it turns out to be too complex
if you use them for everything. Keep it simple, that's my opinion.

Regards,

Michael

 

[Vincent Foley]

Nice work Michael! I hope to see more of Wee in the future, it looks
really interesting. I have a bunch of questions for you: has Avi
tried Wee? Did he like it? Has he made suggestions? Have you looked
at some Seaside code since the last release (I remember that you didn't
when you made the original implementation)? If you've coded in
Seaside, how would you say developping in Seaside and Wee differs
(Smalltalk environment apart)?

One thing I found interesting the new Wee features is that it can be
used with or without continuations. Is that because Ruby can marshal
continuations and threads like Squeak? If it helps with memory usage
in Ruby, do you know if it possibly could in Squeak? I remember
reading a comment on the Rails weblog where someone mentionned using
Seaside, but there was a memory leak *somewhere* and neither he nor Avi
could figure out where it came from.

Keep up the good work!

Vincent.

 

[avi]

Hi Vince,

Apologies for the lack of quoted text - blame the awful new Google
Groups UI.

Yes, I've been aware of Wee since Mike first posted about it on his
blog, and we've been corresponding quite a bit as he's developed it
further. I haven't "tried" it in that I haven't actually used it to
build anything, but I know and like the choices that have been made
(even where they differ from mine with Seaside .

Could you point me to the comment about memory leaks in Seaside? I
don't know of any in the framework - individual sessions may grow to be
fairly large, but once the session expires it always takes all of its
memory with it. I know of several Seaside apps that have gone for
months without restarting, so if there were a serious leak I would
think we'd have seen it by now, unless the problem is a regression
specific to a particular release.

Avi

 

[Michael Neumann]

Am Samstag 15 Januar 2005 03:16 schrieb Vincent Foley:

Nice work Michael! I hope to see more of Wee in the future, it looks
really interesting. I have a bunch of questions for you: has Avi
tried Wee? Did he like it? Has he made suggestions? Have you looked
at some Seaside code since the last release (I remember that you didn't
when you made the original implementation)? If you've coded in
Seaside, how would you say developping in Seaside and Wee differs
(Smalltalk environment apart)?

Wee would not be Wee without Avi's help. He answered "thousands" of my
questions. I first tried to implement it my way, then if I encountered a
problem, he guided me into the "right" direction (conceptual-wise). I am not
sure he has "physically" tried Wee, but I think he knows much about it, as we
talked about it a lot.

I've not developed much with Seaside, only once or twice tried some quick
examples. I like Smalltalk very much, but Ruby a little bit more ;-)

I think Seaside has much greater functionality than Wee. But as the name
suggests (Wee = small), I tried to develop a small core, which has the
potential (continuations-problem let aside) to grow into something like
Seaside, without modifying the core (i.e. everything from now is an
"add-on").

Avi's comments on Wee:
http://www.ntecs.de/blog/Blog/WeeOnHREF.rdoc

One thing I found interesting the new Wee features is that it can be
used with or without continuations. Is that because Ruby can marshal
continuations and threads like Squeak? If it helps with memory usage
in Ruby, do you know if it possibly could in Squeak? I remember

AFAIK, Squeak can marshal threads, continuations and code-blocks. Ruby can't!
The problem is not memory usage, but memory leaks in Ruby! And imagine memory
grows towards infinity and you can't marshal the objects... terrible!

reading a comment on the Rails weblog where someone mentionned using
Seaside, but there was a memory leak *somewhere* and neither he nor Avi
could figure out where it came from.

I'm not qualified to answer this, but I think it's not quite true.

Keep up the good work!

Thanks. You're welcome.

Regards,

Michael

 

[gabriele renzi]

(e-mail address removed) ha scritto:

Could you point me to the comment about memory leaks in Seaside? I
don't know of any in the framework - individual sessions may grow to be
fairly large, but once the session expires it always takes all of its
memory with it. I know of several Seaside apps that have gone for
months without restarting, so if there were a serious leak I would
think we'd have seen it by now, unless the problem is a regression
specific to a particular release.

I think he's talking about this one
http://weblog.rubyonrails.com/archives/2004/12/31/escaping-java-but-not-its-thinking/#comment-101

HTH

 

[Vincent Foley]

This is the comment:
http://weblog.rubyonrails.com/archives/2004/12/31/escaping-java-but-not-its-thinking/#comment-101

 

[Avi Bryant]

Thanks, that thread made for interesting reading. I've posted a reply:
http://weblog.rubyonrails.com/archives/2004/12/31/escaping-java-but-not-its-thinking/#comment-287