Using JQuery in .jelly file
Adrien Lecharpentier
Adrien Lecharpentier
Richard Bywater
google will be your friend hopefully)
On a side matter, does Jenkins have a "preferred" js library?
Personally Im not sure I like the idea of dragging in external js
outside of the Jenkins app (might just be me :) )
Richard.
On Thursday, June 23, 2011, Adrien Lecharpentier
Adrien Lecharpentier
Sven Strittmatter
Am 22.06.11 17:31, schrieb Adrien Lecharpentier:
> <script
> src="http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js"></script>
> <script
> src="http://jtruncate.googlecode.com/svn/trunk/jquery.jtruncate.js"/>
> <script>
> $().ready(function() {
> $("#more").jTruncate({
> length: 10,
> minTrail: 0
> });
> });
> </script>
Try:
(function($) {
$(function() {
$("#more").jTruncate({
length: 10,
minTrail: 0
});
});
})(jQuery);
When you put the code in Firebug, what does it say?
My question (I asked myself a lot of time): Why is jQuery not the
default lib for Jenkins. I'm developing web-foo since 7 years now and in
my experience jQuery is THE ONLY ONE js-lib you want to use. All other
libs are (sorry for that hard word) bullshit.
--
"Ich habe vom Glauben zum Wissen konvertiert." (Abdel-Samad)
R. Tyler Croy
Bundling dependencies like jQuery with Jenkins provides a number of
difficulties in the version management of the new dependency.
What version do we bundle? How/when do we decide to upgrade, if we upgrade the
core jQuery to a more recent release, how will that break plugins? What should
the deprecation policy be?
Additionally, if you rely on externally hosted JavaScripts for your plugin,
you're more or less guaranteed to never work in a corporate environment.
IMHO it's far more trouble than it's worth, especially with a library like
jQuery which is fairly small and doesn't provide a lot of end-user
improvements.
I've been developing web-foo for just as long as you have, jQuery is certainly
not the only toolkit nor the central toolkit I see people using regularly.
There are a couple other major ones (e.g. Prototype) out there, and Jenkins
selecting one to bundle would be an impressive amount of bike-shedding with
almost zero practical benefits (again, IMHO).
Cheers
- R. Tyler Croy
--------------------------------------
Code: http://github.com/rtyler
Chatter: http://identi.ca/agentdero
http://twitter.com/agentdero
Kiyotaka Oku
I wrote jQuery and jQueryUI plugin.
https://wiki.jenkins-ci.org/display/JENKINS/JQuery+plugin
https://wiki.jenkins-ci.org/display/JENKINS/JQuery+UI+plugin
and I used these plugins in Terminal plugin.
http://wiki.jenkins-ci.org/display/JENKINS/Terminal+Plugin
please try it.
Sven Strittmatter
Am 26.06.11 04:04, schrieb R. Tyler Croy:
> Bundling dependencies like jQuery with Jenkins provides a number of
> difficulties in the version management of the new dependency.
Each third party lib brings this problem, isn't it? And Jenkins just
uses some third party libs, right?
> What version do we bundle? How/when do we decide to upgrade, if we upgrade the
> core jQuery to a more recent release, how will that break plugins? What should
> the deprecation policy be?
Yes, this questions need an answer. But you have to answer them on each
lib Jenkins uses, and there are some libs already included, right? So
that's IMO an absolute normal job for developers to give answers on such
questions :)
But I don't say that's easy.
> Additionally, if you rely on externally hosted JavaScripts for your plugin,
> you're more or less guaranteed to never work in a corporate environment.
I don't like including jQuery via google ajax API. I code a lot in the
train without internet :) And yes, corporate env. is also an issue. Not
good when Jenkins will not work, when the Google Ajax API is down for
any reason.
> IMHO it's far more trouble than it's worth, especially with a library like
> jQuery which is fairly small and doesn't provide a lot of end-user
> improvements.
I don't think so. There is already a JS lib included. I've seen some
posts here some time ago with a discussion to replace it. Because its
development was discontinued. And I totally disagree that jQuery does
not provide a lot of end-user improvements. It gives you standardized
way to manipulate DOM with CSS3 over all major browsers. And the code
quality of jQuery is very good. And yes, the lib is very small but
provides a powerful plugin architecture.
> I've been developing web-foo for just as long as you have, jQuery is certainly
> not the only toolkit nor the central toolkit I see people using regularly.
> There are a couple other major ones (e.g. Prototype) ...
*eeeeek* Sorry, but Protoype is out of scope. No one will use it by
choice. It is a bad designed lib: It changes the prototype of internal
JS classes (it's possible @see Douglas Crockford) and it "simulates" a
class like object systems which leads to misunderstanding of JavaScript.
Other libs? ExtJS? JavaScriptMVC? Bloated, same problem, old concepts.
IMO the future is jQuery and it's plugin concept.
cheers
-sven
Adrien Lecharpentier
--
Adrien Lecharpentier
Sven Strittmatter
> thanks!! It works.
>
> I don't think putting any jquery lib in the core is a good idea as some
> company may refuse to use those libs..
Ok, that could be an argument, but Jenkins is already using libs (see
dependencies in pom.xml) what about that? IMO refuses company NOT
jQuery, they refuse open source at all.
Anyway, the possibility to plug in jQuery with Kiyotakas plugin is a
good way. Everybody has the free choice to use it or not :)
-Sven
R. Tyler Croy
POM dependencies are a bit easier to manage because of Maven and the fact that
there is an actual /build/ happening. While we can't account for a regression
in a particular dependency's API, if that API is changed somehow, we can easily
find out via build errors.
My concern with JavaScript-based dependencies is that it's trickier to spot
issues before a user hits them while using Jenkins.
I am a fan of the jQuery plugin, I think if a lot of plugins started to depend
on it, *then* we would have a good compelling reason to pull that plugin into
the "base" Jenkins install.