On Sun, Dec 6, 2009 at 12:37 AM, Koen Deforche <[email protected]> wrote:
> Hey Richard,
>
> 2009/12/2 Richard Dale <[email protected]>:
>> One of the reasons I haven't been working on Wt::Ruby is because I
>> been doing some JavaScript bindings for Qt based on the same 'Smoke
>> libs' that Wt::Ruby uses.
>>
>> http://gitorious.org/qtscript-smoke/qtscript-smoke
>>
>> Because of that I don't think it would be too hard to adapt the
>> Wt::Ruby code to work with Qt QtScript, which is going to be based on
>> the WebKit JavaScrpt engine in Qt 4.6. Is that a crazy idea? Does it
>> make sense to have a service side framework based on JavaScript? I
>> don't know. The Chrome V8 based Node.js server side framework has been
>> generating a lot of excitement, and maybe a QtCore/Wt JavaScript stack
>> would be an interesting combination..
>
> It's certainly mind-bending :-)
>
> I certainly believe it would make sense. It has the potential for
> defining your event handling in JavaScript which may be reworded into
> a client-side JavaScript method (and thus run entirely in client-side
> JavaScript).
>
> Imagine that you write something like:
>
> onClick = function (w, event) {
>  var i;
>  for (i = 0; i < w.parent().count(); ++i) { // WContainerWidget::count()
>    if (w.widget(i) == w) // WContainerWidget::widget()
>      w.hide();
>    else
>      w.show();
>  }
> };
>
> Now if you do this in Wt as a C++ method you will run this on the
> server and have an update such as: hide("o14"); show("o17");
>
> But you could indicate that you want to have this as a client-side
> method, in which case you could rewrite it also in terms of DOM API:
>
> onClick = function (o, event) {
>  var i;
>  for (i = 0; i < o.parentNode.childNodes.length; ++i) {
>    if (o.childNodes[i] == o)
>      o.style.display = "none";
>    else
>      o.style.display = "block";
>  }
> };
>
> That would be a more powerful variant of the current automatic
> JavaScript learning which only works for "stateless methods", applied
> to arbitrary methods.
>
> I only wonder with these server-side JavaScript frameworks is how as a
> developer you do not get confused about where runs what code and not
> make the mistake of trying to call a server-side function from
> client-side code and vice versa. This problem is similar to using GWT
> where you need to keep the client-side Java and server-side Java well
> separated.

Also, I am curious, why the webkit javascript and not tracemonkey or
v8 as they tend to be a *lot* more tested and both are a lot faster
(v8 with javascript that is designed more like classes, and
tracemonkey for everything else)?

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest

Reply via email to