虎克的博客

Enthusiasm Biogeography-Biodiversity Informatics-Data Sciences

网络应用程序界面快速创建

| Comments

Web applications are dynamic- many requiring unique content and interfaces for each user. There are a myriad of ways to take user content out of a database and present it in a browser. This article focuses on the different ways it can be done in the Microsoft world (specifically in ASP.NET), why we chose XSLT for our own product, and finally a look at our technical implementation.

Planning for Dynamic Content

Whether you are in the process of building a new business web application or planning to build one, you most likely need to address how your web application will handle displaying different content for different users.

Considerations

When considering the different options for displaying dynamic content you generally need to take into account the following aspects:

  • Usability
    Usability might be one of the most critical aspects in the success (or lack thereof) of your application.
  • Development Time
    This includes the total amount of development time involved in satisfying your current application requirements.
  • Flexibility
    Regardless of how comprehensive your current requirements are, applications tend to evolve over time. It’s important to evaluate the development effort and skill sets required to accommodate changes.
  • Support, Maintenance & Ongoing Enhancements
    Commonly ignored by many when planning new development projects, it is generally responsible for a good chunk of the total cost of an application over the span of its life. This includes bug fixes, client customizations, minor application enhancements and of course, QA and testing.

The Options in ASP.NET

Generally web applications that use ASP.NET have two main options for displaying dynamic content:

  • Server Controls
    • With Binding – retrieving the relevant data and binding it to the appropriate ASP.Net server controls on a web form
    • In Code – populating the appropriate ASP.Net server controls in code
  • HTML
    • In Code – constructing the HTML to display in code based on the information retrieved from the database
    • With XSLT – retrieving the database information in XML format and then transforming it into HTML with XSLT

A third option is Silverlight, a new technology introduced as an option for web applications by Microsoft about a year ago. Silverlight provides a very rich GUI with the power of the .Net platform (a subset, actually) and tools that make web application development similar to the XAML interfaces found in the latest Windows application development. Silverlight is outside the scope of this particular article though.

Comparing the Different Options

Before you decide on the best route to take to display dynamic content you need to evaluate the impact of each approach on your application. You might find the table below helpful when making this decision.

 

Approach Pros  & Cons When to Use
Server Controls
With Binding The quickest approach in terms of development time but also the least flexible. Best suited for applications with low data complexity and that are not expected to change often.
In Code Hooking up the controls in code takes longer in terms of development but is much more flexible than binding. This approach also requires a higher level of support and maintenance. Best suited for applications with high data complexity and that are not expected to change often.
HTML
In Code Constructing HTML in code gives a good deal of flexibility over the markup that’s created but is time-consuming and extraordinarily brittle. This approach requires extensive testing and support. I wouldn’t recommend this to be used as a general strategy for web applications but at times this might be used for particular sections depending on a unique set of requirements.
Using XSLT Offers high flexibility and the least amount of ongoing maintenance and testing. The development time might be longer depending on your team’s skill set. Best suited for applications with high data complexity and ones that are expected to change significantly and frequently. In addition, this allows for a lot of room for creativity as far as interface design goes.
Silverlight Provides the richest GUI possibilities and the complete separation of interface and code. The time to develop, test and support are currently higher than other options. Best suited for applications that require very rich user interfaces, and for development teams that primarily focus on Windows development.

 

Real-World Use Case: Scopings

When we started evaluating the requirements for Scopings, our homegrown recruiting platform, we needed a way to present complex content with a unique look and feel, a high level of usability, an infrastructure that can easily adapt to frequent and substantial changes, and built-in capabilities for globalization.

Very quickly we realized that although we can use ASP.Net server controls to build the first revision of Scopings in a relatively short period of time, this wouldn’t adapt well to the frequent changes we expected to be an inevitable part of the product lifecycle. This option would substantially increase our total cost of ownership.

After much analysis and many discussions, it became clear to us that designing our own infrastructure for constructing HTML using XML and XSLT would satisfy all of our requirements. We sat down and started to design an infrastructure that has ultimately been used for more than 80% of the functionality on Scopings.

Constructing the HTML

The idea behind the Scopings infrastructure was to allow us to make substantial changes to our user interface, while eliminating the need for any code changes and development staff involvement, and substantially decreasing the amount of QA required following any changes to the user interface.

To accommodate these requirements the Scopings infrastructure was built to be completely indifferent to the information retrieved from our database and to the way the information is ultimately displayed.

To achieve this we designed the infrastructure as follows:

    <li>A separate stored procedure was built against each web content page to be displayed, and was designed to only return XML back to the calling code. </li>
    <li>Upon loading a web page, the code behind would load the XML for the current user. The XSLT would then transform the XML to an HTML interface for the user. </li>
    <li>The web page would be responsible for all functionality,<p class='post-footer'>
       original link:
       <a href='http://Apiaceae.github.io/blog/2009/03/27/%E7%BD%91%E7%BB%9C%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%95%8C%E9%9D%A2%E5%BF%AB%E9%80%9F%E5%88%9B%E5%BB%BA/'>http://Apiaceae.github.io/blog/2009/03/27/%E7%BD%91%E7%BB%9C%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%95%8C%E9%9D%A2%E5%BF%AB%E9%80%9F%E5%88%9B%E5%BB%BA/</a><br/>
       &nbsp;written by <a href='http://Apiaceae.github.io'>Hooker</a>
       &nbsp;posted at <a href='http://Apiaceae.github.io'>http://Apiaceae.github.io</a>
       </p>
    

Comments