Thanks for the response John. On Feb 24, 4:36 pm, John Resig <jere...@gmail.com> wrote: > > 1) If you have to work with certain design patterns, either out of > > personal preference or because that's how your organisation works, > > jQuery will allow you to do that. For example, I rolled my own MVC > > framework on top of jQuery with no problems. However, it would have > > been beneficial to have had a known, well-supported MVC framework to > > use off-the-shelf. For someone coming into JS development from other > > areas where these frameworks are just part of the standard toolset, > > jQuery can appear a bit too minimalist. > > I'm not convinced by this argument. "Because it's what we're familiar > with" does not imply that it's the best solution - or even a good > solution - neither does "everyone else is doing it." I've been doing > JavaScript development for a while now and I'm becoming less-and-less > convinced that the traditional MVC/Classical inheritance styles of > development (carried over from Java or Ruby, for example) do not > translate to JavaScript/DOM well and can, in fact, be improved upon in > some dramatic ways.
Point well made. My only problem here is that without classes or some kind of pattern to organise code, very large jQuery projects can become unwieldy. Dividing things into MVC components is one way of dealing with that complexity. Is there a better way that is a more natural fit for jQuery? > > 2) There's a lot of stuff being done in support for RESTful Ajax (the > > RESTful JSON stuff is v. cool imo). Again, jQuery has no explicit > > support beyond allowing you to do Ajax calls. This is great, but it > > would save on development time if there were standard libraries that > > could support common REST patterns. > > Can you expand on this? We already do a pretty good job of this. I > think there's a bug filed to try and improve upon our content-type > checking and data determination. It sounds like you're using > Ruby/Rails so you can feel pretty safe in knowing that we're going to > have the best solution here (especially since one of our team members, > Yehuda Katz, is a Rails core contributor). Not specifically Rails, no - I've never used it. The code I've written (which duplicates a lot of Justin's work) allows me to do stuff like OrderModel->findById(4), which results in an Ajax request GET /orders/ 4. A complete list of orders is available at /orders/ which supports pagination using the Content-Range header. I can do var x = new OrderModel; x.property = y; x.save(); and this will be POSTed to / orders/. I think that this is sufficiently generic that, with some configuration to allow for unusual REST implementations, it should live in a standard library. What I'd like to be able to do is link specific properties in my model with values of elements in the DOM, so that when a text input box is changed, this automatically updates my model etc. Obviously this can all be done via a plugin and I'm not suggesting that it needs to be part of jQuery core, but I think it could be good to have some 'official' plugins on a similar level to jQuery UI. This all really focuses on the 'model' aspect of MVC - I'll come back to that in a moment. Basically, I'd like to get the ease of use with remote data sources that jQuery gives me with the DOM. Searching, filtering, selecting, loading, saving, the works. > > 4) No real support for data handling. That means ORM for stuff like > > Adobe AIR SQL databases (or other SQL databases), no particular > > support for ActiveResource-style use of remote data as a data source > > (see #2). Basically, jQuery is awesome for handling the DOM, but what > > if your data lives somewhere else, and most of your app revolves > > around manipulating that data? > > I disagree on the client-side SQL database/ActiveResource style stuff. > The client-side SQL stuff is used so infrequently (on specialized > WebKit platforms, only) as to relegate it only to plugin status, at > best. As far as the ActiveResource stuff goes - much of that dictates > how your server-side application should be structured and how it > should return data. jQuery has never been about that (dictating what > your page should look like or what server-side language you should > use) and it's flourished because of that. As I said above, I think that, with some basic configuration, a REST client is generic and not too dependent on server-side configuration. I think this will be important for interfacing with data sources based on CouchDB, Cloudkit, Persevere etc., as well as Rails/other frameworks which are easily configured to serve JSON in a RESTful way. > > I would consider your case to be a specialty case - much like the > jQuery users who embed jQuery in Firefox extensions, or server-side in > platforms like Jaxer. We want to support you (make sure the code > doesn't break) but outside of that we need to keep true to our primary > goal: Cross-browser JavaScript/DOM development. You're right, and the reason I use jQuery is because it's the best library at what it does. I don't want to see jQuery burdened with pointless features or ill-fitting paradigms. I think my case is likely to become more common over time though, as non-standard browsers become more common. <<stuff about OO>> 100% agreed, OO is not necessarily the right way to go. > This brings up an other point: If there was a sanctioned MVC/Classical > inheritance/OOP piece of code for jQuery it would become a huge > dependency burden for most users and developers. Since most developers > would see this tool and try to apply it to their problem, most plugins > would instantly have an other required piece of code for jQuery users > to download -- and at that point we would be forced to include it in > core anyway. Point well made and understood. Perhaps what we're looking for here can be achieved without the wholesale adoption of an MVC framework. Perhaps the UI/widget framework can do a lot of the visual controller stuff anyway, allowing people to create abstract 'objects' (without full OOP) for controlling visual elements. Obviously DOM manipulation provides us with a view component, and people are free to create templating systems or whatever else they like on top of that. The real area where progress can be made, imo, is in data handling. That means, for example, being able to define a 'model' with certain fields, tying those fields to DOM elements, and automatically validating the input in those elements against the rules within the model, then calling a simple function to persist the model data to the server, or load a new model and display that instead, etc. I think that this would be sufficiently useful that a 'jQuery Data' plugin that aims to make this kind of task as easy as DOM manipulation is already would be worth pursuing. Full MVC would be one extension of this approach, but not essential to it. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
