Hey John, sorry to chime in late here, just wanted to get my thoughts out as
well:

On Tue, Feb 24, 2009 at 10:26 PM, John Resig <jere...@gmail.com> wrote:

>
> Ok, so boiling down a list:
>
> Needs code:
>  - Widget utility (I'm working on this)


We should make sure the new core widget factory can be used as true
replacement for the
jQuery UI widget factory. If it can survive this test, it's probably good
for other audiences
as well.

Also, I'd really love to have this become part of core, rather than as a
separate utility, partially
for my own selfish reasons, heh. We could strip out a significant code block
of both jQuery UI's
and jQuery Sky's core (Sky is the new suite featuring the magnifier).



>
>  - Debugging utility


This could be external, but I could also imagine having a prebuild "debug"
version of
jQuery which could be used in development and later on replaced by the
production version.


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


-- 
Paul Bakaus
UI Architect
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus

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