DOMAssistant 2.5 released – CSS selector support, new AJAX methods and more goodies added!

After listening to a number of JavaScript developers, seeing how they work in real life and analyzing their needs, I’m happy to provide the heavily updated DOMAssistant 2.5!

What’s new?

First, DOMAssistant is almost completely re-written, to focus on performance, ease-of-use and the most useful features, while trying keep the file size as small as possible. The new major features are:

CSS selector support

Using CSS selectors have almost become a de facto standard in the major JavaScript libraries. Previously I’ve been a bit hesitant to introduce them, but since everybody loves them and think they are great to use, I have added support for them. And, to be honest, they are a fantastic and easy approach to select element(s), so I’m glad I did!

DOMAssistant supports CSS 1, CSS 2 and CSS 3 selectors to get a reference to the specific elements you want, with just a short CSS statement away. And, as opposed to other JavaScript libraries, the syntax for the CSS selectors are exactly the same as specified by W3C. Therefore, you don’t have to learn anything extra to use CSS selectors with DOMAssistant, just use the technology you’ve already adapted.

Read the complete list of the different CSS selectors you can now use for more information.

New AJAX methods: load and get

Previously, the only way to make an AJAX call was like this: DOMAssistant.AJAX.get(url, functionToCall). Looking at how most people use AJAX call, and also the need to be in an element’s context with the returned content, I’ve added one new method, and tweaked the existing get method. Now, they can both be used directly on an element.

The load method

The load method will go to the provided URL and then automatically load the returned content into that element. Like this:

$("directions").load("maps.php");

It also provides a second, optional, parameter if the returned content should be appended to the element’s already existing content. This defaults to false, i.e. replace the existing content, if not specified:

$("directions").load("maps.php", true);

The get method

The get method works like before, where you call it on the AJAX object and then call a function with the returned content. What’s new, though, is that you can also call it directly on an element, and the function called will be within the context of the element that called. Let me show you:

$("news").get("news.php", insertNews);

function insertNews (returnedAJAXContent) {
// The keyword this in this function is the element with an id of "news"
}

Helper methods

There are also a few helper methods to make it easy to track the state of any current requests. These are:

getReadyState
Returns the readyState of the current AJAX request.
getStatus
Returns the status code of the current AJAX request.
getStatusText
Returns the status text accompanying the status code of the current AJAX request.

The elmsByTag method

This method does just what it says: it selects element’s by their tag name. This code would select all the a elements which are children to the navigation element:

$("contact-form").elmsByTag("a");

The each method

A feature which has been long requested is to have an each method to easily iterate over all elements returned from an element selection. They way it works is that you call a function for each item in the collection:

$("#navigation a").each(function () {
// Do some JavaScript magic
});

What has changed?

DOMAssistant 2.5 is supposed to be completely backwards compatible. That means that if you don’t want to use CSS selectors, or you have written a lot of code that’s dependent on the previous version, it should work just fine. The nice part about this is that if you like CSS selectors, go crazy with them; if you prefer a more method-based approach for each selection, that will work too. These two code samples do the exact same thing:

$("#contact-form input[type=text]");

$("contact-form").elmsByAttr("type", "text", "input");

Note that if you want to reference an element without the CSS selector approach, its id should not be preceded by a # mark. If you have it there, it will be regarded as a CSS selector. A little tweak of this is that if you only send in one value containing just text to the $ method, it regards it as an element id, and not as a CSS selector. This means that this code will only look for an element with that id, and not elements by that tag name:

$("div");

Frankly, it’s a design decision by me that it’s usually unlikely that you want, for example, all the div elements in a web page (from a design perspective, very useful; but not as much from a scripting one). Therefore, if you still were to desire all elements of a certain element type within the document, you have these two options:

$("body div");

$(document).elmsByTag("div");

Another difference is that a CSS selector approach will always return an array of elements, and if there’s no match, it will return an empty array. This mean that chaining etc will fail silently if there’s no match, instead of throwing an error. However, if you do refer to just one element with its id, it will return null if there’s no match. This means that you can use different strategies depending on what you want to use it for. Take a look at these two ways to refer to an element, and what they return if it isn’t found:

// Returns null
var elm = $("container");
if (elm) // Return false

// Returns an empty array
var elm = $("#container");
if (elm) // returns true

Contrary to these examples, though, I strongly encourage you to use typeof, checking length etc to really make sure something exists and is what you expect it to be, before you try to do any operations on it.

Code quality and performance

I’ve worked very hard to write as good and consistent code as possible. DOMAssistant now creates its own scope to make use of private properties, and the modules now have the same disposition and structure as the core module. The whole library is JSLint validated, to make sure the code is top-notch and to avoid any runtime errors one might encounter (except for a conditional comment workaround in the Load module to cater to Internet Explorer specific needs).

It also introduces a namespacing model, where DOMAssistant is the main object and each module is an extended object related to the core one (DOMAssistant.CSS, DOMAssistant.Events etc). But don’t worry whether this will make your life harder; the syntax for the end user is easier than ever, and this is just to ensure code quality behind the scenes. Ease of use and good object structure should not collide with each other.

Performance

Something I find important is to avoid memory leaks in Internet Explorer, for those occurrences when it fails to clean its garbage collection. IE is a very fragile web browser, and it needs to be treated with care. My measure has therefore been to test DOMAssistant together with Drip to make sure no performance is lost, together with making assertions to clean up the code when using innerHTML features to replace already existing code in the document (described more in JScript Memory Leaks).

Another inspiration has been Dan Webb’s metaprogramming JavaScript, which has inspired me to write self-learning code that will be even faster and smoother to execute!

Utilizing XPath

Most major web browsers, but Internet Explorer, has support for XPath. XPath is a great way to reference elements, and with its native support in web browsers, the speed and cost of performing operations outmatches anything by a regular script. The Opera web browser, unfortunately, has some minor problems in its XPath implementation, so for now it defaults to using the script-based version which IE is using too (these bugs will be reported to Opera in the near future).

My take on JavaScript libraries

The way I see JavaScript libraries is that they should be there for you like a tool belt. At one time or another during they day, you will have a need for each respective tool and it will be there to make your life easier. Most JavaScript libraries out there, though, seem to be more like a storage room: let’s fill it with useful things that you might need one day, perhaps.

That’s not for me. DOMAssistant is completely modular, and all modules together consist of core functionality that I believe everyone needs in their daily JavaScript work:

  • Element selection (through CSS selectors or enhanced methods).
  • CSS handling (adding and removing CSS classes).
  • Event handling (adding and removing events).
  • Content manipulation (add or remove elements).
  • AJAX interaction (getting content from other sources, and adding it to the document).
  • DOM loaded (calling functions when the DOM is loaded, as opposed to the document with all dependencies).

It should be noted that DOMAssistant does in no way alter your CSS through some hidden-away inline styling deep in its core. On the contrary, DOMAssistant wants you to have all your styling in separate CSS files, and use the addClass and removeClass to change the styling of an element. Total separation between presentation and interaction, just the way it should be.

Getting serious

With this release of DOMAssistant, I feel that it can seriously compete with the major JavaScript libraries on the market. It has a very easy syntax to select or manipulate elements, and with the core functionality anyone needs, without having to worry about web browser differences, the compressed version with all modules included weighs in at a mere 6kb (Gzipped). If Gzipping isn’t an option for you, the compressed version lands at 21kb.

Bug reporting

From now on, DOMAssistant is hosted by Google code, and with that comes a simple way to report any issue you might encounter, for me to take a look at and quickly fix as soon as possible. It also makes any problems visible to the public, so you can see if it is already being worked on, and at the same time offers all the available downloads for DOMAssistant in one simple interface, where you can go back to a previous release, if you were to encounter any temporary problem with the last released one.

Help me help you!

Please download a copy of DOMAssistant. Play around with it, kick its tires, corner it and try to take its lunch money. See how it reacts to your needs, learn to love the consistent syntax, and, most of all: let it do the dirty work for you so you can focus on the fun parts!

Let me know what you think, and don’t hesitate to contact me if you have any questions! Happy JavaScripting!

 

Acknowledgements

Thanks to everyone inspiring me and helping me! Extra thanks go out to:

39 Comments

  • […] DOMAssistant 2.5 released – CSS selector support, new AJAX methods … By Robert Nyman What’s new, though, is that you can also call it directly on an element, and the function called will be within the context of the element that called. Let me show you:. $("news").get("news.php", insertNews); … Robert’s talk – http://www.robertnyman.com […]

  • […] CSS seçicileri ile taray?c? versiyonlar? aras?nda sorunlar?m?z var, bunlara çe?itli çözümler üretiliyor. Ço?u javascript ile üretilen bu çözümlerden bir tanesi daha burda ayr?ca daha fazla seçici var. Ba?lant? […]

  • Pär T says:

    Good work! Can't wait to try this new version!

  • Andreas Arledal says:

    Good work Robert! I've got an ongoing project where I've been planning to use DOMAssistant. I will definitely try the new version, it looks great.

  • Dave says:

    This looks very good, but it seems to be very similar to JQuery. Have you looked at the JQuery code and try removing the stuff you don't need to make a more comapct library? You could combine forces to improve them both.

  • Robert Nyman says:

    Pär, Andreas,

    Thank you! Enjoy! 🙂

    Dave,

    It is indeed an interesting idea, to join forces. In my opinion, jQuery is very competent, although the core has a little too many features for my taste.

    Besides, the difference here, as mentioned in the post, is that the DOMAssistant CSS selector syntax exactly matches the W3C syntax, as opposed to some jQuery features. And since jQuery has become quite widespread, I think it would be hard to implement "proper" CSS syntax withouth breaking all existing implementations.

    Therefore, I think its ok to have two separate libraries, with slighty different goal objectives. What I do think is the responsibility of every JavaScript library developer, though, is to have a syntax very similar to each others', so any coder can easily switch between them, and choose the one that suits them best in that context.

    Meaning, for one web site, jQuery might be the best choice, while for another you might want DOMAssistant. Using the core <code>$</code> method and, for instance, CSS selectors, makes the code look exactly the same, and very simple to adapt the granular details to make it work with any JavaScript library you want to choose.

  • Dave says:

    Good point Robert. Looking through the code, it does look very good. Keep up the good work.

    I like the idea of having similar code written with different JS libraries. It would be nice to have plugins compatable with many libraries too, or compabability plugins to make them work together. E.g. having a compatability plugin to allow me to use jQuery plugins with DOMAssistant, or Prototype plugins with jQuery, etc.

  • Harald says:

    I like your ideas even if functions like elmsByTag are not very descriptive. No verb and abbreviated, makes it harder to remember the API.

    When you find jQuery too unmodular, the features you describe here are all separated in MooTools modules. Is a modular architecture for domassistant planned?

    When you don't need for example Ajax in your project you simply don't add that MooTools module to your download. The nice thing about a modular architecture is that you can separate the Effects, Cookies, JSON features from the core and make them optional.

  • Robert Nyman says:

    Dave,

    Thanks! And yes, plug-ins compatible for several JavaScript libraries would indeed be nice.

    Harald,

    DOMAssistant is indeed completely modular, just like MooTools. All modules are packaged together since I believe most people need all of the modules, but if you look at the documentation and the download page, you can see that all modules are available as stand-alone modules if you want that.

  • Jörn Za says:

    Hi Robert,

    as a jQuery developer this project is quite interesting: The design seems to be very similar, while several design descision are made that jQuery did before or avoided, because each turned out to be a mistake in one way or the other.

    One example is the $("id") selector which is not the same as $("#id"), but causes a lot of trouble for only one character less.

    jQuery removed XPath-support in 1.2 (delegating to a seperate plugin for anyone still interested) and focusing on faster standard CSS selectors instead.

    jQuery also tried to fully implement CSS3 selectors, and while most of it is implemented as specified, it turned out that there is hardly any developer who ever worked with CSS3, so most of those selectors are hardly ever used anyway. The benefit of optimizing the important selectors (id, class, children, descendant, by attributes) turned out to provide a way bigger benefit for everyone.

    An interesting idea is the get method, providing the selection as the scope for the callback.

    Could you explain how DOMAssistant's structure is any different to jQuery apart from jQuery core's additional animation support? Everything else seems to have a very similar feature set.

    On that matter: jQuery's code in it's repository is split into different files, allowing you to create your own build if you need it, eg. leaving out ajax and animations modules. But for anyone new to jQuery it is most convient to just start with the "full" package, without having to worry which modules are necessary. This gives plugin authors the advantage that the core package is always a present dependency. If anyone actually decides to leave out ie. AJAX, he must be sure that no plugin uses the AJAX module, and that is definitely something a beginner won't want to worry about.

    One more thing: What I'm badly missing on the DOMAssistant site is running code. The site doesn't even include the code, so I can't take a look with Firebug without downloading it. And usually I'm taking a look with Firebug and everything I stumble about… Its awesome how fast you can become that dependent on a Firefox addon…

    Due to google's behaviour of forcing a download on the .js files I can't even take a look at the files in the browser.

    Anyway, you need demos! Lots of demos!

    Something I noted while looking at the Event docs (and because I spent quite some time on jQuery's event module): It doesn't look like you provide anything for getting the event target (which is annoying in IE (event.srcElement) and really annoying in Safari (event.target can be a textNode, which is completely useless, you need to get the parentNode). The event.target property is essentiel for proper event delegation architectures, which are essential for building proper performing web applications (see http://docs.jquery.com/Types/Event#target).

    Looking forward to hear your thoughts on that stuff. Keep up the good work!

    Regards

    Jörn Zaefferer

  • BlueClock says:

    Have you considered nominating DOMAssistant to be hosted at cachefile.net

    They host JS libraries on their server. Any site using their server stands a chance of receiving page views from other sites that use the service as well. In other words the library would already be cached on the client machine.

    They already host about 20 JS libraries and have a interim CDN solution in place as well.

  • This is really nice! I agree with some others' observations that it has a lot of similarity to jQuery — $('…').load(url) to do an Ajax update, for example — but hey, more competition in the marketplace is always a good thing, as is staying simple and modular. Cool stuff.

  • Pelle says:

    Very interesting release – I hope I can test this one out very soon 🙂

  • […] eyes set on providing a JavaScript library that can hold it’s own against the major players. He just announced the release of DOMAssistant 2.5 with enhancements that he feels are on par with other libraries: With this release of DOMAssistant, […]

  • […] eyes set on providing a JavaScript library that can hold it’s own against the major players. He just announced the release of DOMAssistant 2.5 with enhancements that he feels are on par with other libraries: With this release of DOMAssistant, […]

  • Robert Nyman says:

    Jörn,

    Thanks for visiting and commenting!

    <blockquote cite="http://www.robertnyman.com/2007/12/17/domassistant-25-released-css-selector-support-new-ajax-methods-and-more-goodies-added/#comment-164704"&gt;

    One example is the $(”id”) selector which is not the same as $(”#id”), but causes a lot of trouble for only one character less.

    Absolutely, and I weighed back and forth on this. One option might be to use a second boolean parameter, forcing the <code>$</code> method into DOM mode, otherwise it will be CSS selector mode. Still considering what's optimal here, though, while respecting backwards compatibility.

    Regarding XPath: As I've understood it from John Resig, jQuery doesn't use XPath behind the scenes, but instead "regular" JavaScript. In my opinion, if XPath support is there in the web browser, it should be used to get a better performance, and at the same time less code (one day, I guess XPath is all we'll need, but that day is far ahead in the future).

    When it comes to sending XPath expressions into the <code>$</code> 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).

    CSS selectors: I'd say that even if many web developers don't know the CSS 3 syntax, they will eventually need to learn it. And why not use the same for the script, to avoid misunderstanding issues then? I'm sure jQuery's optimization of important selectors is great; what I question, though, is making up your own names like <code>:first</code> instead of <code>:first-child</code>, <code>:eq(index)</code> instead of <code>:nth-child(index)</code> 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?

    Interesting about how you can build your own version/feature set, although I'd humbly suggest that this should be more clear and evident to the end user. Agreed that the full package might be the best way to introduce a beginner to it, to avoid confusion.

    Running code and demos: I definitely agree that I need more of that, and I think the jQuery web site is setting a great example for everyone in this area! My hope and aim is to get there in time, although I think that the existing documentation is sufficient for anyone to start implementing code based on DOMAssistant. My feeling, though, is that few people are as advanced web developers as you are and download the JavaScript files and test with their real-life situations as opposed to playing around with Firebug at the demo site. 🙂

    Event handling: Just like with the <code>get</code> method for the AJAX module, every function called from an event added using the <code>addEvent</code> method is run in the context it is called in. I.e:

    <code>$("my-link").addEvent("click", eventHandlerFunc);</code>

    <code>function eventHandlerFunc (evt) {

    // The this keyword here refers to the element "my-link"

    }</code>

    Usually you always apply the event to the element you will consider as the target in the function handling the event, and therefore don't have to worry about text nodes and their likes. It also adds the simplicity of using the <code>this</code> keyword, knowing that it will always refer to element the event occurred on.

    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).

    To conclude, and to answer the question about the similar feature set: jQuery is a very competent library, with some great features, no doubt. I've just decided to implement some things slightly differently; XPath usage and standardized CSS selector syntax, as well as a different method syntax and module structure. Some people will prefer the jQuery approach while others will want the DOMAssistant way of doing it. So, to me it's about giving users option, which slightly differ from each other, so they themselves can choose what path they want to go.

    Therefore, you keep up the great work, too, and thanks for inspiring the JavaScript community! 🙂

    BlueClock,

    Sounds like an excellent idea! I will definitely do that.

    Frederick,

    Thank you! And absolutely, some features and syntax is inspired by jQuery, where I think they have been spot on with their ideas.

    Pelle,

    Please do! 🙂

  • Fantastic work! 😀

    We are about to set up working guidelines for upcoming projects at work, and the libraries we have used until now is more like useless bytes to download instead of actually making things any better for anyone.

    DOMAssistant is definitely something I should take closer look on and have in mind next meeting.

    (Personally, I don't use libraries at all since I learning DOM scripting and want to master the core before making anything easier for myself. But in business, this isn't really a good sell argument. :p)

  • Robert Nyman says:

    Anders,

    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.

  • Raziel Anarki says:

    great news!

    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:

    <code>

    hasClass : function (className)

    {

    var elms = new ArrayExt ();

    for (var i = 0; i < this.length; i++)

    {

    if (bseDOM.hasClass.call (this[i], className))

    {

    elms.push (this[i]);

    }

    }

    return elms;

    }

    </code>

    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?

  • Great news, Robert. Since I'm already using DOMAssistant for one project I'm working on I will happily upgrade. Some of the features will really simplify things.

  • Robert Nyman says:

    Raziel,

    Thanks!

    Interesting question about <code>hasClass</code>, 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 <code>.end()</code> 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!

  • Jörn Za says:

    Thanks Robert for responding.

    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

  • Robert Nyman says:

    Jörn,

    <blockquote cite="http://www.robertnyman.com/2007/12/17/domassistant-25-released-css-selector-support-new-ajax-methods-and-more-goodies-added/#comment-165176"&gt;

    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.

  • […] Nyman has released the new version of DOMAssistant (DOMAssistant 2.5) with numbers of new […]

  • […] DOMAssistant 2.5 released – CSS selector support, new AJAX methods and more goodies added! […]

  • Doug says:

    Your AJAX module only implements GET. Seems like it would be easy enough to add POST.

  • Robert Nyman says:

    Doug,

    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.

  • 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().

  • Robert Nyman says:

    Frederick,

    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.

  • chenghong says:

    <code>

    <form id="fm1">

      …

      …

      <p id="cfm">…

    </form>

    </code>

    I want to select all p within the form except the last one. But both the following selectors didn't work. Nothing was selected.

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

    $('#fm1 p:not(#cfm)')

    </code>

    May I know what I did wrong?

  • Robert Nyman says:

    chenghong,

    You're doing nothing wrong at all, there was a bug in the <code>:not</code> 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!

  • chenghong says:

    Thanks for fixing the bug!

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

  • Karthik says:

    I have a set of functions in php for database interactions. I want to call that from a html page using AJAX calls and display the returned results in a text box on the html page. IS that possible?

    Awaiting reply. Thanks in Advance.

  • Robert Nyman says:

    Karthik,

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

    <code>$("textbox-id").load("news.php");</code>

  • […] whined, and said I really liked the CSS-selector syntax that jQuery has. So he added support for CSS1, CSS2, and CSS3. The […]

  • […] DOMAssistant 2.5 released Quote: CSS selector support, new AJAX methods and more goodies added! […]

Leave a Reply to Robert Nyman Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.