You can see in the DOMAssistant.AJAX module how to do it. Basically, it’s like this:

$("textbox-id").load("news.php");

Awaiting reply. Thanks in Advance.

I would most definitely love to test the fix ahead of release.

You’re doing nothing wrong at all, there was a bug in the :not syntax in the non-XPath version for Internet Explorer. This has now been addressed and the fix, together with some feature updates, will be released within a few days. If you need a working version right now, let me know and I’ll e-mail it to you.

In the future, please report issues at the code site. I’ve now reported and resolved this one.

Thanks for letting me know!

$('#fm1 p:not([id=cfm])')
$('#fm1 p:not(#cfm)')

May I know what I did wrong?

Interesting feedback. Although, from my point of view, I would probably not use it personally since I’m not a big fan of the chaining approach (it can easily become absurd), but I don’t see anything wrong with offering it to those who desires it.

Having an .end() method does indeed make sense, and not that hard to do, so I will definitely consider it for the next release.

Truthfully, this is the one thing I hate about jQuery. It makes it impossible to have long-lived jQuery objects that are mutations of other jQuery objects, because the parent-child relationship insures that the old ones never get cleaned up by the GC.

The alternative would be to have a .detach() method that lets you, well, detach a node set from any ancestors it has, so that it would no longer support backtracking with .end().

Absolutely, no problem. It’s rather that it seems like it is used very seldom, but rather that people make requests with certain headers and/or query string parameters to update data.

However, if I see that more people needs to POST, I will definitely implement it, since it’s very easy to do. It has just been excluded to trim down methods and file size to an optimal level, but if someone is needed it should indeed be added.

I hope they rather just provide a native getElementsByCSS which libraries can then leverage.

That would be nice, although XPath is more powerful than CSS is, and would be even better. Why not have both?

It is true that the selectors aren’t exactly the same, but at the end of the day, my preference (which is probably very clear by now ) is that supporting CSS selectors just the same way as they are in the specification is the way to go, instead of something just close to the CSS approach, with a slightly different syntax.

Event delegation is interesting, though, and looking at the next release of DOMAssistant, it would probably be a good thing to add.

Thanks for the discussion, I like this! What I hope, also, is for people to see here that there’s no fight between JavaScript libraries, but instead an open discussion expressing ideas and having different ways to implement solutions.

When it comes to sending XPath expressions into the $ method, which is a totally different thing, I completely agree with the jQuery stance that it doesn’t need to be in the core (until all web browsers support XPath, that is).

I hope they rather just provide a native getElementsByCSS which libraries can then leverage.

I’m sure jQuery’s optimization of important selectors is great; what I question, though, is making up your own names like :first instead of :first-child, :eq(index) instead of :nth-child(index) and so on. Same functionality, but one is standardized while the other is exclusive to jQuery. Why not use the same syntax for all technology approaches?

They are not the same. Please take a look at the docs for :first and :first-child. Thats a sublte but very important difference. :first-child is very powerful, but used very rarely.

If there are cases where this isn’t sufficient, though, adding a target reference is something that can easily be done. Also, just need to mention that the function called from the event gets a first parameter which is the event object itself (this goes for all web browsers).

Sure, event delegation isn’t something you deal with every day, but when it takes a several seconds to setup event handlers on a large number of elements, event delegation is a great solution, offering a lot of flexiblity in terms of adding and removing elements at “runtime”.

Several of my jQuery plugins are 100% dependent on event delegation, therefore I think that a DOM event library must support event.target with the least hassle possible. jQuery does a lot to fix event objects.

Regards
Jörn

Thanks!
Interesting question about hasClass, and returning elements instead of booleans. I think that, in my opinion, the name and expected functionality would be to return a boolean value.

Also, I think I’ve mostly regarded it as an operation to run on a single element (where it would return a straight boolean, and not an array of boolean values). If you were to want multiple elements with the same class, I think I’d rather go the CSS selector route from the get go.

But, I love that you use the power of DOMAssistant to override it with your own tweaks! If someone has special requirements which wouldn’t necessary fall into the functionality offered by the base functionality, it is very easy to build your own on top of the existing DOMAssistant code.

Having an .end() method does indeed make sense, and not that hard to do, so I will definitely consider it for the next release.

Gustaf,

Thanks, and thanks for the help with testing and suggestions!

i’ve been using a customized/tweaked domassistant since the first release (mainly beacuse it was simple and easy, and it was a great learning experience for me in DOM scripting)

(i have actually implemented/modded in an .each, and the empty array fallback, and elmsByTag too

and i’ve got one question: why does the hasClass (and the now deprecated hasAttr) return an array of booleans?

in my opinion, it would make more sense if it would filter the array and return the elements which have that particular class?

this is how i tweaked the function:

hasClass : function (className)
{
var elms = new ArrayExt ();

return elms;
}


also i think it wouldnt be too hard to implement an .end() function (for creating tree-like chained calls), as all we need is to save a reference to “parent” array into the “new” one (in the specific HTMLarray funcs), and on .end () just return the parent array (the “previous selection”)

what do you think?

Thank you very much!
And in my opinion, it is always a good thing to learn, if for no other reason to be competent enough to choose the most suitable library.