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 -~----------~----~----~----~------~----~------~--~---
