Recap ... 1. JR has a strategy with which I agree right now. The whole jQ "movement" matures very quickly. If anything jQ lacks it is one thing: stability. I think, jQ right now, before anything else needs much better Wiki, full of usefull conceptual material, diagrams, samples etc. And I can not be happier when I see that JR et. all. do realise that. 2. OO: we (IT community) have nothing better (yet). Feel free to dive in. It is mature and proven and mutch older thank you think ;o) 3. MVC: one of the oldest OOA concepts (we are talking 70's here!). Things have advanced since then ... considerably. (sideline: But not for M$FT , who is trumpeting MVC 30+ years later, after OO disasters like MFC, COM and yes, .NET ) 4. Inheritance : somehow it turns out that the trully usefull software is never based on inheritance. c++ stdlib (aka stl) and loads of others, including jQuery. Keep that in mind. There must be a reason for that. 5. The last but not the least is a little herresy: JavaScript is not the best programing language ever. It is invented with a very strict and narrow scope. Maybe one could consider more appropriate or mature languages for server side, like : ... Python or PHP? Even Java will do ;o) Oh, and there is always c++ ;o) ECMA 4 (http://www.ecmascript.org/es4/spec/overview.pdf) is based on the same assumption (about current JavaScript). Unfortunately it is fundamentaly wrong and too late anyway. So look elsewhere ;o)
My five points . Thanks for persevering and reading all the way till here... --- DBJ On Apr 28, 2:07 pm, 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, > > > Trey > > > > On Feb 27, 6:03 am, 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 > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
