Handling the changing DOM structure with AJAX forms

[Xeoncross]

I have a site that makes all page requests via AJAX.
I also have a comment form that will send the data via AJAX.

Now here it the problem. When you first go to the site there is NO
comment form anywhere in the DOM, then a user clicks on a story and I
sends off an AJAX request for that page and it returns some elements
than contain the form and are inserted (?) into in the DOM. (As far as
I remember, Mootools auto-refreshes the DOM on it's own.)

Ok, so I can't add a window.addEvent('domready', function() {}) to
scan for the form on page load - as the form won't show until the user
goes (via AJAX) to a page that has a comment form.

Now, I guess that I can set Mootools to intercept the form submit and
send it via AJAX after the AJAX call for the page completes - however,
what if the user submits the form and then goes to ANOTHER page with a
form and fills it out and tries to submit it? Will I end up with too
many instances of the form AJAX call? Will I start wasting objects? Or
will mootools reset the AJAX/form call each time DOM elements are
added?

[Xeoncross]

Ok, after every AJAX call I just recheck the DOM for the form element
and create
another instance of the form ajax. I am just not sure if over time
this will cause a
buildup of useless objects thereby wasting RAM.

I am hoping that Mootools is smart enough to delete objects that
reference a DOM
element when that element is removed from the DOM...

[aowie]

One way I have seen do a good job with this, is to split up the js
related to each ajax call into their own files. So if you have an AJAX
call for login & one for registration, then you have a complimentary
js for each of those. You can then load the js how you want (I use
Assets library) after the AJAX call is completed. The new DOM will be
loaded and then the external js fires and recognizes the newly added
DOM.

[Xeoncross]

Well, that is a good idea - however, it wastes ram even more than
what I listed above. Each time a page was loaded that JS file would be
re-added as an asset and the old JS variables would problem still
persist in
memory.

[nwhite]

How much memory are you talking about? How long is the page open? Most browsers do a really good job of garbage collection. Using mootools helps that even more. You might want to take a look at premature optimization, it has been the death of many projects.

[Xeoncross]

On Dec 9, 5:43 pm, nwhite <changereal...@gmail.com> wrote:
> How much memory are you talking about? How long is the page open?

The page will stay open the for length of the users visit. How long
they stay is
up to them.

[aowie]

Why not define a variable in the JS your loading? Then when you go to
make the request again, before the JS is loaded, check for that
variable's existence. If it is defined, dont reload the js, if it
isnt, let the user continue on their merry way without constantly
reloading the same JS files.

[Xeoncross]

On Dec 11, 10:45 am, aowie <aow...@gmail.com> wrote:
> Why not define a variable in the JS your loading? Then when you go to
> make the request again, before the JS is loaded, check for that
> variable's existence. If it is defined, dont reload the js, if it
> isnt, let the user continue on their merry way without constantly
> reloading the same JS files.

No the problem isn't that I keep re-loading a JS file - the problem
is
that a DOM element (I keep attaching a lot of objects too) is removed
every ajax request and a new (identical) version is added (sometimes).

So this means that everytime the new AJAX content comes in I have
to rescan for the element and reattach all this stuff to it. - So I
am
worried that after 10+ pages of this I will have a lot of wasted RAM.

[nwhite]

Is there a need for the same DOM element to be refreshed multiple time with the same data?

Can you use a different approach, maybe append to the element instead of replacing?

When you talk about 10+ pages and reloading the same element. How much data are you actually inserting each time?

The browser garbage collection should be good enough to handle your case. Are you doing any kind of binding to the objects that are inserted?  Creating closures with DOM elements will create memory leaks.

Maybe this will put your mind at ease. Think of GMail. They are constantly replacing DOM elements and refreshing content. They rely heavily on the browsers automatic garbage collection.

[nutron]

Note that MooTools has its own garbage collection. Any time you attach something to an element (events, storage, etc) or reference an element with a property in a class (as with Fx), so long as you use MooTools methods to do this, you needn't worry about memory issues when you destroy that element *provided you also use MooTools methods to destroy it*.

This means that you always use Element.addEvent to add events. You always use Element.destroy or Element.dispose to remove an element.  You always use Element.set('html', yourHTML) to set the innerHTML of an element. Provided you are always using MooTools to attach to elements and remove them, you should be fine.

Note that MooTools classes that attach themselves to objects (like Fx, for instance) and MooTools classes that destroy objects (as Request.HTML can do) use MooTools methods for these things themselves, so they are safe to use and reuse on the same DOM elements or newly created ones.

One final suggestion. If you have a DOM element with a bunch of functionality that you keep destroying and re-attaching to, Might I recommend that you have a class that manages all this for you? Your class would be passed an element reference and it would attach all the events and functionality to that element that it needs to, but it would store data and state in the class (rather than on the element with storage). This class would also have a method to update that element with Request.HTML and, when that request was complete, it would create a new instance of itself with the resulting new element.

This is a pattern I use often. Instead of a bunch of functionality attached to the element, attach all your logic to a class and pass it your element. It makes things easier to maintain but it also gives you access to all the tools that Classes have (options, events, etc).

-Aaron

On Tue, Dec 16, 2008 at 9:23 AM, nwhite (via Nabble) <ml-user%2B93763-1341009700@...> wrote:

Is there a need for the same DOM element to be refreshed multiple time with the same data?

Can you use a different approach, maybe append to the element instead of replacing?

When you talk about 10+ pages and reloading the same element. How much data are you actually inserting each time?

The browser garbage collection should be good enough to handle your case. Are you doing any kind of binding to the objects that are inserted?  Creating closures with DOM elements will create memory leaks.

Maybe this will put your mind at ease. Think of GMail. They are constantly replacing DOM elements and refreshing content. They rely heavily on the browsers automatic garbage collection.

On Tue, Dec 16, 2008 at 11:46 AM, Xeoncross <Xeoncross@...> wrote:

On Dec 11, 10:45 am, aowie <aow...@...> wrote:
> Why not define a variable in the JS your loading? Then when you go to
> make the request again, before the JS is loaded, check for that
> variable's existence. If it is defined, dont reload the js, if it
> isnt, let the user continue on their merry way without constantly
> reloading the same JS files.

No the problem isn't that I keep re-loading a JS file - the problem
is
that a DOM element (I keep attaching a lot of objects too) is removed
every ajax request and a new (identical) version is added (sometimes).

So this means that everytime the new AJAX content comes in I have
to rescan for the element and reattach all this stuff to it. - So I
am
worried that after 10+ pages of this I will have a lot of wasted RAM.

The MooTools Tutorial: www.mootorial.com Clientcide: www.clientcide.com

---

View this message in context: Re: Handling the changing DOM structure with AJAX forms
Sent from the MooTools Users mailing list archive at Nabble.com.

[Xeoncross]

Wow, thanks for the information Aaron. I'm having trouble
understanding some of it
as I still am rather new to JS. Anyway, I have this book marked so I
can keep checking
it out as I continue.

By the way, Nwhite you might want to see a real life example of what I
am talking about.
http://groups.google.com/group/mootools-users/browse_thread/thread/c67698c31e185c17
.