A couple of times in the last week I have been trying to help a community member with their jQuery in XPages and it has turned out that the problem was because of the new jQuery v1.8 core library – something I had not thought about and wanted to clear up. I am always tell people in my article to just go to jQuery.com and get the latest core library – well now I have a caveat and will be more specific in future articles.
As best as they can, like all library developers, the jQuery team (unless otherwise stated) try to ensure the jQuery core library should be backwards compatible but there are specific things which are deprecated and dropped in subsequent versions. There are thousands of qUnit test modules created to do regression testing on the jQuery core but that doesn’t mean everything is caught – it is impossible to foresee every combination in every project – does this sound familiar…
When you download a plugin, you should always check the release notes to determine which version of jQuery core this plugin was written for/with. Especially with the older plugin written circa 2008/2009 they are many version of jQuery core behind and might not be forward compatible.
Many plugins (especially when downloading from gitHub) package a version of jQuery with that version – I recommend you first test with that version of the core and make sure it works in your xPage before moving to a newer version of the core library.
You also need to be careful that the plugin you are using is compatible with an older core library you might be using – sounds like common sense but it might not always be possible in a production environment.
Personally I have not had any issues with jQuery core v1.7.x running older plugins but I have not yet tried v1.8.
If you need an older version of the jQuery core they are all available here…
Xomino 
And behold – one of the major disadvantages of jQuery to Dojo. Dojo’s Dijit framework is integrated directly with the Core version, i.e. you don’t install version X of core and version Y of the UI. Simply review the source and you will see radical differences in architecture and code quality.
jQuery is great for sprucing up a page, or building a one-off custom site. But for any long-term, forward-maintained web application you will save yourself a lot of headache by using Dojo. I encourage XPage developers to learn it. The learning curve is steeper but since it actually ships with XPages you have to deal with it anyway, and you can open bug tickets with IBM for it. Plus with the built-in Dojo aggregator in 8.5.3 XPages it is REALLY slick.
Thanks for the thoughts Erik – you are right, everything is a compromise. Those people who are proficient in Dojo can certainly take advantage of the out of the box availability of it and long term support is definitely a plus for large corporations.
But every situation is different and so is every developer – what I am striving to do is broaden the knowledge of the possible. For most XPage developers, JavaScript as a whole is a daunting proposition and being able to quickly solve a business requirement with an external library sways where the balance of the compromise lies.
While I agree it’s usually better to work with tools that come with the product – especially for things like the aggregation and stuff. There is a nice freedom to not be tied down to what IBM gives us. We’re using Dojo 1.6 in 8.5.3 right? So we’ve “missed” Dojo 1.7 and currently don’t have dojo 1.8. Lot of good features in those versions I’m sure. I know there’s a lot of mobile enhancements.
I think the key to the whole “long-term, forward-maintained” think is how IBM will handle dojo 2.0 for us. I THINK that Dojo 2.0 will remove alot of the syntax we currently use in favor of something else. So in THEORY my impression is out apps will break.. unless IBM does some kind of translation or something. I don’t know. But if we get to dojo 2.0 and it turns out we need to re-write a lot of apps… then there’s less reason to stick with it I think.
The long term reason is why we should probably be using XSP.* instead of dojo.* when we write CSJS, Because IBM can control what the XSP object does but nothing in the dojo classes.
To be clear – I’m not saying you must stick with the Dojo version that ships with IBM’s products. Though it does make it easy to open support tickets.
Aside from playing nice with other frameworks, Dojo also supports running multiple Dojo versions on one page. So you can let the XSP stuff work with the version that ships with Domino and bolt-on your own newer version if you want.
Regarding Dojo 2.0: yes, there will be some things that are deprecated in 1.8+ that will be completely removed. They ship Dojo with an analyzer that scans your code for the deprecated/unsuggested pieces based on each version, which allows you to rework things if-needed.
I’m not saying don’t use jQuery – I’m saying that as a developer the long-term ROI of learning Dojo is higher for writing your own apps. The event model is MUCH better than jQuery’s, as is the packaging, widget encapsulation, and overall architecture.
男性 財布 人気
united homme 財布