|
|
Joined: 7/24/2007
Posts: 9
|
Can anyone tell me if ektronjquery.js can be used like a normal (unmodified) release of jquery? If so, are there any considerations to using it? Thanks,
Ben
|
|
Joined: 6/22/2006
Posts: 1833
|
Ektron is making its branded version of jQuery available for Ektron CMS customers. The file is workarea/java/ektron.js. Use $ektron instead of $ or jQuery. We have made some modifications and enhancements, so if you wish to use pure jQuery, you will need to include an unmodified version from jquery.com.
The Ektron branded version can reside on the same site as an unmodified version. It is independent and does not conflict with any other version of jQuery or other library. Every object is defined within either the $ektron or Ektron objects.
Don't use ektronjquery.js. In fact, the file will not be included in the next release. You may use ektron.js, ektron_xml.js and other plugins that do not have jquery in their name. Those will be removed in the future.
Ektron is in the process of making its documentation for the library and plugins public as well. We are still working out the rest of the details.
Some old Ektron code does define $. We are in the process of changing
that code, but you may wish to use the jQuery object instead of $ and
need to call jQuery's noConflict method.
|
|
Joined: 7/24/2007
Posts: 9
|
If that is the case, can I choose to not include it? Also, will plug-ins play nice with your version? Ultimately, I need a library to perform some animations and DOM manipulation - how can I achieve this without loading extra .js files that I don't need? Wouldn't a simple solution be for Ektron to include a standard copy of jQuery, and write custom functions/enhancements/modifications elsewhere? (Not to mention the developers/designers out there who do NOT want to use JQuery being upset at the added load on their site) Thanks for the quick reply- I appreciate the help.
|
|
Joined: 12/14/2006
Posts: 54
|
Also, could you compress it before releasing it? The 100k file size is pretty intense for our lower bandwidth customers, especially for a file that's mostly optional.
|
|
Joined: 6/22/2006
Posts: 1833
|
@Ben, the ektron.js file is required because Ektron code uses it. The ektronjquery.js file is used in 7.5.2, so it can't be deleted in that version.
Plugins that have been branded to use $ektron instead of $ or jQuery will play nice. The process is simple, so we expect some developers will brand plugins in addition to those Ektron has branded.
If you wish to do some animation and DOM nav, I recommend using $ektron to avoid including both ektron.js and jquery.js. Realize that Ektron will from time-to-time merge in changes to jQuery. If you wish to use a specific version of jQuery, you should include your own copy of jquery.js.
We could not include a standard copy of jquery.js because it would interfere with different versions of jquery.js that may be included on the page.
Developers are not required to use jQuery. Any other library (or no library at all) may be used. Please help me understand why some developers would be "upset at the added load on their site". There are many Ektron-authored files on the site. ektron.js just happens to have a lot of similarity with a certain open-source JavaScript library. It seemed a better choice than writing our own from scratch.
@mrobinson
We will be minifying ektron.js and ektron_xml.js in the future. This was on my TO DO list, but your suggestion was the motivation to get it done. In the mean time, you may minify it if you wish. jsmin is a common tool, but many exist.
|
|
Joined: 4/10/2007
Posts: 61
|
"There
are many Ektron-authored files on the site. ektron.js just happens to
have a lot of similarity with a certain open-source JavaScript library."
Yes, there are, and the way that they are included and written has caused us more than a little headache (global.css and webtoolbar.js come to mind) . The issues, i think, is that most developers try to limit what gets sent across the wire to the client to what is actually needed. If we implement a site that does not make use of EktronJquery, that entire library is still sent accross to the client. Unless, of course, Ektron will be providing a way to leave it off.
I think we all understand that the ektron.js code will be required to make the workarea work, as well as for certain controls. If someone from Ektron is able to reassure us that the ektron.js file will not be included on every single managed page, that would go a long way. Of course we are able to include a clean version of jquery, but the idea of including essentially identical JS libraries on every page does not seem like much of a solution.
Jquery has a solid plugin mechanism (including the ability to extend the JQuery object itself) that should allow for pretty much any kind of new JS functionality you want to add or change. Is there a reason that Ektron didn't simply extend jquery via this mechanism? This seems like a much more flexible, maintainable approach.
Thanks!
|
|
Joined: 6/22/2006
Posts: 1833
|
The approach we are taking with ektron.js is to eventually fix the conflicts caused by files like webtoolbar.js. The ektron.js file should only be included on pages that use it. These include workarea pages and pages that use an Ektron server control that uses ektron.js. If a server control does not use it, it should not be included. If you are seeing it included, please provide details. Perhaps it is included in your master page?
The branding of the jQuery library was done to avoid potential conflicts in the future. When we began, jQuery was at version 1.2.1. It is now 1.2.6 and more releases are coming. As with any library, some later versions are not compatible with older versions. We did not want to force our customers to use a specific version of jQuery. For example, say Ektron is using 1.2 and you wish to use a plugin that requires version 1.0 and is not compatible with 1.2. Likewise, say Ektron is still using 1.2.6 when 1.3 is released and you wish to use a plugin that depends on new features in 1.3. You would not be able to use it if Ektron's library was not branded. Then branding of jQuery to $ektron is step toward solving the headache you have been experiencing.
|
|
Joined: 4/10/2007
Posts: 61
|
The latest post in the "built with Ektron" section of the forum is a good example of the kind of thing that makes me nervous:
http://www.mennonitefinancial.com/
Home page size: 558k
Size of JS on the page: 447k
Size of JS from the Workarea (EktronJquery.js, ek_flexmenu.js, webtoolbar.js, thickbox.js): 266k
Nearly half of the bandwidth used to deliver the page is used to deliver JS that does not seem to be used. The menu does not appear to be using the 112k of JS that is ek_flexmenu.js but i assume the developer included the control in the page in order to access the XML for the site menu. Neither do i see where the home page uses a thickbox or jquery functionality, nevermind the webtoolbar.js. ( the sitemap is an even simpler page and still has these issues: http://www.mennonitefinancial.com/sitemap.aspx)
We are in development on a new (7.5.2) site and I took a look at the default login page. The page is 137k with 131k of that dedicated to the custom jquery and webtoolbar.js. It seems to me that a page that doesn't have anything on it that needs these 2 external files shouldn't load them.
Even considered from a strictly financial point of view, this should be considered; If pages are 90%, or even 50% larger than they need to be, that means I'm paying 90% (or 50%) greater bandwidth costs. There is a financial effect of delivering more than is required. On small sites, the effect is muted, but the larger the site, the bigger the effect.
To the multiple versions of jquery: Jquery provides a method by which multiple versions of the library can be used on one page. jQuery.noConflict (http://docs.jquery.com/Core/jQuery.noConflict). Any user who had an old plugin, or old code, that didn't work with the new version (or just worked differently) could then optionally use the old version for those specific parts. Plus, all of the plugins would work, patches to the library would immediately be available to ektron clients, and the entire constellation of documentation and support for jquery would be easily available to developers.
Don't get me wrong, here. I like jQuery. I've used it in a number of projects and have not had any trouble with it. (I also like http://www.mennonitefinancial.com/, BTW. Nice work!) If you say that in the future all of this extra JS will be included only when it's required, then that's fine, but I also have to ask when this will happen.
Thanks for all of your time in responding to these posts. As we continue implementing sites, the answers to these questions and issues help greatly!
Thanks again!
|
|
Joined: 6/22/2006
Posts: 1833
|
I'm not aware how noConflict can be utilized to allow two versions of jQuery to co-exist. It's primary purpose is to avoid conflict with other libraries. As far as I know, the global jQuery would reference only the most recently included version. Please provide an example. If there is a way to avoid branding, we would like to use it. As the result of an earlier post on this thread, we are now minifying many of the js files. For example, ektron.js is 61KB and thickbox.js is 20KB. This will be part of 7.5.3. I'll look into whether the server controls are including unnecessary JS files.
|
|
Joined: 4/10/2007
Posts: 61
|
noConflict was built to address the issue of conflicting libraries, true, but what is an older version but a library with extreme conflicts?
According to the JQuery site:
"You can now include multiple versions of jQuery, simultaneously, on the same page."
-http://jquery.com/blog/2007/08/24/jquery-114-faster-more-tests-ready-for-12/
As this is likely to be a rare occurrence, examples are thin on the ground. This is from the docs for noConflict at visualjquery.com:
jQuery.noConflict();
(function($) {
$(function() {
// more code using $ as alias to jQuery
});
})(jQuery);
// other code using $ as an alias to the other library [or other version of JQuery]
If you haven't seen this yet, take a look at this thread: http://dev.ektron.com/forum.aspx?g=posts&t=9648&boardid=80&terms=webtoolbar.js
Thanks for looking into this!
|
|
Joined: 6/22/2006
Posts: 1833
|
Thanks for the example.
jQuery.noConflict() restores $
jQuery.noConflict(true) restores jQuery and $
The line
var $ektron = jQuery.noConflict(true);
would have the same effect as the renaming that we have done. If someone wants to use our branded version, but without renaming the jQuery object in their code/plugins, simply assign an alias.
var jQuery = $ = $ektron;
Regarding multiple references to the same file, we have recently added a method that checks whether the JS file has been previously included. You should see a reduction in the number of duplicate includes in the newer releases.
|
|
Joined: 12/12/2007
Posts: 19
|
I noticed the same thing about the Mennonite Financial site while looking at it yesterday, and even brought my lead developer over to show him the bloat. The page we were using as an example was over 660KB (400KB of scripts) and there wasn't any interactivity present on the page other than a menu rollover. To make this worse, the Mennonite site was produced by a third party firm, so I imagine the folks at the bank have no idea. They probably are liking how nice their site looks. We'll be going live soon with a new set of sites and are trying to determine which build would be best to go live with (in the September timeframe). We have 7.5.1.40 on our server, but would like to go live with 7.5.3.11. Are the javascript loading improvements in 7.5.3.11? Along a similar line, the loading of CSS files that are added with the controls make keeping styles in check far trickier than I had hoped. It would be helpful to have a "best practices" document for both the javascript and css loading (showing where everything is stored, where it can be safely changed, and how to minimize/reduce multiple loading and control load order - which is really imprortant for the css). It will help us produce leaner sites, and in the long run that will make the end user happier and make it easier to develop sites. Dave
|
|
Joined: 4/10/2007
Posts: 61
|
Ektron Doug D wrote:Thanks for the example.
jQuery.noConflict() restores $
jQuery.noConflict(true) restores jQuery and $
The line
var $ektron = jQuery.noConflict(true);
would have the same effect as the renaming that we have done. If someone wants to use our branded version, but without renaming the jQuery object in their code/plugins, simply assign an alias.
var jQuery = $ = $ektron;
Regarding multiple references to the same file, we have recently added a method that checks whether the JS file has been previously included. You should see a reduction in the number of duplicate includes in the newer releases.
I guess, then, my question is "Why re-brand it at all?" Seems like it will just add another step (and one that most people won't know about) for users who want to use jquery plugins and generally complicate things for everyone involved.
Thanks.
|
|
Joined: 6/22/2006
Posts: 1833
|
Charles,
Thanks for your continued dialog. Permit me some time to itemize the reasons we decided to use $ektron instead of jQuery. I'm out of the office tomorrow, but hope to get back to you early next week.
-Doug
|
|
Joined: 6/22/2006
Posts: 1833
|
Summary of why we changed the name jQuery to ektron.
1. The Ektron JavaScript Library (ektron.js) file is based upon jQuery but is not identical to jQuery. We have made changes to the core jQuery library. Some changes are minor enhancements, others are fixes. For instance, the jQuery clone method ignores the special needs of form elements because most people using clone don't need to handle form elements. Ektron, however, does so the code was fixed to properly deal with form elements. Due to these and other changes, if the name jQuery was not changed, then developers would expect it to be 100% jQuery. Since the behavior may be different, we changed the name. It is the Ektron library, not jQuery, even though it is based on jQuery and mostly the same. John Resig and the rest of the jQuery team have produced a wonderful library, and we give full credit to them as the basis for our library.
2. Namespacing the library's core object as $ektron completely isolates our code from conflicts with other JavaScript and JavaScript libraries. We use $ektron in place of the jQuery $ global object and the Ektron object for other Ektron JavaScript classes. If all we needed to do was protect the library from other libraries like Mootools, Prototype, ExtJS, Dojo, etc, then we could have used the jQuery.noConflict() method. However, since we also needed to protect the library from other versions of jQuery (see #3 below), the noConflict method is insufficient. The namespacing has little negative impact on using third-party jQuery plug-ins. If a plug-in is well written (and compatible with the version of jQuery from which the Ektron library is derived), then it's just a matter of changing "jQuery" to "$ektron" or assigning jQuery = $ = $ektron.
3. Isolation also protects Ektron code from breaking when incompatible versions of the jQuery library are included. Say for example we had not changed the name. If a site included jQuery 1.2.5 (an unstable version), the Ektron code might have failed and our technical support and engineering staff would have been at a loss why. Our code is written on the base versions we use in the Ektron Library, and thus has been tested for that releases' version of our Ektron Library. As noted in item 1, it is not 100% compatible with jQuery (regardless of version).
4. Branding helps identify the source of the code. We considered using "ek" or "ekt" as a prefix but decided on "ektron" because it quickly identifies the owner of the code. We are not hiding the fact that the Ektron library is largely based on jQuery. It is our intension to keep up-to-date with jQuery, but we need to control the timing of when and how that occurs to ensure that all of our controls and workarea pages function properly.
Since Ektron has created a library that does not conflict with other libraries, you have the option to use it or not. You are free to use our library to provide much (if not all) of the same functionality you expect from jQuery. It is therefore not necessary to include another library unless you wish to for your own reasons.
|
|
Joined: 4/10/2007
Posts: 61
|
Doug,
Thanks for this information. While I'm sure I'll have more questions when we actually see this implemented (in v 8?), I certainly appreciate the effort.
Thanks again.
|
|
Joined: 6/22/2006
Posts: 1833
|
ektron.js is in ~/workarea/java along with a number of plugins in ~/workarea/java/plugins. Many of the changes are in 7.5.3 SP 2 (just released) and more will be in 7.6.
|
|
Joined: 2/15/2008
Posts: 51
|
Hello, thank you guys for starting this conversation. This is the all place i've been able to find any information about this.
I'm having some conflicts with jQuery and ektron controls. One was with a flexmenu that seemed to have something to do with load order. Also I have a poll where the submit and display results function doesn't work when on a page with a link to the standard jquery library. I get the error:
$(c1).appendChild is not a function DisplayResult( "<script language="JavaScript" type="text/javascript">\r\nfunction ektRefreshReport(sUrl)\r\n{\r\n var href...", "control=ctl00_PlaceHolderPriority2_Poll1") WebResource.axd (line 224)  $(c1).innerHTML=''; var dataelem = document.createElement('div');dataele...
Is this a case of confusion using $? I kind of understood your examples to use in my custom scripts, but how can I apply this to server controls? I don't even know how to find these functions. Any help would be greatly appreciated.
btw. I'm using 7.04 (have EktronJQuery.js but no ektron.js)
thanks.
|
|
Joined: 6/22/2006
Posts: 1833
|
The method 'appendChild' is not defined in jQuery, it is a DOM method.
|
|
Joined: 12/17/2007
Posts: 6
|
Using <a rel="Heart" href="/i/heart-center/heart-center_10.jpg" class="ek_thickbox"> image </a> I can trigger a jquery thickbox modal window just fine.
But if I want to utilize Thickbox's "gallery" feature by making sets of images through the rel attribute, it doesn't work. I get a spinning .gif.
I've run into this problem every time I've tried to implement a modal window (e.g. the original prototype lightBox, Lightbox Gone Wild by Particletree, the Jquery lightBox-ripoff plugin). After reading this discussion and discovering that Ektron implements Thickbox, I figured it would be the best and most simple bet for making this happen. But no luck yet.
I don't know much about js and namespaces and all that stuff... just know there's some sort of conflict going on with the Ektron js and the scripts I'm trying to leverage. I can get them all to work just fine on my own static html pages.
I'm running 7.5.2, which uses EktronJQuery.js rather than the ektron.js that has been mentioned.
Any advice? Thoughts? Solutions?
|
|
Joined: 8/15/2006
Posts: 43
|
Ektron Doug D wrote:Some changes are minor enhancements, others are fixes. For instance, the jQuery clone method ignores the special needs of form elements because most people using clone don't need to handle form elements. Ektron, however, does so the code was fixed to properly deal with form elements.
Doug, jQuery is an open source library. If there is a bug in jQuery, why not simply submit a fix to the jQuery team?
I also agree with another previous comment about extending jQuery via their plugin architecture. I'd think that would be a better solution.
Another issue is that you guys are only including the file when a server control is being used. So, if I need jQuery functionality on a page that doesn't use a server control I need to include my own version of jQuery. That leads to the potential issue of having a page that might download two almost identical libraries, if jQuery and ektron.js are both being included. Nevermind the fact that they will likely work together fine - what a waste of bandwidth!
===================
Jeff L
Senior Web Developer
PixelMEDIA, Inc
|
|
Joined: 8/15/2006
Posts: 43
|
btw, I'm not sure how you are doing your namespacing, but using $() or even jQuery() both still work, so I'm a little wary that including another version of jQuery would not cause conflicts.
===================
Jeff L
Senior Web Developer
PixelMEDIA, Inc
|
|
Joined: 6/22/2006
Posts: 1833
|
Jeff, Thank you for your comments. Extending jQuery with a new method does not fix the old method. In the case of clone(), it is used by several other jQuery methods. Adding a new method, say myClone(), would not fix all the other methods which still call clone. Therefore, the clone() method itself must be fixed. Ektron participates in the jQuery community. This is the thread on clone: http://groups.google.com/group/jquery-dev/browse_thread/thread/813dd5bb617facba/81f8e476a730515e?#81f8e476a730515e, which they declined to change. This thread is regarding the trim() function, which has also not changed (yet): http://dev.jquery.com/ticket/2690. However, this fix was adopted: http://dev.jquery.com/ticket/1916. Later versions of ektron.js still define $() and jQuery() so that it may be used. We made this change based on customer feedback in order to allow jQuery plugins to be used without having to define $ = jQuery = $ektron. To use jQuery within the Ektron environment, include ektron.js on the page either using code-behind Ektron.Cms.API. JS.RegisterJS(this, Ektron.Cms.API.JS.ManagedScript.EktronJS); or ASPX, just define id="EktronJS" to avoid duplicate includes. If you need a different version of jQuery, you may include that version without conflict. Ektron code uses $ektron and will, therefore, use the Ektron version even if another version is defined.
|
|
Joined: 8/15/2006
Posts: 43
|
Thanks for the quick response Doug.
Registering EktronJS indeed worked for me. A couple more questions:
Where is Ektron looking to output that in the head? I would want to make sure that shows up before any of my other scripts (which might depend on jquery functionality). Currently it's showing up in the middle of some meta tags.
Also, it would be nice if ektron.js had a comment stating that it was built of off jQuery, and which version of jQuery it was based on. As plugins etc might be depenedent on a certain version of jQuery, this info could prove valuable, and currently I don't see anything in ektron.js that provides this info.
===================
Jeff L
Senior Web Developer
PixelMEDIA, Inc
|
|
Joined: 6/22/2006
Posts: 1833
|
ektron.js attempts to place itself above SCRIPT tags, but below TITLE and META. It is best to register all your JS files the same way to avoid any possible misordering. The RegisterJS method does accept a URL path string. The ektron.js has a comment near the top indicating which version of jQuery it is based on. Additionally, $ektron.jquery provides the version programmatically.
|
|
Joined: 8/15/2006
Posts: 43
|
Good to know about RegisterJS, thanks.
BTW, the only comment I see at the top of the file is this:
/*
* JSMin
* Javascript Compressor
* http://www.crockford.com/
* http://www.smallsharptools.com/
*/
and $ektron.jquery returns undefined, but $ektron.fn.jquery did return the proper version #, thanks.
===================
Jeff L
Senior Web Developer
PixelMEDIA, Inc
|
|
Joined: 5/25/2007
Posts: 133
|
I was able to pull the version information from the EktronJQuery.js file. /*
* Based on jQuery 1.2.6 - New Wave Javascript
*
* Copyright (c) 2008 John Resig (jquery.com)
* Dual licensed under the MIT (MIT-LICENSE.txt)
* and GPL (GPL-LICENSE.txt) licenses.
*
*/ I'm running 7.6.1.53
Tim Gardner | Sales Engineer - Mid Atlantic
ektron, inc.
|
|
Joined: 6/22/2006
Posts: 1833
|
Jeff, Ah yes, of course, I'm looking at the uncompressed edition which has the comment at the top. Comments are removed by JSMin. You are correct concerning $ektron().jquery instead of $ektron.jquery.
|
|
|
|