Releasing DOMAssistant 2.0 – Chainability, AJAX module, DOMReady, XPath and more
Updated October 4th 2007
The DOMAssistantCompressed JavaScript file has been updated. My compression approach was a little too effective for the special DOMReady fix for Internet Explorer, so necessary code for optimal performance was unfortunately removed. This has now been addressed, so please download the new version if you use the compressed file.
Updated October 19th 2007
The DOMAssistantCompressed JavaScript file is updated again. I noticed a problem with the elmsByAttribute method in IE where the compression resulted in a wrong reference, returning incorrect results. Download the new version and it will be fine.
Tired but proud, I would like to announce the 2.0 release of DOMAssistant! Refactored code and new features will improve what is already a vital and must-have JavaScript library for me.
Why DOMAssistant?
Some of you might say that there are already an abundance of JavaScript libraries out there, so why keep on working on yet another one? The reasons for me are simple. The existing ones are generally bloated and contain way more functionality than often needed, most aren’t modular and, most important of all, if you use some part of it, you’re locked into their syntax for whatever else you want to do.
DOMAssistant is plainly an extremely efficient way to work tightly on conjunction with the DOM without worrying about web browser caveats and inconsistencies. No matter what you do, you will always get back a proper reference to the actual DOM element, or an array of references to DOM elements. This means that you can use DOMAssistant for the tasks you want to, and then just hook in your own scripts or other JavaScript libraries wherever and whenever you want to.
New features
I talked to people, compared to other JavaScript libraries and thought about what I could do to improve my and everyone else’s usage of DOMAssistant, and came up with some nice new features.
Chainability
Basically, what chainability means is that you can perform some method on an object and then immediately follow that result with a dot and a new method acting on what was returned. This leads to the nice possibility of writing short, concise and easy-to-understand code like this:
$("container").elmsByClass("mandatory").addEvent("blur", validateInput);
The code above finds all the elements with the CSS class “mandatory” amongst the children of an element named “container”. It then loops through all of the returned elements and applies an onblur event to them to call a function named validateInput.
As you can see from this, fairly complex operations will be one-liners in the code, helping you to focus on other tasks. There’s no limit to how much chaining you can do. However, my recommendation to get legible code enabling an easy overview, use chaining, but moderately. If you do it in ten consecutive steps it might look cool, but it’s not that much fun trying to maintain or debug it later.
Exceptions
There are two DOMAssistant methods that don’t support chaining; so-called end-of-the-line methods to me. You will find this natural, though, since these two methods are hasClass and getStyle, which respectively returns a boolean and a style value. All other methods can be chained.
AJAX module
AJAX is nowadays used in almost every project, in some way or another. This virtually led to the mandatory existence of an AJAX module for DOMAssistant, which is very basic. It supports a get method where you send in an URL to get content from, and a function to call once that data is retrieved. Example usage:
DOMAssistant.AJAX.get("URL", callbackFunction)
The first parameter in the called function will be the responseText from the AJAX call.
Easier DOMReady
In the first version of DOMAssistant, support existed to execute any number of functions as soon as the DOM of a document has finished loading. There were some misunderstandings, though, that they had to be entered in the DOMAssistantLoad file. Making it easier to understand, and at the same time clearly highlighting the benefit of such a method, I have introduced a DOMReady function. It can be used in any JavaScript file you want to, and it is called like this:
DOMAssistant.DOMReady(nameOfFunction);
XPath support
Behind the scenes, XPath is now used for the elmsByClass and elmsByAttribute methods, for web browsers that support that. The idea is that one should experience faster performance and in the future, when it’s more widely supported, XPath opens up for a lot of advanced DOM selections.
Changes from previous version
Two methods have changed name: getElementsByClassName is now named elmsByClass and getElementsByAttribute is now elmsByAttribute. The reasoning behind this is mostly that since native web browser support for getElementsByClassName is starting to pop up, it shouldn’t be confused or mixed up with the method DOMAssistant offers. Another, smaller, reason is that people thought those method names were a bit long, so now they are at least slightly shorter.
Documentation
Online documentation is available in the DOMAssistant web site. There you can also download a complete PDF documentation (PDF link) and a diagram over DOMAssistant’s modules and methods (PDF link).
Sign up for updates
If you want to stay on top of what’s happening with DOMAssistant, updates etc, send me an e-mail at domassistant [at] robertnyman [dot] com to verify your your e-mail address, and I will e-mail you when anything important happens.
Acknowledgements
When developing version 2.0, I had a great support from a number of people when it came to testing, suggestions or basically just being there for me. These are (and if I miss anyone now, just let me know!):
- Martin Jansson – excellent testing, thanks!
- Niklas Lindström
- Roger Johansson
- Emil
- Henrik Box
Go use it!
DOMAssistant can co-exist with other JavaScript libraries, so download it, play around with it and fall in love! 🙂
[…] DOMAssistant 2.0 released! […]
The Complete documentation (PDF) is not exists.
Hi Robert, well done!
However I have different questions about some piece of code.
1 – You use too many var declarations! This is not an error but a code size enemy. Why don't You use a different sintax like this one?
for (var current, i=0; i
Whats bloaty with other libs that are not bloat in DOMAssistant? DOMAssistant doesnt have any community of contributers, its not well documented etc. is it even extensible? dont get me wrong, you are probably very good on javascript but a good webdeveloper isnt an expert on html or javascript or anything else, its someone who can create something inovative with whatever technology available and thats when these other mature libs are good in hand.
x16man,
Thanks, I've fixed the link!
Andrea,
Thank you! Dou you have any example where there are too many? In general, my approach is that I prefer to declare one variable each per line for readability.
Oskar,
<blockquote cite="http://www.robertnyman.com/2007/09/20/releasing-domassistant-20-chainability-ajax-module-domready-xpath-and-more/#comment-106636">
Whats bloaty with other libs that are not bloat in DOMAssistant?
File size. Lots of superfluous functions/methods and functionality that few need. They are, for the most part, not modular.
DOMAssistant has the entire web community available to provide feedback through comments, e-mails and other means. That it isn't an open source project doesn't necessarily mean that it doesn't have a community.
To me, the documentation level is good enough, it's also about at what level you can perceive the information. I could write 100 pages per method, but I don't think it would help anyone, nor make their usage of the library more optimal.
Regarding extensibility: as has been declared in the original DOMAssistant release post and other places, you can add or remove any functions you want. Since it always returns DOM references, as mentioned in this post, you can extend it with your own DOMAsistant modules or other code.
About being innovative: some people think it's innovative with things like direct methods on elements, chainability etc etc, some don't. It's all in the eye of the beholder.
Hi Robert,
it is amazing to me that you find time for quality work,
being a father, having a job. respect!
i would love to see your stuff in action,
are there any working examples to see it working?
as a noob i love to take a look and get inspired by working stuff.
Dirk,
Thank you!
One example is the Eniro web site <img src="http://www.robertnyman.com/images/sweFlag.gif" alt="In Swedish" />, one of Sweden's most visited web sites.
[…] version 2.0 of DOMAssistant. New features include Chainability, AJAX module, DOMReady, XPath and more. Looks pretty interesting, especially as it can co-exist next to other javascript libraries such as […]
I just discovered DOMAssistant via Roger Johanssons post on the subject.
Contrary to Oskar I see DOMAssistant as very different and less bloated than other popular js-libraries: Small file size, modular, easy to use and speeds up manipulation of the DOM.
Very nice work.
Jesper,
Thanks a lot, I'm glad you see it that way! 🙂
manuel,
Thank you!
I was kind of waiting for someone to ask that. 🙂
The truth is that I spent a fair bit of time testing
getElementsBySelectormethods and how well they would play with DOMAssistant. I also looked at work performed by Dean Edwards, Simon Willison and others, to verify my findings that it does take a lot of code to make it work and be consistent.And, besides, if you implement selecting elements with CSS selectors, you’d want at least CSS 2 support and perhaps CSS3 support as well, and the amount of work and code to accomplish that and to mimic such advanced functionality that isn’t available in web browsers isn’t, according to me, worth it. So, at the end of the day, I decided to scrap the idea since it wouldn’t be in line with keeping the file size and performance of DOMAssistant to a minimum; which is also part of DOMAssistant’s competitive edge towards other JavaScript libraries.
I’d rather recommend people to extensively use the
elmsByClassandelmsByAttributemethods in conjunction to come pretty close to the same functionality, but with a syntax that will probably make more sense to someone coming from a programmer’s angle. For example, to find all elements having atypeattribute set to text, and being children of any element with asectionclass name, that in turn would be children of an element with the id container:$(“container”).elmsByClass(“section”).elmsByAttribute(“type”, “text”);
In the future, though, I sincerely hope that native XPath selection will be available in all web browsers (today it is just Firefox), since it is extremely powerful and fast.
The credits question is certainly valid and just something I missed in my ambition for good compression. I will add it now. 🙂
Robert, hi. Thanks for this library. It's great for good old websites and simple web apps, and I can very much relate to your reasoning behind it's creation.
I'm just chiming in to echo this comment asking for getElementsBySelector. Everyone already know how to use those CSS selectors and IMHO it's nicer to read <code>elmsByCSS("#container .mandatory")</code> than <code>$("container").elmsByClass("mandatory")</code>
BTW, am I missing something or your compressed download doesn't match your own licence? (ie, no credits).
"In the future, though, I sincerely hope that native XPath selection will be available in all web browsers (today it is just Firefox)"
And Opera since version 9.
Maffe,
Ah, right. Thanks!
Robert,
I was specifically thinking about Simon's version. I haven't used Dean's.
With Simon's, you can do your example as document.getElementsBySelector("#container .section input[type=text]");
I agree the function is a good bunch of code, but not so much if you compare against your elmsBy functions (without the xpath advantage of course).
Regarding selector support, I think it's just a matter of documenting what's possible and what not.
But hey, it's your library and you're the guru, so this is just my opinion 😉
manuel,
If I was to implement CSS selector support, I would want it to be complete (or as close as possible). And if you check out Dean Edward's (who is a JavaScript master) code, it is indeed a substantial amount to achieve that.
Basically, it can be done, but I don't think it's worth the time nor the effort, and probably not for DOMAssistant's best.
And no, I'm no guru. 🙂
[…] The folks at 456 bereastreet are reporting about the newest release of Robert Nyman’s DOM Assistant. […]
[…] The folks at 456 bereastreet are reporting about the newest release of Robert Nyman’s DOM Assistant. […]
Can you explain the benefits of this lib to a jQuery user?
alek,
First of all, jQuery is a very competent library, no doubt about that. The benefits in DOMAssistant's favor, when comparing, would be:
– It's modular. You can use only the parts of the library you actually need as opposed to just one large JavaScript file containing all of the methods.
– File size. Although the latest, heavily compressed, version of jQuery is quite small, DOMAssistant is smaller, even when using all modules.
– You can use any method of DOMAssistant and it returns a DOM reference or an array of element references. With jQuery, you're more or less bound to only use that library's methods all the way, whereas here you can "break out" at any time.
– In my opinion, it feels like a more programmatic approach where you send in one (or several) strings to the <code>$</code> method to get DOM references. With jQuery you need to precede the id with a <code>#</code> as in CSS syntax.
So, conclusively, I'd say that I personally find DOMAssistant to be a bit more flexible and scalable.
Thanks for the quick reply.
The first point is nice, as I have sometimes thought that it is a bit of overkill to have Ajax calls supported for a page I only need selectors on, etc. On the flip side if you need all that functionality on a single page you are racking up sever hits which in the end will get a slower page load than a single larger file.
I think the third point is based on unfamiliarity with jQuery, I switch back and forth all the time between native methods and jQuery.
The final point is a matter of taste I think. I replaced CSS selector methods I had written myself with jQuery once I stumbled across it. In many cases I am not even using ids anymore. Following the CSS syntax works well for those familiar with CSS, which is larger number than those familiar w/ xpath (I am in both camps, prefer xpath, but will settle for CSS)
$("#container .mandatory") works better for me than $("container").elmsByClass("mandatory"), sure the latter is more "programmatic" for people familiar with compiled languages, but for client-side web developers the former will make just as much sense.
I doubt I will switch personally, but this is encouraging work. I think as you move toward a more unique vision/implementation you stand to offer a lib with its own special niche.
Hmm, looks nice so far. Does the event module incorporate anything like Prototype's unloadCache garbage collection? Seems like a necessity, at while IE6 is still the dominant browser out there.
alek,
DOMAssistant is also offered, with all the modules included, as either one large compressed or uncompressed JavaScript file. If you want to combine just certain modules, you can put them together in one javaScript file.
What I mean with native code is that if you use <code>$("container")</code> in DOMAssistant, you can, for example write code like this:
<code>$("container").getElementsByTagName("input");</code>
This is because the <code>$</code> method return a real DOM reference to the element with an <code>id</code> of container. In jQuery, this code wouldn't work:
<code>$("#container").getElementsByTagName("input");</code>
And that is because jQuery's <code>$</code> method doesn't return DOM references. I think (not sure) you need to do something like this to actually make it work:
<code>$("#container").get().getElementsByTagName("input");</code>.
So, that's what I mean with the difference of direct native referencing.
And, as you say, it is also about taste. The most important thing is that developers use what they like, find fit and most optimal for their usage. DOMAssistant is more targeted at giving you a solid ground for DOM interaction to build upon, as opposed to jQuery that kind of "does it for you".
My recommendation to you is to use jQuery if you like it, but my hope is that you might at least consider DOMAssistant for some small-scale project to give it a test drive. 🙂
Tom,
I'ts a valid question, and the reply is no. The way event handling is implemented in DOMAssistant, though, is that all events are channeled through a special <code>DOMAssistant.handleEvent</code> method. Therefore, you could write some code saving all events applied, loop through it and remove them.
Robert,
I totally hear what you are saying, the jQuery team has their own reasons for wrapping an object inside an extended jQuery object (Array) which requires the explicit retrieval you show for simple cases.
One interesting facet of DOMAssistant is that it could be the first lib/framework to fully embrace on demand loading. If you keep everything in very simple modules from the start and explore integration of a system like JSAN or jsPax into the DOMA core then there is the possibility of a framwork that scales itself up depending on usage. That could be really cool.
[…] Releasing DOMAssistant 2.0 – Chainability, AJAX module, DOMReady, XPath and more – Robert’s talk (tags: javascript library development dom webdev ajax chain chainability domready event xpath web developer) […]
alek,
That is an interesting perspective, and something to consider! Either way, the idea with the modularity as well is to make it easy for people to write their own modules that function on top of the DOMAssistant core.
A way to get around making all methods chainable is to simply provide all getter information through callbacks. That was the technique I used when developing DED|Chain. That way, 'everything' is chainable, and it's more consistent.
Dustin,
Thanks for the suggestion, and the perspective, although they are slightly diferent approaches.
Also, I still await a comment from you here without a link back to your or Yahoo's code. 😉
Comment update: My snappy remark maybe wasn't called for here, and Dustin is a good JavaScript developer, no doubt. Check out his alternative if you find it interesting. I'll leave my comment, though, since I don't believe in suddenly and mysteriously disappearing comments in blog posts.
Hi Robert,
I had a quick look at the library and frankly, I like what I see. Simple and easy to understand code and quickly adjustable to my needs. I was especially interested in the Ajax bit and although the same clearness of coding exists I do think perhaps some things could be improved.
Check this article: http://www.dustindiaz.com/faster-ajax/
And here’s what the MS guys think should be used for namespaces:
http://blogs.msdn.com/xmlteam…
i.e. MSXML2.XMLHTTP.3.0 or MSXML2.XMLHTTP.6.0 (scroll down a bit)
Keep up the good work!! 😉
Calm_Pear,
Thanks, I'm glad you like it, and that you find it simple and flexible!
What's mentioned in the article is to avoid doing the <code>XMLHttpRequest</code> check over and over again, which is good advice. But if you look at my code, what's returned from the first time I run it is then set as a property of the <code>DOMAssistant.AJAX</code>.
Consequently, it will only do that again if it has lost the reference or creation of the <code>XMLHttpRequest</code>; otherwise, it will just directly reference the object instance in the <code>XMLHttp</code> property of the <code>DOMAssistant.AJAX</code> object.
Regarding the Microsoft namespaces: I've been using those that have proven to be stable and solid over some time now, but I agree that in the long run <code>Msxml2.DOMDocument.6.0</code> should be added to that list.
Hi Robert,
Yes, your right… my "Quick look" was perhaps too quick 😉
Kind regards,
Marc (Calm_Pear)
Calm_Pear,
No problem at all, it was good feedback!
Haha. I had nothing to do with that last link to some article I wrote. And hey, this time I'll leave out my website in this comment. The good news about DOM assistant is that you're updating it. I haven't touched my code in months and there's quite a few bugs to work out :
Nevertheless, congrats on your latest release 🙂
Dustin.
I'm glad you took it the right way; I didn't mean any offense!
It's completely valid to link your name to your web site, it was just a mere reflection of what wa in the comment itself. 🙂
And, yeah, thanks. 🙂
Thanks for the nice library, I need the AJAX callback function to pass the responseText and a custom variable, but had no luck.
I tried to access the DOMAssistant.AJAX object but it is not available…
Any example/hint?
Thanks
Andrea,
It depends on how you want to use it, but the AJAX module is very simple in that perspective. You can send in a URL with a query string to the AJAX call if you mean that you need several parameters to the server.
If you want any custom parameter when handling the actual response, it is better and recommended that you do that in the receiving function, e.g. through a parameter of a JavaScript object or a global variable.
[…] The folks at 456 bereastreet are reporting about the newest release of Robert Nyman’s DOM Assistant. […]
[…] DOMAssistant 2.0 Die JavaScript-Bibliothek DOMAssistant ist im Vergleich zu ähnlichen Bibliotheken eine simplere Lösung für DOM-Scripting, etwa zur Manipulation von Knoten im DOM-Baum (HTML-Elementen), Hinzufügen von Events, Klassen und anderen. […]
[…] DOMAssistant 2.0The JavaScript-libary DOMAssistant is, compared to other libraries, a simple and minimalistic solution for DOM-Scripting, e.g. for manipulation of nodes in the DOM-tree, adding events, classes etc. […]
[…] DOMAssistant 2.0The JavaScript-libary DOMAssistant is, compared to other libraries, a simple and minimalistic solution for DOM-Scripting, e.g. for manipulation of nodes in the DOM-tree, adding events, classes etc. […]
[…] DOMAssistant 2.0The JavaScript-libary DOMAssistant is, compared to other libraries, a simple and minimalistic solution for DOM-Scripting, e.g. for manipulation of nodes in the DOM-tree, adding events, classes etc. […]
[…] DOMAssistant 2.0The JavaScript-libary DOMAssistant is, compared to other libraries, a simple and minimalistic solution for DOM-Scripting, e.g. for manipulation of nodes in the DOM-tree, adding events, classes etc. […]
Superb work, Robert!
One question, though. What if I'd want to reproduce these CSS selectors with your library?
<code>#navigation ul li.current</code>
If I'm not mistaken, there is no <code>elemsByTagName</code> in your library, and I can't use the DOM default function <code>getElementsByTagName</code> if I want to preserve the chainable syntax.
Ideas?
Many thanks.
[…] DOMAssistant 2.0The JavaScript-libary DOMAssistant is, compared to other libraries, a simple and minimalistic solution for DOM-Scripting, e.g. for manipulation of nodes in the DOM-tree, adding events, classes etc. […]
Andre,
Thank you! Regarding to your question, the idea with DOMAssistant is to always return DOM references, i.e. with all native DOM methods as well.
The problem with web browser implemented code, such as <code>getElementsByTagName</code>, is that it returns a <code>HTMLCollection</code> instead of an <code>Array</code>, so it's not as easy to extend as desired. Perhaps I should implement my own version of <code>getElementsByTagName</code> as well, for proper chaining support with often-used DOM methods.
To achieve what you want with DOMAssistant, in its current state, would be to do it like this:
<code>
var listItems = $("navigation").getElementsByTagName("ul");
var items = [];
for(var i=0; i<listItems.length; i++){
items.push($(listItems[i]).elmsByClass("current", "li"));
}
</code>
[…] Nyman wrote me awhile back to let me know that DOMAssistant version 2.0 has been released. New features […]
[…] DOMAssistant 2.0 The JavaScript-libary DOMAssistant is, compared to other libraries, a simple and minimalistic solution for DOM-Scripting, e.g. for manipulation of nodes in the DOM-tree, adding events, classes etc. […]