Does GwtQuery offer the same browser compatibility as jQuery? If not, what browsers has it been tested with?
gQuery(GwtQuery) supports Browser compatibility as jQuery.
Each browser gets separately compiled JS
gQuery is an entire rewrite of GWT in jQuery.
GQuery and jQuery are built around selectors.
Both support CSS standard selectors plus extra selectors (:text :password :hidden etc).
jQuery uses the sizzle engine. A javascript engine which works with any browser and has optimizations per browser.
GQuery has optimized engines written in java.
The more appropriate engine is selected in compile time.
GQuery uses a modified sizzle version for IE6/7
GQuery adds compile-time optimizations when using compiled selectors.
Compiled Selectors
Use them with immutable selectors and when selector performance is a goal in your application.
Selectors Performance
GQuery in compiled mode produces the faster javascript code to select DOM elements.
GQuery dynamic selectors are, in most cases, faster or equal than any other library.
Events
GQuery provides methods for assigning event in a cross-browser way.
GQuery event system is compatible with Gwt.
issues: – When Gwt detaches a widget, events added via GQuery are lost.
References:
https://code.google.com/p/gwtquery/wiki/GettingStarted
http://vinaytechs.blogspot.in/2009/09/gwtquery-jquery-in-gwt.html
Related
I am developing a web app with GWT. I'd strongly prefer to code everything in Java instead of hardcoding anything in HTML and CSS. I'm also using GQuery (or GWTQuery) and I'm wondering if using compile time selectors with GWTQuery completely eliminate the need to hardcode any HTML or CSS at all - and have the speed and performance of a fully hardcoded app?
Let me explain with few words what gwt and gquery are.
1- GWT is just a compiler which gives you the tools to produce optimized javascript from java.
2- The js produced with GWT is mainly used to modify the DOM (apart from calculations, business code, ajax etc).
3- GWT additionally gives you a set of widgets, as an abstraction of the DOM, so as you can work with panels, buttons, trees, etc. instead of raw HTML. I think this is what you call hardcoded html.
4- But GQuery is a complement to GWT. It gives you a set of utilities taken from jQuery and ported to java to write less code, it is mainly oriented to manipulate the DOM (select nodes, modify, animate, etc) apart from other cool features like an easier ajax syntax, safe typing, promises, json/xml data-binding, etc.
Said that, don't think that the gwt widget abstraction will make you completely forget about dom and css. Sooner that later you will need to create your own widgets, or customize the current ones.
I think that the only way to forgot almost the DOM is to use a 3rd party widget library like gxt, mosaic, smart-gwt, etc. Because the GWT widgets are tough, they are designed to give the designer the option of easy stylizing them with css.
In the other hand, gwtquery will not help you to forget the DOM at all. It is designed to enhance static DOM elements which are in the page, enhance the DOM of gwt widgets, or create your own DOM structure based on html.
About gQuery compiled selectors, they are used in the same way dynamic selectors are: to select DOM elements, but with a much better performance because the compiler optimizes them. I think you misunderstood their objective, they don't give you any way to eliminate hardcode HTML.
UPDATE: To answer your last comment, it is NOT possible to generate static HTML or CSS with
GWT or GQUERY. They always produce static JAVASCRIPT code written to .js files (or written into javascript tags in .html files depending on the linker)
I've built a GWT application that simulates a standalone popup widget. I can invoke a javascript method that pops the widget from the html page that is part of the application (i.e. PopWidget.html) -- the html is basically auto-generated when I create the GWT eclipse project.
Now I'd like to invoke the javascript method from a standalone html (not part of application). When I try to call the javascript method, I am getting a permissions exception. Is this a SOP issue? And if so, How can i either work around this problem or transform the app to behave as an embeddable 3rd-party javascript library?
I've looked in gwt gadgets and this seems like the ticket, but I have not discovered any "popup" gadgets...
You are correct that it is an SOP issue - the default linker used builds an iframe, and loads the app source into that iframe. To prevent the js from running any file on your system, this is locked down (in most browsers).
Take a look at the "Controlling Compiler Output" section of this link http://code.google.com/webtoolkit/doc/latest/DevGuideOrganizingProjects.html#DevGuideModuleXml- the standard linker (std) uses iframes to protect against possible xss issues, but in your case you want cross origin loading, so you can probably use the xs linker instead.
I used Visual Studio 2010 excellent javascript profiler to profile the javascript of a web page on Internet Explorer.
(Analyze / Launch perf wizard / Instrumentation / JS application / profile js + url of page)
The perf report shows that jQuery's sizzle is the cause of the slowness (ie: some jquery selectors on my web page).
It shows the time spent is in Sizzle > filter > hidden > PSEUDO.
I do not have any selector with :hidden, so i don't understand why it looses this much time in hidden.
I'm using jQuery 1.4.4
I tried with jQuery 1.5 and it is the same.
As mentioned in the comment, :visible calls :hidden so if you're using that, it will show in the profiler.
Also note, that on the jQuery doc for the :hidden selector it mentions
Because :hidden is a jQuery extension and not part of the CSS
specification, queries using :hidden cannot take advantage of the
performance boost provided by the native DOM querySelectorAll()
method. To achieve the best performance when using :hidden to select
elements, first select the elements using a pure CSS selector, then
use .filter(":hidden").
I've seen GWT's getElementById, but I'm looking for something a lot more flexible/powerful. I'd prefer CSS selectors, but an XPath interface would do in a pinch. Thanks.
You may be interested in GWTQuery, a clone of JQuery's functionality (including selectors) to GWT, written by a GWT engineer.
I have been using UIBinder on SmartGWT widgets rather successfully.
However, I have to extend each SmartGWT widget that I use to comply with UIBinder's requirement. Occasionally, I have to masquerade a SmartGWT widget into com.google.gwt namespace, or masquerade a non-GWT-widget as a GWT widget. I extend widgets on as-needed basis.
So, I am starting to wonder, may be SmartGWT already has a UI XML format and I might be doing all this UIBinder acclimatization just to reinvent SmartGWT's wheel.
I have read and reread source codes of the showcase and delved into some of the SmartGWT source code, as well as reading the javadocs.
All I found is XML or Json for communication between server and client.
Is there any UI def XML available for SmartGWT whether gwt-compiled to client-side javascript or like Vaadin's server-side generated UIDL?
And if you happen to be an Isomorphic agent, could you tell us if there are any plans to let SmartGWT play with UIBinder (to preclude me from having to massage SmartGWT widgets on my own anymore)?
Yes, there is a SmartGWT XML component definition - the one used by Visual Builder and Reify, and which you can also write directly. See these docs and this FAQ item:
http://www.smartclient.com/smartgwtee-latest/javadoc/com/smartgwt/client/docs/ComponentXML.html
http://forums.smartclient.com/showthread.php?t=8159#loadVBScreen
As the FAQ clarifies, we recommend using this XML format for a set of use cases that heavily overlaps with what UIBinder is for, that is, keeping your layout and basic component definitions in a declarative format that designers can edit and which can be edited by visual tools, and having your actual Java event handling and other programmatic code separate.
However we strongly recommend against having that declarative format be HTML (as UIBinder does it) because that introduces lots and lots of cross-browser layout issues.
We are likely to eventually support UIBinder as well for the few use cases where it is not redundant with our own XML format. If you need that to happen sooner, consider Feature Sponsorship:
http://www.smartclient.com/services/index.jsp#features
For XML smartclient has the componentxml which is XML based ui design and use JavaScript to have client side logics. You need not compile your app every time in development environment and just reloading of the browser will have the change included and you can test it.