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