You can use jQuery(context).find(selector, selector, selector, ...) And how do you differentiate between $4( [context], selector, selector) and $4(selector, selector, selector)?
cheers, - ricardo On Mar 3, 4:14 pm, Daniel Friesen <[email protected]> wrote: > Yes, a branch is the idea. Though a branch normally implies something > in-repo, while a fork implies it being a project of it's own (even > though it is continually integrating). I've thrown around the terms > "fork branch" and "offsite branch" before, I guess the term use is just > another case of my own messed up interpretation of terms (heh, ^_^ maybe > this is why I have issues talking with other programmers, but I can get > the layman to understand what I'm trying to put across about technical > stuff). > > I went off on a bit of a tangent later on (this was the bottom of the > mail), Instead of sending it I added it to a wiki > page:http://code.google.com/p/js4query/wiki/WhyGit > > Ya, I know there are more ambiguous points. I've been going through one > by one, I've seen a few more "\\ save the old ???\n_???: jQuery.fn.???" > lines in the code but not noted them yet. I'm only part way through on > that part of the project. > > Nice point on the toggleVisibility name, I wouldn't have thought about > that now. Since you pointed it out now, I can give it a better name > without needing to rename it a second time later. > Do you think .toggleDisplay is better? You noted it was the display > being toggled, I'd also agree "Display" is easier to type than "Visibility". > Other than that the only other one I can think of would be .showHide(...); > > Ya, I thought about those performance improvements to size as well. > Right now all I'm doing is wrapping around the dimension function pairs, > and I don't plan on doing much more changes than that in the code. > Trying to add .size performance improvements into 4query would make it > harder to merge jQuery updates in. > That's why I like the idea of doing as much inside jQuery itself as > possible, it reduces the complexity of continually merging, and lets the > project work on the actual improvements it's trying to do. > > Oh, I didn't haven't listed it yet (that improvements page is far from > complete) but if jQuery isn't adding it the .remove -> .destroy rename > that was discussed earlier on in the list will probably go into 4query. > Good documentation is nice, but an unfortunate fact is it's not exactly > always read through. I was bitten by .remove once, and I understand the > API fairly well. If someone understands the jQuery API fairly well from > reading other documentation pages, they aren't likely to look at the > documentation page for every single method they use when they already > have an idea what it is /supposed/ to do. > > John, I should probably note it here. In 4query I'm using a init a > little different than jQuery. > jQuery( selector, [context] ); // jQuery > $4( [context], selector, selector, ... ); // 4query > > At work the current framework I have setup effectively uses this > technique. I know that using > jQuery(context).find(selector).find(selector)... is pretty much the same > thing, however idoms like pf(widgetObj, > functionToBuildSectionSelector('foo'), '.fineGrainSelector'); are used > extremely heavily. Using .find to push a selector onto a selector just > takes a single selector chain just ends up bloating the code, and > doesn't read very well (Technically also if it's stuck in a single > method it is possible to potentially improve performance in the future). > It kind of makes a little more sense as well, instead of having a > selector with an optional node to it's right, you can read from left to > right and see how each selector builds onto each other. > > I'm in no way suggesting making such a large change to the jQuery init, > however I was wondering if you were open to a small modification to > jQuery in the init. > Right now I have two separate objects in 4query, a jQuery obj, and a > 4query obj which inherits from it. This is done to separate any heavy > renames done to 4query in case jQuery and 4query end up conflicting in > part of the API (jQuery().someMethod can work perfectly fine while > $4().someMethod has the incompatible improvement). > Since you are interested in some of the 4query api changes going into > jQuery and it looks like more collaboration is possible, if I can get a > small modification to init into jQuery which will make selector/context > order dependent on how init is called. Then I might be able to have > 4query get away with nothing but a simple $49) function which will call > .init in a slightly different way than jQuery(). Of course that meaning > that the jQuery/4query object separation wouldn't be there either. > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen-fire.com] > -Nadir-Point & Wiki-Tools (http://nadir-point.com) (http://wiki-tools.com) > -MonkeyScript (http://monkeyscript.org) > -Animepedia (http://anime.wikia.com) > -Narutopedia (http://naruto.wikia.com) > -Soul Eater Wiki (http://souleater.wikia.com) > > John Resig wrote: > > So a quick point: What you're talking about isn't a fork, it's a > > branch (you track commits in a branch, you take the project in a new > > direction with a fork). > > > As far as your specific changes are concerned. > > - I like .click(fn, fn) as an alternative to .toggle(fn, fn). > > - I don't like .toggleVisibility - especially since you aren't > > toggling the visibility, you're toggling the display of an element. > > - I like your proposed API for size (.size, .innerSize, .outerSize) - > > I'd imagine that it'd be able to speed up some code. > > > One piece of ambiguity that you missed was .load() (.load(fn) and > > .load(url)). > > > --John > > > On Tue, Mar 3, 2009 at 3:47 AM, Daniel Friesen > > <[email protected]> wrote: > > >> I've mentioned my little fork project on the list a few times before, > >> I've finally written a bit of a report on the goals in the project. I > >> think it's probably missing some stuff, but it definitely explains a bit > >> more. I never really noted how the project relates to the project at > >> work, and there are more improvements and rationales to detail. But for > >> now it's a good start. > >>http://code.google.com/p/js4query/wiki/Report > > >> I'd appreciate it being looked over and commended on, especially by John > >> since it would be nice to do as much of the goals and improvements as > >> possible inside of jQuery itself instead of in a fork. > > >> Currently I think I got the trunk to a moderately usable point. Right > >> now I was just merging updates from jQuery in and tr...@6256 made a bit > >> of a conflict with the jQuery/4query object separation, so I'm merging > >> it and will push those updates once I integrate the improvements together. > > >> -- > >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
