I think it is important for jQuery to have at least a package management tool.
an example of use case is: - two plugins shares same name of jquery extensions. plugin a : jQuery.fn.func1, jQuery.fn.func2 plugin b: jQuery.fn.func1 - jQuery.fn.func2 depends on jQuery.fn.func1 - you need jQuery.fn.func2 from plugin a and jQuery.fn.func1 from plugin b. - loading plugin b would break plugin a What we need is, a way to isolate each plugin, so plugin a and b work seamlessly together. My approach would be that jQuery can have multiple instance. with each instance having their own $.fn. And each instance is able to export and import properties and of course plugins. Here is a mockup on how it could be done: http://friendpaste.com/2EIjWUxrWqQ8qFcjtc3RSQ here a implementation example (experimental packaging tool, without jquery): http://github.com/raid-ox/xi/tree/master What do you think? On Apr 29, 7:29 am, William Chang <diehardb...@gmail.com> wrote: > @Justin Meyer > @John Resig > > Put it this way... > > This is how I think jQuery (the core library) is like a global/ > singleton object that can be used anywhere or in MVC/Classical > Inheritance/OOP all the classes are inherit from jQuery undisclosed, > because it is the ultimate parent. > > The JavaScriptMVC is great and I think it compliment jQuery well, as > long it lets you use the jQuery object anywhere. I don't want jQuery > to reinvent the wheel to be another MVC or MooTools Class (file > Class.js) framework. If we want MVC/Classical Inheritance/OOP, then > jQuery should recognize and extend from JavaScriptMVC to be part of > jQuery documentation (on best practices and coding conventions) for: > - File names > - Method names > - Method structures > - Testing > - Documentation > - Packaging > > The third parties libraries like jQuery UI or plugins, yes, need > overload/override/extensibility/modularity in them by default and > jQuery (the core) should be static. > > Sincerely, > William Changhttp://www.williamchang.org > > On Apr 28, 12:49 pm, Justin Meyer <justinbme...@gmail.com> wrote: > > > Tres, > > Besides plugining your own framework is there a reason why you don't > > think JMVC is for jQuery? You yourself even express the needed for > > tighter control of jQuery and have gone as far as building your own > > tool. > > > At it's center I a proposing a standard way of organizing the only > > things a JavaScript application actually does: > > > Respond to events > > Request data / manipulate services/ Ajax > > Wrap the service data > > Update the DOM. > > > Why do you think JavaScriptMVC is over doing it? Because it is more > > than one file? That is actually a huge advantage ... it allows > > developers to add only the functionality they need without having to > > worry about compression. > > > If you are going to share a 'harsh opinion' please provide reasons for > > why the above Controller and View wouldn't be useful. If you can, I > > think you'd be the first person who doesn't like them - especially > > controller ... I mean, just look at that syntax ... your function > > names are what they respond to ... and who doesn't like event > > delegation? In fact, I'll take the pepsi challenge and promise that > > with JMVC's tools that I can create easier to understand and modify > > code, faster, than with jQuery alone. > > > John has posted some valid points about how some of JMVC's features, > > namely class, could invade the core. However, I'm not sure if even > > John has worked on projects as large and complex as those that have > > prompted JMVC. In these projects, a wiki of suggestions is not going > > to be enough to refine a large group of limited skill developers code > > so that it is maintainable. > > > However, for the (lucky?) few that find themselves losing the reins of > > apps that make Gmail look small, there will be an jQuery based > > solution for them. I'm hoping to find a few who are willing to help > > me perfect the tools and techniques. > > > If you do want to explore these techniques I'm super pumped to work > > with you. Just let me know what you think jQuery needs. However, > > more than one file is a good thing :). > > > @DBJ 2-4 is all done in JMVC. Please let me know if you have any > > comments on the above syntax. > > > On Apr 28, 8:07 am, tres <treshug...@gmail.com> wrote: > > > > Justin, > > > > I think you have some good points about what you are trying to > > > achieve, but personally, I don't think jMVC is for jQuery. I would be > > > interested in collaborating on some projects such as this in the > > > jQuery realm, though. I have done a bit of development on something > > > similar (although, it's one JS file ;) ) and have recently implemented > > > the execution of javascript files withing the context of part of the > > > DOM as well as (previously) lazy loading, caching and namespacing > > > while taking bits from ruby on rails, zend as well as my personal php > > > mvc framework. > > > > Sorry. Harsh opinion, but I wouldn't be me without it. If your > > > interested on working on some projects (as well as other people), I'd > > > love to hear back from you. > > > > -- > > > Trey > > > > On Apr 28, 4:40 pm, Justin Meyer <justinbme...@gmail.com> wrote: > > > > > If anyone out there is still interested ... I just put up the first > > > > alpha. It's pretty slick. You can find it here: > > > > >http://javascriptmvc.com/wiki/index.php?title=Downloads > > > > > I re-mapped JMVC's Controller, View, and Class to work nicer with > > > > jQuery. And, compression works with the latest env.js. > > > > > Here's how class basically works: > > > > > $.Class.extend("Name.Of.MyClass",{ > > > > static : function(){return 'static' }},{ > > > > > init : function( val){ > > > > this.val = val; > > > > } > > > > proto : function(){ return this.val } > > > > > }) > > > > > Name.Of.MyClass.static() // -> static > > > > new Name.Of.MyClass(''proto').proto() // -> proto > > > > Name.Of.MyClass.extend("NewClassName",{},{}) //-> NewClassName > > > > > Here's how a very simple 'show content' controller could work: > > > > > $.Controller.extend("ShowController",{},{ > > > > 'a click' : function(el, ev){ > > > > var id = el.attr('href'); //get id we want to show > > > > this.element.find(id ).toggle(); //find it inside the 'wrapped' > > > > element > > > > ev.preventDefault() //prevent browser from auto-scrolling there > > > > } > > > > > }) > > > > > You could add this to any collection of a's like the following: > > > > > <div id='mycollection'> > > > > <a href='#place_to_open'>Open</a> > > > > <p id='place_to_open'>Blah Blah</p> > > > > </div> > > > > > $('#mycollection').show_controller(); > > > > > Honestly ... what could be better than that!!!! I mean really. That > > > > has got to be the nicest way of defining and grouping functionality > > > > just about ever. > > > > > A few more things about this..... > > > > > When you 'add' show controller to mycollection it does the following: > > > > > adds the class name 'show_controller' to mycollection making it easy > > > > to figure out what controllers are responding to mycollection just by > > > > inspecting the dom. > > > > > puts the controller in the element's data so you can get it like: > > > > > $('#mycollection').data('show_controller') > > > > > And remove all functionality like: > > > > > $('#mycollection').data('show_controller').destroy(); > > > > > You can also have 'setup' functionality. Lets say we wanted to hide > > > > everything in our element that matched some selector, we could add an > > > > init function: > > > > > $.Controller.extend("ShowController",{},{ > > > > init : function(element, hideSelector){ > > > > this._super(element); //sets the element to delegate from and > > > > this.element > > > > this.element.find(hideSelector).hide() > > > > }, > > > > 'a click' : function(el, ev){ > > > > var id = el.attr('href'); //get id we want to show > > > > this.element.find(id ).toggle(); //find it inside the 'wrapped' > > > > element > > > > ev.preventDefault() //prevent browser from auto-scrolling there > > > > } > > > > > }) > > > > > now we could call it like: > > > > > $('#mycollection').show_controller('p'); > > > > > How fantastic is that. This can be better for jQuery that the jersey > > > > we gave John. > > > > > And if you wanted to extend the functionality and make it your own: > > > > > ShowController.extend("MyShowController",{},{ > > > > 'a click' : function(el, ev){ > > > > this._super(el, ev) > > > > el.text( el[0].style.display == "" ? "hide" : "show" ) //says > > > > hide or show > > > > } > > > > > }) > > > > > Oh, I almost forgot views: > > > > > $(".some_thing").append({view '/url/to/view', data: {message: > > > > "hello_world"}}) > > > > > in /url/to/view.ejs > > > > <h1><%= message %></h1> > > > > > prepend, after, before,replace,text,html all work too. > > > > > Now that I got a rough draft ... I'm really looking for people who > > > > want to take this project to the next level with me. Give me a shout > > > > if you are interested and what you think -> justinbme...@gmail.com > > > > > John, let me know if there is a better place for this. It's very > > > > jQuery related, but don't want to be spamming anyone. > > > > > My next step is hardening the API and getting rhino and selenium > > > > testing working. > > > > > On Mar 1, 7:33 am, tres <treshug...@gmail.com> wrote: > > > > > > I realized after I made my last post (#57) I realized that you > > > > > described almost exactly what I had just built :). Sort of like > > > > > finding money behind the couch! > > > > > Try:http://code.google.com/p/jquery-plugin-dev/source/browse/trunk/jquery.... > > > > > > Anyways, I am not trying to say MVC is over-engineering in practice as > > > > > I do understand the need for organization, code-reuse and convention > > > > > (I've authored my own PHP5 MVC framework), but currently I think that > > > > > with JavaScript, there needs to be a happy medium between performance, > > > > > organization and convention. Separating these out into at least 3 > > > > > server calls per page, plus extra processing time that comes from > > > > > dispatching and routing, has the potential for a bit of overhead, > > > > > especially in a large application. > > > > > > UI, being as dynamic as it is, calls for many different situations > > > > > where you might respond to an event by posting a form via ajax, and > > > > > when that is done manipulating the DOM accordingly. As simple as that > > > > > seems, more often than not something will vary with the way JavaScript > > > > > will have to handle the user's last interaction. Sometimes, simple > > > > > conventions and organization is less work and easier to maintain. The > > > > > simplest answer is usually the best answer (within reason, though). > > > > > But that is just my opinion. > > > > > > Cheers, > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
