QCubed works with most JS libraries, but the one library that seems to go out of its way to ensure the best compatibility with other js libraries is jQuery, so that's the one we recommend, and are debating including in future versions of QCubed.

I've worked with the yui library and didn't run into any trouble.

I think any js will work ok.

Cheers,

Marcos

I think jQuery is best because the developer really took time to ensure it doesn't clash with other js libraries and even provided solutions in event of any expected crash. I also love the fact that books and tutorials are readily available for jQuery.

Please include jQuery into Qcubed ASAP. Thanks.

>Please include jQuery into Qcubed ASAP. Thanks.

second that :)

I'm agree with jquery idea

Actually could be a good idea migrate qcodo js files to jquery in order to improve the posibilities, I knew it could be a little tough.

Regards

enzo

I third that!

Qcodo js files to jquery even better, but probably too much work.

I'm all for jQuery.

including support for themeroller:
http://jqueryui.com/themeroller/

So we can have state of the art designed forms in any color scheme.

And the payoff to make qcodo js to jquery would be massive. Not only to rely on only one library consistently but to have a consistent gui and API.

check out this cool firefox droplet:
http://jqueryui.com/themeroller/developertool/

With this you can liveedit your qcubed themeroller-enabled form into a different color scheme..

Tronics!

Haba, before we even start themerolling, let's get the jQuery integrated in first!

Please is there a ticket already submitted for this or do I submit one ASAP?

I've been doing some work on jQuery in this ticket: http://trac.qcu.be/projects/qcubed/ticket/183. There's a patch there already, would love to hear your feedback.

I can't agree with the major opinion here. Everybody recommends simply the framework he knows best, and that's not the solution IMHO.

For instance, my entire controller data validation relies upon input masks used within QControls (and I DON'T mean only validators, but also Javascript masks that directly don't let the user input any invalid data). Those masks are implemented over a plugin that is only available for the Mootools JS framework. Although I've searched a lot, I didn't ever found any similar funcionality in other JS frameworks.

So Mootools is a must for me. My controller relies on Mootools for that simple and powerful reason: it brings a power I absolutley need, not only silly visual effects.

And JS framework incompatibilities are there. Please, don't tell me that JS frameworks are compatible, because they aren't. People who say that is simply because they have never tried and suffered those incompatibilities.

I think it's a huge error to stick QCubed with ONE JS framework and keep any QCubed developer away from all the other JS frameworks.

Fernando,

We absolutely aren't trying to keep the QCubed developers away from JS systems other than jQuery. We just need to pick ONE system that the core will use - currently, that system is a mish-mash of custom javascript that Mike Ho has written a long time ago. That code is pretty old, and has some bugs that the newest frameworks have solved.

If you are interested in pursuing MooTools, we're all for it! Write a QCubed 1.1 plugin that brings the power of MooTools into QCubed! I'm pretty confident that the two frameworks (jquery and Moo) won't conflict. Would you be up for it? Plugin infrastructure documentation is readily available.

I used to love MooTools. But MooTools is the worst Framework when it comes to Compatibility. With a lot of work I managed to get it to run with jQuery (jQuery has very advanced compatibility-options, look at their documentation). Any other JS-Framwork simply won't work with MooTools. So we had an internal vote, which Framework should be used in future. After several presantations of different JS-Frameworks jQuery made the race.

Up to now we had no big problem to rewrite all the scripts we had to use with jquery. And now it is really easy to integrate code from other sources. We will never switch back.

I can't imagine that your data validation is not possible with jQuery. Do you use custom code or a MooTools Library? Could you provide a link?

Hi Alex,

This is Rey Bango of the jQuery Project. We're very excited to hear that you're considering using jQuery for your framework & I wanted to let you know we're here to help. I wanted to bring up some points concerning how we run the jQuery project.

- The jQuery API is stable. We take great pride in the stability of our API. Every major release that we've had (1.1, 1.2, 1.3) has offered complete backwards compatibility for our users. This includes full documentation, upgrade information, and compatibility plugins. As it stands the number of API changes that we've been making is greatly diminishing - our API is quite stable at this point.

- Release synchronization. We are very experienced in working with a number of large projects and companies, synchronizing on release schedules. Right now we actively work with large projects and companies like Google, Microsoft, Nokia, Wordpress, and Drupal on every release (along with the many other developers who use jQuery) to make sure things go smoothly.

- Foundation. The jQuery project is the process of becoming a foundation - established around jQuery and its sub-projects (jQuery UI, QUnit, etc.). This will mean that the jQuery project is going to be around for a very long time to come - the source code and the licensing won't be under the control of a single person, you can feel safe knowing that the code that you're using will be here for quite some time.

- Large developer community. The importance of this cannot be understated - a large community means more people around to offer support, submit tickets, write patches, commit, and ultimately participate in the growth of the library. Currently we have around 1.5 million developers using jQuery on a month-by-month basis.

- OSS Friendships. We love working with other OSS projects to help them enhance their products via jQuery and you can count on us to help guide you if you decide to integrate jQuery into your project.

- Amazing list of companies who have embraced jQuery for their development needs: http://docs.jquery.com/Sites_Using_jQuery

Finally, a great testament to jQuery's capabilities is the fact that your core team member, Mike Hostetler, is not only an active jQuery developer but a "Friend of jQuery" who actively participates with the jQuery team in architectural and design decisions.

If you have questions regarding how it is to work with the jQuery team I can certainly put you in contact with some developers and teams who've had experience working with us.

--Rey..

Fernando: jQuery wasn't suggested since it was something people were familiar with.

We sat down and analyzed what our needs were from a JS framework perspective.
These included full compatibility with other JS, OO design, license, and active development.

jQuery is still the _only_ framework out there we have found with full compatibility. It's lucky that it also exceeds our needs in all other areas as well.

We will be enforcing the need for all QCubed js to work with noConflict enabled, which means that Mootools will still work with QCubed, and you can still do anything you wish with your app and any other JS it needs.

This is why we chose jQuery, because it allows you to use Mootools, and doesn't lock you out of doing what you need.

That's also why we won't include Mootools, because it would prevent people from using other frameworks.

Hi Rey,

this is a great offer and I'm sure that the core contributors will appreciate it. Seems it was absolutely the right decision to go for jQuery.

Andreas

Alex94040, I can't say I'm as confident as you, because I've suffered those incompatibilities and they have no maintainable solution.

Fcool, the same can be said of any JS framework: when it comes to compatibility between them, there's no good one.

And no, Fcool, there are no input masks (MASKS, not only validation) for other JS frameworks, I spent a lot of time searching for them and I didn't find anything but this MooTools plugin I already extended and modified: http://zendold.lojcomm.com.br/imask/ . Try the examples and you see that it's not a visual piece of cake that "must exist for other frameworks" just because you say it. It DOESN'T exist for other JS frameworks, and I don't have the time to study another JS framework and adapt the plugin code to it just because someone imposes the only JS framework he knows and forces me to use it.

VexedPanda, I've never suggested to integrate MooTools and I will never do, for the same reasons I've already explained. I fact, I've suggested several times to not make QCubed dependant on any JS framework due to that reasons.

VexedPanda, regarding to jQuery compatibility, it's not automatic. It requires not only the "noConflict" mode, but a certain care when coding things. And I assure you that this lazy coders (that just want glimmering visual effects) will not take it into account. I PROMISE YOU that QCubed developers will be coding QCubed controls, jQuery extensions, plugins, etc. using (for instance, just to name one incompatibility) the incompatible "$" shortcut. Then I'll invite you to come back here and tell me again about jQuery compatibility and the "noConflict" mode, when my whole controller starts to fail for some people's caprice.

In fact, QCodo JavaScript was already coded in "noConflict" mode, with every method and property conveniently well encapsulated, to not disturb you from using any JS framework you needed. Now this is over because jQuery (and any other JS framework, in fact) pushes lazy people to use external globals and incompatible class names instead of encapsulation. You might celebrate this big error, but sadly I'm out.

The "this is the best JS framework" song (that has been repeated over and over) always mean simply "this is the only JS framework I know". I only see people that claims there are no incompatibilities because they have NEVED dealt with them. I have, and I clearly see this is an error that puts all framework developers apart from choosing its needed JS features.

As I said, my controller inputs strongly rely on that MooTools plugin, and thus in the freedom of chosing the JS framework. So I'm afraid I'll be apart of this project sticking with the old QCodo just for this silly "you must use my Javascript framework" imposition brought by people who just want it to have silly visual effects integrated into the framework. In fact, I see QCubed's aim is clearly not QCodo's one, as QCodo always avoided external dependencies for very good reasons, and QCubed throws that philosophy for silly claims of "bells and whistles".

Fernando: If there are compatability issues due to bad coding in QCubed, it will be considered a bug and fixed, same as anything else. If you don't trust that the releases will not contain bugs (of any kind) that will affect your app, or that you will have appropriate ways to correct such issues, then you shouldn't be using that framework to begin with.

I'm sure there are jQuery plugins out there that are badly coded. We will _not_ be accepting wrappers of them into core, and I would assume you would not use those plugins in your site if they cause problems.

And quit harping on the "jQuery is just well known" point. I don't know jQuery. And I'm not saying there can't be compatability issues in general (or that all jQuery plugins are conflict free). I'm saying there won't be in QCubed core, and any that are found will be dealt with.

If you want to actually be productive create a ticket with your mootools sample code, and we'll make sure it still works in QCubed 1.1.

I'm not sure why you're fighting this instead of working to ensure it's done right.

I can sign my name under every word that Vexed wrote above.

Fernando-

In any open source project, code talks. When you look at how much code has been contributed and pushed into QCubed since we launched in November, you will find those who put their money where their mouth is.

We appreciate your involvement, but this has been decided. If you would like to participate in those decisions, and be welcomed as a member of the Core Contributors, I invite you to start contributing patches and helping to test code.

This is really beside the point right now, but in an attempt to help, have you seen http://digitalbush.com/projects/masked-input-plugin/ ?

In this post ( http://www.qcodo.com/downloads/item.php/151) exists a custom control that implement client side masks and utilize this JQuery plugin.

Wow. That's ironic. And very cool. :) How did I miss that?

I reviewed that jQuery mask plugin a lot of time ago, but it wasn't (and still it isn't) as powerful as needed to rely on it for later input validation: It has no automatic uppercase-lowercase capability (really needed, if you know how users work), no regular expressions masking (a really huge point), and it has some minor glitches as no possibility of hiding the mask (literals and markers) when control has not the focus. All these and more are solved in my MooTools dependant version, and as I said I have no time to migrate all my framework internals and externals just for caprice. Thanks for the attempt, tough.

Also, with only one sight I must note that both the jQuery plugin and its QCodo adaptation DO use the "$" global shortcut, thus making it incompatible with most other JS frameworks. A good example of the incoming incompatibilities I said before due to laziness in encapsulation.

VexedPanda, my contributions can't be put into a ticket or contributed INTO QCubed. I've not only made QCodo/QCubed modifications, but a whole enterprise applications framework on top of it. As two minimal examples, my date, integer and floating fields come automatically masked from the codegen (I integrated reflection for runtime automation of metadata handling), and I can additionally assign/change any mask to any QTextBox (including fixed width and regular expression masks, with preset mask objects for email, URL, currency, etc.) with no need to create a special control that accepts masking. Also my masks come automatically internationalized (date format, decimal and thousand separator, and also currency sign and position if currency mask is used) as specified by an application locale. Really huge to change it, specially when it's working flawlessy. And believe me these are minimal examples of the adaptations I made for a year for my own framework.

I understand your points, but QCodo was all made "customization friendly". I just relied in forward compatibility. My error?

EDIT:

I've just taken a peek at the plugins section and... sorry, but I can only confirm that all the "jQuery is compatibility aware" speech are just words and nothing else. As random samples, here are three more controls that are currently incompatible with most of the other JS frameworks (QTabPanel mod, QSlider and QProgressBar), but claimed to be integrated into the official SVN with no comment about compatibility encapsulation:

http://qcu.be/content/qtabpanel-plugin
http://qcu.be/content/new-plugins-qslider-qprogressbar-and-qemailtextbox

So please... facts, not words. If jQuery has really been chosen (a point I doubt) because it has a compatibility mode, USE IT, don't break compatibility and crash other people's work JUST FOR LAZINESS.

I have the feeling that I'm being nasty, but these random samples are reliable proofs that I'm not wrong in my claims. The "you MUST use only MY javascript framework" path has been taken yet, and I'm astonished to realize that no one cares but me.

We can't control all the plugins out there, and some may not play nice with other frameworks. All we can promise is that QCubed core will. And if you find something in 1.1 that relies on $ to work (right now, it should throw an error, since we do use noConflict()), please create a ticket.

The FACT is that you have yet to show a single error with your app caused by the code currently in 1.1 svn. (Plugins have their own directory, and may be entirely broken, let alone mootools compatible, so use them at your own risk. They are not part of core, and never will be unless they meet the compatibility requirements..)

Correction. The FACT is that currently I can't rely in 1.1 because my applications controller depends on a JS framework, version 1.1 IMPOSES another one, and compatibility between both is compromised. Don't bet on your security about the safety of the current code, because I promise you that developers used to jQuery WILL use incompatible substitutions without regarding about compatibility and they will not look back.

By the way, your phrase "plugins may be entirely broken" sounds like "any unstable crap is accepted in the plugins directory". Sincerely, I don't know what to answer to this, but it gives a very poor idea about the plugins system usefulness. I thought some reviewing was done, at least before putting them into the public SVN.

To note: I've just discovered that in june Mootools 1.2.3 has gone compatible with most other JS frameworks with an optional "document.id" substitution equivalent to the "$" function/object (it made me smile to read in the Mootools documentation that it's specially intended for jQuery lazy developers that don't use the "noConflict" mode). This optional replacement is always available and doesn't need to be activated as a "compatibility mode", so Mootools is truly and natively compatible in this way.

I'm not sure if there will be some other incompatibilities with jQuery to be found (tipically they are in global classes named "Class", "Event" or common names like those), but the "$" selector was the most critical one. I think I can easily adapt my QCubed-based framework to the simple Mootools compatibility replacement for selectors, so by the moment an apparent solution has come from Mootools.

But all in all, I'm still disappointed by the IMPOSITION of a JS framework that personally I don't plan to use. You should better include it with the plugins and never in the core.

Fernando,

Allow me to address some of the concerns you brought up:
1) "Plugins may be entirely broken": just like Firefox makes no promises about the usefulness / working state of its plugins, QCubed makes no promises about community-contributed plugins. Think of the plugins as an officially supported way to extend the framework. You wouldn't blame Microsoft for every crappy Win32 app out there, would you?

Our goal is to create a community that will vote and comment on the plugins, just like Firefor or jQuery, so that the customers would know exactly what's good and what should not be trusted.

2) On "imposition" of a single framework: QCubed is an Ajax platform. It makes asynchronous requests back to the server to support some of the most core pieces of functionality of the framework. This means that QCubed can either write its on Javascript engine (very bad idea for a number of reasons - this is one of the core reasons why QCodo has failed as a project), or use one of the JS frameworks out there. We've chosen jQuery; note that our goal is to NOT impede on the freedom of an individual developer to use Moo or anything else. We are, and will continue to, use the noConflict mode in jQuery. All of the core code will be perfectly compatible with other JS frameworks.

You have raised some doubts in my point of view.

- So plugins are a world apart, and jQuery is necessary for them only if you use jQuery plugins. That's right for me, but please just don't include them in the releases as long as they're not tested against some fatal KNOWN issues.

- QCodo original Ajax engine DOES work, and it's a fact that it's light and it does a very good job. I know it internally, as I've tweaked it in several ways. So, from your words, now I can't see why QCubed has to rewrite the Ajax engine to rely the same functionality it has now on an (unnecessary, from your explanation) external JS library.

Maybe I'm simply not understanding your explanation, but I can't see the point when you talk about QCubed adopting a big external Javascript engine to do the same things that QCodo Javascript engine already does. Because, apart of the Ajax engine (that the framework already has), all the rest of Javascript "doable" things (actions, controls and panel effects) can be perfectly contained in plugins.

To summarize: Why is jQuery in the core? Seriously, what things are needed and currently planned in the core that rely on jQuery and are not already there? Please don't be abstract in the answer, as I know the Javascript core very well. I really thought that jQuery was just going to be used to add "bells and whistles", but you have raised me this true doubt when talking about the JS core as a thing to do.

I hope the answer is not to rewrite the Ajax engine, client control handling or actions system just to base it in jQuery, because that is entirely unnecessary. I truly hope that the answer is not to add visual effects either, as this is never the purpose of a PHP framework and must be done in the view layer.

P.S.: Sorry, but to base the fail of QCodo in its light Javascript core seems an oportunist and tendentious idea to me. It's well known that QCodo failed because its developer discontinued the project without opening it to other developers, a fatal hit in any free project community.

Mike Ho intentionally kept the JS core small exactly to allow the controller to be infinitely extensible with any Javascript module a developer would like to use (I myself took this idea when I heavily extended the controller engine). And in fact he did all the necessary Javascript to make the framework rule as intended, and kept the "bells and whistles" Javascript election intentionally apart from the model-controller PHP framework, as it has to be.

Fernando - first of all, thank you so much for respectful, constructive tone.

Secondly, for v1.1, we are not adding jQuery to the core. There's no core dependency on it whatsoever. If you don't use plugins that use jQuery, you don't get jQuery in your downloaded JS files. Period.

Third, plugins are not going to be bundled with the core distro. That's why they're plugins. You will get the core 1.1 distro, and will hand-pick the plugins that you want. So if you don't want the jQuery plugins - don't take them.

I hope these first points address your immediate concerns. Now, I will move to a long-term vision discussion.

I personally am not the best person to talk about the details of the core JS engine. The other core contribs (VexedPanda, Basilieus, Mike Hostetler) are much stronger in the nitty gritty details. So my answer, unfortunately, has to be a bit abstract.

I think every framework needs to have its specialization. With QCodo/QCubed, the strength is clearly in code generation and (somewhat less) in event-driven, stateful MVC forms. QCubed offers a high-level abstraction; that means that leveraging existing low-level abstractions is a good bet in terms of not spreading ourselves thin.

You are exactly right that the core AJAX framework that Mike Ho put together in QCodo actually works OK. It's indeed very light. It does the job OK. However, we keep seeing subtle cross-bugs that are VERY hard to fix for a team of non-javascript developers. Here at the QCubed core team, we are not hardcore JS developers. We don't know the subtleties of Chrome versus Safari. Heck, we don't want to know them. We want them to be someone else's hassle.

That's why over the long run we want to move the AJAX core to an established library. To reiterate, this is because we don't want to maintain the burden of supporting a custom, hacked-together, complex piece of JS that keeps leaking everywhere.

Your point on on the reasoning behind the fail of QCodo is well taken. That was a cheap shot on my part :-).

There are new browser versions popping up every month now.
The whole open source community is so fast no one keep track now of anything.

We cannot fight on each end.

It makes sense to integrate the best from the best into qcubed and leave e.g the HUGE task of Javascript development to a community that has more then 1,5 million active members.

With patches, accessible ARIA style plugins there. The work from filament group is unparalleled also when looking at themeroller and form elements.

This will rock the world, make it happen.

Alex, it seems we have reached an agreement here. Good decision not to include jQuery if it's not necessary, and (finally) someone has exposed a convincing reason to adopt a particular Javascript framework.

Anyway, two points to keep in mind:

- Most web developers are web designers but not hardcore programmers, so (although you have explained a different and very strong reason) you should agree with me that most people is asking to adopt a JavaScript framework only to have visual effects and nice widgets. If that comes, that kind of features MUST be in the view layer, and not in the controller. Some QControls may have something to do about it (as they render the visible part of the controller), but definitely not the core controller.

- In the long term, when rebuilding the JavaScript core to adopt that externally maintained JavaScript framework, please try to keep two eyes in not to break backwards compatibility. I understand that things must evolve and the core may change, but customized controls and controllers are a thing to maintain between versions, or else customization is just a lie. Maybe an optional compatibility wrapper should be a very convenient idea, please think about it.

Those of us that have relied in customization to adopt and extend this Q-framework will always have understandable concerns about core changes. Same happens with changes in the code generator, templates reorganization and directories being moved from one version to another, but those are other stories, I'm talking only about the controller right now.

For instance, changing in the core things like JavaScript event dispatching or the way that actions are triggered should break internally the backwards compatibility of the QForm-QEvent-QAction triad (that great creation that makes QForms such a wonderful PHP port of ASP, different to all other PHP or JavaScript frameworks that only target to do webs but not applications), thus breaking also any existing customization (not to talk about hacks). That should be a death blow to the idea this framework was made for. If the core changes, I'm very concerned about this kind of things that would render incompatible months and months of customizations work.

Basically, we will work really hard to keep the standard QCubed API the same. So you should still expect to use AddAction with all the same syntax as before.

If, however, you have written custom js that took advantage of some existing QCodo javascript functions that aren't used in most of the apps, some of those low-level elements may end up changing.

It's hard to say at this stage what those will be, and we will do our best to define wrappers to maintain backwards compatibility, but I expect some areas to be rewritten with a different approach that doesn't lend itself to replicating some depreciated QCodo functionality.

@VexedPanda Ah that comment is somewhat a relief to me.
Glad to hear we are still going towards JQuery with 2.0.
At one point I was very dissapointed because this discussion invoked an impression in me that people still like the current JS to stay.
In the longterm we will have much less hassle with new browsers and so many advantages to a custom not supported JS solution.

Cheers,
tronics

JQuery 1.4 just got released. Should be mostly API-compatible to 1.3 and got some good speed improvements.

I just opened a ticket for the 1.1.1 release to include the JQuery 1.4 bits: http://trac.qcu.be/projects/qcubed/ticket/428

So how would we integrate JQuery into QCubed?
I have been experimenting with converting the ajax post from QCubed into an ajax post using JQuery. It seems to work :)
how deep and where would we need JQuery integration. I have some time on my hands this week, so I could take a good stab at it!

Kristof

Cool stuff @kmeirlaen
Yes please post it.
I am 100% positive to get rid of all proprietary stuff and change to JQuery.
Even if we don't use it everywhere in the beginning let's start now.

Cheers,
tronics

Kristof - Basilieus started some experiments on exactly the stuff that you're describing - making Ajax callbacks go through jquery instead of the custom QCubed JS code. He's checked in half-working code here: http://trac.qcu.be/projects/qcubed/browser/experimental/qcubed2jquery.

Feel free to use it as a starting point / keep iterating on it! Or, if you want, feel free to start from scratch.

That is great! I'll check it out and see how it goes.
What are the other things we can/should integrate?
And can I checkin code freely into the branch without going through trac? Or do we keep the guidelines for this?

Thanks,
Kristof

You should feel free to check in freely into the experimental branch - that's why it's separate from the main stuff. When you have a stable / working thing, we'll slowly integrate it over.

The main stuff - getting all the events to work through jQuery - would be a huge thing. The next up would be using jQuery controls in place of QCubed controls.

And somewhere in there we'd like to make everything fall back gracefully for browsers with no or limited js support.

After some issues (mostly related to PHP 5.3) the branch is now working on my side.
Having a look at the work of Baselius, the ajax part is mostly working (at least from my limited testing perspective) and events seem to be integrated using jQuery, but I need to takea further look on how Baselius has come along with this.
Taking a look at the jQuery 1.4 release, is this the release we are aiming to include in QCubed? I would vote for that as there are many improvements in the new release.
Interesting for QCubed are:
- performance gains
- Event Multi-binding (http://api.jquery.com/bind/)
- `change` and `submit` events normalized (http://api.jquery.com/change, http://api.jquery.com/submit)
The change and submit events work reliably across browsers for both normal and live events. We override the normal change and submit events in Internet Explorer and replace them with events that work identically to the other browsers.

There are many others of course!

Should we also aim at CSS compatibility with jQuery (like ThemeRoller).

Kristof

> Should we also aim at CSS compatibility with jQuery (like ThemeRoller).

Yes totally, this is where we will want to be in a few month.
All the current css and styling is far from what themeroller will bring us.

Kristof, I am SO excited about this. If we can get a development release of QCubed out the door that has jQuery integrated, it would be HUUUUGE. Enormous. It would transform this community in a great way.

To answer your question: yes, we definitely want to ship with jQuery 1.4. In this experimental branch, in order to be most agile, I encourage you to do whatever most makes sense to you: for example, if you're seeing templates missing for controls, just add them if it makes sense. Don't have to ask permission here :) That's why it's the experimental branch. You build whatever you'd like, then show it off when you're ready; we then all review it and scream "OH MY GOD this is so hot" :-)))

I know Basilieus has been incredibly busy in the past few months, I don't know if he can help you much this week.

JQuery 1.4.2 just got released. It has some internal changes for the event binding. So for 2.0 we maybe should use this soon, to see if it all still works.

http://blog.jquery.com/2010/02/19/jquery-142-released/

Sure, keeping up with jQuery releases won't hurt. I don't want to make integrating every single dot release of jQuery a top priority, though.

akrohn, if you feel like integrating it into 2.0 and 1.1, go ahead! We'll gladly check it in.

JQuery UI 1.8 just got released and has interesting things to offer. There is now an autocomplete plugin available which we could use for our current autocomplete plugin.

News: http://blog.jqueryui.com/2010/03/jquery-ui-18/

Autocomplete-Plugin: http://jqueryui.com/demos/autocomplete/

That would be great because, there is a conflict between the existing autocomplete and jQuery sortable. If you have an autocomplete on the page, sortable is blocked for some reason. See ticket #536.