Each control would have a property called ScriptPathUI and ScriptPathjQuery or so which you would be using to instantiate the necessary scripts. This could be the full path to the core files, no need to follow a naming convention.

Hi proeder!

I don't think, I'll be able to fit in the update this week. I just created a new release with the current version 1.4.2 of jQuery and a minor addition to the Tabs control.

I wanted to add your feature, but it got me thinking about the best way to implement it. The problem is, that there are a few things things to consider:

• Where is the jQuery core js file? (needs the complete path, due to version number)
• Where is the jQuery UI js file? (same problem)
• How and when do you configure, which files to use? This must occur before any control tries to register jQuery on the page.

The "ThemePath" has already been implemented though. If you want to use your own custom theme, you can call

JQueryUI.RegisterJQueryUITheme(this.Page, "MyTheme", "~/Path/To/MyTheme/", "1.7.2");

You have to follow a convention though: Your css file must be named jquery-ui-<Version>.<ThemeName>.css, in order for the infrastructure to find it. The path is freely choosable, but must be in the application, since the infrastructre will perform a check, if the file actually exists. Maybe I can add an override, so you can specify a url for using a CDN.

For the core files, this would have to occur in a similar fashion. Do you perhaps have a picture in mind, how you would want to include the core files?

Regards,
Christoph

I just created a new release (jQuery Core module 0.6.0), that upgrades to jQuery 1.4.2 and adds a property named UseInlineBlockInitialization to the Tabs control. If you set this to true (like in the new example .ascx), the tabs widget will be initialized with a script block instead of the document.ready event. I believe, this has sped up the initialization significantly. Nonetheless, if your Tabs contain a lot of content, you will still see the basic rendering before it is changed to the tabs style. This is a "limitation" of jQuery UI, though. Please try it out and tell me, if this solves your problem.

Best regards,
   Christoph

There may be drawbacks when using the inline script block. I posted a question aiming at this issue in the jQuery forums, in which I explain a possible problem when not using the document.ready event. You can find it here: http://forum.jquery.com/topic/best-practice-for-initializing-widgets. I'll get back to this, when I receive a satisfactory answer. For now, I do not consider this a bug in the jQUI-DNN Integration package, but a minor drawback in jQuery UI itself.

The scripts and css files are loaded in the head content of the page and are available early enough. This effect is due to the way the widgets are initialized. As in all the demos on the jQuery UI page, the widgets are initialized using the document.ready event. This event fires when the document is loaded, so if the document is large and your connection is slow, it will postpone converting the html structures to the widgets until the event fires. So far, this has not created any problems for any of my products, but I will consider adding the behavior to use inline script blocks placed directly after the rendered html structure instead of the document.ready event. This should speed things up in large documents. Thanks for the info!

I see there is problem on demo page ...

If You clear cache and reload page You will see for a second original not ui formated tabs div, you will see ul li etc ... !!!

If tabs have content like big photos, tabs will not be formated several seconds and show ul li code ...

I think jquery-ui.js is not loaded well ? it is loaded after page content, i think scripts must be loaded before content !?!?!?

Hi proeder!

I actually built this library having in mind an easy deployment. Various commercial modules require you to install more than one module, due to the fact that they have their own reusable framework libraries, that were deployed separately (at least until DNN5). The same thing happens here: The jqui-module package is simply a prerequisite for your own custom modules.

Nonetheless, I will consider adding support for manual support files distribution. Especially since I am not always able to keep up with the latest jQuery development, this would enable developers to deploy their own jQuery version with their modules. I'll try to post an update later this week.

Regards,
Christoph

Hi Christoph,

it would be helpful to have the ability to set the path to scripts and themes. Right now, one has to have the jquery ui module installed if using the library in a custom module, for redistributing the library this is not very helpful.

You also might consider support for CDN's.

Other than that, great work!

Hi Lance!

If I understand you correctly, your main problem is getting jQuery tabs to work in XModPro. Maybe you should ask the their team for support. The jQUI-DNN module is rather meant as an aid for developers wanting to use jQuery UI in their own custom modules. I have not used XModPro yet, so I won't be of much help. But if I read their product description correctly, they offer something similar to tabs with the tabstrip control out of the box, don't they?

If you can use .ascx file for templates in xmod, it would be possible for you to use this module to complement xmod, but since I have never worked with it, I don't know if this is supported. If it is, then I can probably help you.

Regards,
Christoph