I thought .find only accepted a single selector? In fact I recall
needing to patch .find as well so I could do that and make $4 use it.
Nonetheless, that still suffers from the same issue, what I'm trying to
avoid is that second call to find things after finding other things
which doesn't make sense when all you are trying to do is find a single
set of things.
$4(widgetObj, '.somesection', '.specificSelector');
And yes I know I can combine those two string selectors together, that's
not what I'm trying to work around. In the app I'm programming that
second selector is normally generated by some function which is not the
kind of case that lends itself nicely to string concatenation.
Other than that there are other uses, like trying to avoid concatenating
strings to build selectors.
$4(widget, attreq('foo', bar), 'a'); // Like $4(widget, '[foo='+bar+']
a'); but without concatenating any strings resulting in sometimes
unpredictable behavior
All I'm trying to do is loosen up the rigid syntax necessary to do
moderately complex things. These kind of /complex/ things are used so
much at work they're the simpler parts of the app.
"Is there anything about that framework that would make it hard to
integrate seamlessly into our application?" is the kind of question a
company might ask when trying to decide whether to use an external JS
framework, or write their own proprietary one for use in their app.
Effectively I'm just trying to eliminate many of the reasons why the
answer to that question wouldn't be "No".
Going from "jQuery avoids conflicting with your code" to "jQuery avoids
conflicting with your code, but still lets you integrate it and pretend
as if it was part of your app".
`context` is just a term to refer to a DOM node or a Document context.
Selector to a string pattern.
jQuery already checks if the first node you pass is domish or a
selector, I just stuck two pieces of code inside two parts of init.
From the perspective of someone just using the library, they don't care
about the difference between context and selectors, all they know and
care about is that they can use document objects, dom nodes, and string
css selectors and stick them inside $4 in an order that makes sense to
build them on top of each other. The fact that the dom node or document
they shove into the leftmost parameter is actually a context rather than
a selector is completely transparent to them.
~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)
ricardobeat wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
