Jeremy said:
You have my (our?) sympathies.
I suppose sympathy is appropriate when that is such an easy mistake to make.
You would get best help on a jQuery related forum.
That is probably true, literally. But I am forced to question how much help
that "best help" is going to be. As a result of observing the author of
jQuery's many published misconceptions I become interested in the gauging
the extent to which those misconceptions might be shared by people using
jQuery (and especially the individual offering help on the use of jQuery).
To that end I have spent some time in the last week looking at jQuery forms.
I would say that I was disappointed by what I observed, but my expectations
were not high and what I observed was pretty much what I expected to
observe.
An example thread went; Question: following a official tutorial (good start;
RTFM and all that) the OP was making an XML HTTP request but the call-back
functions (for both successful completion and errors) were not being called.
Both functions did no more than put up an alert so there was no potential
for them to go wring in themselves. The only response to the question
proposed using the POST method in place of the GET method (in the unhelpful
uninformative 'try this instead' tone). To which the OP (unsurprisingly)
replied that the change made no difference, and someone else replied that
they were experiencing the same problem and asked if they should change the
method they were using to POST.
That is problem solving by stabbing about in the dark; pure guesswork. Even
worse than that, it is pretty much random guesswork. The consequences of
changing a GET method to the POST method are that in some circumstances a
browser that had served a cached version of the response may decide to fetch
a fresh response form the server, but as a cached response should trigger
the appropriate call-back methods regardless the symptoms described by the
OP didn't even relate to the proposed 'solution'.
And that is the general level of activity on that jQuery forum. Sometime
last week someone expressed the opinion to me that comp.lang.javascirpt
might be suffering because its level of activity was less that that jQuery
form, but if the activity on that forum is largely random stabbing about in
the dark for 'solutions' then the ineffectiveness of the approach taken will
produce bulk (without much substance). It is the blind leading the blind
(and in the land of the blind even the one-eyed man can be king).
Many here on c.l.j won't/can't help with jQuery related issues
More like "won't" than "can't". It is a lot to ask someone to read to the
extend of being able to understand such a mass of convoluted and
interdependent code.
and those who MAY be willing to help would need to see a
stripped down example of your problem.
The problem in this case (beyond the fact that jQuery is so convoluted and
interdependent that stripping it down to the minimum needed to demonstrate
the issue in isolation would be a job for someone who would not need to be
asking this question) is that the issue may be outside of the code entirely.
It may still be useful to know what the implications (in terms of
application code and JQuery code) of "removes all <img> tags from the dom"
were. That is; how are they removed, should the removal code be expected to
free all references to the elements so they become eligible for garbage
collection, and is the IE circular reference memory leak issue likely to be
involved in this picture or not. Without code none of those factors can be
considered.
But there are other considerations here. For a start, are the images being
downloaded from the server regardless (that is, could they not be cached
client-side and served from there for all requests subsequent to the very
first)? There might be issues with the HTTP headers sent with the images,
and if they were solved the issue as expressed may be rendered moot.
Not the full web site, just the minimum needed to reproduce
the issue.
But in this case an on-line demonstration so that the HTTP traffic can be
examined in detail.
Richard.
