荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: Jobs (温少), 信区: Visual
标 题: How is ASP+ Different from ASP?
发信站: BBS 荔园晨风站 (Sun Sep 17 02:48:39 2000), 转信
How is ASP+ Different from ASP?
In yesterday's article we saw in outline how ASP+ is now an integral
part of the operating system. But how, and why, is ASP+ different to
earlier versions of ASP? And just how different is it? Well, if you just
want to run existing pages and applications, you probably won't notice
the differences much at all. However, once you open up the ASP+ SDK or
Help files, you'll see a whole new vista of stuff that doesn't look the
least bit familiar.
Don't panic! We'll work through the main differences next. We'll start
with a look at why Microsoft have decided that we need a new version of
ASP, and how it will help you, as a developer, to meet the needs of the
future when creating Web sites and applications.
Why Do We Need a New Version of ASP?
The main motivations that Microsoft had when designing and developing
ASP+ were discussed in the previous article. Considering that ASP has
been so successful, why do we need a new version? There are really four
main issues to consider:
Currently, ASP can only be scripted using the basic non-typed languages
such as VBScript and JScript (unless you install a separate language
interpreter). While ASP does parse and cache the code for the page the
first time it is executed, the limitations prevent more strongly-typed
languages like Visual Basic and C++ from being used where this would be
an advantage. ASP+ provides a true language-neutral execution framework
for Web applications to use.
It is also very easy to create huge ASP pages containing a
spaghetti-like mixture of code, HTML, text, object declarations, etc.
And it's hard to re-use code, unless you place it in separate 'include'
files ?not the best solution. In many environments, developing a web
application utilizes the skills of a wide range of professionals, for
example, you have programmers writing the code, and designers making the
HMTL look good. Having both the code and the content intermixed in a
single file that both of these groups need to operate on makes it
difficult for them to work together. ASP+ allows true separation of code
and content.
In previous versions of ASP, you have to write code to do almost
anything. Want to maintain state in form fields? Write code. Want to
validate data entered on the client? Write code. Want to emit some
simple data values? Write code. Want to cache regions of pages to
optimize performance? Write code. ASP+ introduces a real component
model, with server-based controls and an event driven execution paradigm
similar in concept to the way that a Visual Basic 'Form' works now. The
new ASP+ server controls are declarative (i.e. you only have to declare
them in order to get them to do something), and so you actually write
less code ?in fact, in many situations you don't have to write any code
at all!
The world out there is changing. The proportion of users on the Web that
will access your site through an 'Internet device' such as a mobile
cellular phone, personal digital assistant (PDA), TV set-top box, games
console, or whatever else, will soon be greater that the number using a
PC and a traditional Web browser. This means that we probably have to be
prepared to do more work at the server to customize our pages to
integrate with these different devices. We'll also have to create the
output in a whole new range of formats such as the Wireless Markup
Language (WML). And, in addition to creating WML for rendering, new
Internet devices and business applications are going to want to be able
to send and receive XML data from Web applications. Doing this today
from ASP requires you to manually use an XML parser, convert data to and
from XML schemas, etc. ASP+ Web Services makes it much easier to tailor
our pages to suit a specific device.
Besides all of this, the rapidly changing nature of distributed
applications requires faster development, more componentization and
re-usability, easier deployment, and wider platform support. New
standards such as the Simple Object Access Protocol (SOAP), and new
commercial requirements such as business-to-business (B2B) data
interchange, require new techniques to be used to generate output and
communicate with other systems. Web applications and Web sites also need
to provide a more robust and scalable service, which ASP+ provides
through proactive monitoring and automatic restarting of applications
when failures, memory leaks, etc. are discovered.
So, to attempt to meet all these needs, ASP has been totally revamped
from the ground up into a whole new programming environment. While there
are few tools available to work with it just yet, Visual Studio 7.0 will
be providing full support to make building ASP+ applications easy (both
ASP+ Pages and ASP+ Services). The rich, component-based, event-driven
programming model is specifically designed to be 'tools friendly', and
this support will be available for all Visual Studio languages
?including VB, C++, and C#. And you can be sure that 3rd party tool
manufacturers will not be far behind.
How Does ASP+ Make Your Life Easier?
The biggest challenges facing the Web developer today must be the
continued issues of browser compatibility, and the increasing complexity
of the pages that they have to create. Trying to build more interactive
pages that use the latest features of each browser, whilst still making
sure that the pages will work on all the popular browsers, is a
nightmare that refuses to go away.
And, of course, it will only get worse with the new types of Internet
device that are on the way, or here already. In particular, trying to
build pages to offer the same user-level capability to cellular phones
as to traditional browser clients is just about impossible. The
text-only 12-character by 3-line display of many cellular phones does
tend to limit creativity and user interaction.
One obvious solution is to create output that is targeted at each
specific client dynamically ?or create multiple versions of the same
site, one for each type of client. The second option is not attractive,
and most developers would prefer the first one. However, this implies
that every hit from every user will require some server-side processing
to figure out what output to create.
If this is the case, why not automate much of the process? To this end,
ASP+ introduces the concept of server controls that encapsulate common
tasks and provide a clean programming model. They also help to manage
the targeting of all the different types of client.
Server-side HTML Controls ?Less Code to Write
ASP has always provided the opportunity to execute components on the
server, and these components can generate sections of the page that is
returned to the user. ASP+ extends this concept through server controls.
All that's required to turn any HTML element into a server control is
the addition of an extra attribute: runat="server".
Any HTML element in a page can be marked this way, and ASP+ will then
process the element on the server and can generate output that suits
this specific client. And, as a by-product, we can do extra tricks ?in
particular with HTML <FORM> and the associated form control elements,
where we can create the code to manage state during round trips to the
server. This makes the programming experience less monotonous and
dramatically more productive.
While the concept of having HTML elements that execute on the server may
at first seem a little strange, as you'll see it adds a whole new layer
of functionality to the pages, and makes them easier to write at the
same time. What more could a programmer want?
The Problems with Maintaining State
One of the most cumbersome tasks when creating interactive Web sites and
applications is managing the values passed to the server from HTML form
controls, and maintaining the values in these controls between page
requests. So one of the core aims of ASP+ is to simplify this
programming task. This involves no extra effort on behalf of the
programmer, and works fine on all browsers that support basic HTML and
above.
Take a look at the next section of code. This creates a simple form
using HTML controls where the user can enter the name of a computer and
select an operating system. OK, so this isn't a terribly exciting
example in itself, but it illustrates a pretty common scenario used by
almost every web application out there today. When the form page is
submitted to the server, the values the user selected are extracted from
the Request.Form collection and displayed with the Response.Write
method:
<HTML>
<BODY>
<%
If Len(Request.Form("selOpSys")) > 0 Then
strOpSys = Request.Form("selOpSys")
strName = Request.Form("txtName")
Response.Write "You selected '" & strOpSys _
& "' for machine '" & strName & "'."
End If
%>
<FORM action="pageone.asp" method="post">
Machine Name:
<INPUT type="text" name="txtName">
<P />
Operating System:
<SELECT name="selOpSys" size="1">
<OPTION>Windows 95</OPTION>
<OPTION>Windows 98</OPTION>
<OPTION>Windows NT4</OPTION>
<OPTION>Windows 2000</OPTION>
</SELECT>
<P />
<INPUT type="submit" value="Submit">
</FORM>
</BODY>
</HTML>
Although this is an ASP page (the file extension is .asp rather than
.aspx), it will work just the same under ASP+ if we changed the
extension to .aspx. Remember that the two systems can quite freely
co-exist on the same machine, and the file extension just determines
whether ASP or ASP+ processes it.
This screenshot shows what it looks like in the Internet Explorer 5.
When the user clicks the Submit button to send the values to the server,
the page is reloaded showing the selected values. If course, in a real
application, some the values would probably be stored in a database, or
be used to perform some application-specific processing ?for this
example we're just displaying them in the page:
One problem is that the page does not maintain its state, in other words
the controls return to their default values. The user has to re-enter
them to use the form again. You can see this is the next screenshot:
To get round this situation, we have to add extra ASP code to the page
to insert the values into the controls when the page is reloaded. For
the text box, this is just a matter of setting the value attribute with
some inline ASP code, using the HTMLEncode method to ensure that any
non-legal HTML characters are properly encoded. However, for the
<SELECT> list, we have to do some work to figure out which value was
selected, and add the selected attribute to that particular <OPTION>
element. The changes required are shown below:
<FORM action="pageone.asp" method="post">
Machine Name:
<INPUT type="text" name="txtName"
value="<% = Server.HTMLEncode(Request("txtName")) %>">
<P />
Operating System:
<select name="selOpSys" size="1">
<OPTION
<% If strOpSys = "Windows 95" Then Response.Write " selected" %>>
Windows 95</OPTION>
<OPTION
<% If strOpSys = "Windows 98" Then Response.Write " selected" %>>
Windows 98</OPTION>
<OPTION
<% If strOpSys = "Windows NT4" Then Response.Write " selected" %>>
Windows NT4</OPTION>
<OPTION
<% If strOpSys = "Windows 2000" Then Response.Write " selected" %>>
Windows 2000</OPTION>
</SELECT>
<P />
<INPUT type="submit" value="Submit">
</FORM>
Now, when the page is reloaded, the controls maintain their state and
show the values the user selected:
Controls that Automatically Maintain Their State
So, how does ASP+ help us in this commonly met situation? The next
listing shows the changes required for taking advantage of ASP+ server
controls that automatically preserve their state. We still use the
Response.Write method to display the selected values. However, this time
some of the elements on the page have the special runat="server"
attribute added to them. When ASP+ sees these elements, it processes
them on the server and creates the appropriate HTML output for the
client:
<FORM runat="server">
Machine Name:
<INPUT type="text" id="txtName" runat="server">
<P />
Operating System:
<select id="selOpSys" size="1" runat="server">
<OPTION>Windows 95</OPTION>
<OPTION>Windows 98</OPTION>
<OPTION>Windows NT4</OPTION>
<OPTION>Windows 2000</OPTION>
</SELECT>
<P />
<INPUT type="submit" value="Submit">
</FORM>
You can clearly see how much simpler this ASP+ page is than the last
example. When loaded into Internet Explorer 5 and the values submitted
to the server, the result appears to be just the same:
How Do The Server-Side Controls Work?
How is this achieved? The key is the runat="server" attribute. To get an
idea of what's going on, take a look at the source of the page from
within the browser. It looks like this:
<HTML>
<BODY>
You selected 'Windows 98' for machine 'tizzy'.
<FORM name="ctrl0" method="post" action="pageone.aspx" id="ctrl0">
<INPUT type="hidden" name="__VIEWSTATE" value="a0z1741688109__x">
Machine Name:
<INPUT type="text" id="txtName" name="txtName" value="tizzy">
<P />
Operating System:
<SELECT id="selOpSys" size="1" name="selOpSys">
<OPTION value="Windows 95">Windows 95</OPTION>
<OPTION selected value="Windows 98">Windows 98</OPTION>
<OPTION value="Windows NT4">Windows NT4</OPTION>
<OPTION value="Windows 2000">Windows 2000</OPTION>
</SELECT>
<P />
<INPUT type="submit" value="Suberver">
...
</FORM>
When the page is executed by ASP+, the output to the browser is:
<FORM name="ctrl0" method="post" action="pageone.aspx" id="ctrl0">
...
</FORM>
You can see that the action and method attributes are automatically
created by ASP+ so that the values of the controls in the form will be
POST ed back to the same page. ASP+ also adds a unique id and name
attribute to the form as we didn't provide one. However, if you do
specify these, the values you specify will be used instead.
If you include the method="GET" attribute, the form contents are sent to
the server as part of the query string instead, as in previous versions
of ASP, and the automatic state management will no longer work.
Inside the form, we wrote this ASP+ code t appropriate <OPTION> element:
<SELECT name="selOpSys" id="selOpSys" size="1">
<OPTION value="Windows 95">Windows 95</OPTION>
<OPTION selected value="Windows 98">Windows 98</OPTION>
<OPTION value="Windows NT4">Windows NT4</OPTION>
<OPTION value="Windows 2000">Windows 2000</OPTION>
</SELECT>
Again, a unique id attribute has been created, and the <OPTION> elements
have matching value attributes added automatically. (If we had provided
our own value attributes in If Len(Request.Form("selOpSys")) > 0 Then
strOpSys = Request.Form("selOpSys")
strName = Request.Form("txtName")
Response.Write("You selected '" & strOpSys _
& "' for machine '" & strName & "'.")
End If
...
However, one of the other great features of ASP+ and server controls is
that they are available to the code running on the server that is
creating the page output. The ASP+ interpreter insists that each one has
a unique id attribute, and therefore all the server controls (i.e. the
elements that have the runat="server" attribute) will be available to
code against. This means that we no longer have to access the Request
collection to get the values that were posted back to the server from
our form controls ?we can instead refer to them directly using their
unique id:
...
If Len(selOpSys.value) > 0 Then
Response.Write("You selected '" & selOpSys.value _
& "' for machine '" & txtName.value & "'.")
End If
...
Visuhod calls in VB7 must have the parameter
list enclosed in parentheses (much like JScript and JavaScript). In
VBScript and earlier versions of VB, this was not required ?and in some
cases produced an error. You can see that we've enclosed the parameter
to the Response.Write method in parentheses in our example.
Server-side Event Processing ?A Better Code Structure
Of course, if we are going to have HTML elements that execute on the
server, why not extend the concept even more? ASP+ changes each page
ges:
<HTML>
<BODY>
<SCRIPT language="VB" runat="server">
Sub ShowValues(Sender As Object, Args As EventArgs)
divResult.innerText = "You selected '" _
& selOpSys.value & "' for machine '" _
& txtName.value & "'."
End Sub
</SCRIPT>
<DIV id="divResult" runat="server"></DIV>
<FORM runat="server">
Machine Name:
<INPUT type="text" id="txtName" runat="server">
<P />
Operating System:
<select id="selOpSys" size="1" runat="server">
<OPTION>Windows 95</OPTION>
<OPTION>Windows 98</OPTION>
<OPTION>Windows NT4</OPTION>
<OPTION>Windows 2000</OPTION>
</SELECT>
<P />
<INPUT type="submit" value="Submit"
runat="server" onserve.g. those submitted by
the user). Because the text box and <SELECT> list also run on the
server, our code can extract the values directly by accessing the value
properties of these controls. When the page is executed and rendered on
the client, the <DIV> element that is created looks like this:
<DIV id="divResult">You selected 'Windows NT4' for machine
'lewis'.</DIV>
Connecting Server-side Control Events To Your Code
By now you should be asking how the VB subroutine actually gets
executed. Easy ?iogrammable within
ASP+ on the server. The onserverclick="ShowValues" attribute then tells
the runtime that it should execute the ShowValues subroutine when the
button is clicked. Notice that the server-side event names for HTML
controls include the word "server " to differentiate them from the
client-side equivalents (i.e. onclick, which causes a client-side event
hander to be invoked).
The result is a page that works just the same as the previous example,
but the ASP+ source now has a much more structured and 'clean' format.
It makes the code more readable, and still provides the same result
?without any client-side script or other special support from the
browser. If you view the source code in the browser, you'll see that
it's just the same:
We can improve the structure even more, by separating out the code
altogether. And, even better (as with earlier versions of ASP) we can
add our own custom components to a page or take advantage of a range of
server-side components that are provided with the universal runtime.
Many of these can be tailored to create output specific to the client
type, and controlled by the contents of a template within the page.
--
好好学习，天天向上！！！！
※ 来源:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 192.168.18.211]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店