|
|
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:
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.
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. |
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. |
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.
System messages apply across all pages while page messages are specific to each page.
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.
<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. <GX TYPE=tile...> and <GX TYPE=cell...> tags. For more information about templates, see the NAS developer documentation
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.
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>.
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.
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.
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.
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.
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.
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:
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:
<!-- HEADER START -->
<!-- Setup the header -->
<IMG SRC='/csrc/images/CiscoLogo.gif'> 
<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.
<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.
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
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. |
Example 4-3 shows the Account and Subscriber objects from the User Registrar Subscriber application's schema:

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."
![]()
![]()
![]()
![]()
![]()
![]()
![]()
Posted: Fri Oct 15 12:27:12 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.