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


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

Reply via email to