Future Enhancements

This is a list of features that could be implemented or enhanced in future versions of the Performance Tracking (PT) application:

• The client-side data validation that a function in IsValid.js performs does not handle shift-jis, the Japanese character set. The ValidateForm function is disabled for the Japanese character set.
• The application does not sequence address fields by locale preference. For example, a truly localized version of the application would display address information from a Japanese user in a different layout than that used for English speakers.
• The application does not change the first day of the week by locale preference. Many countries start the week on Monday. Although this isn't a huge problem, the PT application will seem strange to people who do not use its week-day sequencing convention.
• The error messages from Microsoft® SQL Server™ are not localized. Although localized system messages were specified in the design phase, the SQL Server error messages are part of the stored procedures, making them unlocalizable. The stored procedures will be updated in the next release of the BDG.
• The en_us version of the application does not use Unicode character encoding. If the application handled all language versions in the same manner (Unicode decoding and encoding) it would make a stronger globalization story, and in addition, the application might not need locale-specific ASP pages because all languages would use the same code page and character set.
• The PT application menu does not support mouseover effects. Since mouseover effects are used elsewhere in the application, it would make sense to also use them for the menu. Doing this would take a fairly simple modification to the XSL template. Fortunately, the mouse cursor changes to a hand when hovering over the menu items to indicate that they are clickable.
• The build process doubles <BR> tags in labels. LABEL tags in the lingo file sometimes contain a line break to facilitate layout. Because the BR tag normally doesn't require a closing element, it is represented as <BR/> in the XML source code. However, when this line is processed during a build, the output becomes <BR></BR>. According to HTML, both tags are equivalent and result in two line breaks.
• Clicking the New button does not clear noneditable text fields. For instance, clicking New on the Group form after editing an existing record resets the form's fields, but leaves the existing Current Size text displayed.
• It is desirable to offer alternate methods of selecting the desired language. Not everyone is aware that they can change the language settings of their browser. For these users, it is more convenient to display a list of supported languages and allow them to select the one that they will use. With this approach, you can offer both the generic "en-us" and specialized "hardware" lingo versions of the application side-by-side.
• The viewData.asp page desperately needs paging functionality. Currently, it returns the entire recordset that matches a query, and it will possibly process thousands of records to do so. Limiting the number of records returned from the query to a "page" (perhaps 120 records or so) would be a tremendous boon to performance. The next page could be requested later, and added to the visible TargetTable, when the user reached the end of the currently loaded list. It would also be possible to return a page from the middle of the recordset, if the user requested to do so.