Feel free. The source is open, after all.

Just to be clear, however: concrete5 was in development before the jQuery dialog class existed. Hence, our own solution.

I asked "is it possible" precisely because I had tried and failed, and wondered if someone else had tried and succeeded.

big respects Andrew!!
I knew you're a php god, but you're a javascript/jquery god now too for me!

If you mean using a regular .dialog() you can just load jqueryui when !User::isLoggedIn()
and it will be automatically loaded when you're logged in so just execute the function nobody keeps you from doing it.

the problem with that is that it won't work. since the dialog function is overidden in concrete, calling dialog() will just trigger the jQuery.fn.dialog.open() c5 uses.

i've yet to figure out how to get around this without messing up built in c5 functionality.

if anyone have any suggestions, feel free to share!

It may take some research, but you can use namespaces with jQuery.

http://docs.jquery.com/Using_jQuery_with_Other_Libraries...

Technically you'd be using jQuery with another instance of itself, but only load what modules you need and not the entire library twice.

I'm experiencing a related but opposite problem. That is, the jQuery dialog box is appearing when it shouldn't when pages are in edit mode. The reason it's happening (which complicates resolving the issue) is that for the live site, I'm using Google's CDN (content delivery network) to reference jQuery and jQuery UI. There are a number of advantages to using a CDN (including faster load times for visitors), but it means that you can't customize the library by selectively removing the dialog plug-in to eliminate the conflict.

I completely understand that C5's dialog plug-in was first on the scene, but given jQuery's popularity, I think the onus is on the C5 team to resolve this issue and make C5 developers' lives easier. If I get some time, I will look into a namespace work-around as ijessup suggests; but really, a developer shouldn't have to bend over backward to use (or not use) the native jQuery dialog plug-in. Just my $0.02 USD...

-Steve

i too think it's only fair to say that c5 is the one that should "fix" this issue. especially since c5 in general encourages the usage of jquery and the dialog widget is one of jquery's most useful ui features.

anyway, i can see how it's not getting any immediate attention as there are probably a lot of other things that get prioritized.

in the meantime, i'll probably too play around a bit with the noConflict() function. (btw, that last suggestion on the jquery page was just awful).

another suggestion which i might end up using myself is the dozens of other non-official jquery dialog plugins.

I completely agree !

I'm trying to use the latest jquery ui widget and themeroller to integrate with the auto-nav feature to have a multi-level accordion nav menu. So far I haven't succeeded because the jquery libraries that are needed are interfering with the jquery libs C5 uses.

Has anyone solved that problem and is anything being done by C5 development to make use of the latest jquery ui, widgets and effects possible ??

I am just getting started on C5 and am already running into issues with namespacing of CSS and jQuery while converting themes. To an extent I can get round it by creating my own nanespaces, but avoiding clashes is getting more and more complicated and I am constantly having to add little fixes for blocks that slip through.

When it gets to the point of many developers having to fiddle with workarounds, what was once considered a quirk is becoming a bug.

Despite the historical precedent that C5 was there first, the cleanest solution for the future would be for C5 to have its own namespace for all javasctipt and css used for the dashboard and edit mode, including jQuery plugins and jQuery UI.

So that's my request for Concrete 5.4.1.2

Here is the way I've used it (a bit of a hack).

I copied the jQuery UI Dialog section from the UI script. Then inserted it into another file to load separately. Most importantly, I changed all instances of ".dialog" to ".jdialog".

My use of it is now:
$("#mydialogbox").jdialog();

Hope this helps :)

Garry

Its funny, I have been speculating about the feasibility of the opposite hack, doing a global replace of 'dialog' within C5 and packages I am using to become 'c5dialog'. I have even gone so far as to do global searches for 'dialog' and start looking for cases where the replacement needs to be more refined than a simple text replace. But I have not dared to actually risk the change yet. Maybe on a rainy day I will make a complete copy of my development installation and give it a go.

In the mean time, I have plenty of other problems to solve, so had put this to the back in the hope that C5 sorts it out before I need it in a production system. If the next release of C5 does not, I suspect I will end up doing something like the hack you have suggested.

To anyone subscribed to this thread: you might find this other thread interesting. We're close on swapping out our built-in dialog with jQuery UI's dialog (well, making one support the other):

http://www.concrete5.org/community/forums/customizing_c5/jquery-ui-...

Thanks Andrew,

I have just done some quick initial tests, and looking good :)

All the best.

Garry