Introduction to HTML Applications (HTAs) | DHTML文档教程 |
The power to build HTML Applications (HTAs) brings Microsoft® Internet Explorer 5 to the fore as a viable Microsoft Windows® development platform. HTAs are full-fledged applications. These applications are trusted and display only the menus, icons, toolbars, and title information that the Web developer creates. In short, HTAs pack all the power of Internet Explorer—its object model, performance, rendering power, protocol support, and channel-download technology—without enforcing the strict security model and user interface of the browser.
- why use htas
- creating an hta
- the power of trust: htas and security
- compatibility
- hta deployment
- conclusion
- related topics
why use htas
historically, programming languages like c++ and microsoft visual basic® have provided the object models and access to system resources that developers demand. with hta it is now time to add dynamic html（动态html，即dhtml） with script to that list. htas not only support everything a web page does—namely html, cascading style sheets (css), scripting languages, and behaviors—but also hta-specific functionality. this added functionality provides control over user interface design and access to the client system. moreover, run as trusted applications, htas are not subject to the same security constraints as web pages. as with any executable file, the user is asked once, before the hta is downloaded, whether to save or run the application; if saved to the client machine, it simply runs on demand thereafter. the end result is that htas runs like any executable (.exe) written in c++ or visual basic.
htas are suited to many uses, whether you are prototyping, making wizards, or building full-scale applications. whatever dhtml and script deliver now—forms, multimedia, web applications, html editors, and browsers—so can htas...and then some. best of all, htas make some tasks easier. the simplicity of generating prototypes using htas makes it possible for program managers and designers to script dialog boxes and alerts while the c++ or visual basic developers program the underlying functionality.
creating an hta
create an hta by writing an html page and saving it with the .hta extension. it is that simple!
this sample demonstrates the simplest possible hta. it consists of the string, "hello, world", and is saved with the .hta extension. internet explorer is so forgiving that even the missing html and body tags do not cause an error. the program can be closed by pressing alt+f4.
hello, world
to launch an hta , double-click its program icon, run it from the start menu, open it through a url, or start it from the command line. once running, the hta renders everything within the paired body tag and displays the value set in the title tag as the window title.
hta-specific functionality
where the .hta extension tells the system how to handle the application, the new hta:application tag and attributes tell the window how to behave as an application. this tag exposes a limited set of attributes—attributes that control everything from border style to the program icon and its menu. the majority are read-only and have default values optimized for the average application. to comprise a valid hta, this tag must appear within the paired head tags.
the hta:application tag in this example specifies application features not available in dhtml. as prescribed by the attributes, this application has neither border (border), nor title bar (caption), nor standard program icon (sysmenu). the application title appears in the windows task list but not in the taskbar (showintaskbar), and only one instance of the application is permitted to run at a time (singleinstance). when launched, the hta is known to the system as "monster" (applicationname) and initially is sized to fill the screen (windowstate). for a full list of attributes and properties, and links to more information about each, see html applications reference. the program can be closed by pressing alt+f4.
<HEAD> <TITLE>My Monster Application</TITLE> <HTA:APPLICATION ID="oMyApp" APPLICATIONNAME="monster" BORDER="none" CAPTION="no" ICON="/graphics/creature.ico" SHOWINTASKBAR="no" SINGLEINSTANCE="yes" SYSMENU="no" WINDOWSTATE="maximize"> </HEAD>
Many of the HTA-specific properties that affect the user interface of the window are interdependent. When sysMenu is set to no, not only the program icon, but also the Minimize and Maximize buttons are disabled. When border is set to none, neither the window border, program icon, title bar, nor Minimize and Maximize buttons display. Finally, when caption is set to no, the Minimize and Maximize buttons, the program icon, and the window border are disabled. These contingencies all make sense in the light of standard Windows graphical user interface design.
The Power of Trust: HTAs and Security
As fully trusted applications, HTAs carry out actions that Internet Explorer would never permit in a Web page. The result is an application that runs seamlessly, without interruption.
In HTAs, the restrictions against allowing script to manipulate the client machine are lifted. For example, all command codes are supported without scripting limitations (see command id). and htas have read/write access to the files and system registry on the client machine.
the trusted status of htas also extends to all operations subject to security zone options. in short, zone security is off. consequently, htas run embedded microsoft activex® controls and java applets irrespective of the zone security setting on the client machine. no warning displays before such objects are downloaded and run within an hta.
hta windows can extend the trust relationship to content in other domains. htas allow cross-domain script access between window objects and cookies. to address the security risks inherent in cross-domain scripting, hta enables the application attribute for frames and iframes. this hta-only attribute is not the sole security precaution available. htas are designed such that frames and iframes, where the application attribute is set to no />, have no script access to the hta containing them. in this way, no unsecure content is allowed into an hta through an untrusted window.
htas are designed such that untrusted html?b>frames and iframes have no script access to the hta containing them. in the case of frames that are not hta-enabled, the highest level frame comprises the top window for all frames it contains. for that frame, window.top and window.self are one and the same. in addition, unsafe frames and iframes receive neither a referrer nor an opener爑rl from the parent hta. the end result is that they are unaware of the containing hta as the parent window.
in applications where all content is safe, frames and iframes can safely be marked as trusted. wizards and control panels are examples of safe content. the hta-enabled status of the iframe in the example below permits it to pass information back to its parent window.
<iframe src="filename.htm" application="yes">
by contrast, an iframe that allows browsing to unsecured content must be implemented as regular html. content in the iframe example below is subject to the security setting for its zone. the following iframe can be used when embedding html.
<iframe src="filename.htm" application="no">
When running HTAs, users should take the same precautions as with any executable: Only install HTAs produced by reliable sources. HTAs cannot be code-signed. However, they can be installed from signed cabinet (.cab) files or other signed installation formats. Either way, the most accountable sources will be corporate intranets and established software vendors.
Compatibility
The Microsoft implementation of HTA is limited to Windows 32-bit systems running Internet Explorer 5. HTAs do not support the html autocomplete in forms feature, or the external object.
hta deployment
the hta implementation supports multiple deployment methods: the web model, the package model, and a hybrid of the two. application developers should decide how best to meet their distribution needs.
the web model
the web deployment model consists of an application that can be run and administered just like a web page. in this scenario, the hta is launched simply by browsing to its url or by accessing it from the internet explorer favorites list. before launch, an internet explorer dialog box presents the user with the choice to open or save the application. after launch, ancillary application components are downloaded from the server as needed and then cached. servers must have the mime type "application:hta" registered for delivery through the http: protocol to work.
This model boasts some important strengths. It facilitates seamless updates: The intranet administrator need only post the new code or content for the client to receive the latest version. It provides ease of use: The user need never install or uninstall the application. Unused applications are automatically flushed from the cache. One important consideration when evaluating this deployment model is that server-based applications cannot be run offline or when the server goes down. One option is to anticipate this eventuality by implementing the advanced channel (CDF) features in Internet Explorer 4.0 and later. For more information, see the introduction to active channel technology.
the package model
in the package deployment model, the installation process for the hta is the same as for traditional applications. files are copied from disk or over a network, using any installer or self-extracting executable. the installer places the application in the program files directory or in the directory selected by the user. a link to the hta is included in the start menu. and the application's dependency on internet explorer 5 or greater is registered. this way the user is warned that uninstalling internet explorer will disable that application. look to tools vendors for vehicles for packaging and delivering htas to your specifications.
like the web model, the package model has points in its favor. the user is prompted only during the initial installation about trusting the application; thereafter, the application runs as trusted code just as an .exe does. also, the installed hta is always available to users, whether they are connected to the server or not.
hybrid deployment models
any combination of web and package deployment models is feasible. the method of delivery is transparent to the hta. hta components are always referenced as urls, absolute or relative, so the applications simply work.
examine your priorities
what are your distribution needs? the following list presents just a few scenarios.
- if keeping the initial download time brief is paramount, then hybridize by installing the top window of the hta onto the client machine, leaving the hta to access the server for images and support files.
- if your users run the application both at work and remotely, consider deploying htas over the local network using the web model while also distributing it for remote use using the package model.
- perhaps your business requires a tool where the content is maintained by separate groups and is distributed across servers. the application will look and function like a unified whole if you create a single user interface and use web deployment automatically to deliver the latest information.
conclusion
no matter what the delivery model, using internet explorer as your development platform is a compelling way to build applications large and small.