8:19 p.m.
Does anyone see an issue with adding jQuery to GwtHostPage? Some PatternFly widgets
require bootstrap.min.js which requires jQuery.
Thanks,
Greg
Greg Sheremeta
Red Hat, Inc.
Sr. Software Engineer, RHEV
Cell: 919-807-1086
gshereme(a)redhat.com
8:26 a.m.
----- Original Message -----
My understanding is that PatternFly is essentially a "skin" of Bootstrap CSS,
which doesn't imply the need for using Bootstrap _JavaScript_ library (which
needs jQuery) to deal with widgets in JavaScript runtime.
I thought that the purpose of "gwtbootstrap3" GWT module (integration with
Bootstrap CSS framework) was to provide such widgets in context of GWT app.
If not, what is then the purpose of "gwtbootstrap3" module?
In other words, doesn't "gwtbootstrap3" module provide us with all widgets
we need?
8:44 a.m.
----- Original Message -----
Any JavaScript-enabled widgets (like tooltips) do require bootstrap.js and
jquery.js. The only reason I didn't add them in the main PatternFly patch
is that we didn't need them back then. But now we need them.
gwtbootstrap3 provides renderings of GWT widgets that are compatible with
bootstrap css. It does not rewrite the jQuery code into GWT-JavaScript code.
In other words, doesn't "gwtbootstrap3" module provide us with all widgets
we need?
I wouldn't say "provide." It enables using the widgets more easily from
GWT.
Take a look at
https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/...
line 521 on down.
It simply wraps everything for ease-of-use from GWT / UIBinder.
Greg
9:49 a.m.
----- Original Message -----
I'm not sure this is the only way. gwtbootstrap3 could do the same thing,
after all its code becomes JavaScript in the end. I think there is no real
difference (conceptually) between bootstrap.js vs gwtbootstrap3, each one
can use JavaScript to implement widgets like tooltips. In the end it boils
down to styling DOM elements with CSS classes, so Bootstrap CSS framework
is the lowest common denominator.
The only reason I didn't add them in the main PatternFly patch
is that we didn't need them back then. But now we need them.
Hm, I assume you mean this:
http://getbootstrap.com/javascript/#tooltips
these are jQuery plugins, apparently bootstrap.js builds on top of jQuery
to ease the work with DOM elements. For example:
$('#example').tooltip(options)
will register mouse listeners on given element that control the tooltip.
Anyway, the tooltip behavior is just JavaScript + setting CSS classes,
not really related to jQuery.
However, I found this:
https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/...
so it seems that gwtbootstrap3 _does_ support things like tooltips.
EDIT: see my comment below, Tooltip.java depends on jQuery, you're right.
You are correct. So gwtbootstrap3 requires jQuery. I didn't know
this, just realized this now after looking at Tooltip.java code.
So gwtbootstrap3 is just a thin GWT wrapper to bootstrap.js which
implies the need for jQuery. (Originally I thought it's not just
a thin wrapper.)
Considering above, I'm OK with adding jQuery to GWT UI host page.
BTW, we could do this via <script> in GwtCommon.gwt.xml which will
cause the script to be automatically injected into GWT compilation
(permutation) output, so we wouldn't need to modify host page HTML.
However, question is, how/where to maintain jQuery script file(s).
9:58 a.m.
----- Original Message -----
Noted, thanks.
However, question is, how/where to maintain jQuery script file(s).
I have to RPM package gwtbootstrap3 and patternfly, so I'll just add
it in one of those RPMs. Probably the patternfly one. It'll be an
additional Source in the spec. Sound ok?
11:19 a.m.
----- Original Message -----
gwtbootstrap3-0.6.jar actually contains CSS/JS/fonts of Bootstrap plus
jquery-1.11.0.min.js, its NoThemeResources.gwt.xml module exposes all
of these files as public resources of the GWT application:
<public path="resource">
<include name="css/*.css"/>
<include name="js/*.js"/>
<include name="fonts/*"/>
</public>
(Note: GwtBootstrap3NoTheme inherits NoThemeResources.)
All public resources should be copied into final WAR output during
GWT application build. This means we could use jquery-1.11.0.min.js
bundled within gwtbootstrap3.
What do you think?
10:43 a.m.
apologies in advance for the complete ignorance here:
- is there any kind of potential collision that can occur between the gwt
javascript and the jQuery javascript?
- is jQuery expected to substantially affect performance / loading time
on the client side or anything like that?
10:51 a.m.
----- Original Message -----
Namespace collision -- no. jQuery registers itself globally as '$' and
'jQuery',
and neither GWT itself nor our GWT code use those names anywhere.
However, there can be behavior conflicts. I'm currently debugging a problem
where tooltips aren't destroyed when grid refreshes happen. The jQuery widget
doesn't 'know' that the GWT widget it's attached to was destroyed :(
- is jQuery expected to substantially affect performance / loading time
on the client side or anything like that?
First-load time will be negligible and cached.
Mass-use of bad selectors could decrease browser performance. I think we should
very rarely use jQuery in oVirt. Usages of it should be very justifiable.
Greg
3957
days inactive
3958
days old
10 comments
3 participants
participants (3)
-
Einav Cohen -
Greg Sheremeta -
Vojtech Szocs