cc/td/doc/product/rtrmgmt/csrc/ur
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring User Registrar

Configuring User Registrar

You can use the Cisco Subscriber Registration Center (CSRC) application framework to customize the User Registrar Subscriber interface presented to the end user during subscriber activation and maintenance. The CSRC application framework provides a common platform for developing Web-based applications.

You can change the following aspects of the User Registrar Subscriber application:

Configuration Areas

The User Registrar Subscriber application allows you to tailor your own user interface, such as adding specific corporate branding or introducing specific business logic. The following sections describe the specific areas that you can configure to meet your company's needs.


Note The template files are the User Registrar Subscriber pages described in the
"Using User Registrar" section and listed in Table A-1.

Customizing Template Files

Every page in the application has a corresponding template file containing the HTML presentation and textual content. You can use most HTML design tools or text editors to modify these template files.

Tips
Some HTML editors change the order of tags or add new ones. Be sure to use an editor that does not add Body and Head tags to template files.

While the template files primarily contain layout and text, these files also determine which input fields the user must complete. In the case of a registration screen, the template determines what information a new subscriber must enter.

Tips
The template files are located in the install directory (<csrc-root>) with the path of <csrc-root>/csrc/html/csrc-ur-sub directory.

Changing Images

The template files reference external images for each of the buttons in the UI. These files are referenced with the HTML tag <IMG SRC=xxx>. To change the image, replace the xxx with the new file name.

For example, change <IMG SRC='/csrc/images/ciscologo.gif'> to <IMG SRC='/csrc/images/MSO.gif'>.

If you have an existing image, you can simply replace it. Otherwise, use a standard image editor to create the image and then specify the new image by file name.

The template files contain the width and height of every image. If you replace or update an image with one of a different size, you need to update every <IMG> tag that references the modified image. The images are stored in the <csrc-root>/csrc/images directory.

Tips
Make sure that you enter the correct width and height for each image. Having specified dimensions is critical to increasing the perceived performance of any Web page displayed to end users. This is particularly noticeable when using the Netscape browsers. If the template does not contain the dimensions, Netscape browsers wait to display a page until they have loaded all the images.

Changing Text

Each template file contains text that describes user actions. You can edit the source templates to modify the text in these template files. Remember, however, if you add or delete significant amounts of text you may need to adjust the layout of the page.

The default installation of the User Registrar Subscriber application specifies the English language. The files that support the English language are located in the <csrc-root>/csrc/html/csrc-ur-sub/en directory.

If you plan to use another language or multiple languages, see "Supporting Other Languages" section.

In addition to the text in the template files, there is also a file containing all of the error messages the system displays. This file contains a mapping from the message code to the message text. This file is <csrc-root>/csrc/html/csrc-ur-sub/en/messages.cwaf.

For example, the following two lines are messages for the known_login page:

page:known_login:missing=Username=Username, please re-enter.
page:known_login:missing=Password=Password, please re-enter.
 

Each line contains a message key defining the type of message. There are two categories of messages: system and page. Using this unique identifier for a message, the interpreter extracts everything from the right of the equals sign to the end of the line for substitution when the message is required. User Registrar automatically truncates any white space at the end of the line.

System messages apply across all pages while page messages are specific to each page.

Changing Layout

The template files rely upon tables to layout the components of each page. You may want to change the order of components or to completely redo the page. In either case, you should use standard HTML formatting guidelines to modify the template.


Note Do not modify the NAS-specific tags, which must be maintained for the proper functioning of the page. You can recognize these NAS tags by the <GX> or %GX% syntax. For example, during template rendering, User Registrar replaces <GX TYPE=cell ID=Subscriber.Username></GX> with the current subscriber's username.

When
modifying templates, make sure you follow all of the NAS rules. In particular, make sure to maintain the relationship between <GX TYPE=tile...> and <GX TYPE=cell...> tags. For more information about templates, see the NAS developer documentation
Tips
When working with tables, Internet Explorer is more lenient about beginning and ending table tags than Navigator. Thus, to ensure the correct functioning of any HTML table, view any page you change in both Netscape and Internet Explorer and preferably against multiple browser versions.

Adding Display Fields

For each data object in the system, there are attributes that are available after installation called the core attributes, and there are attributes configurers create that extend the basic application schema called extension attributes. For more information about extension attributes, see "Schema Extensions."

The default User Registrar template files use a subset of the core attributes, however you can change these files to show any attribute without modifying any of the underlying page logic source code.

For example, to display a hint for the user's password on the login page, create an extension attribute named Hint and add it to the Subscriber object with the line <GX TYPE=cell ID=Subscriber.Hint></GX> in the login template page. Then every time the user accesses the login page, User Registrar displays the hint.


Note For more information about creating attributes, see
"Extending the Application Schema" section and "Creating Schema Extensions" section.

Similarly, you do not need to make code changes to access extension attributes of referenced objects. If you extended the Account object with a LastPayment attribute, you could access it indirectly through a Subscriber object by <GX TYPE=cell ID=Subscriber.AccountNumber.LastPayment></GX>.

Adding Input Fields

The User Registrar page logic application schema performs dynamic input processing so that you can easily add attribute inputs. Each page has the required object attributes for self-provisioning already requested from the user.

In the choose_username page, User Registrar expects a Subscriber object. In the default User Registrar Subscriber application, this page asks for a username and password. Without modifying the logic, you can request an additional attribute input for the Subscriber object.

For example, to have users enter a hint for their password, add an input box to the choose_username page using a special syntax<INPUT> tag. In the case of the hint, it looks like: <INPUT type=text name=NewSubscriber.Hint>.

The new_login page expects a NewSubscriber object of type Subscriber to be created and passed in as an input. The addition of new attribute extensions is discussed in"Extending the Application Schema" section and "Creating Schema Extensions" section.

To support additional extension input fields, the application schema has the concept of required and optional flags for attributes. These flags allow User Registrar to dynamically determine what error messages should be returned when setting values for arbitrary objects.

The CSRC schema also employs required and optional attributes. In this case, required means that the attribute must have a value in the database. Whereas, in the application specification file, required means the subscriber must enter the value.

For example, to add a new field to a Subscriber object, specify in the page whether this is a required or optional attribute. The application specification file defines the required attributes for a given page in contrast to those required by the CSRC schema. For example, the schema may require 10 subscriber attributes, but the application specification file might require only five attributes. For User Registrar to successfully write the page attribute values to the database, the balance of the attributes need to be present.

Placing User Registrar in Frames

One of the easiest changes you can make to the User Registrar Subscriber application is to put the application inside frames. User Registrar is based on the assumption that the content in the surrounding frame panes do not need to change in association with the current application context.


Note See the
Netscape Application Server documentation for more information on the URL syntax required for calling applications and HTML documentation on using frames and frame sets.

One result of placing the User Registrar Subscriber application inside frames is that the Web browser will not display the non-intuitive URLs that Netscape Application Server typically uses. Instead, the browser displays only the first URL that contains the <FRAMESET> tag. This hides the lower-level implementation from the subscriber.

Modifying the Application Specification File

The application specification file defines the page flow in the User Registrar Subscriber application. Using a standard text editor you can modify the file to reference new pages or change the order of pages the application displays.

Although these changes may not require modification to the underlying Java source code, they do require application knowledge. Because some pages are designed to function as a unit, there may be preconditions of the pages requiring certain values for successful operation.

For example, in the case of create and then confirm page sets, if you place the confirm page before the create page, the application will fail because the required information displayed by confirmation has not yet been created. The application specification file contains comments explaining what preconditions exist.

Each page in the specification file contains the necessary page destinations. The four categories of destinations are:

Next is the most common destination that is used as the default path for the workflow. The remaining three are used as additional destinations on a per-page need. Pages defined in the specification file contain descriptions outlining the expected inputs and outputs. Using this information, you can ensure that the modifications to the workflow result in a valid application.

Example 4-1 is from the User Registrar Subscriber application specification file (csrc-ur-sub.app) for the confirm_username page. It defines the flow information specific to the choose_username page.


Example 4-1:
Page Information
page choose_username
{
     Title = "Select a User Name"
     Logic = choose_username;
     Template = "choose_username.tmpl"
     Children = confirm_username;
     NextPage = confirm_username;
     CancelPage = logout;
 
    help
    {
        SeeAlso = confirm_username;
    }
 
     objects
     {
         Subscriber NewSubscriber
         {
             Required = Username, Password;
             Direction = input, output;
         }
     }
 }
 
 logic choose_username
 {
     Class = "com.cisco.csrc.ursub.choose_username"
     File = "com/cisco/csrc/ursub/choose_username.class"
     GUID = "{72AF89A6-C672-11D2-8202-0060B0FC247E}"
 }}
 

The page information section defines standard information about the page including:

For each page in the application, there are two entries in the application specification file (.APP):

For a page to function, both of these sections must exist. While the majority of the pages have a corresponding logic, in certain instances two pages may share a single logic. For instance, the activate_reboot and activate_wait pages both share the underlying activate_wait Java logic.

In each page definition, indicated by page [name] { }, the .APP file contains:

In Example 4-1, NextPage and CancelPage determine how the buttons function when the subscriber clicks them. In particular, clicking Choose on the page that corresponds to NextPage takes the subscriber to the confirm_username page

Similarly, the objects section defines the input and output objects available on the page. In the choose_username page, there is an input object of type Subscriber named NewSubscriber. On this page, the subscriber must specify the NewSubscriber attributes Username and Password or User Registrar returns an automatic error. In addition, the NewSubscriber object is available for both input and output so you could have User Registrar display any existing values to the subscriber.

For each page, the corresponding logic definition, indicated by logic [name] { }, defines the Java logic to execute when processing requests for the page. There are three values that must be specified for each logic:

Changing Page Headers and Footers

Each page has a common header and footer that the application defines.The application's header and footer are defined in the csrc-subscriber tmpl file. Modifying this file allows you to change the application's header and footer. You do not need to change the source code to make these changes.

Example 4-2 shows example headers and footers that you might use in the User Registrar Subscriber application:


Example 4-2: Example Headers and Footers
<!-- HEADER START -->
 
<!-- Setup the header -->
<IMG SRC='/csrc/images/CiscoLogo.gif'>&nbsp
<B>User Registrar 1.0 </B>(Subscriber)
 
<!-- If appropriate, show the help button -->
<GX type=tile id=UseHelpButton max=1>
    <FORM Method=POST
    Action="/cgi-bin/gx.cgi/GUIDGX-<GX Type=cell Id=_GUID>(guid)</GX>">
    <INPUT Type=hidden Name='_goto' Value='urhelp'>
    <INPUT type=image src=/csrc/images/nbHelp.gif
    border=0 name=helpButton></FORM>
</GX>
 
<!-- If appropriate, show the exit help button -->
<GX type=tile id="ExitHelpButton" max=1>
    <FORM Method=POST
    Action="/cgi-bin/gx.cgi/GUIDGX-<GX Type=cell Id=_GUID>(guid)</GX>">
    <INPUT Type=hidden Name='_goto' Value='urhelp'>
    <INPUT type=image src=/csrc/images/nbExitHelp.gif
    border=0 name='Exit Help' value='Exit Help'></FORM>
</GX>
 
<!-- If appropriate, show the logout button -->
<GX type=tile id="LogoutButton" max=1>
    <FORM Method=POST
    Action="/cgi-bin/gx.cgi/GUIDGX-<GX Type=cell Id=_GUID>(guid)</GX>">
    <INPUT Type=hidden Name='_logout'
    Value="<GX Type=cell Id=_PageName>(pagename)</GX>">
    <INPUT Type=image Src=/csrc/images/nbLogout.gif
    Border=0 Name=logout_button></FORM>
</GX>
 
<!-- End the header section -->
<HR>
 
<!-- HEADER END -->
<!-- BODY START -->
 
<!-- Include the current page template file -->
<GX Type=Include Id=PageTemplate></GX>
 
<!-- BODY END -->
<!-- FOOTER START -->
 
<!-- Common application footer -->
<HR>
<FONT SIZE='-2'>Copyright (C) 1999 by Cisco Systems.</FONT>
 
<!-- FOOTER END -->
 

Example 4-2 contains three primary sections:

Since the page body is simply the location of the current page the user is viewing, you should not modify this section. In the header and footer sections, you can change the header and footer presentation. In particular, you can use any regular HTML tags, including graphics and fonts, to alter the presentation.


Note The page template file does not contain a <HEAD> or <BODY> tag. The application framework provides these tags as part of its execution.

You can also change the location and order of the system buttons. For example, if a certain UI design calls for the logout button to be located in the footer instead of in the header, simply move the entire section that defines the logout button behavior.

Supporting Other Languages

English is the default language for the User Registrar Subscriber application.

To support any language other than English, do the following:

When rendering template or help files, there is a hierarchy of directories with each available language in its own directory. The template files for the User Registrar Subscriber application are installed in the <csrc-root>/html/csrc-ur-sub/en/ directory.

The following example shows the html directory hierarchy for a server with multilanguage support:

<csrc-root>/html/csrc-ur-sub/en
<csrc-root>/html/csrc-ur-sub/fr
<csrc-root>/html/csrc-ur-sub/sp
 

Note Each language directory must contain a copy of every template and help file with the changed text.

In addition to the template pages and help files, User Registrar Subscriber contains a file with all of the messages used by it. This file, named messages.cwaf contains a mapping for each message in a page to the particular text to display. For more information on the message file, see the section "Changing Text" section.

After you have created the files, change the default language. User Registrar, by default, does not prompt users to select a language.

To enable support for multiple languages, you can prompt the user on the first page to determine which language to use. Store this information in the user's session and access it whenever a template page, help, or message is used. Then each user has the capability of selecting a different available language.

Tips
.If you need only one language, you can simply modify the values in the csrc-ur-sub/en directory.

Extending the Application Schema

User Registrar is based on an application schema that abstracts the underlying data stores from the development of the user interface. The application schema defines all the objects and attributes that are available to you as the User Interface configurer.

Example 4-3 shows the Account and Subscriber objects from the User Registrar Subscriber application's schema:


Example 4-3: Account and Subscriber Objects




In Example 4-3, the class { } sections define objects and the various lines in each object define the attributes available. For each attribute, you can configure various properties.

The AccountNumber attribute of Subscriber is a reference to an Account object. This relationship is represented by ref(Account.AccountNumber). Similarly, an attribute can be multivalued (multi), unique across all instances (unique), and have default values. Unlike normal properties, specify default values by placing an equal sign to the right of the attribute name and then specify a value. For example, string IsDisabled=false; ensures that newly created Subscriber objects are not disabled by default.

Working in conjunction with extension configurers, it is possible to augment the schema with new attributes. After an extension has been properly configured to provide a new attribute, you must update the application schema to reflect this change. Additions to the application schema require a corresponding change to either an extension callout or an additional storage attribute.

Edit the schema file located in <csrc-root>/conf/cwafmw.spec to contain the new attributes and then provide the values using extension attributes or callouts. The order of the attributes in the schema is not significant to the operation of the application, though for consistency add the extension attributes after the core attributes User Registrar installed. For more information on extending the underlying CSRC object layer, refer to the "Schema Extensions," and "CSRC Schema."


hometocprevnextglossaryfeedbacksearchhelp
Posted: Wed Aug 4 09:09:33 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.