Requirements of the PT Components

Several of the components used by the PT application are recycled from previous BDG scenarios. The Search component is fundamentally the component that was used in Scenario 1: Fitch & Mather Corporate Media Library Application and Scenario 2: Fitch & Mather CML/LitCrit Application. The MTSEnvironment module is derived from the MTSEnvironment component in Scenario 1.

The LitWare designers want to design the PT application components so they can be used in other applications. To be reusable, components and modules should have the following characteristics:

• Flexible. For example, the data access component should handle SELECT statements (that can include WHERE clauses and full-text search criteria), stored procedures that retrieve data, and stored procedures that perform updates to SQL Server 7.0 tables.
• Versatile. The data access component must not contain any hard-coded strings. When the ASP Request object is passed as a parameter, the component should be able to examine the QueryString and Form methods, which provide access to values in hidden fields on the form and perform queries or table actions based on their values.
• Globalized. Components cannot contain any localized information. For example, the text for messages cannot reside within the component.
• Task-specific. The methods in each component should be task-specific. This allows future applications to include compact modules that support their specific needs.
• Stateless. Methods in PT application components should accept parameters instead of having properties set by the script. Stateless components are far more flexible and reusable and improve an application's performance and scalability.