Persistent client-side event sinks
The following example shows setting up an event sink that will result in the title attribute of all spans getting dumped to the debug trace. This starts working at the moment the call is made and will continue working even for new spans that get created after that.
$listen(“hover”, “span[title]”, function(e) {
Sys.Debug.trace(this.title);
});
The average web page’s DOM is becoming increasingly volatile. Elements may be destroyed, appended, and replaced many times between each page refresh. Maintaining event handlers on those relatively ephemeral elements is often a significant headache.
Hence I think $listen has great potential, with one caveat: Performance.
If I have a dozen $listen sinks set up, what happens when I dump a thousand new elements into a table or select list? Will a $query be executed for each $listen, on every DOM modification?
If $listen introduces client-side hangs during those sorts of operations, the convenience would not justify the trade-off. Please be sure to include that sort of scenario in your testing.
Client Data and UI Templates: The Good
For performance critical functionality, using something like the UpdatePanel will never be a panacea. It was a noble effort, but trades far too much performance for its simplicity. When speed counts, the only thing on the wire should be data.
For that reason, I’m very happy to see client-centric markup generation being officially supported. Check out this example code, from the road map document:
<div id="repeater1"></div>
<div id="template1" class="sys-template">
<h2><a href="{{ products/ + id }}">{{name}}</a></h2>
<p>{{description}}</p>
</div>
<script type="text/javascript">
Sys.Application.add_initialize(function() {
$create(Sys.UI.DataView, {
template: $get("template1"),
data: myData
}, {}, {}, $get("repeater1"));
}
</script>
This implementation is fundamentally similar to my recent post on creating a client-side repeater with jQuery and ASP.NET AJAX. I think it will be a solid step in the right direction, and it will be great to see the technique become more mainstream in v.Next.
Client Data and UI Templates: The Ugly
The road map goes on to describe more complex templating, attaching client-side behaviors through xmlns attributes, and even a client-side analogue for DataSource server controls. Here’s an example:
<body xmlns:sys="javascript:Sys"
xmlns:dv="javascript:Sys.UI.DataView">
<div id="tripList" sys:attach="dv" dv:data="{{myData}}"
dv:template="{{$get("template2")}}"></div>
<div id="template2" class="sys-template"
xmlns:ac="javascript:Sys.UI.AutoComplete"
xmlns:wm="javascript:Sys.UI.Watermark"
xmlns:dp="javascript:Sys.UI.DatePicker">
<input type="text" sys:id="{{ "airport" + $index }}"
sys:attach="ac,wm"
ac:serviceUrl="airportList.asmx"
ac:minimumPrefixLength="{{1}}"
wm:text="Type the name of an airport"
value="{Binding airport, mode=twoWay}" />
<input type="text" sys:id="{{ "flight" + $index }}"
value="{Binding flight, mode=twoWay}" />
<input type="text" sys:id="{{ "date" + $index }}"
sys:attach="dp"
dp:lowerBound="{{ new Date(1970, 4, 21) }}"
dp:upperBound="{{ new Date(2050, 1, 1) }}"
value="{Binding date, mode=twoWay}" />
</div>
In my experience, this code is not maintainable. Unless spectacular Intellisense and designer support accompanies its release, I wouldn’t expect it to see much use in production.
Further, the behavior and content should be separated; especially given that one of the road map’s stated goals is accessibility. Unobtrusive JavaScript is the way to go here, not overloaded declarative markup.
Can we get this functionality in a way that is conducive to separation of concerns?
Improved animation support
I bet there are more people who have used the toolkit’s AnimationExtender once than there are who have used it twice. It’s a very powerful animation framework, but unwieldy and difficult to learn.
For that reason, it’s a relief to see the XML syntax being abandoned for fluent JavaScript objects. The example from the road map:
$query(".sprite").animate([
new Sys.Animation.FadeIn(300),
{
"style.backgroundColor": "#ff0000",
"style.fontSize": "2em"),
duration: 500
},
new Sys.Animation.FadeOut(300)
])
);
That’s a massive improvement over the AnimationExtender, but still a bit verbose. It would be great if that could be further distilled down to something like this:
$query(".sprite").FadeIn(300)
.FadeCSS({
"backgroundColor":"#f00",
"fontSize":"2em",
duration: 500 })
.FadeOut(300);
New AJAX Control Toolkit components
The next section in the road map describes several new AJAX Control Toolkit controls in the works, and solicits community input:
Which controls get implemented first will highly depend on community feedback. We welcome suggestions and encourage you to communicate your preferences about which controls would be the most useful to you as well as what features you would expect on each of them. We identified the following controls as possible candidates:
High priority (v.Next):
* Grid. Make this work with ASMX and WCF JSON serialized services, and it will be the most popular control in the toolkit. Be sure that it renders <thead> and <tbody> elements, unlike the GridView.
* Upload. We need a solid solution to the async upload problem. It’s not something that would be used as often as the Grid, but would be nearly irreplaceable.
* Asynchronous validator. I began writing an asynchronous username availability validator last year, but became disillusioned before overcoming all of the hurdles involved. I think an asynchronous validator base control that allows custom, server-side validation rules would be a great addition.
Would be nice later:
* Progress bar. How would this work? If it were easy to use, it could be very popular. It shouldn’t be rushed though. Save this till later and take the time to perfect it.
* TreeView. This isn’t something I would use very much personally, but I think it would be welcomed by many developers.
Low priority:
* Layout. How many real websites use these ubiquitous splitter controls? They are typically indicative of a poor web UI, attempting to copy the layout of a thick client. We can do without this.
* Chart. It makes no sense to reinvent this wheel. A Silverlight based control isn’t going to be very widely adopted right now. More importantly, it doesn’t make sense to alienate the companies who have been supplying excellent visualization controls for years.
* Color picker and rich text editor. As with charting, this functionality has been available for many years. There are mature solutions already available. Your efforts would be needlessly squandered here.
JavaScript build tools
Aggregation and minification (is that a word?) is a constant thorn in my side. More details on implementation specifics would be nice, but I think the feature can only be an improvement.
While you’re supporting minify, you might as well add packer support as well. Depending on the speed of the client machine and execution order of scripts, packed scripts may load faster than minified ones, and can also be used to provide minimal obfuscation.
Ideally, this would enable us to work with an uncompressed, commented JavaScript include in debug mode. Then, in release builds, the include would be optimized and combined with other scripts. Please keep in mind that we may be using scripts hosted externally, which also have separate debug and release versions. A mechanism to allow for that would be excellent.
I think that the ability to add script references at the web.config level could be very useful as well. For example, I may want to reference jQuery throughout my entire website. Save me the trouble of adding that script include on every page, and I’ll buy you a beer the next time you’re in Atlanta.
Stay focused on your core users
Finally, I was surprised to see this ambitious goal early in the document:
Make ASP.NET Ajax the first-class choice for all Web 2.0 developers
I don’t mean to sound negative, but that is simply attempting to bite off more than even Microsoft can chew. At least in the near-term, developers using other application stacks or JavaScript frameworks aren’t going to replace what they’re using with v.Next of the client side ASP.NET AJAX library.
We need the ASP.NET Team to focus on the needs of those of us using ASP.NET AJAX today. Empower existing ASP.NET developers to create robust, dynamic websites, and you’ll find that our work has the potential to reach broad audiences on your behalf.
source: encosia
Related Stuff
-
MooV: Using cutting edge Video phones and Software Video Phones - coupling all that with VoIP and empowering the disabled.
-
Moo Telecom: VoIP communications made easy - Ring anyway with the fun and ease of using a normal phone
-
TagR:Mobile Social Network with Real Time Locations Based services, and Ambience Intelligence, VoiP, IM, Skype, Googletalk, Mapping, Flickr, Events, Calendaring, Scheduling, SecondLife Support
-
ClearSMS : ClearSMS is a Web-based application that lets you send bulk SMS messages to your customers, contacts, or just about anyone.
-
Jajah:jah is a VoIP (Voice over IP) provider, founded by Austrians Roman Scharf and Daniel Mattes in 2005[1]. The Jajah headquarters are located in Mountain View, CA, USA, and Luxembourg. Jajah maintains a development centre in Israel.
-
Skype: It’s free to download and free to call other people on Skype. Skype the number one voice over ip software
- PrivatePhone: a free local phone number with voicemail and messages you can check online or from any phone.
Be the first ... |Add your comment.
Your Comment ...
Name (required)
Email (required, hidden)
Website