On Jul 23, 9:26 am, Klaus Hartl <[EMAIL PROTECTED]> wrote:
> But that doesn't make any difference. It would still overwrite a
> property named "target" of the jQuery object.
Ah, i now see what you mean. Yes, that would of course be a danger.
> You have to know jQuery very well to not accidently use a name that
> isn't already in use. And who knows if jQuery 1.1.4 does not introduce a
> target property on the jQuery object? Jörn described that very well a
> while ago in another thread - I think that was related to one of your
> plugins ;-)
Very possibly - i liberally use custom fields to store internal data.
i'll have to go revisit that approach.
> Again, a var should be sufficient using closures. Or if you need to
> store things in another object, create a new one but do not use the
> jQuery object.
Thanks for the clarification.
Something to consider for jQuery:
In my embedded JS code i often create top-level classes for my
applications, e.g.:
function MyApp() { ... }
Then i want client code to be able to safely store their own data in
there without colliding with mine, so i do:
MyApp.client = {};
And that becomes the "public" place to store any client-specific data,
and my app promises not to touch that field. For example, i have an
ncurses JS wrapper and a small framework built on top of it for
providing basic ncurses app functionality. In that framework i specify
that MyApp.client is the place where client-side code can store their
data, and in my apps i use MyApp.client.windows to store my client-
specific ncurses windows. Here's a screenshot demonstrating what i
mean:
http://spiderape.sourceforge.net/screenshots/ape-20050910.png
(somewhere in there is an object called ApeWS.windows.client - near
the bottom/left)
i think jQuery could benefit from the same idea, with the intention
being that plugin authors have a "safe haven" where they can attach
data to jQuery objects.
:)
