下面这几点希望能够帮你加快你的学习。
1.把selectors当作asp.net中的sets。
在asp.net的世界,通过一个查询找到一系列控件是非常少见的.相反我们比较习惯于通过一个唯一的ID来找到一个控件。当然,在jQuery中这个也是没有问题的,但是jQuery的选择功能相对更加神奇。
使用jQuery的selectors能够很容易定位到一个set的元素,相对来说比在asp.net中使用迭代的规则来找到一个set的元素更加清晰和易于表达。
2.使用CSS类来代替styling。
另外一个不直观的技术是把CSS类作为一个flag。与'selector engin'一样,'flag'类也是个令人惊喜的东西。
举个例子来说吧,最近有个活动是做一个在线的能够与客户端互动的纸牌游戏。一个需求是纸牌需要有个onclick haddler在某个特定时间,不过这些事件只针对那些face down(脸朝下)的。作为一个.net的开发者我立刻能够想到的办法是让这些纸牌在客户端通过一个collection来编号.然后我可以在需要的时候给这个数据一个onclick handlers。这个固然可以,不过难以维护且有点凌乱。
现在如果我使用CSS类来实现，face up的纸牌我通过addclass方法为它们加上一个'flipped'类,然后可以通过一个简单的 '$(".card:not(.flipped)")'选择那些face down的纸牌。使用jQuery的click(fn)功能能够让我使用几行代码就实现这个功能。更重要的是它更容易理解和读取。
下面附上几点英文原版的:
3。Understand unobtrusive JavaScript.
In the ASP.NET world, we use a lot of what's sometimes termed obtrusive JavaScript. This means that client-side event handlers are defined as attributes on elements. For example, several ASP.NET WebControls render an OnClick=”javascript:__doPostBack()”attribute as part of their markup. This is considered obtrusive JavaScript.
When ASP.NET was initially being developed, this inline JavaScript was the norm. However, as browsers began providing more sophisticated faculties for imperatively adding event handlers, this declarative technique quickly lost favor with client-side developers. As a consequence, the preferred approach has shifted toward what's called unobtrusive JavaScript.
Unobtrusive JavaScript is now considered a best practice when wiring up client-side event handlers. This is primarily because it facilitates separation of concerns between behavioral JavaScript and structural HTML markup. Unobtrusive JavaScript also helps you to write cleaner, more semantic markup, which improves accessibility and often has SEO benefits.
Use the console to learn interactively.
Coming from the save-compile-reload paradigm of statically typed server-side development, it's natural to approach client-side development in a similar fashion. While you certainly can write client-side code that way, it's akin to working blindfolded when you consider the alternatives.
Since JavaScript is usually interpreted by a browser, the browser is one of the best debugging environments available. In particular, a JavaScript “console” is terrific for interactively interrogating the DOM, testing jQuery selectors against actual markup, and refining JavaScript code in real-time.
My preferred browser-based tool is the Firebug addon to Firefox. I cannot praise this Firebug highly enough. It has revolutionized how I approach client-side development, both of JavaScript and of CSS. If you prefer Internet Explorer, IE8's updated developer tools are also very capable in this department.
Whatever your browser of choice, I urge you to give these utilities a try when debugging client-side functionality. Once you become proficient with one of these tools, you'll be amazed that you ever developed client-side code without it.
Get the VSDOC.
Even though browser-based tools are great for debugging, an ASP.NET developer's primary editor is still going to be Visual Studio. When writing jQuery code in Visual Studio, having proper Intellisense can make a tremendous difference in productivity. The discoverability that Intellisense provides is especially beneficial when you're unfamiliar with jQuery's API.
As part of the official support for jQuery, Microsoft provides a documentation file to provide jQuery Intellisense inside Visual Studio 2008. This is provided through what's called a vsdoc file, and is available on the jQuery download page (via the “Documentation: Visual Studio” links).
Jeff King has assembled an excellent FAQ to help you get Visual Studio 2008's JavaScript Intellisense working: http://blogs.msdn.com/webdevtools/archive/2008/11/18/jscript-intellisense-faq.aspx
