[jQuery] Re: Returning Javascript
To restate:
> I have setup my application to work so all pages are loaded via ajax,
> using anchor's as navigation. However on some pages that i return
> using the AJAX i want to be able to run code.
So this code is the text of an AJAX response, correct?
>
>
> Title:
>
>
>
>
> // attach handler to form's submit event
> alert("Javascript");
> $('#myform').submit(function() {
> // submit the form
> alert("form submitted");
> // return false to prevent normal browser submit and page navigation
> return false;
> });
>
If so, I'd suggest pulling the script portion out of the response,
and running it *after* inserting the HTML into the document.
If you're simply inserting the text, *as is*, into the document,
it's likely that the form ('#myform') is not yet available to be
found by document.getElementById().
--
hj
[jQuery] DOM element as message when blocking element
I seem to have found a bug. If I try to use $('#someelement').block
({ message: $('#loadingMessage') });
Then when I unblock with $('#someelement').unblock(); the loading
message is removed from the DOM, so any subsequent calls to block it
fail and cause a JS error. Everything works fine if I block the whole
page with $.blockUI({ message: $('#loadingMessage') }); then
$.unblockUI(); but I don't want to block the whole UI.
Is this a bug or am I doing something wrong?
[jQuery] Re: Getting Parent Element using "this"
> Could you possibly just give your form an id attribute? Then onchange you
> could just return $("#myformid").attr("action") and not have to mess with
> any traversing.
>
> -- Josh
>
> - Original Message -
> From: "briandichiara" <[EMAIL PROTECTED]>
> To: "jQuery (English)"
> Sent: Thursday, May 08, 2008 1:58 PM
> Subject: [jQuery] Re: Getting Parent Element using "this"
>
> > Ok, I tried this:
>
> > $(elm).parents().map(function () {
> > alert(this.tagName);
> > });
>
> > but the FORM never shows up. Reason is because the source looks like
> > this:
There's no need for any of this; elements of a form (input, select,
textarea) has a "form" property, so:
function changeAction(elm){
var formAction = elm.form.action;
...
}
And, as others have suggested, it's a better practice to do this all
in JavaScript, so that becomes:
jQuery(document).ready(function() {
jQuery('select#some_select').change(function() {
var formAction = this.form.action;
...
});
});
--
hj
[jQuery] Re: Way to designate links as form submitters?
> Anyway to do that? > > Have certain links, say with an id of "link", > to be programmed to submit a form when clicked? Why not mark up the links as buttons, or input type=submit elements, and then just use CSS to style them appropriately? -- hj
[jQuery] Re: getScript is great to add scripts dynamically, but how might you remove scripts?
On Apr 21, 3:41 pm, cfdvlpr <[EMAIL PROTECTED]> wrote:
> Is it possible to remove a script from a page dynamically?
Something like this was just discussed on another mailing list that
I read. The answer is something like:
A) Remove the script element itself from the DOM. This accomplishes
pretty much nothing, since the *code* for the script is still
active.
B) Imagine that you've saved the names of all global (window)
properties
before loading the script. So, after you remove the script
element,
you then need to delete all the properties that didn't exist
before;
e.g.
globals = {};
for (var prop in window) globals[prop] = window[prop];
delete prop;
// now you load your script
//
// use it
//
// and now you're ready to "unload" it
for (var prop in window) {
if (typeof globals[prop] == 'undefined')// i.e., defined by
your script
delete window[prop];
}
delete prop;
C) Remember that if your script has defined any event handlers that
you must revert those as well; otherwise, you'll get errors when,
for example,
a click event occurs and the handler no longer exists. If you
*know* the source
of the script you intend to remove, this may be workable;
otherwise, it's a big
housekeeping problem.
--
hj
[jQuery] Re: tbody and jQuery
On Apr 15, 5:44 pm, Karl Swedberg <[EMAIL PROTECTED]> wrote: > Nope. It's the browser's "tag soup" parser. Your best bet is to put > them in yourself. :-) > > On Apr 15, 2008, at 10:57 AM, Alex Ezell wrote: > > > > I am beginning to suspect that jQuery is the reason these tbody tags > > are "appearing" in the rendered source of my pages, despite the tables > > not having tbody tags in my code. No, it's not "tag soup" -- this is the prescribed behavior. The TBODY tag is required unless there's only one, and there are no THEAD or TFOOT tags. The TBODY *element*, however, is required, and its presence is inferred, if necessary, by the browser. http://www.w3.org/TR/html401/struct/tables.html#edef-TBODY -- hj
[jQuery] Re: Remove script
On Apr 7, 3:17 am, "Karl Rudd" <[EMAIL PROTECTED]> wrote:
> You'll need a record of every function and variable that a script
> defines. Perhaps a function that does the "clean up". For instance
> (untested):
>
> var blah = 3;
> var blahblah = { 'f': 12 };
>
> function aFunc() { };
> function aFunc2() { }
>
> function cleanUp() {
> blah = undefined;
> blahblah = undefined;
> aFunc = undefined;
> aFunc2 = undefined;
>
> }
If you can structure your scripts like this, then it could work.
However, you might be better served to do:
function cleanUp() {
delete blah;
delete blahblah;
delete aFunc;
delete aFunc2;
setTimeout(function(){delete cleanUp},0);
}
And you still might be stuck with hanging references in any
event handlers that are defined. Your cleanUp function would
need to remove those as well, e.g.:
btn = document.getElementById('someButton');
btnHandler = btn.onclick;
function myhandler() {
// do some stuff
btnHandler();
}
btn.onclick = handler;
function cleanUp() {
// cleanup variables and functions as above.
// restore old event handler
btn.onclick = btnHandler;
delete myhandler;
delete btnHandler;
}
Obviously, this can get *really* hairy.
--
hj
[jQuery] Re: Remove script
> I have added a js file in my html file.
>
>
> I want to remove the script from my file using jQuery.
> I have tried using the following
> jQuery('script[src="test.js"]').remove();
> But the script is not getting removed.
Do you want to remove the script, or the functions and variables
that it defines? To remove the script element, try:
jQuery('script[src*=test.js]').remove();
But that will only remove the element from the DOM; all the functions
and variables it defines will still exists.
--
hj
[jQuery] Re: How do I get a standard DOM object from jQuery selector.
Maybe this will seem impudent, but ...
> I have a feeling I'm just missing something in the documentation, but
> is there anyway to get a standard DOM object to return from a jquery
> selector?
>
>
>
>
>
> Essentially I want a way for $('.target', '#context') to give me the
> equivalent of
> document.getElementById('context').getElementsByTagName('div')[0]
If your real-life situation is as simple as your example, then what's
wrong with using your "equivalent" solution? Using jQuery (and I do)
doesn't mean you have to unlearn what you know about the native DOM
API ... which in this case does exactly what you want (and likely
faster than jQuery access).
Otherwise,
var target = jQuery('#context .target').get(0);
--
hj
[jQuery] Re: About jQuery.attr(type,value)
On Feb 13, 6:41 pm, wwwiori <[EMAIL PROTECTED]> wrote:
> Thank you for your reply. And I have testing on IE7 and
> Firefox2.0.x , and when I using code:
> document.getElementById("changeType").setAttribute("type","button");
> can change the type when the element has created... so，I think maybe
> IE and Firefox can support on the change when the element has
> created. Do you think so ?
No. In both IE6 and IE7, an input element's type is immutable once
it's been set. Why? My guess is that these elements are not
implemented
by the browser, but are instead native Windows controls, which don't
support this mutability. And, apparently, the IE designers didn't want
to replace such an object with another just because its type had
changed
(think copying all attributes and event handlers).
But that's just a guess; in any event, if you really *must* change an
input's type, your only cross-browser solution is what andrea varnier
suggested; but that leaves the responsibility of duplicating ID,
classes,
style, hooked events, etc. to *you*.
--
hj
[jQuery] Re: Error - getComputedStyle?
> Error is as follows:
>
> uncaught exception: [Exception... "Could not convert JavaScript
> var getComputedStyle = document.defaultView.getComputedStyle( elem,
> null );
Not surprising; IE doesn't implement document.defaultView, let alone
the getComputedStyle method. jQuery doesn't -directly- provide a
substitute method, either.
Try this (untested):
function getStyleOf(elem,ref) {
return (document.defaultView ?
document.defaultView.getComputedStyle(elem,ref) :
elem.currentStyle);
}
--
hj
[jQuery] Re: ajax load, url variable question.
On Jan 20, 2:18 pm, Mike Geise <[EMAIL PROTECTED]> wrote:
> I am using the ajax load method to populate a select list.
>
> $("#games").load("$siteRoot/file/ajaxgames.aspx",
> {criteria.Platform.PlatformID: $(this).val(), view: "normal"});
>
> what I am wondering is how I can get jquery to work with the var
> "criteria.Platform.PlatformID"
It's not a "var"; try
$("#games").load("$siteRoot/file/ajaxgames.aspx",
{criteria: {Platform : {PlatformID : $(this).val()}}, view: "normal"})
--
hj
[jQuery] Re: FlyDOM + New Input Field != New Field being Submitted
On Dec 21, 3:15 pm, Bitruder <[EMAIL PROTECTED]> wrote: > I'm using jQuery + FlyDOM to add new elements dynamically after page > load to the DOM tree. I'm adding new input fields this way. They are > clearly within tags (added as children to a within > the ). However, when I submit the form, only the pre- > existing input fields get submitted and show up in PHP's $_POST > variable. > > Any idea how to get the new input fields to submit as well? Do the new elements each have a NAME attribute? Lack of NAME means the element won't be submitted with the form. Do the new elements have a DISABLED attribute? If DISABLED="disabled" (or if the element's 'disabled' property is true), the element won't be submitted with the form
[jQuery] Re: JSS - New Plug-in
On Oct 9, 12:56 am, "R. Rajesh Jeba Anbiah"
<[EMAIL PROTECTED]> wrote:
> On Oct 8, 3:42 pm, Andy Kent <[EMAIL PROTECTED]> wrote:
>> Yep, absolutely. If you have any ideas on how we could test a
> browsers
> > support for a selector without maintaining a hard coded list then I
> > would love to hear them.
>
>
>
> $(document).ready(function () {
> $('body').append(
> ' \
>
[jQuery] Re: Syntactic sugar for checking whether an element exists
On Jul 9, 10:19 am, Felix Geisendörfer <[EMAIL PROTECTED]> wrote:
> I've just been wondering if jQuery has some syntactic sugar for checking
> if an element exists. I know the following works:
>
> if ($('#my-element').length) {
> // #my-element exists}
>
>
> but is there also something similar to the following?:
>
> if ($('#my-element').exists()) {
> // #my-element exists}
Don't get me wrong -- I *really* like and appreciate jQuery. But there
is value
in knowing the DOM API. For a simple test like this one: "does an
element with
this ID exist?", I'd simply say:
if (document.getElementById('my-element')) {
// and so on
}
--
hj
[jQuery] Re: using jQuery with multiple libraries
> I'm having problems getting my jquery code to execute properly. I've
> read the documentation on jquery.com but i'm still receiving the error
> message: "jQuery(document).ready is not a function".
I had the exact same situation here, just yesterday, combining with an
older (v1.3.1) version of prototype.js. That prototype code is sort of
dirty: it defines Object.prototype.extend, which, I think, completely
screws up jQuery's use of its own extend method.
I upgraded to prototype v1.5.1 ... Object.prototype.extend is no
longer
defined, and jQuery works again. But other code which depended on
prototype's older, broken API needed fixing, specifically:
someObject.extend({key: value, ...})
becomes
Object.extend(someObject,{key: value, ...});
--
hj
