Thanks a ton.
PS - Sorry for the duplicate post. I'm still a newb when it comes to
newsgroups as well, it seems.
- Gavin
On Feb 24, 10:35 pm, David Zhou wrote:
> To help with test cases, here are a couple tools to help with the boilerplate:
>
> http://jquery.nodnod.net/http://jsbin.com/
>
> --
To help with test cases, here are a couple tools to help with the boilerplate:
http://jquery.nodnod.net/
http://jsbin.com/
-- dz
On Tue, Feb 24, 2009 at 10:32 PM, John Resig wrote:
>
> The best technique to get started is to go in the bug tracker, find an
> open ticket and to produce a worki
On Feb 24, 5:44 pm, John Resig wrote:
> > 3. Users should be able to over-ride defaults at the plugin level
> > (true for all instances) or per-instance
> Do you mean something like: .myplugin({ myprop: "override" }) where
> passing in the option overrides it for that instance? (I think that's
>
The best technique to get started is to go in the bug tracker, find an
open ticket and to produce a working (or failing, as the case may be)
test case if it doesn't have one already. If it passes or fails, bring
it to our attention (here on the mailing list) and we can start to
look in to it more.
Hey there everyone,
I've been interested in joining an open source project for a little
while now and, given that I work with jQuery on a daily basis at my
job, I was thinking of helping out with development - whether it be
tracking down bugs, routine maintenance, or whatever needs doing. I'm
jus
I'm new to jQuery development and I'd like to pitch in, if possible.
Is there a special way to go about helping to fix bugs in the tracker
(i.e. are they assigned by someone)?
Sorry if this is considered spam, just trying to get my jQuery sea
legs. :)
Regards,
Gavin
--~--~-~--~~
The q element is supposed to be rendered with quotation marks around
it, according to the W3C specs:
"Visual user agents must ensure that the content of the Q element is
rendered with delimiting quotation marks. Authors should not put
quotation marks at the beginning and end of the content of a Q
Diogo -
Unfortunately I don't have a link to that original discussion - that
took place long ago (likely early 2006).
This seems like a relevant post on the subject:
http://peter.michaux.ca/articles/javascript-the-good-parts-built-in-object-augmentation-and-namespacing
--John
On Tue, Feb 24,
Thanks Marcus, looking forward to seeing your code.
--John
On Tue, Feb 24, 2009 at 9:20 PM, Marcus Pope wrote:
>
> John- I don't have an account yet so I cannot post the diff. I'll
> send you an email containing the diff, but it was really just a proof
> of concept to ensure that my app woul
John,
Following this conversation, I remembered that someone told me that
jQuery was avoiding extending native objects since it's very
beginning, and there was a discussion about it involving you and other
developers... if you have, can you put a reference/link to that
discussion here, to read wh
John- I don't have an account yet so I cannot post the diff. I'll
send you an email containing the diff, but it was really just a proof
of concept to ensure that my app would compile with the jquery lib
included.I haven't tested it yet and it's partly why I asked the
group about the situation
I haven't. Do you have a URL that we could see? Better yet could you create
a test case and attach it to the ticket?
--
Brandon Aaron
On Tue, Feb 24, 2009 at 7:33 PM, treshug...@gmail.com
wrote:
>
> http://dev.jquery.com/ticket/4239
>
> I've created a ticket for this.
>
> Anyone else experience t
http://dev.jquery.com/ticket/4239
I've created a ticket for this.
Anyone else experience this?
-Trey
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to
On Tue, Feb 24, 2009 at 5:29 PM, Matt Kruse wrote:
>
> On Feb 24, 2:15 pm, Mike Hostetler wrote:
> > If the
> > jQuery team adopted a few choice plugins, like a debugging plugin, a data
> > layer plugin, and by putting the widget code into the core, allowed these
> > plugins to be extended, I th
Well, yes that's not the only reason for the /fork/. There are others,
and it could also be considered an experiment in getting public
involvement/opinion (I'm thinking of experimenting with a ideatorrent
setup).
I actually made some plans and a standard on how to deal with renames in
the oth
John,
I am potentially interested. I'm concerned that what you are
proposing would be a step back in helping large application
development. There are a few reasons:
1. Some of jQuery's current conventions might hurt large projects
(I've seen far too much added to $ and jQuery.fn ). Without
Umm, we're talking about standard naming of jQuery plugins, not jQuery core.
I'm very skeptical that any renaming (as you put it) of jQuery methods
would require a fork of a project (and that existing plugins would
even still work without a lot of changing).
Have you filed any bugs on inconsiste
I think I agree with all of your points, a great list. I was wondering
if you could clarify:
> 3. Users should be able to over-ride defaults at the plugin level
> (true for all instances) or per-instance
Do you mean something like: .myplugin({ myprop: "override" }) where
passing in the option ov
To the defence of jQuery here, I don't think that would work. As I
understand, the purpose of aliasing those methods is to make the
jQuery object work transparently as an Array object when passed to
Sizzle.
All in all, this was not a lot of trouble for me. Luckily I worked out
pretty fast what wa
On Feb 24, 3:57 pm, John Resig wrote:
> Does anyone have
> any examples of plugins that they wished to extend in a particular
> manner? (I needed the validation plugins X method to do Y - examples
> like that.)
Many!
I've had to re-write BlockUI, Autocomplete, accordian, bgiframe,
context menu,
Ohh, a defined convention for the API?
The inconsistency and messiness of method naming inside of the jQuery
API was one of the reasons at work we decided to fork jQuery into a
project for cleaning it up instead of just using it directly.
The aim wasn't to replace jQuery with the project, but w
>> Hijacking a thread is even worse. <<
I know, I know...
Humble apologies -- no intention to hijack the thread :-(.
Sam
On Tue, Feb 24, 2009 at 10:38 PM, Klaus Hartl wrote:
>
> On 24 Feb., 15:23, Sam Dutton wrote:
> > Really sorry -- I replied to the group and forgot to change the subject
>
On 24 Feb., 15:23, Sam Dutton wrote:
> Really sorry -- I replied to the group and forgot to change the subject
> line.
Hijacking a thread is even worse.
--Klaus
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQu
Somewhat off-topic, but:
"On the other hand, property lookups in Internet Explorer are just
abysmal - and you'd be doing a ton of those if you were using nothing
but OO techniques. You're damned if you do and damned if you don't in
the land of Internet Explorer!"
John, do you have any documentation
On Feb 24, 2:15 pm, Mike Hostetler wrote:
> If the
> jQuery team adopted a few choice plugins, like a debugging plugin, a data
> layer plugin, and by putting the widget code into the core, allowed these
> plugins to be extended, I think a very powerful foundation would be provided
> to developers
Umm... I think you may be confused. He's talking about the cases where
some other code on a site modifies the Object.prototype (not jQuery -
some other code). It's jQuery's responsibility to try and work in the
most situations, regardless of the outside code (even if it's native
code extensions, l
So I guess I got everything wrong ... you are planning to implement
hasOwnProperty in every for in ... bad choice, imho, people do not need to
use Object.prototype when $.each(o) instead of o.each() is basically the
same number of characters/speed.
Code elegance to ruin performances?
On Tue, Feb
Don't want to sound like I'm pushing my own wishlist (though this is
up there on mine) but I consider browser history support to be a
critical for RIA and usability. AJAXy apps have hijacked native
browser navigation/bookmarking facilities.
Whether or not this belongs in the core, I am not sure.
> JS is Object Oriented. So are we really just talking about classical
> inheritance (and even more specific, _super) ?
Yeah, I'm talking about constructing classes and inheritance.
> I see how widget.js creates a plugin. But how does one expand on the
> plugin?
There's two ways (one implemen
Mike, Justin, other's interested in helping with this area,
Can we chat for 30 min this evening online and talk about how we
coordinate?
Thatcher
On Tue, Feb 24, 2009 at 4:45 PM, Mike Hostetler wrote:
> I can help write up the following, as I'm already writing some of this
> already:
>
> Needs
I can help write up the following, as I'm already writing some of this
already:
Needs (defined/documented) conventions:
- File names
- Method names
- Method structures
- Testing
- Documentation
- Packaging
Mike Hostetler
http://amountaintop.com
On Tue, Feb 24, 2009 at 14:37, chris thatche
Marcus -
This is the current ticket that I'm tracking on the issue:
http://dev.jquery.com/ticket/2721
I currently have it on the 1.4 roadmap - but if you already have a
patch, I would love to see it (please attach it to the above ticket,
as well) - perhaps we can get something landed sooner, ra
One of the best peculiarity of jQuery is its way to be compatible with other
libraries as well (or better, it is not pretending to be THE ONE in the
script tag)
the for in loop is one of the most used one from every JS lib or snippet.
Adding an hasOwnProperty to each for in loop destroys performan
I'd definitely be interested in working with someone like Justin to
define/document the conventions listed. Keeping the guess work out of
thoses area would benefit the plugin developer community for sure and help
lower the barrier of entry for new developers.
Thatcher
On Tue, Feb 24, 2009 at 4:2
Of the 4 total bugs found when searching for hasOwnProperty, each one
reports that jQuery doesn't support object prototype extensions
because of some factor. In the most recent case a bug was closed
invalid with the following explanation:
"jQuery does not support changes to Object.prototype. The
Ok, so boiling down a list:
Needs code:
- Widget utility (I'm working on this)
- Debugging utility
- Static plugin analyzer
Need a tutorial to cover the concepts of (I'm working on this):
- Encapsulation
- Extensibility
- Modularity
Needs (defined/documented) conventions:
- File names
-
I'm a little scared of jumping into this, but I feel I'd like to make a few
quick points, as I've run up against these issues myself.
1. I've scheduled time for myself and my team to re-build the plugins site
next week. The goal initially is simply to re-create the existing
functionality in a mor
JS is Object Oriented. So are we really just talking about classical
inheritance (and even more specific, _super) ?
I see how widget.js creates a plugin. But how does one expand on the
plugin?
I'm more than happy with widget.js if you can easily expand on the
widget. For example, quickly add
> - package and minimize multiple files (YUI Compressor)
- Could be solved much better as it is not integrated into the
'framework'. You have to 'double' include everything (once in your
page, another in your build script). You have to set your html to
switch from loading separate files to load
> Quick comments:
>
> On OOP and not being convinced. What other approaches are you hinting
> at? OOP being well understood is a valid argument only because
> inheritance and OO does provide reuse. If you have something that
> does work in many cases, you are allowed to factor in popularity and
Quick comments:
On OOP and not being convinced. What other approaches are you hinting
at? OOP being well understood is a valid argument only because
inheritance and OO does provide reuse. If you have something that
does work in many cases, you are allowed to factor in popularity and
understand
Hi Justin -
> Thanks for your reply! You are absolutely right that we need to
> discuss which problems are difficult to solve.
>
> Is it safe to say that you agree that jQuery says very little about
> how to :
> - package and minimize multiple flies
> - document
> - test
> - dependency manageme
Justin Meyer wrote:
> John,
> Thanks for your reply! You are absolutely right that we need to
> discuss which problems are difficult to solve.
>
> Is it safe to say that you agree that jQuery says very little about
> how to :
> - package and minimize multiple flies
> - document
> - test
> - dep
John,
Thanks for your reply! You are absolutely right that we need to
discuss which problems are difficult to solve.
Is it safe to say that you agree that jQuery says very little about
how to :
- package and minimize multiple flies
- document
- test
- dependency management
- log errors / debug
> Point well made and understood.
>
> Perhaps what we're looking for here can be achieved without the
> wholesale adoption of an MVC framework. Perhaps the UI/widget
> framework can do a lot of the visual controller stuff anyway, allowing
> people to create abstract 'objects' (without full OOP) f
disclaimer: I've just built a pretty complex app (drag/drop, inline editing,
history support, popup windows) with jmvc & jquery
I personally feel that jquery as it stands at the moment is superb for doing
all the nitty gritty details of dhtml sites, but as the scope of the
functionality in the sit
Thanks for the response John.
On Feb 24, 4:36 pm, John Resig wrote:
> > 1) If you have to work with certain design patterns, either out of
> > personal preference or because that's how your organisation works,
> > jQuery will allow you to do that. For example, I rolled my own MVC
> > framework
On Tue, Feb 24, 2009 at 10:05 PM, John Resig wrote:
>
>> This is my biggest contention with the widget framework at the moment
>> and I am only left with the option of copy/pasting snippets due to
>> lack of extensibility features. In fact, if I may be bold enough to
>> say it, I think the widget
> This is my biggest contention with the widget framework at the moment
> and I am only left with the option of copy/pasting snippets due to
> lack of extensibility features. In fact, if I may be bold enough to
> say it, I think the widget framework wasn't well planned and I have a
> feeling that
On Tue, Feb 24, 2009 at 9:36 PM, John Resig wrote:
>
>> 3) I know jQuery UI supports widgets, but it's a long way off being a
>> comprehensive UI/widget framework.
>
> Absolutely - and it's a definite work in progress. The UI team is
> getting larger, becoming more efficient, well-organized, all
> disclaimer: I've just built a pretty complex app (drag/drop, inline editing,
> history support, popup windows) with jmvc & jquery
>
> I personally feel that jquery as it stands at the moment is superb for doing
> all the nitty gritty details of dhtml sites, but as the scope of the
> functionalit
> @John regarding his specific questions:
> Part of the issue isn't that there isn't any way to solve jQuery's
> shortcomings, it's that there are no really good ways to solve them.
> For instance, I know I can use closures to get around scoping issues in
> jQuery, but most enterprises are stuck o
> 1) If you have to work with certain design patterns, either out of
> personal preference or because that's how your organisation works,
> jQuery will allow you to do that. For example, I rolled my own MVC
> framework on top of jQuery with no problems. However, it would have
> been beneficial t
Justin,
I've been following your work for a while now, and I have to say I really
dig JavascriptMVC. I think there are some amazing ideas in there, and I know
I'll be keeping an eye on what you're doing.
@John regarding his specific questions:
Part of the issue isn't that there isn't any way to so
There are a few problems to which jQuery isn't a good solution at
present:
1) If you have to work with certain design patterns, either out of
personal preference or because that's how your organisation works,
jQuery will allow you to do that. For example, I rolled my own MVC
framework on top of
Going to CC remy in here.
--John
On Tue, Feb 24, 2009 at 9:58 AM, Diogo Baeder wrote:
> Hi there,
>
> I don't know if it's a jquery-api-browser or Adobe AIR bug, but there's a
> memory leak there, in Windows XP (haven't tried it at home, using Ubuntu).
> When you start jquery-api-browser, and
Hi there,
I don't know if it's a jquery-api-browser or Adobe AIR bug, but there's a
memory leak there, in Windows XP (haven't tried it at home, using Ubuntu).
When you start jquery-api-browser, and the shut it down, the process is not
killed, but put to sleep. When you restart it, it uses even mor
Really sorry -- I replied to the group and forgot to change the subject
line.
Thanks for the link.
Sam
On Tue, Feb 24, 2009 at 2:18 PM, John Resig wrote:
>
> Umm - this seems to be pretty off-topic for the current thread. But
> the Env.js stuff in jQuery core is very old at this point.
>
> I
Umm - this seems to be pretty off-topic for the current thread. But
the Env.js stuff in jQuery core is very old at this point.
I recommend that you visit the Env.js google group:
http://groups.google.com/group/envjs
And grab the code from the current, active, fork:
http://github.com/thatcher/env
Hi Justin -
> jQuery community,
> Amazing work. I can't believe how fast jQuery has developed into
> the best bottom-up JS library. 1.4 looks great. But as jQuery expands
> to include things like lazy loading, it might be time for a sister
> project that provides important, but less commonly
I want to set up automated tests with QUnit as part of our build process
(using Ant/Cruise) along the lines of this article:
http://ejohn.org/projects/bringing-the-browser-to-the-server/.
I've installed Rhino 1.7R1 and downloaded env.js from the above page.
JavaScript code works as expected in th
I'd just like to speak up in favour of this proposal. Working on a
JavaScript/AIR project recently, I rolled my own JavaScript MVC
library on top of jQuery, largely because I didn't know that
JavaScriptMVC existed at the time I started, and I wanted to keep
jQuery at the heart of the project (rat
Sounds fantastic to me.
On Feb 24, 6:38 am, Justin Meyer wrote:
> jQuery community,
> Amazing work. I can't believe how fast jQuery has developed into
> the best bottom-up JS library. 1.4 looks great. But as jQuery expands
> to include things like lazy loading, it might be time for a sister
Awesome,
as a fan of JMVC and jQuery, i can´t wait to see this.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscr
Your question is probably better suited to one of these lists:
http://groups.google.com/group/jquery-ui
http://groups.google.com/group/jquery-ui-dev
Thanks.
- Richard
On Tue, Feb 24, 2009 at 5:50 AM, bobbykjack wrote:
>
> Using jQuery 1.3.2, I see the following error when trying to
> call .d
Those 'internal' methods could also be prefixed with an underscore as
an easy solution to avoid conflicts. It is considered by many in the
PHP world as a convention and best-practice to prefix all protected
and private members with an underscore.
Just an idea.
-Trey
On Feb 24, 10:06 am, Robert
Using jQuery 1.3.2, I see the following error when trying to
call .draggable('destroy') on ui.draggable within a droppable's drop
function:
$(this).data("draggable") is undefined
var o = $(this).data('draggable').options; ui.draggable.js (line
565)
Any ideas what I'm doing wrong?
- Bobby
--~-
67 matches
Mail list logo
