On Wed, Mar 10, 2010 at 9:59 PM, Bhushan Inamdar <[email protected]> wrote: > 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...
Tracemonkey tends to be better with such things (Firefox's javascript engine) and faster in the general case. I do not understand why you would want to add such a thing to Wt though, if you want to make a web page in some other worse language then C++, why not just use one of the already existing platforms already, there are a few javascript based server backends. I like Wt since it is pure C++, although I am not big on the Qt design of it to be honest, it is C++. On Thu, Mar 11, 2010 at 12:37 AM, Pau Garcia i Quiles <[email protected]> wrote: >> 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. > > I disagree. > > "the widgets would render on the final web application as they render > in the Wt..." *IN* *ONE* *BROWSER*, the one you are using to run > WtDesigner. If you are running WtDesigner on Firefox, you won't be > sure how it will look on Safari, IE7, Chrome or whatnot. Further, > nothing prevents you from making the QtDesigner-based WtDesigner > render the widgets on a QtWebKit canvas or replace "Show with > Plastique style", "Show with CDE style", etc from QtDesigner with > "Show in Firefox 3.0", "Show in Opera", etc. In fact, ideally > WtCreator would automagically download and install (a-la > portable-apps, ie. no system-wide installation) all those browsers so > that you can easily test your design. Why would it look different at all?!? Does not Wt go through great pains to make sure everything looks the same everywhere already? ------------------------------------------------------------------------------ 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
