I am very much new to all this. But from what I understand, My 2 cents
w.r.t. the following suggestions made by Omer in his post to Koen...
Koen:
> 1) You could use some kind of tag instead like dojo does
> <event attach="someWidget" signal="someSignal">
> javascript here
> </event>
> A javascript parser is an overkill but it actually sounds like a nice idea
> to have one as part of the build chain, it can be useful :)
> 2) Sure, I will do so ASAP.
> 3) True, again if there is a need for run time efficiency this should be
> turned off.
> 4) If you would have looked into my source code that I had sent you you'd
> see a wrapper class that integrates the model into the widget, if you choose
> to not use a model you can just create a regular widget.
>
To add to what Omer and Koen have been talking in point (1) above, I would
like to know if using Google V8's model for implementing javascript code
would help? I am not sure about the kind of licensing restrictions Google
has put for V8 use for commercial purposes, yet it might be worth looking
at. The basic concept behind V8 is as folllows. Javascript by nature is a
dynamic language as against the other object oriented languages like C++,
java, C#, etc. This implies that a var declared in javascript can hold any
data assigned to it. This is not the case with OOP languages which are
strongly typed. Also, since Javascript is an interpreted language, it cannot
have the speed and performance benefits as that of the compiled languages.
However, V8 is a javascript engine that provides javascript in exactly what
it lacks by the way of implementing what they call as "Hidden classes" under
the hood. It compiles the javascript code the first time it is executed. As
a result, when the same code is executed any time further, it will perform
better. However, as of now, it does not provide greater benefits if the code
is compiled and called only once. Google is already working on this problem
and has its own algorithm to decide if the code should be compiled or not.
This would really help plug some of the redundancies that Javascript brings
along with its numerous advantages. There is more as to how V8 works, but I
will leave it to the readers to explore.
What I am hinting is creating or using something like V8 that suits Wt. I am
not sure what language V8 is written in, but most probably it would be Java
and/or C++. You might still need a parser I believe. But may be a better
performance at runtime can be achieved at the expense of increased build
times. It should, therefore be kept optional to use as mentioned in point
(3).
Please let me know if that makes any sense, as my knowledge in OOP languages
interaction with Javascript is very poor...
Thanks,
Bhushan
On Thu, Mar 11, 2010 at 8:54 AM, OvermindDL1 <[email protected]> wrote:
> On Tue, Mar 9, 2010 at 4:18 AM, omer katz <[email protected]> wrote:
> > A framework for binding javascript libraries would be nice.
> > Something that simplifies the process of binding Wt and javascript in
> such
> > way that you can map javascript and C++ correctly.
> > I would really like to bind dojo.
>
> Heh, I had thought about that along with ideas to implement it. I
> *just* graduated so I doubt I am eligible for GSoC though, maybe if I
> have some free time sometime then.
>
>
> On Tue, Mar 9, 2010 at 6:10 AM, mobi phil <[email protected]> wrote:
> > 3. The already proposed idea about using Qt Designer to design Wt
> > widgets, might be a wrong direction. In my opinion a better solution
> > would be to create a Wt application that would allow the construction
> > of "empty" widgets, through a web application. The advantage of this
> > approach is that contrary to Wt Designer, the widgets would render on
> > the final web application as they render in the Wt. The product of
> > this designer wt application would be a html template. Any .ui
> > interface etc. would mean unnecessary overhead in the development
> > cycle etc. etc.
>
> That is *exactly* how I thought that should be designed, even played
> with it a bit (just a quick creator as I was designing my app so I
> could figure out how they 'feel', *very* basic though). This would be
> fun to do.
>
>
> On Tue, Mar 9, 2010 at 7:14 AM, omer katz <[email protected]> wrote:
> > A mentor is a very experienced programmer who guides and leads the
> feature
> > implementation/bug fix.
> > No idea about the benefits though.
>
> If I am not eligible as a student, I could always act as a mentor, I
> am good at prodding people to get things done, since I need to done to
> me as well. ;-)
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> witty-interest mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
