So far, all of the steps we have followed work with the
vanilla ASP.NET 2.0 and Visual Web Developer tool products – we haven’t used
any Atlas features yet.
What we want to-do is to use Atlas to replace the built-in
ASP.NET post-back model so that instead of refreshing the entire page when a
post-back occurs, we use XMLHttp to only send back the regions of a page that
have changed. This enables us to make the page feel much more dynamic,
perform faster, and obtain a much richer user-experience.
Step 14) Our first step to add Atlas support will be to add
the <atlas:scriptmanager> server control to the page, and set its
“EnablePartialRendering” attribute to “true”:
Figure 34
Step 15) We are then going to add an
<atlas:updatepanel> control onto the page, and use it to wrap our
GridView control and associated content:
Figure 35
This is now an “updatable” region within our page – which
means that when a post-back event occurs, Atlas will intercept the event, and
instead of refreshing the entire page it will use XMLHTTP to just send back
partial updates from the server, and then dynamically repaint those portions of
the page.
Try running the application again, and add a new item, then
sort, filter, and edit items. Notice how fast it feels – and the fact
that the page wasn’t refreshed on each action.
Step 16) When running the above app, you might have noticed
when you added a new item to the list, the textbox value wasn’t cleared. This
is because the textbox lived outside of the <asp:updatepanel> we added
above – and so wasn’t refreshed as part of our post-back call.
We could either move it to be inside the above
<asp:updatepanel> or more optimally choose to add a new <asp:updatepanel>
to the page that contains in. This is more optimal because we will not update this panel every-trip to the server, but
instead only when a declarative trigger that we’ll specify occurs (or
alternatively if someone writes code on the server to explicitly trigger
it).
Figure 36
The above trigger means that this panel will only be
refreshed only if the “add” button fired (or if we wrote code on the server to
explicitly refresh it). This means it will not fire in response to the
drop-down filter changing, or to sorts, edits, updates, deletes within the
GridView.
And now when we run our application again, it is ajax enabled, and allows us to dynamically add, remove, update, sort, page and filter our
list items….
The full-blown sample I showed at the beginning does a few
more cool things, but the walkthrough above captures the basic concepts from
it. As you can see, building one of these types of apps be done in
minutes, doesn’t require much code at all (you only have to manually write 4
lines of code total), and enables you to start building Ajax applications with
a fraction of the concept count from before.
Hope this helps -- and happy holidays,
Scott
