Michael Neumann
2/16/2005 2:13:00 PM
Joao Pedrosa wrote:
> Hi,
>
>
>>I am really curious about continuation-based web frameworks. Can you
>>give us some examples in how this kind of web development can be
>>different/better than what is done with a more "standard" framework
>>such as Rails ?
>
>
> Wee does not need continuations to work, which is a good thing because
> sometimes they provoke some memory leaks in Ruby, mainly when things
> get complex. I really don't know much about continuations myself. I
> know that Wee at first used continuations, but since then it has
Not quite right ;-)
Wee was developed without continuations from day one. Then, in a
discussion with Avi, I realized how nice continuations are (for some
kind of applications). So I added them (that was ~ 30 lines of code ;-).
> GUI is generally divided in components/widgets, right? The problem is
> that in the web, GUI components happen to exist in the browser
> (client), but most of the business logic and state comes from the
> server. In a normal web-page, you may have more than a FORM tag. So
> when one is submitted, you may lose what has been entered in another
> FORM. You may need to handle the BACK browser button. And you may need
> to handle the Session, that is the maintenance of the state between
> browser requests. Now, imagine arbitrary GUI components that happen to
> be in the same web-page. Imagine each component with its own state and
> responding to events. That's a lot to imagine, but have no fear,
> because Wee is here.
>
> Wee supports the GUI componentization for a web-app. You no longer
> need to worry about everything by yourself (mainly about keeping
> everything in sync), because Wee can handle a lot by itself. Not only
> that, but the HTML generation is nice ruby code, with closures,
> blocks, etc. The components will work together in the same page or in
> different pages. Unload your work to them, and they will handle it.
> You no longer need to worry about URLs, for instance. Just
> "call(Component.new)" and it's like going to the next page. Just
> "answer" and the previous component takes care.
If you call a component, this will replace the calling component with
the called component until the called component answers.
As a page in Wee consists usually of multiple components, this can
happen at different places simultaneously. For example, you have a
IntegerField component, which lets you enter integer values into an
input field. If you enter a wrong value (say: "123f", which is not an
integer), this component might display an ErrorMessageBox component
instead of itself, which tells the user about the faulty input. If the
users clicks that message box away, the original IntegerField component
is displayed. The rest of the page stays the same all of the time
(unless you click on other "parts" of the page while the message box is
displayed).
> Most of the layout work should be handled by CSS and JavaScript,
> anyway. So the only HTML that's going to be generated by Wee is the
> minimum necessary.
>
> A lot of this happens by "magic". Sometimes you need to direct Wee to
> do the right thing, because resources are limited so it's better to
> share the responsibility of the resource handling with the developer.
> For example, when handling the BACK button, I think (maybe because of
> the lack of continuation issue.)
I don't understand you here. Could you please try to explain again.
Maybe: As there is only one component(-tree) per session, you have to
take snapshots of those values that you want to be back-trackable, so
that you can view older states of the page.
> Wee has less layers than Rails, so it should be faster when working on
Hmm, I don't know too much about Rails, but Wee will probably be slower
as there are multiple phases and you usually have a component-tree
instead of just one "controller/view". This component-tree is traversed
two times, once to invoke callbacks and another time for rendering the
html. And then, the html-renderer is probably slower than ERb, but then
you're not limited to use the programmatic rendering approach, you can
use whatever you like to generate the HTML.
> WEBrick. Wee is smaller than Rails, also. And lastly, I needed a
> web-framework for some persistence library that I've created, and it
> seems that Wee is a perfect match for it, so I couldn't be happier.
> :-) In the future I might release it, but it's not an O/R mapper so
> Og, which is an O/R mapper, already fills this role.
>
> This is my unofficial description of what I've gathered of Wee at the
> moment. It may be even better than this. It may become even better. It
> has a bright future, that's for sure.
Thank you very much for this nice description. Very helpful!
Regards,
Michael