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
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.
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,
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
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
Sorry, I didn't mean to offend you. What it really comes down to, I
think, is two different methods to tackle the same problem. I like
your initiative and enthusiasm and it's nice to see someone else out
there who sees a need for organization with JavaScript.
My *opinion* that it isn't for
@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
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.plugin.js.
Anyways, I am not trying to say MVC is
Hi guys,
I have written a couple of plugins that I'd to share. The first is an
MVC style mini-framework with the M and V (or C, depends on how you
look at it) stripped out of it. Anything more, IMHO, is overdoing it
no matter how large the project. It is called jFrame. It works on top
jQuery and
Having missed most of the discussion, I wanted to at least throw in
some existing resources on the topic.
For one, the Plugin Authoring guide covers a few of the requirements
that Matt listed: http://docs.jquery.com/Plugins/Authoring
On the topic of extending plugins, I covered one approach to
On Feb 26, 5:37 pm, chris thatcher thatcher.christop...@gmail.com
wrote:
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
Heads up: I just updated that page because it was a little out of
date, especially with the jQuery UI/Draggables/draggable examples. If
anyone sees any obvious errors, feel free to fix them.
Also, if we're going to make this a standard way for people to
document their plugins, it might
I'll admit that I wasn't aware this page existed. As for jQuery UI
documentation, it's had a bit of an overhaul over the last couple weeks.
It's now similar, but significantly different (read: incompatible) with the
jQuery docs standard. This is necessary for a number of reasons that I won't
go
@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)
Hey John, sorry to chime in late here, just wanted to get my thoughts out as
well:
On Tue, Feb 24, 2009 at 10:26 PM, John Resig jere...@gmail.com wrote:
Ok, so boiling down a list:
Needs code:
- Widget utility (I'm working on this)
We should make sure the new core widget factory can be
Some great replies by Matt Kruse.
I'd like to propose, in addition:
13. In all but trivial circumstances, events and callbacks should
always be implemented with named functions. Invoking in-situ
anonymous functions and callbacks, as convenient as these may appear,
are eventually going to give
On Feb 25, 11:36 am, Daniel Friesen nadir.seen.f...@gmail.com wrote:
I also thought about the idea of a jquery-debug.js at one point. My
thought was adding a number of logging statements for various warnings
(selector found 0 nodes but you try to style or do stuff to it; common
issue for not
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
I'd just like to speak up in favour of this proposal. Working on a
JavaScript/AIR project recently, I rolled my own JavaScript MVC
library on top of jQuery, largely because I didn't know that
JavaScriptMVC existed at the time I started, and I wanted to keep
jQuery at the heart of the project
Sounds fantastic to me.
On Feb 24, 6:38 am, Justin Meyer justinbme...@gmail.com wrote:
jQuery community,
Amazing work. I can't believe how fast jQuery has developed into
the best bottom-up JS library. 1.4 looks great. But as jQuery expands
to include things like lazy loading, it might
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
@John regarding his specific questions:
Part of the issue isn't that there isn't any way to solve jQuery's
shortcomings, it's that there are no really good ways to solve them.
For instance, I know I can use closures to get around scoping issues in
jQuery, but most enterprises are stuck on
disclaimer: I've just built a pretty complex app (drag/drop, inline editing,
history support, popup windows) with jmvc jquery
I personally feel that jquery as it stands at the moment is superb for doing
all the nitty gritty details of dhtml sites, but as the scope of the
functionality in
On Tue, Feb 24, 2009 at 9:36 PM, John Resig jere...@gmail.com wrote:
3) I know jQuery UI supports widgets, but it's a long way off being a
comprehensive UI/widget framework.
Absolutely - and it's a definite work in progress. The UI team is
getting larger, becoming more efficient,
This is my biggest contention with the widget framework at the moment
and I am only left with the option of copy/pasting snippets due to
lack of extensibility features. In fact, if I may be bold enough to
say it, I think the widget framework wasn't well planned and I have a
feeling that due
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
Quick comments:
On OOP and not being convinced. What other approaches are you hinting
at? OOP being well understood is a valid argument only because
inheritance and OO does provide reuse. If you have something that
does work in many cases, you are allowed to factor in popularity and
- 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
I'm a little scared of jumping into this, but I feel I'd like to make a few
quick points, as I've run up against these issues myself.
1. I've scheduled time for myself and my team to re-build the plugins site
next week. The goal initially is simply to re-create the existing
functionality in a
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
I'd definitely be interested in working with someone like Justin to
define/document the conventions listed. Keeping the guess work out of
thoses area would benefit the plugin developer community for sure and help
lower the barrier of entry for new developers.
Thatcher
On Tue, Feb 24, 2009 at
Mike, Justin, other's interested in helping with this area,
Can we chat for 30 min this evening online and talk about how we
coordinate?
Thatcher
On Tue, Feb 24, 2009 at 4:45 PM, Mike Hostetler mike.hostet...@gmail.comwrote:
I can help write up the following, as I'm already writing some of
JS is Object Oriented. So are we really just talking about classical
inheritance (and even more specific, _super) ?
Yeah, I'm talking about constructing classes and inheritance.
I see how widget.js creates a plugin. But how does one expand on the
plugin?
There's two ways (one
Don't want to sound like I'm pushing my own wishlist (though this is
up there on mine) but I consider browser history support to be a
critical for RIA and usability. AJAXy apps have hijacked native
browser navigation/bookmarking facilities.
Whether or not this belongs in the core, I am not sure.
On Feb 24, 2:15 pm, Mike Hostetler mike.hostet...@gmail.com wrote:
If the
jQuery team adopted a few choice plugins, like a debugging plugin, a data
layer plugin, and by putting the widget code into the core, allowed these
plugins to be extended, I think a very powerful foundation would be
Somewhat off-topic, but:
On the other hand, property lookups in Internet Explorer are just
abysmal - and you'd be doing a ton of those if you were using nothing
but OO techniques. You're damned if you do and damned if you don't in
the land of Internet Explorer!
John, do you have any documentation
On Feb 24, 3:57 pm, John Resig jere...@gmail.com wrote:
Does anyone have
any examples of plugins that they wished to extend in a particular
manner? (I needed the validation plugins X method to do Y - examples
like that.)
Many!
I've had to re-write BlockUI, Autocomplete, accordian, bgiframe,
I think I agree with all of your points, a great list. I was wondering
if you could clarify:
3. Users should be able to over-ride defaults at the plugin level
(true for all instances) or per-instance
Do you mean something like: .myplugin({ myprop: override }) where
passing in the option
John,
I am potentially interested. I'm concerned that what you are
proposing would be a step back in helping large application
development. There are a few reasons:
1. Some of jQuery's current conventions might hurt large projects
(I've seen far too much added to $ and jQuery.fn ). Without
On Feb 24, 5:44 pm, John Resig jere...@gmail.com wrote:
3. Users should be able to over-ride defaults at the plugin level
(true for all instances) or per-instance
Do you mean something like: .myplugin({ myprop: override }) where
passing in the option overrides it for that instance? (I think
40 matches
Mail list logo
