I agree with justin that mvc is an important pattern. I agree with trey that
with javascript mvc is in someway built in.
The issue is both organizational and a metaprogramming problem.
Even 30+ files or 'classes' (outside of core and plugins) can make a project
difficult for new developers to contribute efficiently.
The success of Rails and Django (or for you old school java geeks, Spring),
or php Cake or whatever is due to the fact that convention for mvc is a
business scalability issue. Johns probably right that right now 90% of
jQuery developers are fine with everything in core plus a couple lightweight
plugins.
I do think we should acknowledge that the future is going to put more
pressure on the client (browser in most cases) to do more. mvc, ioc, aop,
category logging, packaging whatever... are not immediate issues... but we
should as a community think about the value of business scalablility and the
value it can give to jQuery as a platform. If my webapp has more than 30
custom files I'm going to spend $10,000 before my new hire can contribute
effectively unless I've hired a jQuery developer who understands the
application conventions. that's not good.
so yeah today's webapps are covered, but justin is right, tomorrows are left
behind.
It's not just 'business' either , the Library of Congress is building apps
that need these patterns. I'm making every personal effort to make sure
jquery wins the spot. There is competition though, and they do diligance.
I get both sides, though I'm sure there are more than two ;) What I'm
hoping is that we can keep jQuery simple, clean elegant (we could burden
plugin developers just a little more to pass muster.) Let UI focus on
widgets. And add a spot for the railable patterns we need to scale to
satisfy the next generation (meaning about 2 years at this point).
the mvc stuff should pass all the ussual tests: look, feel, taste like
jQuery. be small and effiecient and focused on real problems that arent
alreay solved.
write less, do more
Thatcher
On Thu, Feb 26, 2009 at 2:03 PM, Justin Meyer <justinbme...@gmail.com>wrote:
>
> @Trey,
> You created a plugin to deal with the exact problems we have been
> talking about :).
>
> Have you developed a JS centered application, something that could
> be considered a 'Thin-Server-Architecture' app?
>
> When you build the entire HTML structure client side, a lack of a JS
> template (View) is brutal.
>
> If you only have raw services to work from, something that can wrap
> and provide context to the data is essential.
>
> Although widget.js comes close to a 'controller' anyway, wouldn't it
> be great if you can make plugins like:
>
> $.plugin('todo',{
> init : function(element, options) {
> //initialization code on the element
> //uses something in 'data' as 'this' for state, instead of
> this=element
> this.created = true;
> }
> "a.destroy click" : function(element, event){
> //uses event delegation to call without actually having to setup
> delegation
> this.destroyed = true;
> },
> destroyed : function(){ return this.destroyed } // a normal function
> on the plugin
> })
>
> Widget.js could just see which functions look for events and setup
> delegation on the element for you.
>
> Now, what if you can create your plugin like:
>
> var instances = $('.someClass').todo(options)
>
> and it would return the 'instances' of the plugin you were operating
> on so you could do something like:
>
> instances[0].destroyed();
>
>
> MVC isn't over-engineering in a 'large' project because it fits
> perfects with what you always have to do.
>
> -respond to events
> -connect to/manipulate services
> -wrap data from those services
> -Build/manipulate HTML/DOM
>
> Logically separating these concerns is extremely helpful. Doing it in
> an organized and repeatable fashion is event more important.
>
>
>
> @nicolas - I was never implying any of this should be part of the
> core. It should not be. I was simply proposing that a new 'branch'
> of jQuery is started with a focus on tools and structure needed for
> large projects.
>
>
>
>
>
> On Feb 25, 6:11 pm, tres <treshug...@gmail.com> wrote:
> > I think 'MVC as it states - Model, View, Controller - in JavaScript
> > terms, is over-engineering what doesn't need to be over-engineered.
> > jQuery in it's simplicity can evolve with a very complex application
> > quite nicely.
> >
> > That being said, I have authored myself a plugin called jFrame in
> > order to help with code convention, organization as well as automated
> > loading. Works nicely for me.
> >
> > -Trey
> >
> > On Feb 25, 8:26 am, 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
-~----------~----~----~----~------~----~------~--~---
