Home
User Guide
The information contained in this section applies to IBM WebSphere Commerce Version 7.0.0.9 and Feautre Pack 8. The documentation also applies to all subsequent releases and modifications until otherwise indicated in new editions.
Developing
The topics in the Developing section describe tasks performed by an application developer.
Presentation layer
WebSphere Commerce uses Java Server Pages (JSP) to implement the view layer of the Model-View-Controller (MVC) design pattern. The view layer is in charge of retrieving data from the database through the use of data beans and formatting it to meet the display requirements. The view layers determines whether the request is sent to a browser or streamed out as XML. JSP files present a clean separation between data content and presentation.
Customizing IBM Sales Center
In the IBM Sales Center for WebSphere Commerce there is a set of user interface panels, views and dialogs that contain the most commonly used features. You can add to or configure the user interface to suit your needs, as well as changing the content and format of the data that is passed between the client and the server.
Deploying customizations to the IBM Sales Center
Depending on the number of clients and frequency of updates required, you have several choices for installing and updating the IBM Sales Center.
Update mechanisms
Once a set of features are installed on the client, it may later be necessary to distribute fixes and changes to the installed code. Just as the initial code took the form of plugins and features packaged into an Eclipse update site for installation, modifications are provided as updated plugins and features and again packaged into an Eclipse update site. And, just as there were three mechanisms available to install the original update site, those same three mechanisms can be used to distribute the changes:
Distributing updates independently
Once a set of features are installed on the client, it may later be necessary to distribute fixes and changes to the installed code. Just as the initial code took the form of plugins and features packaged into an Eclipse update site for installation, modifications are provided as updated plugins and features and again packaged into an Eclipse update site. This section explains how to distribute updates independently.

Distributing updates independently

Once a set of features are installed on the client, it may later be necessary to distribute fixes and changes to the installed code. Just as the initial code took the form of plugins and features packaged into an Eclipse update site for installation, modifications are provided as updated plugins and features and again packaged into an Eclipse update site. This section explains how to distribute updates independently.

About this task

Eclipse Update Sites containing new revisions of features can be distributed exactly as if they were original features. The mechanisms of manual installation, provisioning using the embedded Tivoli DMS agent, and software distribution using non-integrated products like Tivoli Configuration Manager, can all be employed exactly as described earlier.

Using these mechanisms means that no new infrastructure or training is necessary to distribute version 1.0.1 of a feature than was necessary for version 1.0.0. It also permits version 1.0.1 to be distributed both to clients that had version 1.0.0 installed, and to clients that do not have any previous version. The platform runtime will detect and disable any previous version that is being overridden.