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 other project that theoretically makes it so that the project still
retains full jQuery compatibility. The ideal was to be able to provide a
clean front API, but still retain 100% of the jQuery api in an
alternative API ($ or fork specific object, vs. directly using jQuery)
so 99% of jQuery plugins should theoretically still work (^_^ reserving
that 1% for extensions that do things so awfully strange it's a wonder
they would ever work), at the very least through the jQuery API.
I had an earlier thread in the list, from the comments I received in it
the jQuery community seamed more opposed to than accepting towards
method renaming to remove ambiguities and make parts of the api more
consistent. So I didn't push any further on the bugtracker.
I've been targeting methods which have ambiguous names, use operator
overloading to provide two completely different purposes (normally this
is due to having an ambiguous name, or choosing a poor name), or don't
follow a naming pattern which is similar to one used in a similar part
of jQuery (I believe one of your lectures noted the benefits of naming
patterns for similar areas of code?).
Just for examples here:
.toggle is an example of both ambiguity and bad operator overloading.
.toggle() and .toggle('speed'); show/hide the element.
.toggle(fn, fn, ...); run a click handler which alternates through the
methods.
The notes I had:
- "toggle" is an ambiguous name, it doesn't specify what is being
toggled. The confusing nature of $(':checkbox').toggle(); shows this is
an ambiguous name.
- .toggle(fn, fn, ...); could be considered a poor method name, it
doesn't properly specify what is actually being done. In this case it
happens to have something to do with mouse clicks.
To solve this case, I renamed .toggle() .toggle('speed'); to
.toggleVisibility. And I enhanced the .click() method to support the
same alternating event binding as .toggle;
Code migration is as simple as changing .toggle to .toggleVisibility
where used to show/hide, and switching .toggle for .click where used to
alternate click events.
Of course, the old methods are retained for backwards compatibility and
the new methods work the same as the old ones.
The other example is offset API vs. dimension API:
In the offset API we deal with positions and offsets (side-note, the
documentation didn't give enough explanation what the difference is last
time I checked). To do so we use the methods .offset and .position;
In the dimension api, we deal with the dimensions, inner dimensions, and
outer dimensions. To deal with these we use the methods .width/.height
.innerWidth/.innerHeight .outerWidth/.outerHeight;
The naming here is inconsistent, the offset API uses a single method
which returns an object with both numbers, while the dimension API
instead uses two methods which each return an individual number.
To solve this case, I created .size, .innerSize, and .outerSize
shortcuts to match the offset and dimension APIs. I left all the other
methods intact as there are still cases where someone may only need the
use of one of the values.
This actually cleans up a common pattern I use for syncing one node to
another (for purposes of various types of overlays in a UI).
It's true that .attr/.css aren't consistent with
.[has|remove|add|toggle]Class, however I ignored these as I cannot think
of cleaner method name patterns which would make sense. And I think
these methods are etched enough in the minds of even newbies to jQuery
that there isn't much issue with the difference.
If jQuery is interested in reports on naming ambiguities like these.
Then I would be very happy to open up tickets into the bugtracker on
them detailing the ambiguities, issues, and rationales. As well as
provide patches, either fresh, or extracted from fixes I've already
committed into the fork to be ported back into jQuery itself.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
John Resig wrote:
> 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 inconsistencies?
>
> --John
>
>
>
> On Tue, Feb 24, 2009 at 5:56 PM, Daniel Friesen
> <nadir.seen.f...@gmail.com> wrote:
>
>> 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 work on things in
>> the project that jQuery itself wasn't willing to add.
>>
>> So, if we're defining a standard to naming the API, then I'm in. That's
>> one less thing to do in an external project, and one more thing I can
>> contribute to jQuery instead.
>>
>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
>>
>> chris thatcher wrote:
>>
>>> 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
>>> <mike.hostet...@gmail.com>wrote:
>>>
>>>
>>>
>>>> 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 thatcher <
>>>> thatcher.christop...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>> 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:26 PM, John Resig <jere...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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
>>>>>> - Method names
>>>>>> - Method structures
>>>>>> - Testing
>>>>>> - Documentation
>>>>>> - Packaging
>>>>>>
>>>>>> Once the above conventions are finalized, that static plugin analyzer
>>>>>> can be written.
>>>>>>
>>>>>> Once the widget code is done, the tutorial needs to be updated.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> So, with that drawn in the sand, Justin, would you be interested in
>>>>>> working on the debugging plugin, the static analyzer, defining
>>>>>> conventions, all of the above?
>>>>>>
>>>>>> Any/all of those would be a huge help and I'd imagine that if the work
>>>>>> is solid they should all become official jQuery projects/conventions.
>>>>>>
>>>>>> Now I'm not discounting any additional code or patterns but we need to
>>>>>> start with what we have and make sure that we're working with the best
>>>>>> possible resources. If we define the above conventions and code we may
>>>>>> find that there is less of a need for a new project than we originally
>>>>>> thought - and we get the benefit of having excellently defined and
>>>>>> documented resources and conventions for people to use - so everyone
>>>>>> wins.
>>>>>>
>>>>>> --John
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer <justinbme...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>>> - 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 loading the combined in
>>>>>>> production.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> - documentation (jQuery Documentation Wiki - already allows devs to
>>>>>>>> have inline demos and can be extracted to external sources)
>>>>>>>>
>>>>>>>>
>>>>>>> Unless I am misunderstanding something, does this allow me to document
>>>>>>> my application, or is this just for jQuery? I am talking about
>>>>>>> something similar to JSDoc.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> - testing (QUnit)
>>>>>>>>
>>>>>>>>
>>>>>>> Does it handles synthetic events? Can it run server-side to ensure
>>>>>>> sanity before checkin? Can you do point and click testing like
>>>>>>> selenium?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> Where do I put the files?
>>>>>>>>> What should I name the files?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I'm not completely convinced that this is a huge problem - but at
>>>>>>>> worst this could be solved through convention and documentation.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> How/where should I respond to events?
>>>>>>>>> How should I deal with state?
>>>>>>>>> How can I maximize the chances of re-usability?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> All three of these are handled either through better documentation or
>>>>>>>> with the widget/jQuery.plugin code that I showed earlier (it
>>>>>>>> especially helps to deal with state and reusability, while responding
>>>>>>>> to events would be more of a documentation issue).
>>>>>>>>
>>>>>>>>
>>>>>>> Yes, these conventions are exactly what is needed. Documentation can
>>>>>>> definitely do that, but so far I've not seen it for jQuery.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> Where should I be connecting to the service?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> That's probably outside the scope of anything that we would do, since
>>>>>>>> it would probably define what needs to happen on the server-side.
>>>>>>>>
>>>>>>>>
>>>>>>> I mean, where should ajax calls happen in the client? In JMVC they
>>>>>>> are in the Model, akin to ORM.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> How can I wrap the service data? (For example, maybe the todo has
>>>>>>>>> passed it's completion date and you want to ask it .isPastDue().
>>>>>>>>>
>>>>>>>>>
>>>>>>>> This seems like another case of encapsulation or dealing with state
>>>>>>>>
>>>>>>>>
>>>>>> (imo).
>>>>>>
>>>>>>
>>>>>>>>> How can I create HTML in a readable manner?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> At best, something that's done through convention.
>>>>>>>>
>>>>>>>>
>>>>>>> Yes, but where should that html go, etc. Yes, convention is needed.
>>>>>>> I guess that is the central point we've arrived at.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> Christopher Thatcher
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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 unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
