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
@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
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 jQuery
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
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
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
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.
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 over-engineer
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
On Feb 26, 5:37 pm, chris thatcher
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
> widgets. And add a spot for the
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 t
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 int
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 make
Actually, we wrote up how to write API documentation a while back:
http://docs.jquery.com/How_to_write_API_documentation
You can feel welcome to document your plugins on the jQuery wiki (and
in doing so, your docs will be able to be extracted to api.jquery.com,
visualjquery, and other resources).
I know that this may not be the best place to ask this, but since it
was mentioned quite a few times, I'll ask anyway.
At the moment, are there any guidelines for writing documentation for
plugins, or at least some indication on how jquery plugins should be
documented? Or is the pattern of jquery
I agree with justin that mvc is an important pattern. I agree with trey that
with javascript mvc is in someway built in.
The issue is both organizational and a metaprogramming problem.
Even 30+ files or 'classes' (outside of core and plugins) can make a project
difficult for new developers to con
@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) i
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 hel
Matt, I generally agree with all of your suggestions, and I believe
that if they are applied in practice it will benefit all those who
deal with jquery in one way or another. Having said that, it is highly
unlikely that all those suggestions will be implemented by the
majority of users. These thin
On Feb 25, 11:36 am, Daniel Friesen 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 understanding why noth
Paul Bakaus wrote:
> 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 wrote:
> ...
>> - Debugging utility
>>
> This could be external, but I could also imagine having a prebuild "debug"
> version of
> jQuer
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 s
On Feb 24, 10:36 am, John Resig wrote:
> If I had to guess and put percentages on the jQuery user base I would
> say that they break down something like this:
> - 95% of jQuery user's needs are perfectly met by current jQuery
> code/plugins (19 out of 20 users)
> - 4% of jQuery user's create co
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 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 used as true
r
On Feb 24, 5:44 pm, John Resig 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 that's
>
On Tue, Feb 24, 2009 at 5:29 PM, Matt Kruse wrote:
>
> On Feb 24, 2:15 pm, Mike Hostetler 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 th
Well, yes that's not the only reason for the /fork/. There are others,
and it could also be considered an experiment in getting public
involvement/opinion (I'm thinking of experimenting with a ideatorrent
setup).
I actually made some plans and a standard on how to deal with renames in
the oth
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
Umm, we're talking about standard naming of jQuery plugins, not jQuery core.
I'm very skeptical that any renaming (as you put it) of jQuery methods
would require a fork of a project (and that existing plugins would
even still work without a lot of changing).
Have you filed any bugs on inconsiste
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 ov
On Feb 24, 3:57 pm, John Resig 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,
context menu,
Ohh, a defined convention for the API?
The inconsistency and messiness of method naming inside of the jQuery
API was one of the reasons at work we decided to fork jQuery into a
project for cleaning it up instead of just using it directly.
The aim wasn't to replace jQuery with the project, but w
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, 2:15 pm, Mike Hostetler 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 provided
> to developers
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.
> 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 implemen
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 wrote:
> I can help write up the following, as I'm already writing some of this
> already:
>
> Needs
I can help write up the following, as I'm already writing some of this
already:
Needs (defined/documented) conventions:
- File names
- Method names
- Method structures
- Testing
- Documentation
- Packaging
Mike Hostetler
http://amountaintop.com
On Tue, Feb 24, 2009 at 14:37, chris thatche
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 4:2
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'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 mor
JS is Object Oriented. So are we really just talking about classical
inheritance (and even more specific, _super) ?
I see how widget.js creates a plugin. But how does one expand on the
plugin?
I'm more than happy with widget.js if you can easily expand on the
widget. For example, quickly add
> - 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 load
> 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
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
understand
Hi Justin -
> Thanks for your reply! You are absolutely right that we need to
> discuss which problems are difficult to solve.
>
> Is it safe to say that you agree that jQuery says very little about
> how to :
> - package and minimize multiple flies
> - document
> - test
> - dependency manageme
Justin Meyer wrote:
> John,
> Thanks for your reply! You are absolutely right that we need to
> discuss which problems are difficult to solve.
>
> Is it safe to say that you agree that jQuery says very little about
> how to :
> - package and minimize multiple flies
> - document
> - test
> - dep
John,
Thanks for your reply! You are absolutely right that we need to
discuss which problems are difficult to solve.
Is it safe to say that you agree that jQuery says very little about
how to :
- package and minimize multiple flies
- document
- test
- dependency management
- log errors / debug
> 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) f
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 the sit
Thanks for the response John.
On Feb 24, 4:36 pm, John Resig 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 Tue, Feb 24, 2009 at 10:05 PM, John Resig wrote:
>
>> 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
> 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
On Tue, Feb 24, 2009 at 9:36 PM, John Resig 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, well-organized, all
> 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
> functionalit
> @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 o
> 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 t
Justin,
I've been following your work for a while now, and I have to say I really
dig JavascriptMVC. I think there are some amazing ideas in there, and I know
I'll be keeping an eye on what you're doing.
@John regarding his specific questions:
Part of the issue isn't that there isn't any way to so
There are a few problems to which jQuery isn't a good solution at
present:
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
Hi Justin -
> 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 be time for a sister
> project that provides important, but less commonly
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 (rat
Sounds fantastic to me.
On Feb 24, 6:38 am, Justin Meyer 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 be time for a sister
Awesome,
as a fan of JMVC and jQuery, i can´t wait to see this.
--~--~-~--~~~---~--~~
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 unsubscr
63 matches
Mail list logo
