Programming Model in BSP
Programming Model in BSP
The following documentation describes the BSP programming model: BSP Applications BSPs BSP Directives Central Classes and Interfaces Important Global Objects BSP Extensions Model View Controller (MVC) Stateful and Stateless Control Flow and Lifetime Caching Page Design Accessibility For SAP Web AS 6.20, the BSP programming model was enhanced with the MVC design pattern as well as the paradigm of the BSP extensions.
Tutorials
The following tutorials are available: 1. First tutorial: Getting Started with Business Server Pages 2. Second tutorial: A Simple BSP Application and A Sample BSP Application with HTMLB 3. Third tutorial: Online Bookshop 4. Fourth tutorial: Further Developing the Online Bookshop 5. A small tutorial is also available for getting started with the Model View Controller (MVC) Design Pattern. 6. A more comprehensive MVC tutorial based on the third tutorial: Our Online Bookshop Using MVC and HTMLB
Analog to a classic transaction, a BSP application consists of a user interface and business logic that is assigned to a logical unit, in this case the BSP application. The user interface of a BSP applications includes: Static Web sites Dynamically generated Web sites, which are BSPs or templates that contain server-side scripting that is executed dynamically at runtime to generate a static Web site BSPs can either be pages with flow logic or views. There can also be controllers if the MVC design pattern is used Various MIME objects, such as pictures, icons, sound files, style sheets, and so on, that are parts of a typical Web application
All of these objects are integrated in the Change and Transport Organizer as parts of the BSP application and are handled as a logical unit. This allows all objects that are part of a BSP application to be fully and consistently transported between all the systems in an SAP system landscape.
The business logic can be accessed from the BSP application using the typical methods, such as BAPIs, function modules, or class libraries. In addition, the BSP programming model provides a structuring tool, the BSP-Application class , that can be used to encapsulate the business logic functionality in the BSP application.
A BSP application consists of the following components: Controllers Controllers contain business logic and application data. Controllers assess the data of an incoming request based on a model and then select a suitable view for rendering the reponse to the user, see also Model View Controller (MVC). Business Server Pages (BSPs) BSPs are the Web sites that are displayed in the browser when the application is in use. BSPs can contain static HTML code and dynamic scripting code (ABAP or JavaScript). The scripting code is interpreted on the server. The exact structure of a BSP is described in Building an BSP. A page can have the following versions: o Page with flow logic These are simple pages with event handlers, but without much application logic or visualization elements. It is possible to build a BSP application exclusively out of pages with flow logic and event handlers. o View
Views are used to visualize data, see also Model View Controller (MVC). o Page fragment These are created in the same way as normal BSPs, but are then marked as page fragments. Other BSPs can also include these fragments using the include directive (see Include Directive). Navigation structure The navigation structure determines which navigation request is used to direct the navigation process from which page to which subsequent page. Application class The business logic of a BSP application is encapsulated in an application class. The application class is implemented using a global ABAP class. This global class implements access to business data, for example, via BAPI calls. Every page of a BSP application can directly reference the components of this class (attributes, methods, and so on) using the predefined Object application. You can also assign several BSP applications to an application class. For more information, see Applications Class of a BSP Application. MIME objects In the SAP system, all MIMEs, such as graphics, style sheets (used to define formatting properties of individual HTML tags), audio files, video files, and so on, are stored and administered in a central repository, the MIME repository. For every new BSP application, a directory of the same name is created in the MIME repository. This directory is used as a storage location for all application-specific MIMEs. o Theme A theme is a container for MIME objects. These MIME objects can be used to modify the appearance of one or more BSP applications after the application has been created. You can replace every MIME object in your application with another object from the file system. A theme is created as an independent development object in the Web Application Builder. A theme can be assigned to BSP applications in order to redefine style sheets and MIMEs in the pages of a BSP application after they have been created. The theme concept is a powerful tool for easily changing the layout of your pages in accordance with your needs, without the need for modifying the layout source code. See also: See also: Tailoring Layouts to BSP Applications
Accessing a BSP Application Starting and Ending a BSP Application Building a BSP
The full name of the server is specified, including the network domain (here: sapag.de). Otherwise, the BSP runtime environment returns an error. The full domain must be specified as otherwise there may be problems with HTTP cookies (such as Single Sign On). If the BSP that you start using Transaction SE80 contains a shortened URL (it does not specify the host name), then proceed as described in Note 434918. When this URL is started in the Web browser, the BSP application is started and the initial page is displayed (by default this is default.htm). To determine the URL of a BSP or BSP application within the SAP development environment, look on the Properties tab at the right side of the SAP GUI screen.
For a list of all system-specific URL parameters that have a special use in the BSP application environment, see System-Specific URL Parameters.
Procedure
The following commands are supported:
open: Restarts a BSP application that is running. The application is started if it is not running already. To be compatible with the Internet Transaction Server (ITS), the following abbreviated format is supported, whereby the page name is replaced by an exclamation mark (!):
http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00/!
close: Ends a running BSP application and either tells the system to display a blank page or go to a specific Web site (exit URL). The exit URL is specified using an additional URL parameter, This parameter is calledsap-exiturl,and must contain a full HTTP URL. To be compatible with SAP Internet Transaction Server (ITS) and the SAP Enterprise Portal (SAP EP), you can also use ~exitURL.
Example
1. Restart of BSP test application IT00:
http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00?sapsessioncmd=open
or
http://myServer.sap.corp:1080/sap/bc/bsp/sap/it00/!
close:
Ends the BSP application named in the URL and sends the browser, if specified, to the Web site defined by sap-exiturl. If you want the user to be able to end the application, this option should be available in a BSP application as part of the user interface (as a pushbutton or hyperlink). Specifies the URL to which the browser is directed when the BSP application ends (for example, http://www.sap.com) Overrides the theme for a BSP application to use other MIME objects, such as pictures and Stylesheets for visualization. Used to handle paths to other locations from where stylesheets are taken. Specifies the client for a logon to the SAP Web Application Server; can be used in the URL or in HTML forms to override the default client. Specifies the user for a logon to the SAP Web Application Server; can be used in the URL or in HTML for forms. Specifies the password for logon; can be used in HTML forms. Do not enter this directly in the URL as Web browser URLs are stored in a History list and the password would be visible in plain text, even after the browser is closed.
* * *
sap-client
sap-user sap-password
* *
sap-language
Specifies the language (ISO language ID, such as EN or DE) for a logon to the SAP Web Application Server; can be used in the URL or in HTML forms to override the default logon language. Dynamic switching of the different default design variants, without using the attribute design of <htmlb: content>. Possible values are CLASSIC, DESIGN2002 and DESIGN2003. For SAP Enterprise Portal 5, DESIGN2002 is supported. For SAP Enterprise Portal 6, both DESIGN2002 and DESIGN2003 are supported.
sap-htmlb-design
sap-domainRelax sap-accessibility
Maximum domain relaxing, see also Domain Relaxing Specification for the accessibility See also SYSTEM_PUBLIC and Configuration Settings. To activate this indicator, an activated checkbox is placed on the logon screen for input help.
The parameter names are not case sensitive, nor are the parameter values (exception: sapexiturl, if it is pointed to a case-sensitive server). You can combine several parameters in one URL. Here is an example of how to restart a BSP application in client 800 with logon language English. http://myServer.sap.com:1080/bc/bsp/sap/it00?sapsessioncmd=open&sap-language=en&sap-client=800
Process
If an HTTP request is sent to a BSP, that is, if a page (in stateless case: for the first time) is called, the page in instantiated in OnCreate. Next, OnRequest is called. The handler is then run that is most appropriate for the request, that is, OnInitialization for URL input, OnInputProcessing for HTML input, or another individual event handler if controls are used. If it hasnt already, OnInitialization is run, so that the initialization phase data is assessed. Data in the SAP system, such as table contents or BAPIs, can be accessed in this phase. Then, the layout part (the hidden part of the event handler OnLayout) is processed, which determines the design and presentation logic of a page. This code consist of static parts (for example, HTML) and scripting code. To ensure clean programming, no business logic or data retrieval is carried out in the layout part. The manipulation part becomes important if the HTTP data stream should be modified later. The manipulation code should likewise contain no business logic or statements for data retrieval functionality. If there are no subsequent changes, the manipulation part is not required. On the basis of all this data, the first page is built and sent to the user. Next comes the user interaction phase, in which the user inputs data. The user input is sent back to the BSP. This input triggers an additional HTTP request. You can specify for every page whether stateful or stateless mode is required. This is done in the input processing part. For example, incorrect input can be checked, data can be read from the database, and the succeeding page can be determined. The subsequent page for the navigation request is determined in the navigation part of the application. If no succeeding page is set, the first page is reprocessed. Then, processing of the initialization part continues. For more information, see Control Flow of BSPs
You create your Web application in the form of a BSP application. For information about creating BSP applications, see the various tutorials (Creating Web Applications with BSPs) and the documentation on Web Application Builder, specifically the sections under Basic Functions.
There may be conflict with old BSP applications with names that are longer than 15 characters. Before SAP Web AS 6.20 you could create BSP applications whose names could exceed the length of the service name in Transaction SICF. In this case, we recommend that you copy all of the old BSP application to a new BSP application with a shorter name, so that the node is automatically created.
one business application that contains different interfaces, such as for various devices, without having to replicate the business or application logic. This also means the global Object application can be used in the BSP application to access the attributes and methods of the application class. You do not have to use an application class in your BSP application. It is an optional way for you to structure your BSP application. You use the Web Application Builder in transaction SE80 to assign an application class to a BSP application.
A simple example of where an application class could be useful would be a class for controlling dialog logic and maintaining data consistency in a BSP application for shopping. This application class would include a shopping basket (internal table or other object) as an attribute. There would also be methods for changing and processing the shopping basket, such as to add, change, or delete articles. Methods for determining prices, creating offers, and posting orders would also be helpful. For an example of the use of an application class, see Extending the Online Bookshop. In many cases, the application class is only used to encapsulate existing application functions, such as from SAP Customer Relationship Management (SAP CRM), and then access the function through BAPI interfaces. Using an application class to encapsulate the functions ensures that the BSP application functions are stored in a central location (in the application class) and that both implementation and distribution are transparent (local method call but remote BAPI call internally). If a customer or developer wants to change or adapt a BSP
application or use the application for an additional device, they have the full functions of the original BSP application available in the interface of the application class.
Runtime Behavior
Any ABAP Objects class can potentially be used as an application class of a BSP application. However, the BSP runtime environment must treat the class as a singleton, that is, a class for which there is only one instance per session. The lifetime of an application class depends on the state model of the BSP application. A BSP application can be stateful or stateless.
For stateless applications, for example, it would be useless to implement expensive data gathering routines as these would be lost after every request. Instead, just get the exact data you need at that time. In stateful applications, you can implement an initialization phase where you get a large amount of data at one time, which can improve performance.
Please note that this time point is not available after every request in stateless BSP applications. In addition this time is not evaluated if the session is implicitly terminated by a timeout. Consequently, in this method it is only possible to execute optional operations that are not critical. Typically, this is a good time for cleanup operations such as deleting browser cookies or server-side cookies, if the application generated them. IF_BSP_APPLICATION_EVENTS~ON_REQUEST This method is called by the BSP runtime environment for every incoming request to a BSP before the BSP is given control (in the OnRequest event handler).
This time can be used by the application class, for example, to restore attributes that were rescued in client- or server-side cookies in a previous request. IF_BSP_APPLICATION_EVENTS~ON_RESPONSE This method is called by the BSP runtime for every outgoing response of a BSP after the BSP has been processed (after the OnManipulationevent handler). This time can be used by a stateless application class for tasks such as rescuing attributes in client-side or server-side cookies. See also: You can find details of interface IF_BSP_APPLICATION_EVENTS in the reference documentation: Interface IF_BSP_APPLICATION_EVENTS
BSP Components
Business Server Pages (BSPs) are HTML pages that contain the actual application logic and presentation logic. BSPs define the Web user interface and determine the elements of user interaction.
Server-side scripting determines the presentation logic as part of layout processing. In the preview, you can check the appearance of your pages, without having to call up the browser. Page attributes are visible in the layout processing as well as in the event handlers of a page. They can be used to store data obtained in the standard handler OnInitialization, and to make this data accessible for the layout processing and the other event handlers. Predefined event handlers are available for the different events. You can use type definitions to define local types. Similar to every object in the SAP System, BSPs also have different administration attributes.
Properties
BSPs have a number of general properties or attributes. For example, each BSP is assigned to a package in the SAP system, and each BSP has a URL used to call up the BSP in a Web browser. The following describes the most important additional properties.
Page Type
You can find additional information about the different features of a page in Structure of a BSP Application.
Error Handling
For more information see Creating Error Pages.
Status
A BSP can be stateful or stateless. For more information see Stateful and Stateless.
Caching
For more information see Caching BSPs.
Transmission Options
You can set the flags Compression and HTTPS as the transmission options. Compressing If you set this flat, the page is sent compressed to the browser, provided that the browser supports compression.
Note that it only makes sense to activate compression for large pages. It is considerably more efficient to send small pages uncompressed. It is considerably more efficient to send small pages uncompressed. HTTPS By selecting this flag, you can determine that a BSP should be accessed using HTTPS, that is, a secure connection. The BSP runtime then checks the URL. In the case of http://... it redirects the browser immediately to https://... .
Not the following browser-specific feature: As soon as you activate HTTPs, all other BSPs of your BSP application are accessed using HTTPS. It is considerably more efficient to send small pages uncompressed.
Layout
Use
You determine the presentation logic for your BSP using server-side scripting in the layout. To ensure clean development, layout and presentation must be separated from processing logic. Therefore, scripting for the static details of a page is part of layout processing, while the dynamic processing steps are set in the different event handlers (see Event Handlers). The layout can also be regarded as an internal event handler for the presentation.
Functions
You can access the following objects in the implementation: Object APPLICATION Reference Type type ref to application class Description Application class refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means object application is not available. runtime object is defined in interface IF_BSP_RUNTIME . request object is defined in interface IF_HTTP_REQUEST. response object is defined in interface IF_HTTP_RESPONSE. Page object is defined in interface IF_BSP_PAGE.
RUNTIME REQUEST
RESPONSE
PAGE PAGE_CONTEXT
Example
BSP only with Layout
Event Handler
Event handlers allow the separation of static and dynamic code in a page. The layout processing deals with the static data, while the event handlers deal with the dynamic data. The following predefined event handlers are available in the SAP system: Event Handler OnCreate Description OnCreate is called once when the page is first created (stateful mode), and performs a once-off data initialization or object creation. OnRequest is called whenever a request is made for a particular page and is used to restore the internal data structures from the request. This is important when working in stateless mode. This event handler is mainly used for data retrieval. For example, it allows data required for displaying the BSP to be read from the database. It can also execute any program. This event handler checks and processes user input. It can also define navigation, that is, whether the user should be taken to the same page or another when the BSP is called. You can use this event handler to manipulate the HTTP data stream later. This event handler is available for special functions.
OnRequest
OnInitialization
OnInputProcessing
OnManipulation OnDestroy
The ABAP syntax checks that apply in the context of ABAP Objects also apply to event handlers. Read and modify access to page attributes is available in all handlers. Global objects are also available.
Global objects and their signatures for individual event handlers are displayed if you choose in the Web Application Builder.
The use of the individual event handlers is explained in more detail in the individual sections of the documentation. See also:
OnCreate
Use
OnCreate is used when a page is called for the first time, and performs a once-off data initialization or object creation. OnCreate is called each time that the BSP page class is created. You can therefore initialize the page object (in object-oriented thought, this corresponds to the constructor). OnCreate initializes the parts of the object that are created once and then used for the entire lifetime of the object, such as the online shopping basket. create object shopbasket. The data that is used to fill the object is read in the event handler OnInitialization The BSP application is called in the following cases: Single call, if the BSP application is staeful. In this case, the the normal ABAP OO constructor. Call each time if the BSP page class is created in the stateless case.
Integration
OnCreate is useful mainly in stateful applications, because in stateless mode, the page object is reinitialized every time the page is called. In you are working in stateful mode without an explicit navigation path, and if you run the page a second time (reuse the page), the page instance remains constant. OnCreate is not run the second time. See also: Stateful and Stateless BSP Applications
Functions
You can access the following objects in the implementation: Object APPLICATION Reference Type type ref to application class Description Application class refers to the individual application or application class specified in the
BSP application. If there is no application class in the BSP application, this means that the object application is not available. RUNTIME PAGE PAGE_CONTEXT type ref to IF_BSP_RUNTIME type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT The runtime object is defined in interface IF_BSP_RUNTIME . Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
OnRequest
Use
OnRequest is run when a request comes to access the current page. This request can be made in the following ways: The URL is entered in the browser. In this case, OnInitialization is run after OnRequest. The user inputs data on a page (current page or other pages). In this case, OnInputProcessing is run after OnRequest.
Integration
OnRequest is the second handler (after OnCreate) to be called when a BSP is being processed. The only exception to this occurs when a page is recalled in stateful mode without explicit navigation. In this case, OnCreate is skipped and OnRequest is called straight away.
Functions
You can access the following objects in the implementation: Object APPLICATION Reference Type type ref to application class Description Application class refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means that the
object application is not available. RUNTIME REQUEST type ref to IF_BSP_RUNTIME type ref to IF_HTTP_REQUEST The runtime object is defined in interface IF_BSP_RUNTIME . The request object is defined in interface IF_HTTP_REQUEST.
type STRING type ref to IF_BSP_NAVIGATION type ref to IF_BSP_PAGE type ref to IF_BSP_PAGE_CONTEXT The navigation object is defined in interface IF_BSP_NAVIGATION. Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
Example
Persistency of Data Using Serverside Cookies
OnInitialization
Use
This event handler is processed directly after OnRequest during page processing. This handler implements data retrieval. The data is stored in page attributes and is therefore accessible in the layout and in the other event handlers.
Integration
While the event handler OnCreate is used to initialize objects needed for entire page, OnInitialization is used for getting data from database tables. If you develop a BSP for managing a shopping basket, the shopping basket object is initialized using OnCreate and then filled with selected products. Here, this would be the catalog ID and the number of objects. You use OnInitialization to read the short texts from the database, calculate the current subtotal, and so on.
Functions
You can access the following objects in the implementation:
Object APPLICATION
Description Application class refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means that the object application is not available. The runtime object is defined in interface IF_BSP_RUNTIME . The request object is defined in interface IF_HTTP_REQUEST. The response object is defined in interface IF_HTTP_RESPONSE. The navigation object is defined in interface IF_BSP_NAVIGATION. Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
RUNTIME REQUEST
RESPONSE
Example
BSPs with Layout, Initialization and Navigation
OnManipulation
Use
This event handler is processed after the WCF controls embedded in the page are generated.
You can use OnManipulation to manipulate the HTTP data stream again (in particular for XSLT processing).
Functions
You can access the following objects in the implementation: Object APPLICATION Reference Type type ref to application class Description Application class refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means that the object application is not available. The runtime object is defined in interface IF_BSP_RUNTIME . The request object is defined in interface IF_HTTP_REQUEST. The response object is defined in interface IF_HTTP_RESPONSE. Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
RUNTIME REQUEST
RESPONSE
PAGE PAGE_CONTEXT
Example
Persistency of Data Using Serverside Cookies
OnDestroy
Use
This event handler runs immediately before the page instance is deleted and is therefore the exact opposite of OnCreate. You can use it to execute closing actions for a page.
Since locks and so on are reset in ABAP, this event handler is not usually required and is therefore rarely used. With stateful processing, the event handler OnDestroy is not called in every request-response cycle and the page object is not destroyed. OnDestroy is only called right at the end when you switch back to stateless processing. With stateless processing, both OnCreate and OnDestroy are called for every request-response cycle. This event handler is therefore called in very rare cases, for example if an application is stateful and the controllers lifetime is shorter. The system then explicitly destroys the controller and calls the corresponding method.
Object APPLICATION
Description Application class refers to the individual application or application class specified in the BSP application. If there is no application class in the BSP application, this means that the object application is not available. The runtime object is defined in interface IF_BSP_RUNTIME . Page object is defined in interface IF_BSP_PAGE. Page context object is defined in interface IF_BSP_PAGE_CONTEXT.
You can use this event handler in connection with server-side cookies, for example: Using OnCreate you can load the cookie and then (at the end of the process flow) you use OnDestroy to store it again so that the information held in the cookie does not get lost.
Functions
You can access the following objects in the implementation:
Page Attributes
Page attributes are parameters that are declared explicitly for one page. You can access page attributes from the layout and from all event handlers. You use page attributes to store data that
is determined in the event handler OnInitialization, and you can use the page attributes to make the data accessible to layout processing and the remaining event handlers. Access to the contents of the page attribute is not, however, given automatically at any time. If, for example, you fill an internal table in OnIntialization that you have defined as a page attribute, although this definition is known in OnInputProcessing, the table contents is not known if you are working in stateless mode. Additional information is described below. There are two types of page attributes: Automatic page attributes Non-automatic page attributes
navigation -> set_parameter(name = 'FLIGHT' value = 'LH' ) Let us assume that you have defined FLIGHT as an automatic page attribute and assigned it a value from the navigation process. If you then use a parameter of the same name on another page, this parameter will automatically get the value ' LH' (Lufthansa) at runtime. Possible Types for Automatic Page Attributes Before SAP Web Application Server 6.10, auto page attributes could only have the type STRING. Now, other types are available: Elementary types except for XSTRING Structures Tables
If firstname is a field in a structure called myaddress of the type address, and myaddresses is a table of addresses, you can access firstname in the layout as follows: <input type=text name="myaddress.firstname">
myadresses[i].firstname allows you to specify the first name in question in the line of the table represented by i, that is, if i=6, the first name used in line 6 of the table is being referred to.
No Yes No Yes
Attribute Type
Value in OnInputProcessing
Explicit Transfer
Value in OnInitialization
Type Definitions
You can create type definitions for pages with flow logic. Type definitions are not available for views, however. If you want to use a page attribute that should only be used within a page and in the different methods of the page (event handler and layout), you can create a local type for this. Type definitions are therefore local types visible in all event handlers of a BSP and the BSP itself. Type definitions are also relevant when BAPIs are used (see BAPI Explorer). In the page editor, you call the BAPI browser through which you cut & paste the type definitions and a template for the requested BAPI call to the Type Definition and Event Handler tabs in your BSP.
You define local types only for those objects that are necessary within a BSP for the processing process. Types that are used several times or that can be implemented universally should be defined in the Data Dictionary.
BSP Directives
Overview
BSP directives are enclosed in tags: <% Directive %> The directives described in the following sections are supported by Business Server Pages (BSP). The syntax is compatible with the familiar server page technology. The following BSP directives are available: Page Directive Inline Code Comments Include Directive OTR Directives Extension Directive
You use the Tag Library to add BSP directives to your code using Drag & Drop. For more information see Transferring Variables.
if sy-subrc ne 0. clear workarea. endif. .... This means that the sy-subrc set when the internal table is read is overwritten by the function module call. The two pieces of code therefore behave differently.
Page Directive
Definition
This directive is used to specify the script language. ABAP and JavaScript are currently supported.
otrTrim
From SAP Web AS 6.20 Support Package 7, the attribute otrTrim is also available for the page directive.
<%@ page language=("ABAP" | "JAVASCRIPT") otrTrim=("TRUE" | "FALSE") %> This attribute is a boolean value, that is, it can have the values TRUE and FALSE. The default value is FALSE. If it is set to TRUE, all OTR texts on a page are condensed by removing all blank characters from the start and end of a string. An example of switched on attribute (otrTrim=true): <%@page language="abap" otrTrim="true" %> <% DATA: s TYPE STRING VALUE 'test'. %> [<otr> test line </otr>]<br> [<otr> before <%= s%> middle <%= s%> end. </otr>]<br> [<%= otr(sbsp_test/it00_otr_1) %>]
The output generated using this coding then looks as follows: [test line] [before test middle test end.] [This is a test for an alias text]
Example of the case when otrTrim is switched off (otrTrim=false): <%@page language="abap" otrTrim="false" %> <% DATA: s TYPE STRING VALUE 'test'. %> [<otr> test line </otr>]<br> [<otr> before <%= s%> middle <%= s%> end. </otr>]<br> [<%= otr(sbsp_test/it00_otr_1) %>] The output generated using this coding then looks as follows: [ test line ] [ before test middle test end. ] [This is a test for an alias text]
Inline Code
Definition
With this directive you can embed the script code into the page. The inline code is written in the language specified with the Page directive.
Comments
Definition
You can write comments on the code on the server. Unlike code that includes HTML comments, server-side comments are not included in the page sent to the client /browser. When you use HTML comments, however, they require longer processing times as well as larger bandwidths. This is why you should not use HTML comments with BSPs or views.
Include Directive
Definition
With this directive you can paste in existing pages or pages fragments into the page. Enter the URL of the page to be pasted in relative to the URL of the current page.
OTR Directives
Definition
The Online Text Repository (OTR) is a repository for all HTML texts, which are accessed using an alias. OTR texts can be translated into other languages using translation tools. At runtime, the OTR directive is replaced by the text defined for the logon language.
Use
There are two ways of using the OTR. 1. You can first write the text in the OTR and give it an alias that should be as meaningful as possible. Then you can display the text with the following syntax: <%=otr(alias)%>. 2. You can however also specify the text in the page layout: <otr> HTML text, can also contain scripting code </otr> This is an auto-OTR text that is automatically transferred to the OTR and translated there. If the user logs on in a different language, they see the translated text.
The text is only automatically transferred if it was entered in the original language. See also: Internationalization and Translation Online Text Repository (OTR)
Transferring Variables
You can transfer expressions, for example variables, with the following syntax:
bgcolor = "green" creates a green background by transferring the value green. With bgcolor = "<%=color%>" the current value of the variable color is assigned to the attribute bgcolor.
Extension Directive
Definition
You can use the extension directive to import a BSP extension into your BSP. As a result you can access all elements of the extension in your BSP. The extension directive is always located immediately after the page directive.
<%@extension name="<Name>" prefix="<Prfix>"%> The prefix is used as the namespace for all elements in the BSP extension. The prefixes sap and bsp are reserved. See also: BSP Extensions
Class CL_BSP_CONTROLLER2 Interfaces: Interface IF_BSP_APPLICATION Interface IF_BSP_APPLICATION_EVENTS Interface IF_BSP_NAVIGATION Interface IF_BSP_PAGE Interface IF_BSP_RUNTIME Interface IF_BSP_PAGE_CONTEXT
Interface IF_HTMLB_TABLEVIEW_ITERATOR Many of these classes and interfaces are the basis for their associated global objects. To develop BSP applications with the focus on representing Web pages on different mobile end devices, you can use interface IF_CLIENT_INFO.
Class CL_BSP_APPLICATION
Overview
Class CL_BSP_APPLICATION is an optional superclass for BSP application classes. Each application has the option of deriving its own application class from CL_BSP_APPLICATION . If the application class has not already been derived in an inheritance hierarchy, we recommend that it is derived from CL_BSP_APPLICATION . Class CL_BSP_APPLICATION has methods that are typically required by a BSP application for embedding in a Web environment. This is how information about the current BSP application (such as session timeout, current URL of BSP application, state mode and so on) can be called or set.
All of the methods of class CL_BSP_APPLICATION can be accessed via the interface IF_BSP_APPLICATION and are described in the corresponding reference documentation. See Also: IF_BSP_APPLICATION Object application
Class CL_BSP_MESSAGES
Overview
You can use class CL_BSP_MESSAGES in BSPs for outputting error and information messages.
You can flag each message with a condition that serves as a key for the message. The effect of this is that a message is only output in a BSP if the pertinent condition is fulfilled. This makes it easy to place input-specific messages directly beside the relevant input fields. Each BSP has an instance of this class that contains the current messages of the class. The object is reset after every HTTP request/response cycle. The object is accessed from a BSP via the parameter page of the event handler as page->messages or via the self-reference me in the form of interface qualification me->if_bsp_page~messages.
Superclass
-
Attributes
Attribute Name co_severity_error co_severity_fatal_error co_severity_info co_severity_success co_severity_warning Declaration Type Constants Constants Constants Constants Constants Description Error severity: error Error severity: Fatal error Error severity: Information Error severity: Confirmation of success Error severity: Warning
Methods
Method add_message
Signature method add_message importing condition type string message type string optional otr_alias type string optional severity type i default co_severity_error . This method inserts the message on the condition specified into the list of messages. If
Description
there is already a message with the condition, it is overwritten. One of the two parameters message or otr_alias must be specified (exclusive or). If message is used, the message text is transferred directly, if otr_alias is used, the alias name of an OTR text is transferred. This makes it easy to address language-dependent messages from the OTR. Parameters CONDITION MESSAGE Message condition Message text (if otr_alias-parameter is not used) Alias name of an OTR text to be used as message text (if message parameter is not used) Message severity (see constants co_severity_...)
OTR_ALIAS
SEVERITY
Method assert
Signature method assert importing condition type string returning index type i . This method returns the message index (1..n) for the condition specified or 0 if there is no message for this condition. Thus, you can use this method in BSPs in if statements if, for example, you want to insert HTML areas in the output on a messagedependent basis.
Description
Example: ... <% if page->messages->assert( 'invaliduser' ) <> 0. %> <img src="stop.gif"> <%= page->messages>assert_message( 'invaliduser' ) %> <% endif %> Parameters Return Values/Exceptions CONDITION INDEX Message condition =0: no message for condition >0: Message index Cross References See also: assert_message, assert_severity
Method assert_message
Signature method assert_message importing condition type string returning message type string . This method returns the message for a specified condition. If there is no message for the condition, it returns an empty string. CONDITION MESSAGE Message condition Message
Description
Method assert_severity
Signature method assert_severity importing condition type string returning severity type i .
Description
This method returns the message severity (see constants co_severity_... ) for the specified condition, or 0 if there is no message for the condition. CONDITION SEVERITY Message condition =0: no message for condition >0: Message severity (see constants co_severity_...)
Cross References
Method get_message
Signature method get_message importing index type I exporting severity type I condition type string message type string . This method returns information about the message for the specified index (1..n). If there is no message for the index, in other words, if index > num_messages(), this is indicated by severity = 0 . INDEX message condition severity Message index (1..num_messages()) Message text Message condition Message severity (see constants co_severity_...)
Description
Cross References
Method num_messages
Signature
method num_messages returning count type I . This method returns the number of messages that were defined using add_message(). count See also: add_message Number of currently existing messages
Description
Class CL_BSP_SERVER_SIDE_COOKIE
Overview
Class CL_BSP_SERVER_SIDE_COOKIE provides methods for setting, getting, deleting, and managing cookies on the server. Server-side cookies are persistent data, similar to the usual client-side cookies. However, while on the client-side, there are restrictions that limit the size of cookies to around 4 kilobytes per cookie, the number of cookies to 300 in total and 20 per server or domain, server-side cookies are subject to no such restrictions. A server-side cookie is stored on the database. For technical reasons, each individual cookie can be stored in one of the following ways: as a field or as a structure or as an internal table
When you get a cookie, please note that it must be returned to the same data structure. Otherwise, an error will occur, which you can query using an error method. The parameters username and session_id deserve special attention. Setting username to sy-user is ambiguous in cases where an application is started by an anonymous user stored on the server. It would be better to use session_id (see example) since runtime->session_id indicates the browser session.
When you design an application, you should give careful consideration to whether the application should be stateless and the required context data be retained from page to page in cookies (client-side or server-side), or whether the application should be stateful. A stateful application makes sense when there is a large amount of context data that would otherwise have to be read from or written to the database using cookies and thus slow down performance (see also Stateful or stateless programming?). The program BSP_SHOW_SERVER_COOKIES provides an overview of all of the cookies set in the system. The program BSP_CLEAN_UP_SERVER_COOKIES deletes all expired cookies to the day.
The system administrator should schedule the program BSP_CLEAN_UP_SERVER_COOKIES to run in the background on a regular basis. Class CL_BSP_SERVER_SIDE_COOKIE is contained in the package SBSP_RUNTIME.
Superclass
-
Attributes
Attribute Name CC_OK CC_WRONG_DATA_OBJECT Declaration Type Constants Constants Description Action was successful. The data object of the cookie to be read does not match the data object of the set cookie. Call parameters are missing. Cookie does not exist.
CC_PARAMETER_MISSING CC_NOT_EXISTS
Constants Constants
Methods
Method get_server_cookie
Signature method GET_SERVER_COOKIE exporting NAME EXPIRY_TIME EXPIRY_DATE SESSION_ID USERNAME APPLICATION_NAMESPACE APPLICATION_NAME DATA_NAME DATA_VALUE This method gets a server cookie. EXPIRY_TIME EXPIRY_DATE DATA_NAME SESSION_ID USERNAME APPLICATION_NAMESPACE APPLICATION_NAME NAME DATA_VALUE Validity date (time): to time Validity date (date): to date Data object name Session ID Name of user Name space of BSP application Name of BSP application Name of cookie Data object content
Description Parameters
data: sorders type sales_orders, edate type d, etime type t, usr type string. clear sorders. call method cl_bsp_server_side_cookie=>get_server_cookie
exporting name = 'SALESORDER_GETLIST' application_namespace = runtime>application_namespace application_name = runtime->application_name username = usr session_id = runtime->session_id data_name = 'SORDERS' importing expiry_date = edate expiry_time = etime changing data_value = sorders.
Method delete_server_cookie
Signature method DELETE_SERVER_COOKIE exporting NAME APPLICATION_NAME APPLICATION_NAMESPACE USERNAME SESSION_ID This method deletes a server cookie. NAME APPLICATION_NAME APPLICATION_NAMESPACE USERNAME SESSION_ID Name of cookie Name of BSP application Name space of BSP application Name of user Session ID
Description Parameters
data: usr type string. call method cl_bsp_server_side_cookie=>delete_server_cookie exporting name = 'SALESORDER_GETLIST' application_namespace = runtime>application_namespace application_name = runtime->application_name username = usr session_id = runtime->session_id.
Method set_server_cookie
Signature method SET_SERVER_COOKIE importing DATA_VALUE exporting EXPIRY_DATE_ABS EXPIRY_TIME_ABS DATA_NAME SESSION_ID USERNAME EXPIRY_TIME_REL EXPIRY_DATE_REL APPLICATION_NAMESPACE APPLICATION_NAME NAME This method sets a server cookie. DATA_VALUE EXPIRY_DATE_ABS EXPIRY_TIME_ABS Data object content Valid to date Absolute validity duration
Description Parameters
If you do not specify a value, the system sets the absolute validity duration to 23.59. DATA_NAME SESSION_ID USERNAME EXPIRY_TIME_REL Data object name Session ID if required Name of user, and email address Relative validity duration in seconds
If you do not specify a value, the system sets the relative validity duration to 23.59.
Validity duration in days Name space of BSP application Name of BSP application Name of cookie
data: sorders type sales_orders, edate type d, usr type string. call function 'BAPI_SALESORDER_GETLIST' destination 'ABC' exporting customer_number = '0000001000' tables sales_orders = sorders. edate = sy-date. add 1 to edate. "valid for one day
call method cl_bsp_server_side_cookie=>set_server_cookie exporting name = 'SALESORDER_GETLIST' application_namespace = runtime>application_namespace application_name = runtime->application_name username = usr session_id = runtime->session_id expiry_date_abs = edate expiry_time_abs = sy-uzeit data_name = 'SORDERS' data_value = sorders.
Method get_last_error
Signature method GET_LAST_ERROR importing RC This method returns the return code of the last call.
Description
Parameters
RC
Returncode
Method get_last_error_name
Signature method GET_LAST_ERROR_NAME importing NAME This method returns the internal name of the exception of the last call. NAME Internal error text
Description Parameters
Method get_server_cookie_info
Signature method GET_SERVER_COOKIE_INFO exporting COOKIES APPLICATION_NAMESPACE APPLICATION_NAME SESSION_ID USERNAME NAME
Description Parameters
This method returns information about server cookies. COOCIES APPLICATION_NAMESPACE SESSION_ID USERNAME NAME APPLICATION_NAME List of all cookies. Name space of BSP application Session ID Name of user Name of cookie Name of BSP application
data: usr type string, cookie_info type tsscookiei. call method cl_bsp_server_side_cookie=>get_server_cookie_info exporting application_name = runtime->application_name username = usr importing cookies = cookie_info .
Class CL_BSP_GET_TEXT_BY_ALIAS
Overview
Class CL_BSP_GET_TEXT_BY_ALIAS provides a method to fetch OTR alias texts.
Superclass
Attributes
-
Methods
Method GET_TEXT
Signature method GET_TEXT importing LANGUAGE ALIAS returning ALIAS_TEXT. This method fetches an OTR alias text for a specified OTR alias name. LANGUAGE ALIAS Current language of SAP System Name of alias in form <Paket>/<Aliasname> Text of the alias
Description Parameters
report OTRTEST. class CL_BSP_RUNTIME definition load. data TEXT type STRING. TEXT = CL_BSP_RUNTIME=>GET_OTR_TEXT( ALIAS = 'sbsp_test/it00_otr_1' ). write / TEXT.
Class CL_BSP_CONTROLLER2
Overview
Class CL_BSP_CONTROLLER2 is used to create controllers and components. Every controller class automatically inherits all methods and attributes from this central basic class.
If the basic class of your controller class displays CL_BSP_CONTROLLER instead of CL_BSP_CONTROLLER2, change the inheritance hierarchy accordingly. Class CL_BSP_CONTROLLER2 enables you to: Retain a list of sub-controllers Create unique IDs for the sub-controllers, where the sub-controller is assigned the controller ID prefix Use models Forward data to the correct controller as well as fill model classes (if they exist)
Methods
Below you can find an overview of all methods in a controller class. Processing Process provides details on the most important methods. The individual methods can be separated into different categories:
You must overwrite this method. In DO_REQUEST you specify the request processing, that is, this method is called for every request. This method does the "main work"; in particular it should branch to the correct view. DO_REQUEST can be used in two different areas: If it is the top-level controller of a component, then this method handles both input and output processing. If it is a sub-controller of a component, then this method only handles output processing.
You should overwrite these methods in order to determine input processing. Method DO_HANDLE_DATA DO_HANDLE_EVENT Description Reacts to user input. Processes data input for this component. Reacts to user input. Processes events if the component contains them. Exactly one view controller is called to handle the event, which contains an event such as a save button, for example. DO_FINISH_INPUT Ends the input processing.
Service functions
You can call these methods: Method CREATE_VIEW Description Creates or fetches a view instance
object
A view must always belong to the same BSP application as its controller. CALL_VIEW CREATE_CONTROLLER CALL_CONTROLLER Calls the request handler of the view instance. Creates or fetches a controller instance Calls the request handler (method DO-REQUEST) of the controller instance. Returns the specified page attributes. Generic method for reading an attribute value. Returns the lifetime of this page (only for the top-level controller) Returns the URL of the page or the current controller Sets the specified page attributes. Generic method for setting an attribute value. Changes the lifetime of this page (only for the toplevel controller) Creates a formatted string Writes a formatted string in the output Fetches the current output writer Changes the MIME type of the page or the content type of the header field Instantiates the parameter from the request using the request data Changes the caching values There are two types of caching: Browser cache Server cache
GET_ATTRIBUTE GET_LIFETIME GET_PAGE_URL SET_ATTRIBUTE SET_LIFETIME TO_STRING WRITE GET_OUT SET_MIME_TYPE INSTANTIATE_PARAMETER SET_CACHING
See also
Caching BSPs.
You can only use limited caching here. Note that the server cache is not user-specific. If you change the page, you should reset the cache that may be set. DISPATCH_INPUT Dispatches the input processing (only for the top-level controller). For each input, DISPATCH_INPUT calls the correct methods in the correct sequence. This method fetches data from the request.
This method does not have any attributes. GET_ID SET_MODEL CREATE_MODEL GET_CONTROLLER CONTROLLER_SET_ACTIVE Calculates the ID from the specified ID and the component ID Creates and registers a model instance Creates and registers a model instance Fetches a sub-controller Sets a controller to active/inactive. This is relevant with input processing, since you can use it to hide a controller. See also Lifetime Deletes a model instance Fills the model data Deletes a sub-controller Fetches a model instance Is this controller a top (main) controller (0: no, 1: yes)? Has a controller requested a navigation (0: no, 1: yes)?
Framework functions
These methods are provided as part of the framework and are only included here for the sake of completeness. They are not usually relevant for application development. Method IF_BSP_DISPATCHER~REGISTER IF_BSP_CONTROLLER~FINISH_INPUT_PROCESSING IF_BSP_CONTROLLER~FILL_VALUES IF_BSP_CONTROLLER~HANDLE_EVENT GET_FIELD_COMPONENT GET_FIELD_MODEL Description Registers a sub-components Processes or dispatches: end of input processing. Processes or dispatches: handling values Processes or dispatches: Handle event Finds components for a field name Finds model for a field name
Interface IF_BSP_APPLICATION
Overview
The interface IF_BSP_APPLICATION is implemented using class CL_BSP_APPLICATION. It provides methods that enable a BSP application to call up information about its runtime environment or influence this environment.
Enhanced Interface
Specializing Interfaces
-
Attributes
-
Methods
Method get_application_name
Signature method get_application_name returning name type string . This method returns the name of the BSP application as defined in the development environment (transaction SE80). -
Description
Parameters
Return Values/Exceptions
NAME
Method get_application_namespace
Signature method get_application_namespace returning namespace type string . This method returns the name space of the corresponding BSP application as defined in the development environment (transaction SE80). For BSP applications that have no explicit name space specified, this is the SAP name space, in other words, the method returns "sap".
Description
Parameters
Return Values/Exceptions
NAMESPACE
Method get_application_start_page
Signature method get_application_start_page returning start_page type string . This method returns the start page of the corresponding BSP application as defined in the development environment (transaction SE80). If no page was explicitly specified, the method returns the name default.htm. The start page of a BSP application is called if no specific page is included in the URL when the application is started, in other words, when the URL ends with the application name. Parameters -
Description
Return Values/Exceptions
START_PAGE
Method get_application_theme
Signature method get_application_theme returning theme type string . This method returns the name of the theme of the BSP application as defined in the development environment (transaction SE80). If there is no theme explicitly associated with the
Description
BSP application, the method returns an empty string (default theme). Themes can be used together with BSP applications to customize the look and feel, see also Layout Adjustments to BSP Applications. Parameters -
Return Values/Exceptions
THEME
Method get_application_url
Signature method get_application_url returning url type string . This method returns a server-specific URL that references the current BSP application, for example /sap/bc/bsp/sap/retailstore. -
Description
Parameters
Return Values/Exceptions
URL
Method get_request
Signature method get_request returning request type ref to if_http_request . This method returns an interface reference to the current HTTP request object. -
Description Parameters
Return Values/Exceptions
REQUEST
Method get_response
Signature method get_response returning request type ref to if_http_response . This method returns an interface reference to the current HTTP response object. -
Description Parameters
Return Values/Exceptions
RESPONSE
Method get_runtime
Signature method get_runtime returning runtime type ref to if_bsp_runtime . This method returns an interface reference to the current BSP runtime object. -
Description Parameters
Return Values/Exceptions
RUNTIME
Method get_timeout
Signature method get_timeout returning timeout type t .
Description
This method returns the current timeout value (length of time). The timeout value is only important for stateful BSP applications. Stateful applications use this value to determine after what length of time the server should terminate a running application when no further requests are received.
You can set timeout values in Transaction SICF for BSP applications, see also Creating an ICF Service. Parameters -
Return Values/Exceptions
TIMEOUT
Maximum length of time which a BSP application may continue to run in the absence of requests. After this time the application is automatically terminated.
Cross References
set_timeout
Method is_stateful
Signature method is_stateful returning stateful type i . You can use this method to determine whether a BSP application is working stateful or stateless. -
Description
Parameters
Return Values/Exceptions
STATEFUL
Method set_stateful
Signature Description Parameters Method set_stateful This method sets the BSP application to stateful processing. -
Return Values/Exceptions
STATEFUL
Cross References
Method set_stateless
Signature Description Parameters method set_stateless. This method sets the BSP application to stateless processing. -
Return Values/Exceptions
STATEFUL
Cross References
Method set_timeout
Signature
method set_timeout importing timeout type t . This method sets the current timeout value (length of time) of the BSP application. The timeout value is only important for stateful BSP applications. Stateful applications use this value to determine after what length of time the server should terminate a running application when no further requests are received.
Description
You can set timeout values in Transaction SICF for BSP applications, see also Creating an ICF Service. Parameters TIMEOUT Maximum length of time which a BSP application may continue to run in the absence of requests. After this time the application is automatically terminated.
Interface IF_BSP_APPLICATION_EVENTS
Overview
The interface IF_BSP_APPLICATION_EVENTS can be implemented by a BSP Application Class if it wants to have control over executing its own functions at specific points in the lifecycle of a BSP application. The possible time points for doing so are at application start and end, and at HTTP Request Input and HTTP Response Output. Typically, these time points are used to carry out authorization checks, data persisting, or data restoration in stateless BSP applications.
Enhanced Interface
-
Specializing Interfaces
-
Attributes
-
Methods
Method on_start
Signature method on_start importing runtime type ref to if_bsp_runtime request type ref to if_http_request response type ref to if_http_response . This method is called by the BSP runtime environment when the corresponding BSP application is first started at the start of the BSP session. This applies to both stateless and stateful applications. Typically, this time point is used to carry out authorization checks that apply to the entire application, or for preliminary data retrieval (in stateful applications). Parameters RUNTIME REQUEST RESPONSE Reference to the BSP runtime Reference to the current HTTP Request Reference to the current HTTP Response
Description
Return Values/Exceptions
Method on_stop
Signature method on_stop
importing runtime type ref to if_bsp_runtime request type ref to if_http_request response type ref to if_http_response . Description This method is called by the BSP runtime environment when the corresponding BSP application is explicitly ended. This applies to both stateless and stateful applications.
Please note that this time point is not available after every request in stateless BSP applications. Moreover, the time point is not evaluated if the session is implicitly terminated by a timeout. Consequently, in this method it is only possible to execute optional operations that are not critical. Typically, this is a good time for cleanup operations such as deleting browser cookies or server-side cookies, if the application generated them. Parameters RUNTIME REQUEST RESPONSE Reference to the BSP runtime Reference to the current HTTP Request Reference to the current HTTP Response
Return Values/Exceptions
Method on_request
Signature method on_request importing runtime type ref to if_bsp_runtime request type ref to if_http_request response type ref to if_http_response . This method is called by the BSP runtime
Description
environment for every incoming request to a BSP before the BSP is given control (in the OnRequest event handler). This time can be used by the application class, for example, to restore attributes that were rescued in client- or server-side cookies in a previous request. Parameters RUNTIME REQUEST RESPONSE Reference to the BSP runtime Reference to the current HTTP Request Reference to the current HTTP Response
Return Values/Exceptions
Method on_response
Signature method get_parameter importing name type string returning value type string . This method is called by the BSP runtime for every outgoing response of a BSP after the BSP has been processed (after the OnManipulationevent handler). This time can be used by a stateless application class for tasks such as rescuing attributes in client-side or server-side cookies. Parameters RUNTIME REQUEST RESPONSE Reference to the BSP runtime Reference to the current HTTP Request Reference to the current HTTP Response
Description
Return Values/Exceptions
Interface IF_BSP_NAVIGATION
Overview
The interface IF_BSP_NAVIGATION controls the transition between BSPs in a BSP application. The relevant interface reference is available in all event handlers of a BSP via the parameter NAVIGATION. There are two possible options for navigating between BSPs:
1. In the BSP layout, the subsequent page is addressed directly in the relevant HTML 2.
elements such as <form> or <a>. In the layout of a BSP only the page itself is referenced (for example, in <form> or <a>HTML elements with <%= page->page_name( ) %>) and a page change is triggered (per HTTP Redirect) by means of the navigation object (see also Object navigation) that corresponds to the event. This is the preferred method in BSP applications.
Page control via the navigation interface requires in some cases transfer of arguments to the auto page attributes of the subsequent page. There are methods available for this purpose in the navigation interface.
Please note that the amount of data to be transferred is restricted by Web Browser limitations (typically to 1KB). You should not try to transfer large amounts of data, but rather where possible selection IDs that lead to the data concerned. If this is not possible in every case, you can use the mechanism "AutoSubmit-Forms" as an alternative (see IF_BSP_NAVIGATION~USE_AUTO_SUBMIT_FORM() ). This lifts the data volume restriction. However, we recommend that you do not use this mechanism as a general rule since it causes problems with the browser history and it is not available for all devices (for example, WAP).
Enhanced Interface
Specializing Interfaces
-
Attributes
-
Methods
Method call_application
Signature method call_application importing url type string return_url_parameter type string default 'sap-exiturl' return_event_id type string optional . You can use this method to call an external application. The application is accessed via the HTTP Redirect mechanism. You must specify the external application in the parameter URL. There are two prerequisites for returning to the calling application from the external application: 1. The calling application must be implemented accordingly and 2. The required return address must be specified. The current page from which the external application was accessed is taken as the return URL. The parameter return_event_id lets you select an additional event ID that should be triggered on return as the event ID in the onInputProcessing event handler of this BSP. Since we cannot assume that all external applications have the same prerequisites for transferring the return address, you have the option of selecting this in the parameter return_url_parameter as required. The default name is sap-exiturl, whereby BSP applications are able to call each other easily. For ITSbased applications, the address ~exitURL should be used.
Description
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! Parameters URL RETURN_EVENT_ID URL of external application Name of the parameter used to transfer the return address/URL to the calling application Event ID used to address the onInputProcessing event handler of the calling page on return from the calling application
RETURN_URL_PARAMETER
Return Values/Exceptions
Method encode_parameters
Signature method encode_parameters importing encoded type i value 1 . This method controls whether the parameters defined using set_parameter() should be passed uncoded in plaintext as name/value pairs in the query string of the URL, or coded, that is, BASE64-coded as a value of the URL parameter sap-params. Parameters are passed in coded form by default.
Description
Note that we are talking of coded form here, not encrypted Parameters ENCODED 0: Parameter is passed in plaintext as name/value pairs 1: Parameter is BASE64-coded
Return Values/Exceptions
Method exit
Signature method exit importing exit_url type string optional . This method terminates this BSP application regardless of whether the application is working stateful or stateless. In particular, the event handler if_bsp_application_events~on_stop is triggered if the interface IF_BSP_APPLICATION_EVENTS is implemented by the application class. You can use the optional parameter exit_url to branch to any end page or URL per HTTP Redirect.
Description
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! Parameters EXIT_URL URL to which a HTTP Redirect should branch as the "end page".
Return Values/Exceptions
Method get_parameter
Signature method get_parameter importing name type string returning value type string . This method returns the value of the requested parameter from the navigation object.
Description
Unlike set_parameter(), this method always returns the value as a string. Parameters NAME VALUE Return Values/Exceptions Cross Reference set_parameter Parameter name Parameter value
Method goto_page
Signature method goto_page importing url type string . This method handles navigation to the specified URL. In most cases, this is a relative URL and contains only the name of the subsequent page, for example navigation>goto_page( 'confirm.htm' ). Unlike the method next_page(), here the subsequent page is specified directly.
Description
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! Parameters URL URL of the subsequent page, typically a relative URL or only the page name
next_page
Method has_parameters
Signature
method has_parameters returning has_parameters type i . This method indicates whether parameters have been set for the current navigation object (0: no, 1: yes). HAS_PARAMETERS 0: No parameters set 1: Parameters set
Description
Cross Reference
set_parameter
Method next_page
Signature method goto_page importing url type string . This method defines the subsequent page by specifying a page exit. You can define page exits of a navigation graph in the development environment (transaction SE80) of a BSP application. When you do so, starting from the current page, you assign a target page via a page exit (that is, a "link" identified by a unique name). Then, for navigating between pages, the subsequent page is not directly defined in ABAP code, an indirection is inserted instead. The name of the page exit is used to determine the subsequent page currently assigned to the page exit. This can be changed easily without having to adapt all of its usages in the code.
Description
Actual navigation is not triggered at this point. It is triggered on return from the BSP event handler! Parameters EXIT Name of page exit in the navigation graph (case-insensitive)
goto_page
Method response_complete
Signature Description Method response_complete You can use this method to indicate to the BSP runtime that no further event handlers/sections should be addressed on return from the BSP event handler in which it was called. On the contrary, the HTTP Response has already been completely generated and can be sent back to the client/browser. This method is typically called in the OnRequest or OnInitialization section of a BSP, when the HTTP Response was generated differently from the OnLayout section (for example, MIME Object from the database or generated XML Output) and was written directly to the HTTP Response object. Calling the OnLayout section would, in such cases, include unwanted output in the response (for example, blanks that are of critical importance in binary document). The call can be suppressed here. Parameters Return Values/Exceptions -
Method set_parameter
Signature method set_parameter importing name type string value type any optional . This method sets the specified parameter for the transfer to the subsequent page. As a rule, the name of the parameter is the same as an auto page attribute of the subsequent page. Otherwise, it can be read on the subsequent page using Request Object and the method
Description
if_http_request~get_form_field(). In certain circumstances, the value of the parameter can be omitted. This would be the case if a form field of the same name was sent in the current request to be passed on to the subsequent page. The parameter value is then simply taken over from the current request and passed to the subsequent page. Since it is possible to transfer any ABAP data types with the exception of references, the parameter VALUE can only be untyped. Parameters NAME VALUE Parameter name Parameter value. If the parameter is not specified; the value of the form field of the same name of the HTTP Request is taken.
get_parameter, has_parameters
Method use_auto_submit_form
Signature method use_auto_submit_form importing target_frame type string optional . With this method, when navigating to a subsequent page, no HTTP redirects can be used, but insread an HTML page is used with an embedded form. The parameters to be transferred are mixed into the form as hidden fields, and the form is automatically returned to the subsequent page (auto submit) after it is received in the browser. Using this method, you can circumnavigate the dataset restrictions with query string parameters. Note however, that auto submit forms can cause problems in the browser history and that this mechanism canot be used with WAP devices, for example.
Description
You can use parameter target_frame to control in which HTML frame (or new browser window) the subsequent page should be displayed. Parameters target_frame Name of frame in which subsequent page is to be displayed. Exception: the parameter type is not allowed.
Return Values/Exceptions
cx_bsp_inv_param_type
Enhanced Interface
-
Specialized Interfaces
-
Attributes
Attribute Name co_format_currency co_format_long co_format_lower co_format_none co_format_short co_format_upper lifetime_page lifetime_request lifetime_session messages Declaration Type Constants Constants Constants Constants Constants Constants Constants Constants Constants Instance attribute
Description write()- or to_string()-method: Output as currency write()- or to_string()-method: long output write()- or to_string()-method: output in lower-case letters write()- or to_string()-method: standard formatting write()- or to_string()-method: short output write()- or to_string()-method: output in upper-case letters Page is valid until explicit navigation away from this page Page is only valid for this HTTP Request Page is valid for the complete session (only for stateful BSP applications) Reference to the messages-object of this BSP
Methods
Method get_application
Signature method get_application returning application type ref to object . This method returns the application object for this BSP. If no application class was defined for the BSP application of this page, a zero (0) reference is returned.
-
Description
Method get_application_name
Signature method get_application_name returning name type string . This method returns the name of the BSP application of this page as defined in the development environment (transaction SE80).
-
name -
Method get_application_start_page
Signature method get_application_start_page returning start_page type string . This method returns the start page of the corresponding BSP application as defined in the development environment (transaction SE80). If no page was explicitly specified, the method returns the name default.htm. The start page of a BSP application is called if no specific page is included in the URL when the application is started, in other words, when the URL ends with the application name.
-
Description
start_page -
Method get_application_theme
Signature method get_application_theme returning theme type string .
This method returns the name of the theme of the BSP application as defined in the development environment (transaction SE80). If there is no theme explicitly associated with the BSP application, the method returns an empty string (default theme). Themes can be implemented in connection with BSP applications for Look & Feel customizing.
Description
theme
Method get_application_url
Signature method get_application_url returning url type string .
This method returns a server-specific URL that references the current BSP application, for example /sap/bc/bsp/sap/retailstore. -
url
-
Method get_attribute
Signature method get_attribute importing name type string exporting value type any .
This method returns the value of the requested attribute. Since attributes can be of any type, the return value can only be untyped and must be integrated type-related when called. ABAP move logic plays a role in the assignment of the attribute value to the return value to enable the type conversion to take place. The ABAP restrictions regarding type conversion apply so that exceptions may occur in the event of incompatible type assignments.
Description
name value
Name of attribute (case-insensitive) Attribute value Exception: Attribute does not exist
cx_bsp_inv_attr_name set_attribute()
Method get_lifetime
Signature method get_lifetime returning lifetime type i .
This method returns the current settings of the lifetime of this BSP page (see lifetime_..-constants of the IF_BSP_PAGEINTERFACE). This method has no effect on stateless applications and always returns the value lifetime_request.
Description
lifetime
Current lifetime of the BSP (see lifetime...constants of the IF_BSP_PAGE): lifetime_page | lifetime_request | lifetime_session
Cross References
Method get_page_name
Signature method get_page_name returning name type string .
This method returns the name of this BSP. -
name -
Method get_page_url
Signature method get_page_url returning url type string .
This method returns the server-specific URL for this BSP. -
Method get_request
Signature method get_request returning request type ref to if_http_request .
This method returns an interface reference to the current HTTP Request Object. -
request
Method get_response
Signature method get_response returning response type ref to if_http_response .
This method returns an interface reference to the current HTTP Response Object. -
response
Method get_runtime
Signature method get_runtime returning runtime type ref to if_bsp_runtime .
This method returns an interface reference to the current BSP Runtime Object. -
runtime -
Method serialize
Signature method serialize returning data type string .
This method serializes the content of this page (after processing in the layout event handler) in a string. This method is typically only called in the OnManipulation section of the BSP when the generated output needs to be postprocessed. However, for performance reasons this is not recommended unless absolutely necessary. The output of a BSP is no longer automatically returned to the client in the HTTP Response when this method is called explicitly. Instead, the developer is responsible for sending it. This can be done with the method if_http_response~set_cdata() and the HTTP Response Object.
Description
data:
Method set_attribute
Signature method set_attribute importing name type string value type any .
This method sets the value of the specified attribute. Since attributes can be of any type, the return value can only be untyped and must be integrated type-related when called. This method does not let you define new attributes dynamically at runtime. On the contrary, only attributes that were defined in the development environment (SE80) statically for the BSP page can have values assigned. Otherwise, the method will terminate with the exception cx_bsp_inv_attr_name. ABAP move logic plays a role in the assignment of a value to the attribute to enable the type conversion to take place. The ABAP restrictions regarding type conversion apply so that exceptions may occur in the event of incompatible type assignments.
Description
Parameters
name value
Name of attribute (case-insensitive) Value of attribute (appropriately typed) Exception: Attribute does not exist
cx_bsp_inv_attr_name get_attribute()
Method set_lifetime
Signature method set_lifetime importing lifetime type i .
This method returns the current lifetime of this BSP page (see lifetime_..-constants of the IF_BSP_PAGE). This method has no effect on stateless applications.
Description
Parameters
lifetime
New lifetime of the BSP (see lifetime...constants of the IF_BSP_PAGE): lifetime_page | lifetime_request | lifetime_session
Method to_string
Signature method to_string importing value type any format type i optional outputlength type i optional num_decimals type i optional reference_value type c returning string type string .
This method formats as a string the value of a scalar ABAP variable with any type. There are several optional parameters available to let you control the formatting. The string generated can be easily integrated in the output in a BSP using the output directive <%= .. %>.
Description
Parameters
value
Value to be formatted
format
Output format (see if_bsp_page~co_format_..constants) Maximum output length (in characters) Number of decimal places Reference value (for example, the currency) Formatted output string
Method write
Signature method write importing value type any format type i optional outputlength type i optional num_decimals type i optional reference_value type c .
This method outputs as a string the value of a scalar ABAP variable with any type. Output is at the current write position in the BSP. There are several optional parameters available to let you control the formatting. This method can be used for output in a BSP for example, in script directives <% .. %>.
Description
Parameters
value format
Value to be formatted Output format (see if_bsp_page~co_format_..constants) Maximum output length (in characters) Number of decimal places Reference value (for example, the currency)
Method otr_trim
Signature method otr_trim importing alias returning text .
This method returns the language-dependent text for an OTR alias (short text) This method is available from SAP Web AS 6.20 Support Package 7. alias
Description
text
Interface IF_BSP_RUNTIME
Overview
The interface IF_BSP_RUNTIME gives you access to information contained in the current runtime environment of a BSP application. It gives you access to the most important objects and information in the form of attributes.
Accessibility is integrated in the BSP runtime.
Implementing Class
CL_BSP_RUNTIME
Attributes
Attribute Name application_name application_namespace application_theme application_url ddic_utils keep_context Declaration Type Instance attribute Instance attribute Instance attribute Instance attribute Static attribute Static attribute Description Name of the BSP application Name space of the BSP application Theme of the BSP application URL prefix of the BSP application Dictionary services Stateful/stateless BSP application
(0/1) page_name page_url runtime_url server session_manager client_info Instance attribute Instance attribute Static attribute Static attribute Static attribute Static attribute Name of the BSP URL prefix of the BSP URL prefix of the BSP runtime HTTP Server Workplace Session Manager Device properties for the current request BSP Session ID This attribute uniquely labels the user session. The backend is therefore completely independent, that is, the value of this attribute is set independently of the context at the server. The value of this attribute does not change: 1 1 If you set keep_context from 0 to 1 and
session_id
Static attribute
1 1 If you already have a browser open and you open a new one (using File New Window, for example)
The value of this parameter does change if you close the browser and open a new one.
Methods
Method construct_bsp_url
Signature class-method construct_bsp_url importing in_protocol type string default 'http' in_host type string optional in_port type string optional in_application_ns type string optional in_application type string in_page type string optional in_parameters type tihttpnvp optional in_suppress_rewrite type I default 0 exporting out_protocol type string out_host type string out_port type string out_local_url type string out_abs_url type string . This method builds a server-specific, absolute URL for a BSP application or BSP. You can use the parameter in_protocol to control whether a HTTP- or HTTPS URL should be generated. This method can be expensive at runtime, You are recommended not to call it unnecessarily often. At runtime, instead of using this static method, you can use the instance attribute runtime_url, application_url or page_url as an
Description
alternative. Parameters in_protocol in_host in_port in_application_ns in_application in_page in_parameters Requested protocol (HTTP or HTTPS) Requested host Requested port number Namespace of the BSP application (if not 'sap') Name of the BSP application Name of the BSP Table with name/value pairs that are to be integrated in the URL as query-string parameters 0: Allow URL rewriting of the BSP runtime 1: Suppress URL rewriting of the BSP runtime Actual protocol (HTTP or HTTPS), which can differ from in_protocol if not supported by the server Domain name of the application server Port number for protocol on the application server URL relative to current application server Absolute URL, that is, including protocol, application server name, port number etc.
in_suppress_rewrite
Return Values/Exceptions
out_protocol
Method get_otr_text
Signature method get_otr_text importing
Description
alias type string returning text type string . This method returns the OTR text in the current language (sy-langu) for the alias specified. If there is no such alias, an empty string is returned. If there is no text for the alias in the current language, the secondary (or fallback) language is used. alias OTR alias including name space (caseinsensitive) OTR text for alias in the current language or empty string if no alias exists
Parameters
Return Values/Exceptions
text
Method with_accessibility
Signature method with_accessibility returning access type boolean . You determine the accessibility using this method. Note that this does not make any statement about the accessibility of the application itself. access This return value states whether accessibility is active or not.
Description
Interface IF_BSP_PAGE_CONTEXT
Overview
Interface IF_BSP_PAGE_CONTEXT forms a wrapper around a BSP and is based on the Page Context Object.
Attributes
-
Methods
Method GET_OUT
This method outputs the current, active writer to the stack.
Method GET_RUNTIME
This method returns the runtime object.
Method GET_NAVIGATION
This method returns the navigation object.
Method GET_REQUEST
This method returns the request object.
Method GET_RESPONSE
This method returns the response object.
Method GET_PAGE
This method returns the page object.
Method POP_WRITER
This method takes the first writer off the stack and returns it.
Method PUSH_WRITER
This method sets a new writer on the stack and returns it as a response.
Method ELEMENT_PROCESS
You can use this method to process other BSP elements dynamically. You can use this when you create Composite Elements for example.
Definition
The iterator is an instance object that implements the interface IF_TABLEVIEW_ITERATOR. With the iterator, you can create complex logic for <htmlb:tableView> elements, for example for the evaluation of a TableView row and calculation of the value of another row. This iterator interface makes it possible that a <htmlb:tableView> BSP element is not rendered in one step, but that there is a communication with the application after each field or column which enables the application to influence the rendering of a certain field, row or column. As <htmlb:tableView> does not contain application logic itself, the iterator allows the TableView to handle data very flexibly. The interface should be implemented by the corresponding application class of the BSP application, or when controllers are used by the controller class.
Process Flow
The interface IF_HTMLB_ITERTATORcontains 3 callback methods. When processing its BSP (in which its own iterator object is embedded) with <htmlb:tableView iterator="<%= my_iterator %>" ... />, the iterator calls back the three interface methods every time it encounters an <htmlb:tableView/> element or an <htmlb:tableViewColumns/> element.
Use
1. ... 1. 1. In transaction SE24, you can create your own class that implements the interface IF_HTMLB_TABLEVIEW_ITERATOR. 2. 2. Instantiate your iterator class.
Note that you execute the instantiation via the application class or the controller class.
3.
3. Embed your iterator instance in the <htmlb:tableView iterator=< %= my_iterator %> ... /> element. 4. 4. The three methods of IF_HTMLB_TABLEVIEW_ITERATOR are called, i.e., called back. You can implement them according to your needs.
method if_htmlb_tableview_iterator~render_cell_start. * html_bee object is responsible to modify HTML code data: html_bee type ref to cl_bsp_bee_html. data: col_value type string. data: html_str type string. * <row> is a structure of table field-symbols: <row> type any, <col> type any. * p_column_key has a name of each table column if p_column_key = 'COLUMN_NAME'. * conventional logic to extract column value assign p_row_data_ref->* to <row>. assign component p_column_key of structure <row> to <col>. col_value = <col>. create object html_bee. if col_value = 'CONDITION_YOU_WANT'. * do something interesting html_str = "<HTML_code_you_want_to_generate_dynamically />" endif. * set HTML code you want...add() can have up to 10 params for concatenation html_bee->add( html = html_str ). p_replacement_bee = html_bee. endif. endmethod.
Implementing Classes
-
Enhanced Interface
-
Specialized Interfaces
-
Attributes
-
Methods
Method get_column_definitions Signature Description This method is called at the start of the rendering of the TableViews. This methode contains important import parameters which provide information about the current TableView. The row definitions of the TableViews are handed over. At this moment, the application can exert influence. Overwrite this methode, if you plan to make changes here.
Parameters
P_TABLEVIEW_ID
Import parameter for the ID parameter for columns in the TableView Changing parameter to overwrite certain cells in the TableView
P_COLUMN_DEFINITIONS Changing
P_OVERWRITES
Description
RENDER_ROW_START is called at the beginning of every row. This methode contains important import parameters which provide useful information about the current row. Use this method if you want to influence the rendering at the beginning of every row. You can filter rows or insert additional information to the rendering. This is especially convenient for tables that do not put out all rows. You can give the rendering information exactly to the rows that are rendered.
Parameters
Import parameter for the ID Import parameter for the row index Import parameter for the row key the reference to the data of a row
P_SKIP_ROW
Method render_cell_start Signatur e Descripti on RENDER_CELL_START is called at the beginning of every column (cell), i.e., before the rendering of every single table field. You use this method to render columns dynamically. Via the import parameters, you obtain the row and column index, as well as a reference to the current row. Thus, you can define a custom rendering for a certain row as is shown in: Custom-Rendering for the Author column. To define a new rendering engine, use the parameter p_replacement_bee. Then, the <htmlb:tableView> element calls this application-specific renderer for this row.
Paramet ers
Import parameter for the ID Import parameter for the cell ID Importparameter for the binding name Import parameter for the row index Import parameter for the row key Import parameter for the column index
Import parameter for the column key Import parameter for the reference to the data of a row Import parameter for a checkbox Export parameter for a BSP extension expression (BEE)
P_STYLE
Changing parameter for <td style="...">. When using Design2003, you can change the background color of a cell with predefined colors via P_STYLE (P_CLASS is no longer analyzed in Design2003). To do this, use the attribute cellDesign in P_STYLE (e.g. P_STYLE="cellDesign:STCD_STANDARD"). Possible values of cellDesign are STCD_STANDARD, STCD_ALTERNATING, STCD_TRANSPARENT, STCD_NEGATIVE, STCD_POSITIVE, STCD_TOTAL, STCD_SUBTOTAL, STCD_SUBTOTAL_LIGHT, STCD_BADVALUE_DARK, STCD_BADVALUE_MEDIUM, STCD_BADVALUE_LIGHT, STCD_CRITICALVALUE_DARK, STCD_CRITICALVALUE_MEDIUM, STCD_CRITICALVALUE_LIGHT, STCD_GOODVALUE_DARK, STCD_GOODVALUE_MEDIUM, STCD_GOODVALUE_LIGHT, STCD_GROUP_HIGHLIGHTED, STCD_GROUP_HIGHLIGHTED_LIGHT, STCD_KEY_MEDIUM, STCD_GROUP_LEVEL1, STCD_GROUP_LEVEL2, STCD_GROUP_LEVEL3, STCD_MARKED, STCD_FILTER and STCD_POPIN. You can find an example for the use of cellDesign in the BSP application sbspext_table, page TableViewIterator.bsp, iterator class CL_SBSPEXT_ITERATOR, method
P_CLASS
class="...">.
P_ISREADONLY
Return values / Exceptio ns -
readonly>.
Example
You find an example in the BSP tutorial: Our Little Online Bookshop using MVC and HTMLB and Custom-Rendering for the Author column.
IF_CLIENT_INFO Interface
Definition
The IF_CLIENT_INFO interface provides a range of methods that take into account the different display options for Web applications on different browsers, along with other device-specific properties such as screen size or input method.
Use
In this way, you can use the methods of the IF_CLIENT_INFO interface when you create Web applications like BSP application, and thus take the often substantial differences in the display of Web pages on different devices into account.
You can also use this Device Recognition Process and the comparable ClientInfo Interface when developing Java applications. So that you can estimate the significance for your Web application of the methods described in the following table, some of them have been assigned a priority. For those device properties not assigned a priority, you can decide yourself whether or not you want to use them in your Web application. Device properties can be categorized by their significance as follows:
Prio. 1 Title Prerequisite Description This property is prerequisite for running the mobile application at all. In general, these conditions are fulfilled by all "real" devices that fulfil the HTML or WAP standard. Emulators, however, do not fulfil these prerequisites. Thus this property need not be checked in the application. At most, you need a check program that ascertains whether or not an emulator is suitable for executing the application
If this property is not assigned a value, the application may crash on some devices that is, may not be executable If this property is not assigned a value, the application may not show all its information For example, a loss of information may occur if the paragraph attribute for automatic line breaks is switched off (<p mode=nowrap>) and the paragraph (in a WML page) contains text that does not fit on one line. If the
mobile device does not support the GET_MARQUEE_TEXT_SUPPORTED property, it is possible that the end of the text is simply truncated. For this reason
we advise you to think carefully before switching off the automatic line break property even if doing so would allow you, for example, to make better use of a small screen on a mobile telephone. 4 Unacceptable display If this property is not assigned a value, the application may be displayed in a way that does not do justice to the look and feel of the device If this property is not assigned a value, the application may not be displayed at its best. However, the display should not actually disturb the user significantly.
Inappropriate display
Similarly, some properties are assigned to the markup languages WML (Wireless Markup Language) and HTML (Hypertext Markup Language) that is, you specify the markup language for which each method is relevant and thus how it can meaningfully be used. For example, the method GET_FRAMES_SUPPORTED is only significant in HTML, since only HTML-enabled browsers can interpret frames. In general, it is HTML browsers on handheld devices like PDAs and pocket PCs, WAP-enabled mobile telephones with small screens cannot display frames, because of their screen interfaces. If the appropriate table column does not contain a value, the method can be used in both markup languages. The following source code fragment shows how you can access the methods of the IF_CLIENT_INFO interface: <%@page language="abap"%> <% ... data client_info type ref to IF_CLIENT_INFO. client_info = runtime->client_info. if client_info->get_title_supported( ) = X. ... %>
To obtain more information on using some of the methods of the IF_CLIENT_INFO interface in your Web application, use the links in the table.
Methods
Method GET_ACCEPT Signature
method get_accept returning value type string
Description
Equivalent to the HTTP request-header "userAgent".
Possible values
Content type
Prio.
GET_ALERTING_SUPPORTED
method get_alerting_supported returning value type flag method get_anchor_supported returning value type flag method get_anchor_prev_support ed returning value type flag method get_app_links_supported returning value type flag method get_app_link_types returning value type string method get_back_hard_wired returning value type flag
Specifies whether or not the device supports messaging for example, using SMS. Specifies whether or not the <anchor> tag is supported
"X" or space
GET_ANCHOR_SUPPORTED
"X" or space
WML
GET_ANCHOR_PREV_SUPPORTE D
"X" or space
WML
GET_APP_LINKS_SUPPORTED
Specifies whether or not you can call a local application on a device using a special link Specifies what type of application links the device supports
"X" or space
HTML
GET_APP_LINK_TYPES
HTML
GET_BACK_HARD_WIRED
Specifies whether or not you can execute the "Back" function using a fixed key without an associated tag Specifies whether or not a label attribute must be specified in the <do type=prev> tag to display a label Specifies whether the <do type="prev"> tag can lead to any Web address
"X" or space
WML
GET_BACK_LABEL
"X" or space
WML
GET_BACK_TO_ANY_URL_SUPPO RTED
method get_back_to_any_url_sup ported returning value type flag method get_big_supported returning value type flag method get_bold_supported returning value type flag method get_breaking_space returning value type string method get_browser_category returning value type string
"X" or space
WML
GET_BIG_SUPPORTED
"X" or space
WML
GET_BOLD_SUPPORTED
"X" or space
WML
GET_BREAKING_SPACE
GET_BROWSER_CATEGORY
GET_BROWSER_NAME
unknown" InternetExp lorer" NetscapeN avigator" mobile" unknown" HPUX" Linux" MacPPC" SunOS" Win32" mobile"
GET_BROWSER_NAME
GET_BROWSER_VERSION
method get_browser_version returning value type int4 method get_cache_enabled_by_d efault returning value type flag method get_certificates_supported returning value type flag method get_char_height returning value type int4 method get_char_width returning value type int4 method get_color_depth returning value type float method get_color_supported returning value type flag method get_content_type returning value type string method get_content_type_version returning value type int2 method get_cookies_supported returning value type flag method get_css_supported returning value type flag
GET_CACHE_ENABLED_BY_DEFA ULT
"X" or space
GET_CERTIFICATES_SUPPORTED
"X" or space
GET_CHAR_HEIGHT
GET_CHAR_WIDTH
GET_COLOR_DEPTH
HTML
GET_COLOR_SUPPORTED
"X" or space
HTML
GET_CONTENT_TYPE
Returns the content type, for example HTML or WML Returns the version of the content type for example, 3.2 for HTML 3.2 or 1.1 for WML 1.1 Specifies whether or not browser cookies are supported "X" or space
GET_CONTENT_TYPE_VERSION
GET_COOKIES_SUPPORTED
GET_CSS_SUPPORTED
Specifies whether or not the browser supports CSSs (Cascading Style Sheets).
"X" or space
HTML
GET_CSS_VERSION
method get_css_version returning value type int4 method get_default_action_design returning value type string
HTML
GET_DEFAULT_ACTION_DESIGN
Returns the default design for user interface elements representing an action
WML
GET_DEFAULT_BLOCK_SEPARAT OR
method get_default_block_separat or returning value type string method get_default_bullet returning value type string method get_default_form_style returning value type string method get_default_menu_style returning value type string method get_device_category returning value type string
GET_DEFAULT_BULLET
Returns the default symbol used to indicate points in a list Returns the default display type for input masks onePage" menu" wizard"
WML
GET_DEFAULT_FORM_STYLE
WML
GET_DEFAULT_MENU_STYLE
WML
GET_DEVICE_CATEGORY
GET_DEVICE_NAME
method get_device_name returning value type string method get_dom_supported returning value type flag method get_dom_version returning value type int4 method get_emphasized_supporte d returning value type flag method get_emulator returning value type flag
Returns the device name Unique ID for a set of device properties Specifies whether or not the browser supports a Document Object Model (DOM) Returns the Document Object Model (DOM) version supported Specifies whether or not text can be formatted as "highlighted" "X" or space "X" or space HTML
GET_DOM_SUPPORTED
GET_DOM_VERSION
HTML
GET_EMPHASIZED_SUPPORTED
WML
GET_EMULATOR
Specifies whether or not the device is to be categorized as an emulator Specifies how input fields that belong together are to be laid out using the <fieldset> tag
"X" or space
GET_FIELDSET_LAYOUT
WML
sideBySide "
GET_FIELDSET_TITLE_VISIBLE
method get_fieldset_title_visible returning value type boolean method get_font_proportional returning value type flag method get_form_factor returning value type string
Specifies whether or not the title attribute of the <fieldset> tag is used as label. Specifies whether or not the default font of the device is a proportional font Returns the screen format of the device
"X" or space
WML
GET_FONT_PROPORTIONAL
"X" or space
GET_FORM_FACTOR
PC" VGA" halfVGA" mediumLan dscape" mediumPor trait" phone" unknown "X" or space WML
GET_FORM_MENU_SUPPORTED
Specifies whether or not the browser supports the technique of displaying a selection menu with the input mask Specifies whether or not frames are supported
GET_FRAMES_SUPPORTED
method get_frames_supported returning value type flag method get_gray_level returning value type float
"X" or space
HTML
GET_GRAY_LEVEL
Returns the number of shades of gray supported in grayscale pictures Specifies whether or not the device has a horizontal scroll bar
"X" or space
GET_HORZ_SCROLLING_SUPPOR TED
method get_horz_scrolling_suppor ted returning value type flag method get_href_with_params_su pported returning value type flag method get_http_get_supported returning value type flag method get_http_post_supported returning value type flag method get_image_alignment_sup ported returning value type flag
"X" or space
GET_HREF_WITH_PARAMS_SUPP ORTED
Specifies whether or not an Href attribute in a link can contain URL parameters.
"X" or space
WML
GET_HTTP_GET_SUPPORTED
"X" or space
WML
GET_HTTP_POST_SUPPORTED
"X" or space
WML
GET_IMAGE_ALIGNMENT_SUPPO RTED
"X" or space
WML
GET_IMAGE_LINKS_SUPPORTED
method get_image_links_supporte d returning value type flag method get_image_size_max returning value type float method get_input_format_date returning value type string method get_input_format_numeric returning value type string method get_input_method_hand_ writing returning value type flag method get_input_method_keyboa rd returning value type flag method get_input_method_keypad returning value type flag method get_input_method_keypad _intell returning value type flag method get_input_method_voice returning value type flag method get_input_shown_with_ca ption returning value type flag method get_italic_supported returning value type flag method get_java_supported returning value type flag method get_java_version
"X" or space
GET_IMAGE_SIZE_MAX
WML
GET_INPUT_FORMAT_DATE
WML
GET_INPUT_FORMAT_NUMERIC
WML
GET_INPUT_METHOD_HAND_WRI TING
"X" or space
GET_INPUT_METHOD_KEYBOARD
"X" or space
GET_INPUT_METHOD_KEYPAD
Specifies whether or not the device supports input using a telephone keypad Specifies whether or not the device supports input using T9 text input or similar
"X" or space
GET_INPUT_METHOD_KEYPAD_IN TELL
"X" or space
GET_INPUT_METHOD_VOICE
"X" or space
GET_INPUT_SHOWN_WITH_CAPTI ON
Specifies whether or not the browser uses the title attribute of the <input> tag is used as a label Specifies whether or not text can be formatted as "talic"
"X" or space
WML
GET_ITALIC_SUPPORTED
"X" or space
WML
GET_JAVA_SUPPORTED
Specifies whether or not the device supports the Java programming language Returns the Java
"X" or space
HTML
GET_JAVA_VERSION
HTML
version supported
GET_LINKS_SEPARATED
method get_links_separated returning value type flag method get_link_decoration returning value type string
"X" or space
WML
GET_LINK_DECORATION
Returns the delimiters that are automatically added to the link text by the device for example [ ] or < >. Returns the maximum number of characters that a link can have to fit into one line. Specifies whether or not the device supports locally stored graphics or symbols "X" or space
WML
GET_LINK_TEXT_WIDTH
method get_link_text_width returning value type int2 method get_local_images_support ed returning value type flag method get_local_variables_supp orted returning value type flag method get_marquee_link_suppor ted returning value type flag method get_marquee_text_suppor ted returning value type flag method get_max_link_length returning value type int4 method get_media_formats returning value type string
WML
GET_LOCAL_IMAGES_SUPPORTE D
GET_LOCAL_VARIABLES_SUPPO RTED
"X" or space
WML
GET_MARQUEE_LINK_SUPPORTE D
Specifies whether or not a long link can be displayed in one line, for example as a tickertape. Specifies whether or not a long text can be displayed in one line, for example as a tickertape. Returns the maximum size of the Href attributes of a link.
"X" or space
WML
GET_MARQUEE_TEXT_SUPPORT ED
"X" or space
WML
GET_MAX_LINK_LENGTH
GET_MEDIA_FORMATS
Returns the list of multimedia formats supported such as .agif (animated .gif format), .gif, .jpg, .png, .wbmp Returns the maximum memory capacity of the device Returns the name of the device type such as 7110 for the Nokia 7110 mobile telephone Specifies whether or not the device supports "X" or space WML HTML
GET_MEMORY
method get_memory returning value type float method get_model returning value type string
GET_MODEL
GET_NBSP_SUPPORTED
method get_nbsp_supported
non-breaking blank characters Specifies whether or not the browser supports nested tables "X" or space HTML 2
GET_NESTED_TABLES_SUPPORT ED
method get_nested_tables_suppor ted returning value type flag method get_newline_after_image returning value type flag method get_newline_after_input returning value type flag
GET_NEWLINE_AFTER_IMAGE
Specifies whether or not a line break is inserted automatically after an <img> tag. Specifies whether or not a line break is inserted automatically after an <input> tag on a specific mobile device. Specifies whether or not a line break is inserted automatically after a link
"X" or space
WML
GET_NEWLINE_AFTER_INPUT
"X" or space
WML
GET_NEWLINE_AFTER_LINK
method get_newline_after_link returning value type flag method get_newline_after_select returning value type flag method get_newline_before_imag e returning value type flag method get_newline_before_input returning value type flag method get_newline_before_link returning value type flag method get_newline_before_selec t returning value type flag method get_newline_between_im ages returning value type flag method get_newline_between_link s returning value type flag method get_newline_betw_link_an
"X" or space
WML
GET_NEWLINE_AFTER_SELECT
Specifies whether or not a line break is inserted automatically after an <select> tag. Specifies whether or not a line break is inserted automatically before an <img> tag.
"X" or space
WML
GET_NEWLINE_BEFORE_IMAGE
"X" or space
WML
GET_NEWLINE_BEFORE_INPUT
Specifies whether or not a line break is inserted automatically before an <input> tag. Specifies whether or not a line break is inserted automatically before a link Specifies whether or not a line break is inserted automatically before an <select> tag.
"X" or space
WML
GET_NEWLINE_BEFORE_LINK
"X" or space
WML
GET_NEWLINE_BEFORE_SELECT
"X" or space
WML
GET_NEWLINE_BETWEEN_IMAGE S
Specifies whether or not a line break is inserted automatically after an <image> tag
"X" or space
WML
GET_NEWLINE_BETWEEN_LINKS
Specifies whether or not a line break is inserted automatically between two <image> tags
"X" or space
WML
GET_NEWLINE_BETW_LINK_AND_ TAG
"X" or space
WML
GET_OFFLINE_BROWSING_SUPP ORTED
method get_offline_browsing_sup ported returning value type flag method get_offline_forms_support ed returning value type flag method get_page_size_max returning value type float method get_pixel_height returning value type float method get_pixel_width returning value type float method get_redir_absolute_suppo rted returning value type flag method get_redir_relative_support ed returning value type flag method get_script_supported returning value type flag method get_script_version returning value type int4 method get_secure_protocols_sup ported returning value type flag
Specifies whether or not the browser supports offline browsing through locally stored pages (that is, cached pages) Specifies whether or not the browser allows the user to fill out input forms offline on the device Returns the maximum page size that can be processed in a mobile device. Specifies the screen height in pixels.
"X" or space
HTML
GET_OFFLINE_FORMS_SUPPORT ED
"X" or space
HTML
GET_PAGE_SIZE_MAX
GET_PIXEL_HEIGHT
GET_PIXEL_WIDTH
GET_REDIR_ABSOLUTE_SUPPOR TED
Specifies whether or not the browser supports the redirection of an absolute URL address.
"X" or space
GET_REDIR_RELATIVE_SUPPORT ED
Specifies whether or not the browser supports the redirection of a relative URL address.
"X" or space
GET_SCRIPT_SUPPORTED
"X" or space
GET_SCRIPT_VERSION
GET_SECURE_PROTOCOLS_SUP PORTED
Specifies whether or not the browser supports SSL (Secure Socket Layer) or WTLS (Wireless Transport Layer Security) Returns the names of the security protocols supported The names are separated by semicolons
"X" or space
GET_SECURE_PROTOCOLS_NAM ES
method get_secure_protocols_na mes returning value type string method get_selection_menu_supp orted
GET_SELECTION_MENU_SUPPOR TED
"X" or space
WML
GET_SETVAR_ON_EVENT_SUPPO RTED
GET_SKIPPING_TO_INPUT
"X" or space
WML
GET_SMALL_SUPPORTED
method get_small_supported returning value type flag method get_softkey_num returning value type int1
"X" or space
WML
GET_SOFTKEY_NUM
WML
GET_SOFTKEY_STYLE1
method get_softkey_style1 returning value type string method get_softkey_style2 returning value type string method get_softkey_title_width returning value type int2 method get_sound_supported returning value type flag method get_strong_supported returning value type flag
WML
GET_SOFTKEY_STYLE2
WML
GET_SOFTKEY_TITLE_WIDTH
WML
GET_SOUND_SUPPORTED
"X" or space
HTML
GET_STRONG_SUPPORTED
Specifies whether or not text with the <strong>can be formatted as "highlighted" Specifies whether or not "Submit" is supported within the <onevent type="onenterforward"> event handler Allows you to split devices into different sub-categories
"X" or space
WML
GET_SUBMIT_ONEVENT_SUPPOR TED
method get_submit_onevent_supp orted returning value type flag method get_sub_category returning value type string
"X" or space
GET_SUB_CATEGORY
Any text
GET_TABLE_HAS_BORDERS
method get_table_has_borders returning value type flag method get_table_supported returning value type flag method get_telephony_links_supp orted returning value type flag method get_text_alignment_suppo rted returning value type flag method get_text_styles_supported returning value type flag method get_title_supported returning value type flag
"X" or space
GET_TABLE_SUPPORTED
Specifies whether or not the browser supports tables with several columns Specifies whether or not a telephone can be dialed directly using a link
"X" or space
GET_TELEPHONY_LINKS_SUPPO RTED
"X" or space
GET_TEXT_ALIGNMENT_SUPPOR TED
Specifies whether or not text within a paragraph can be aligned left, right, or centered
"X" or space
WML
GET_TEXT_STYLES_SUPPORTED
Specifies whether or not the browser can format text using tags such as <b> or <small> Specifies whether or not a label is to appear on the top of the screen using the "title" property of the <card> WML tag. Returns the maximum number of characters of the title Specifies whether or not text can be formatted as "underlined"
"X" or space
WML
GET_TITLE_SUPPORTED
"X" or space
WML
GET_TITLE_WIDTH
method get_title_width returning value type int2 method get_underline_supported returning value type flag method get_user_agent returning value type string method get_vars_across_card_su pported returning value type flag method get_vendor returning value type string method get_xsl_supported returning value type flag
GET_UNDERLINE_SUPPORTED
"X" or space
WML
GET_USER_AGENT
Equivalent to the HTTP request header "userAgent" Specifies whether or not browser variables passed to a card can also be used for different cards Returns the manufacturers name "X" or space WML 1
GET_VARS_ACROSS_CARD_SUP PORTED
GET_VENDOR
GET_XSL_SUPPORTED
Specifies whether or not the browser supports Extensible Stylesheet Language (XSL) Returns the XSL version supported
"X" or space
HTML
GET_XSL_VERSION
HTML
Global Objects
Certain global objects can be accessed from all parts of a BSP (initialization, layout, input processing). For example, the request and response object, the application object (if an application class was defined for the BSP application), the navigation object, and the runtime object, can be accessed. The following global objects are available: Object application Object navigation Object messages Object runtime Object request Object response Object page Object page context
The objects and their signatures for the individual event handlers are displayed if you choose Example: in the Web Application Builder.
Object application
Definition
The object application refers to the application class of a BSP application. See also: Class CL_BSP_APPLICATION Interface IF_BSP_APPLICATION
Integration
This object is only available if an application class was defined for the BSP application. If so, the methods defined there can be accessed.
Object navigation
Definition
The object navigation has the same type as interface IF_BSP_NAVIGATION. The following methods are available for navigation between BSP pages. They collect information required for the presentation of the subsequent page. After the subsequent is navigated to, the navigation object is deleted. The class contains methods which are used to determine the characteristics of the subsequent page, and methods which can be used for transferring parameters between pages.
When called, this method determines the subsequent page from the navigation structure.
navigation->next_page( 'TOORDER' ). This call triggers a search for the navigation request TOORDER in the navigation structure of the BSP application, and the subsequent page is opened.
goto_page
When this method is called, the URL of the page that is to be navigated to next is displayed.
navigation->goto_page( 'error.htm' ).
exit
This method ends the current session in the active application and navigates to the given URL. If no exit URL is given, the exit URL of the BSP application is used.
call_application
You can use this method to navigate to a page (specified by the URL) in another application. If the BSP application in which the method was called is running in stateful mode, the current context is maintained. The foreign application receives the URL as a parameter.
set_parameter
Using the call navigation->set_parameter( name='myparameter' value = myvalue ). you can set the page parameter myparameter to the value myvalue. This value can then be used for processing in the subsequent page.
If the form field (in the layout part) and the page parameter are of the type string and are specified by the same name (in this case, myparameter), the following abbreviation can be used: navigation->set_parameter( 'myparameter' ).
get_parameter
You can use this method to obtain the value of a parameter.
This method is not recommended for BSP applications. It is used when the users own HTTP request handlers are implemented.
has_parameters
This method returns 1 if at least one parameter was specified. Otherwise, the method returns 0.
Object runtime
Definition
The runtime object refers to the interface IF_BSP_RUNTIME. The following attributes can be set: runtime->keep_context 0: stateless mode 1: stateful mode
See also: Stateful and Stateless BSP Applications A Sample BSP Application
Object request
Definition
The request object is of the type IF_HTTP_ENTITY. IF_HTTP_REQUEST. This interface contains the interface
IF_HTTP_ENTITY.
Object response
Definition
The request object is of the type IF_HTTP_ENTITY. IF_HTTP_REQUEST. This interface contains the interface
IF_HTTP_ENTITY.
Object messages
Definition
The object messages is the same type as the class CL_BSP_MESSAGES. This object is a message contained and outputs different types of error messages. It contains a list of error messages with details of severity, condition, and the corresponding text.
Use
You use the object to handle users incorrect entries in BSP applications. For more information see Handling Incorrect Input. An entry is made in the list if syntax errors occur in automatic page attributes, for example, when the entry cannot be converted to a specific format. The attribute name must be available. You can add additional entries to the messages object during input processing. Texts and conditions are user-definable in this case.
Structure
The following methods are available: NUM_MESSAGES This method returns the number of messages when it is called. ADD_MESSAGE This method adds a single message when it is called. GET_MESSAGE This method returns the requested message when it is called. ASSERT This method returns the message index for a specific condition or 0 when it is called. ASSERT_SEVERITY This method returns the severity of the error for a specific condition or 0 when it is called. ASSERT_MESSAGE This method returns the message for a specific condition or an empty string when it is called. The conditions specify the message types or error levels. The following error levels are available: Attribute Name CO_SEVERITY_ERROR CO_SEVERITY_FATAL_ERROR CO_SEVERITY_INFO CO_SEVERITY_SUCCESS CO_SEVERITY_WARNING Initial Value 2 1 4 5 3 Description of Error Level Normal error Fatal error Information Success message Warning
Example
There is an example showing the use of this object in the SAP System in the BSP application bsptutorialmessages, in the package SBSP_DOCU.
Object page
Definition
The object page accesses information about a BSP. It is the same type as class CL_BSP_PAGE or the interface IF_BSP_PAGE
Structure
The following methods are the most important: Method get_page_name Use in Source Code <%= page>get_page_nam e( ) %> <%= page>get_page_url( ) %> <%= page>get_application _namespace( ) %> <%= page>get_application _name( ) %> <%= page>get_application _url( ) %> <%= page>get_application _theme( ) %> <%= page>get_application Output (Example) basic_page_object.htm Description Output of the BSP name
get_page_url
get_application_namespace
Output of the BSP application namespace Output of the BSP application name Output of the BSP application URL Output of the BSP application theme Output of the BSP
get_application_name
it00
get_application_url
/sap(bD1kZQ==)/bc/bsp/sap/it00
get_application_theme
SAP_DEFAULT
get_application_start_page
default.htm
_start_page( ) %>
Object page_context
Definition
Based on the interface IF_BSP_PAGE_CONTEXT, the page context object provides information that is sent to all BSP elements.
This object is not used in the BSPs themselves, but only in connection with BSP extensions or elements.
BSP Extensions
Introduction
The BSP programming model, which is based on the server pages technology, provides developers with additional scope regarding the HTML coding that they can create, from an empty page right up to complex applications. However, repeatedly creating complex HTML coding is often a lengthy process that can easily result in errors. As an example, a simple HTML pushbutton can be implemented very easily: <input id=btn type=submit>. If you now start to use additional styles and other attributes for the size and the status of the button, the original simple HTML coding becomes considerably more complex and unclear. Here an abstraction technology can be used to express both the syntax and the semantics of a specific section of HTML coding simply. This mechanism is structured so that it can also be used by other types of BSPs, XML, WML and so on. With this technology you call them BSP extensions. A BSP extension contains a collection of BSP elements. In the BSP context, each element is assigned to an ABAP class to represent the element functionality, which the generation of the HTML coding usually contains. Defining the elements and mapping them to the ABAP classes is so flexible that you can use this technology to solve many additional problems and difficulties.
SAP provides an infrastructure that developers can use to implement BSP extensions within BSP applications. SAP delivers a set of predefined extensions such as HTML Business for BSP (HTMLB), XHTMLB and PHTMLB which are available and can be used in every SAP Web Application Server 6.20 system. In addition you can define your own extensions to meet specific requirements. You can create these using an editor that is integrated in the development environment (Transaction SE80). You include an extension in a BSP using the extension directive. For more information see Creating Your Own BSP Extensions.
You can also create composite elements to facilitate layout changes with complicated BSP applications.
In the sample pushbutton above, the start tag is followed immediately by the end tag. No body components whatsoever are available or required (by the pushbutton). For other examples, it may be useful to manipulate the body or to process more detailed input.
A typical element, for example, could be an HTML link for creating a small text segment. In this case, the element has a body, which is first rendered in a string and then passed as a parameter to the element for further processing. <htmlb:link id=link1 reference=http://www.sap.com> Homepage of the e-company! </htmlb:link> This results in:
The link element takes the Internet address as the reference. Furthermore, the link element provides formatting based on the style that is provided by the BSP extension. The body is used as input for the element.
Even if using elements and their resulting ABAP class calls seems to be fairly complex for this type of simple HTML element, using and supporting BSP extensions provides several advantages that should not be underestimated:
The standard XML syntax that is used can be parsed and checked during the BSP compile time. The returned HTML coding need only be generated once (by an expert) in the ABAP element class, thereby ensuring that the coding is correct. The element class can contain additional logic for generating browser-dependent HTML code. The HTML coding that is generated contains correct references to the style sheets that are available.
In addition to a BSP extension for standard HTML elements such as pushbuttons, input fields, dropdown lists and so on, you can also implement highly specialized extensions.
For example, you could develop an extension to map a companys corporate identity to an HTML page. In this case, the users coding for this extension, for example, could be as follows: <%@extension name=SAP_Corporate_Identity_Extension prefix=corp %> <corp:logo/> <corp:stock_ticker/> This could look as follows on the HTML page:
Examples
Different examples of BSP applications that use BSP extensions are available in the system. You can find simple examples of using BSP extensions HTMLB, XHTMLB and PHTMLB in the BSP applications SBSPEXT_HTMLB, SBSPEXT_XHTMLB and SBSPEXT_PHTMLB, and further examples in BSP extension HTMLB_SAMPLES.
As part of the tutorials for creating Web applications with BSP, a Tutorial for a Small Online Bookshop is also available, whose layout is implemented using HTMLB.
The following sections provide two simple examples of the HTMLB elements button and tableView: Button TableView
Button
You can find this example in the system under BSP application SBSPEXT_HTMLB, page button.bsp (package SBSPEXT_HTMLB).
Layout
<%@page language="abap"%> <%@ extension name="htmlb" prefix="htmlb"%>
<htmlb:button id
= "myButton1"
<br><br>
<htmlb:button id
= "myButton2"
text = "Emphasized button" tooltip = "button quick info: Please click me" onClick = "MyButtonClick"
<br><br>
<htmlb:button id
= "myButton3"
text = "Small button with fixed size " tooltip = "button tooltip: Please click me" onClientClick = "alert('myButton3 Clicked')" design = "small" width = "300" />
OnInputProcessing
CLASS CL_HTMLB_MANAGER DEFINITION LOAD.
* Optional: test that this is an event from HTMLB library. IF event_id = CL_HTMLB_MANAGER=>EVENT_ID.
IF event->name = 'button' AND event->event_type = 'click'. DATA: button_event TYPE REF TO CL_HTMLB_EVENT_BUTTON. button_event ?= event. ENDIF.
* Scenario 2: Dispatch event directly onto event class DATA: event_handler TYPE REF TO CL_HTMLB_EVENT_EXAMPLE. CREATE OBJECT event_handler. CL_HTMLB_MANAGER=>dispatch_event( request = runtime->server->request event_handler = event_handler page_context = page_context ).
ENDIF.
Output
TableView
You can find this example in the system under BSP application SBSPEXT_HTMLB, page TableView.bsp (package SBSPEXT_HTMLB).
Layout
<%@page language="abap"%> <%@ extension name="htmlb" prefix="htmlb"%> <htmlb:content> <htmlb:page title = "BSP Extension: HTMLB / Element: tableView"> <htmlb:form> <htmlb:tableView id = "tv1" headerText = "Connections" headerVisible = "true" design = "alternating" visibleRowCount = "8" fillUpEmptyRows = "true" onHeaderClick = "MyEventHeaderClick" onRowSelection = "MyEventRowSelection" selectionMode = "multiselect" table = "<%=sflight%>" > <htmlb:tableViewColumns> <htmlb:tableViewColumn columnName = "carrid" wrapping = "true" width = "100" onCellClick = "MyCellClickCarrid__" horizontalAlignment="center" title = " " type = "user" > <htmlb:textView id="$TVCID$" text = "$TVCVALUE$" design = "LABELSMALL" layout = "PARAGRAPH" required = "TRUE" width = "100%" tooltip = "$CARRNAME$" encode = "FALSE" wrapping = "TRUE" /> </htmlb:tableViewColumn> <htmlb:tableViewColumn columnName = "myicon" type = "user" title = "Image" horizontalAlignment="center" > <htmlb:link id = "$TVCID$"
onClick = "$CARRNAME$" tooltip = "$CARRNAME$"> <htmlb:image src = "$TVCVALUE$" alt = "$TVCVALUE$" tooltip = "$CARRNAME$" /> </htmlb:link> </htmlb:tableViewColumn> <htmlb:tableViewColumn columnName = "myinputfield" type = "user" title = "Input Field" cellInvalidKey = "invalid" cellDisabledKey = "disabled" horizontalAlignment="center" > <htmlb:inputField id = "$TVCID$" width = "100%" value = "$myinputfield$" type = "Date" showHelp = "true" firstDayOfWeek = "2" /> </htmlb:tableViewColumn> <htmlb:tableViewColumn columnName = "mybutton" type = "button" title = "Button" cellDesignKey = "design" onItemClick = "MyButton__" horizontalAlignment="center" /> <htmlb:tableViewColumn columnName = "fldate" onCellClick = "MyCellClickFldate__" title = "Datum" wrapping = "true" width = "100" horizontalAlignment="center" /> <htmlb:tableViewColumn columnName = "DDLKEY" title = "User defined: List Box" type = "user" > <htmlb:dropdownListBox id = "$TVCID$" table = "<%=sflight%>" nameOfKeyColumn = "DDLKEY" nameOfValueColumn = "CARRNAME" /> </htmlb:tableViewColumn> <htmlb:tableViewColumn columnName = "linktextid" title = "Link" type = "link" linkColumnKey = "linkcarrid" linkClickTarget = "_blank"/>
<htmlb:tableViewColumn columnName="linkstextid" onItemClick = "MyLink__" title = "Link with Handler" type = "link" linkColumnKey = "linkcarrid"/> <htmlb:tableViewColumn columnName="linkid" horizontalAlignment = "center" type = "imagelink" linkColumnKey = "linkcarrid" linkClickTarget = "_blank" title = "ImageLink" /> </htmlb:tableViewColumns> </htmlb:tableView> </htmlb:form> </htmlb:page> </htmlb:content>
Attributes
Attribute rowSelection rowSelectionEvent sflight Auto Typing Type TYPE TYPE TYPE Reference Type STRING STRING MYSFLIGHT
OnInitialization
* event handler for data retrieval data: wa like line of sflight, name type string, value type string, str type string, scol type string,
srow type string, id type string, mod type i, sytabix type sytabix, sflightlink type table of sflightlink. field-symbols: <wa> like line of sflight, <waLink> type sflightlink. select * from sflight into corresponding fields of table sflight. select * from sflightlink into table sflightlink.
loop at sflight assigning <wa>. sytabix = sy-tabix. read table sflightlink assigning <waLink> with key carrid = <wa>-carrid. <wa>-LINKCARRID = <waLink>-HTTPLINK. <wa>-linktextid = <waLink>-CARRNAME. <wa>-linkstextid = <waLink>-CARRNAME. <wa>-myinputfield = sy-cdate. "<wa>-FLDATE <wa>-mybutton = <waLink>-CARRNAME. <wa>-FLOATT = 2000000. str = <wa>-FLDATE. concatenate <wa>-CARRID <wa>-CONNID str into <wa>-DDLKEY. str = page->to_string( value = <wa>-FLDATE ). concatenate <waLink>-CARRNAME ' (' <wa>-CONNID '/' str ')' into <wa>CARRNAME. if <wa>-carrid eq 'AA'. <wa>-linkid = '../HTMLB_SAMPLES/aa.gif'.
else. concatenate '../HTMLB_SAMPLES/' <waLink>-CARRNAME '.gif' into <wa>-linkid. endif. mod = sytabix mod 8. case mod. when 0. <wa>-myicon = 'ICON_WF_WORKITEM_READY'. when 1. <wa>-myicon = 'ICON_WF_WORKITEM_RESERVED'. when 2. <wa>-myicon = 'ICON_WF_WORKITEM_STARTED'. when 3. <wa>-myicon = 'ICON_WF_WORKITEM_COMMITTED'. when 4. <wa>-myicon = 'ICON_WF_WORKITEM_WAITING'. when 5. <wa>-myicon = 'ICON_WF_WORKITEM_COMPLETED'. when 6. <wa>-myicon = 'ICON_WF_WORKITEM_ERROR'. when 7. <wa>-myicon = 'ICON_WF_WORKITEM_CANCEL'. endcase. mod = sytabix mod 5. case mod. when 0. <wa>-invalid = 'X'. <wa>-disabled = 'X'. when 1. <wa>-disabled = 'X'. when 2. <wa>-invalid = 'X'. endcase. mod = sytabix mod 3. case mod.
when 0. <wa>-design = 'STANDARD'. when 1. <wa>-design = 'EMPHASIZED'. when 2. <wa>-design = 'SMALL'. endcase. endloop.
OnInputProcessing
* event handler for checking and processing user input and * for defining navigation
* Optional: test that this is an event from HTMLB library. IF event_id = CL_HTMLB_MANAGER=>EVENT_ID.
* Scenario 1: Read event from manager. DATA: event TYPE REF TO CL_HTMLB_EVENT. event = CL_HTMLB_MANAGER=>get_event( runtime->server->request ).
IF event->name = 'tableView'. DATA: tableview_event TYPE REF TO CL_HTMLB_EVENT_TABLEVIEW. tableview_event ?= event. ENDIF.
* Scenario 2: Dispatch event directly onto event class DATA: event_handler TYPE REF TO CL_HTMLB_EVENT_EXAMPLE. CREATE OBJECT event_handler. CL_HTMLB_MANAGER=>dispatch_event( request = runtime->server->request event_handler = event_handler page_context = page_context ).
ENDIF.
Output
also covers references to the appropriate element handler classes. Each BSP element has an element handler class assigned to it that implements its specific functions.
The figure below explains these connections with a relatively simple example.
Tool Support
In addition to the usual infrastructure (transport, where-used list, and so on), the workbench provides the following functions in order to ensure efficient processing of BSP extensions: Creating and editing BSP extensions In the Object Navigator (SE80), you first create a BSP extension as a new development object. Then you create one or several BSP elements and declare the individual element attributes. Generating the element handler class For each BSP element, you can generate a corresponding element handler class and its basis class in the Class Builder. Integration in the Tag Browser Through activation, each new BSP extension is copied, without additional effort, as an entry into the Tag Browser in SE80. On the BSP application pages, you can then place the corresponding tags and their attributes wherever you want them in the editor using Drag&Drop. See also: Using BSP Extensions.
Process Flow
Complete implementation of a BSP extension takes place in the following steps:
1. 2. 3. 4. 5.
Creating a BSP Extension Defining the Corresponding BSP Elements Implementing the Element Handler Class Activating the BSP Extension Entering Documentation
The specific functions of a BSP element are implemented with the help of a global element handler class myElementClass in the Class Builder.
Procedure
To create a new BSP extension: 1. Open the Object Navigator (transaction: SE80).
Alternatively (to steps 1-4), you can create a new BSP extension by selecting the Create function from the context menu of a BSP extension that already exists within an object list.
2. Choose the BSP Extension category from the object list selection and enter a name for the BSP extension you want to create. 3. Click the button or press ENTER.
The system checks whether a BSP extension with the specified name already exists in the SAP System. If there is none, the Create Object dialog box appears.
5. Enter the default prefix without blanks or other special characters and also a meaningful description for the BSP extension as a short text.
The default prefix is a prefix that is entered into the BSP page in the standard version during Drag&Drop of the extension or one of your BSP elements from the Tag Browser into the BSP page Within a particular page, the prefix references the corresponding BSP extension that is assigned through the extension directive. The predefined default prefix can be overwritten on the page of the BSP application by renaming the prefix attribute for the extension directive.
6. Choose
1. Assign a package.
The new BSP extension is copied into the object list of the package.
Result
With the new BSP extension, you create a separate development object in the Repository that appears in inactive status in your worklist. You can now create one or several BSP elements for this BSP extension and declare the appropriate element attributes.
Prerequisites
The BSP extension already exists.
Procedure
Creating BSP Elements
1. Choose the required BSP extension from the object list.
2. Choose the function Create BSP Element from the context menu.
The system displays the Create BSP Element dialog box.
3. Enter the name of the BSP element, a valid name for the Element Handler Class, and a
meaningful description for the BSP extension as a short text.
You can specify an existing, valid ABAP class as the element handler class. A valid class must support the interface IF_BSP_ELEMENT. We recommend that you derive this class from the automatically-generated basis class(Z)CLG_<name of BSP extension>_<name of BSP elements>. This basis class already contains a standard implementation of the interface methods and is automatically updated whenever changes are made to the element data. As a rule, you enter the name of a non-existing class as the element handler class into the respective input field. Then you have this generated, together with the corresponding basis class.
4. Choose
Continue to confirm your entries. The properties of the created BSP element are displayed in the editor.
Furthermore, you have the following options available to you: User-Defined Validation
Attribute
In this column, enter a name that uniquely identifies the attribute. After you have activated the BSP extension , the system generates a public attribute with the same name in the basis class (CLG_* or ZCLG_*).
Required
By setting this flag, you define that the attribute must be defined whenever the BSP element is used in a BSP page. By setting this flag, you define that the value of the attribute in a BSP page may also be specified dynamically through a BSP expression (<%= ...%>). Otherwise, only static values are possible in the form of a string. By setting this flag, you define that the attribute is passed to the event handler class as a reference. Otherwise, no value is passed. For more information, refer to the section Pass by Reference for Attributes.
Pass by reference
Kind of typing
You have at your disposal the two types TYPE and TYPE REF TO, depending on whether you have data or object references. Note that the selection TYPE REF TO is only appropriate in combination with the active option Dynamic Value Allowed. The reason for this is that object references in BSP pages can only be passed with the help of BSP expressions, not statically in the form of a string.
Reference type
As reference type, you can use the elementary ABAP types (however, no generic types) or object types (classes and interfaces). Generic types such as C, N, X, P, and so on are not allowed because generically-typed attributes are not allowed in ABAP classes either. There is a 1:1 relationship between the attributes of the BSP element and the class attributes.
Default value
Here you always enter a value if the attribute is to be predefined with a value. This value is copied from the Tag Browser into the BSP page when you insert the attribute or the entire BSP element. Here you enter an explanatory attribute description.
Description
The specifications marked with X are absolutely mandatory for each attribute.
Result
The new BSP element is assigned as a subobject to the BSP extension and copied inactive into the object list. With the new BSP element, the basis class (Z)CLG_<name of BSP extension>_<name of BSP elements> is automatically created itself, and possibly also the specified element handler class, provided this does not yet exist. Also, you have specified the BSP element behavior at runtime through further properties, and have also declared the corresponding attributes. In the next workstep, you can activate the BSP extension
Empty
You select this option if the BSP element is not to have any content.
Example: Input field from the BSP extension HTMLB <ui:inputField id="myID" value="" /> or <ui:inputField id="myID" value="" > </ui:inputField >
Example: Tree element from HTMLB <ui:tree id="myTREE"> <ui:treeNode id="ROOT" text="Root node"> <ui:treeNode id="N1" text="Node 1"/> <ui:treeNode id="N2" text="Node 2"/> </ui:treeNode> </ui:tree>
Example: Form element from HTMLB <ui:form id="myFormID" method="POST"> <ui:inputField id="myID" value="" size="24"/> <br> <br> Some Text ... <a HREF="" ...> ...</a> </ui:form>
Example: The BSP element executes an SQL statement that must be specified in the element content. <sql:selectStatement> SELECT * from SFLIGHT into table myFlights </sql:selectStatement >
User-Defined Validation
Use
Activate this option in the Attributes display for the BSP element if you wish to execute a userdefined validation of the element call. This can be the case, for example, if you wish to check the correct type of attribute values. Generally speaking, validation can take place both at compile time and at runtime. Runtime validation is particularly appropriate if attributes for BSP elements are assigned through BSP expressions (<%=...%>) only at runtime, or for attributes whose values are transformed into another data type (String -> I) at runtime. Validation at compile time, on the other hand, is done by the BSP compiler and takes place whenever values are passed using static attributes.
Activities
In addition to activating the option User-Defined Validation , you need to redefine the methods COMPILE_TIME_IS_VALID (for validation at compile time) and/or RUNTIME_IS_VALID (for validation at runtime) in the element handler class.
You must set the return parameter valid within the method COMPILE_TIME_IS_VALID. When determining this value, you use the predefined attributes and utilities belonging to the validation object validator. This object has corresponding conversion methods that identify attributes at compile time through the attribute name (see first
example). The validation object validator is already contained in the interface for COMPILE_TIME_IS_VALID as an input parameter. The RUNTIME_IS_VALID method, on the other hand, does not define any return parameter. The runtime validation triggers an appropriate runtime exception if there is an error. The validation object m_validator.is an important part of the method implementation. This object is already defined as an attribute of the element handler class and also has conversion methods that identify the attributes through their names and also through their value (see second example). The attributes to be checked (runtime attributes) are supplied as argument for calling the method RUNTIME_IS_VALID. This argument consists of a string in which the names of the attributes to be checked are listed, separated by / .
It can happen that the string with the runtime attributes to be checked exceeds the maximum length of 200 characters when <Elementname>>RUNTIME_IS_VALID(attr_1/attr_2/ .../attr_n) is called that is, if there is a large number of attributes. In such cases, you should pass the string / * / instead of the attribute name in order to avoid termination during activation.
Activities
In addition to activating this option, you must also redefine the interface method DO_AT_ITERATION of the element handler class.
This method is called each time at the end of an iteration. Using the return parameter , you control whether the loop is ended (RC=CO_ELEMENT_DONE) or run through once again (RC=CO_ELEMENT_CONTINUE).
Example
Let us assume that you wish to have a repeated text call with a simple <do>-Element. The number of iterations is set through the corresponding attribute howOften. Example: <loops:do howOften = "10"> Hello World ! </loops:do> The value of the attribute howOften is used at the beginning of the element call in the method DO_AT_BEGINNING in order to initialize the loop counter count: method IF_BSP_ELEMENT~DO_AT_BEGINNING . if howOften > 0. count = howOften - 1. rc = CO_ELEMENT_CONTINUE. else. rc = CO_ELEMENT_DONE. endmethod.
The method DO_AT_BEGINNING should have already checked whether the element content is to be evaluated at all. If this not the case, DO_AT_ITERATION is skipped and afterwards the method DO_AT_END is called. The implementation of DO_AT_ITERATION could look like this: method IF_BSP_ELEMENT~DO_AT_ITERATION . if count <> 0.
Note that the method DO_AT_ITERATION is only called if the operation Iteration Through Element Content has been explicitly assigned as element attribute. See also Defining BSP Elements. DO_AT_ITERATION is called as soon as the element content has been processed. The method DO_AT_END, on the other hand, is called whatever the case, but only once; in this case, the call takes place after the iteration has closed
Activities
After activation of this option, a so-called BodyWriter becomes available in the interface attribute M_OUT for the element handler class. This manages the content of the BSP element. Using the BodyWriter methods, you can manipulate the content accordingly. To change the element content, you must also redefine the interface method DO_AT_END for the element handler class as well as activate the option Manipulation of the Element Content.
This method is accessed in any case at the end of the element call. You can use them especially for manipulating the content in order to explicitly pass the BodyWriter content to the BodyWriter of a surrounding BSP element. If no pass takes place in this case, the element content is discarded.
Example
In the following example, a BSP element is to convert its entire text content into upper-case letters. The method DO_AT_END is overwritten as follows: First, the element content from the current BodyWriter m_out is written to the local variable content. A new content is then assigned to this variable. Afterwards, the method call me>get_previous_out() returns the BodyWriter of the surrounding element previous_out. The new content, however, is not automatically copied to this BodyWriter. The assignment of the new content finally takes place with the method print_string(). method IF_BSP_ELEMENT~DO_AT_END. data: content type string. content = m_out->get_content( ). translate content to upper case. data: previous_out type ref to IF_BSP_WRITER. previous_out = me->get_previous_out(). previous_out-> print_string( content ). rc = CO_PAGE_CONTINUE. endmethod.
In addition, the pass by reference is used whenever the BSP element is to change the content of a variable defined in the BSP page.
Note that in this case you must also select the typing kind TYPE REF TO for the corresponding attribute.
Example
The BSP element is to increase the content of a passed variable by 1. The attribute value is required for passing the value. Calling this increment element into the BSP page could then take place as follows: <xyz:increment value = "<%=my_var%>"/> The variable my_var is declared in the BSP application as a page attribute of the type I. For the value attribute, the indicator Dynamic Value Allowed was activated and TYPE REF TO was selected as Typing Kind in the attribute display. To execute this pass by reference at the beginning of the element call, you need to overwrite the method DO_AT_BEGINNING: method IF_BSP_ELEMENT~DO_AT_BEGINNING . ... add 1 to value->*. rc = CO_ELEMENT_DONE. endmethod.
Note that there is a reference to data in this example within a BSP element. To access data, the reference operator ->* must be used in ABAP in this case.
You use this standard function of the Workbench in order to put the entire BSP extension, including its elements, into the active version. If necessary, the system will generate the basis class (CLG_* or ZCLG_*) again upon activation. This renewed generation always tales place during activation in the following cases: If generation-relevant element data has been changed because, for example, element attributes have been created, deleted, or changed. If a basis class for a particular element does not exist at all because, for example, it was deleted manually, or was not transported by mistake.
Prerequisites
You have either created a BSP extension or processed one that already exists.
Activation does not take place for the individual BSP elements alone, but is always done for the entire extension.
Procedure
1. Choose the required BSP extension from the object list. 2. Select the Activate function from the context menu or through the respective the application toolbar. icon in
The system displays a list of all inactive objects. The selected BSP extension is marked.
Continue.
Result
When you activate, you create a runtime version of the BSP extension. If necessary, the system will also regenerate the element handler classes and your basis classes. Newly-created classes are automatically written to the same transport request as the BSP extension. Now the active version of the BSP extension appears in the Tag Browser under the entry BSP Extensions. There it is assigned to the selection Transportable or Local, depending on the object catalog entry.
Note that activating the extension can invalidate all the BSP pages that use this extension. Calling the respective BSP pages again means they will be regenerated if changes have been made.
Prerequisites
A valid element handler class must implement the interface IF_BSP_ELEMENT. We therefore recommend that you derive this class from the generated superclass (Z)CLG_<EXTENSION>_<ELEMENT> because it already contains the standard implementations for the interface methods.
Process Flow
The flow during implementation of the specific functions of a BSP element is divided up into the following three steps:
1. Creating the attributes for the BSP element See also Defining BSP Elements.
In this way, you make sure that the new attributes are added as attributes of the element handler classes after activation of the BSP extension.
The following figure shows the position of the element handler class within the inheritance hierarchy of the classes involved:
Extension Framework
IF_BSP_ELEMENT Basic interface that each valid element handler class must implement. The methods and attributes of this interface already define the actual extension framework for BSP applications. Basis class with a standard implementation of the IF_BSP_ELEMENT methods for all BSP elements.
CL_BSP_ELEMENT
Element-specific classes
(Z)CLG_<EXTENSION>_<ELEMENT> This class is automatically generated by the development environment for each new BSP element and is provided as a basis class for the element handler class. It has a 1:1 relationship to a BSP element and already contains a standard implementation for the corresponding element. In contrast to its superclass CL_BSP_ELEMENT, it contains public attributes that correspond to element attributes and, additionally, the standard implementation for the constructor (and, if necessary, for the class constructor as well). CL_<EXTENSION>_<ELEMENT> The element class, too, has a 1:1 relationship to a BSP element and implements its specific functions. As a rule, it is derived from the CLG class. This is recommended, but not compulsory. Compared to its basis class, the element handler class can be enhanced to include specific methods. In addition, special interface methods can be redefined, depending on the element attributes.
Use
The standard implementation of the class CL_BSP_ELEMENT provides the common basic functions for all element handler classes. To implement specific functions of a BSP element, you must overwrite certain interface methods in the element handler class and possibly also create new ones there. Refer also to the section: Implementing Element Handler Classes. Methods Interface Methods for Validation COMPILE_TIME_IS_VALID Determines at compile time whether correct values have been assigned to element attributes. The validation result is written to the return parameter valid. The possible values for valid are: X' or ' ' (blank). For information on how you can overwrite this method in the element handler class, refer to the example given for userdefined validation. RUNTIME_IS_VALID Determines at runtime whether correct values have been assigned to the element attributes. For more information, refer also to the example for user-defined validation.
By calling the runtime method <Elementname>>RUNTIME_IS_VALID with the special argument /*/, you can prevent termination from happening at activation if the string with runtime attributes (arg_1/arg_2/...) becomes too long (maximum length is 200 characters) and thus overflows. Interface Methods to Influence Element Flow and Element Content DO_AT_BEGINNING This method is always accessed at the beginning of the element call when the BSP page is processed. Using the return parameter RC you can control whether the content of the current BSP element is to be evaluated or not. The possible values of the return parameter RC are therefore: CO_ELEMENT_CONTINUE and CO_ELEMENT_DONE. For an example of a special implementation of this method, refer to the section Pass by Reference for Attributes. DO_AT_ITERATION This method is accessed after evaluation of the element content when the BSP page is processed. The prerequisite
for calling this method at all is that the corresponding option Iteration Through Element Content has been explicitly set for the element. This method returns the return parameter RC. The possible values of the return parameter RC here, too, include the following: CO_ELEMENT_CONTINUE and CO_ELEMENT_DONE. For an example of the implementation, refer to the section Iteration Through Element Content. DO_AT_END This method is accessed, whatever the case, at the end of the element call. Since the entire element content is available at this point, this method can be used for Manipulation of the Element Content. Using the return parameter RC, you can control whether the entire BSP page is to be evaluated further or not. The possible values are therefore: CO_PAGE_CONTINUE and CO_PAGE_DONE. Interface Methods for Accessing Parent Nodes GET_CLASS_NAMED_PARENT GET_ELEMENT_NAMED_PARENT GET_DIRECT_PARENT Interface Method For Error Handling RAISE_ERROR Triggers an exception of the class CX_BSP_ELEMENT_EXCEPTION. Returns an arbitrary parent element that is identified by the element handler class. Returns an arbitrary parent element that is identified by the name of the extension and the name of the element. Returns the direct parent element.
Interface Method for Accessing the Content of the BodyWriter GET_PREVIOUS_OUT Returns the reference to the BodyWriter of the surrounding element.
ID M_NAME M_EXTENSION M_CLASS_NAME M_PARENT M_PAGE_CONTEXT Predefined Interface Constants CO_PAGE_DONE CO_PAGE_CONTINUE CO_ELEMENT_DONE CO_ELEMENT_CONTINUE Interface Attribute for the BodyWriter M_OUT Interface Attribute for Validation M_VALIDATOR
BSP element ID BSP element name BSP extension name Name of element handler class Reference to a parent element Reference to the page context (IF_BSP_PAGE_CONTEXT)
This constant defines that the BSP page is not to be evaluated further. This constant defines that the BSP page is to be evaluated further. This constant defines that the BSP element is not to be evaluated further. This constant defines that the BSP element is to be evaluated (once more).
Static validator (for all class instances) that is used for runtime validation. Instances of this object are created only if the option Iteration Through Element Content has been explicitly set for the element.
Entering Documentation
Use
You can create a long text documentation both for a BSP extension as well as for each BSP element in the system that is contained in this extension. This document is of particular importance for the productive usage of the extension in BSP pages because you can include special aspects of the individual BSP elements here. If you store the documentation in the system, it is then available to users through the context menu in the Tag Browser and also through insertion of the tag into a BSP page also by pressing F1 in the layout editor.
Prerequisites
The BSP extension and the elements to be documented have already been created. There are two different templates available for the BSP extension and the BSP elements. The procedure for creating the documentation is the same, however.
Procedure
To create documentation for a BSP element in SE80: 1. Select the BSP extension in the Repository Browser. 2. Double-click the required BSP element in the object list. The system displays the element editor.
Result
You have created a SAPScript document for the long text documentation of a BSP element and have assigned a transport request to it. If you have saved the document as an active version as well, this will be transported to the translation worklist.
Example
The documentation for all BSP elements is available for the BSP extension HTMLB.
Prerequisites
The switch button Tab Browser is available in the navigation area of the Object Navigator. If this is not the case, change the corresponding user settings. So that the BSP extension is displayed with the required elements in the Tab Browser, the extension must already be activated.
Procedure
To insert BSP elements or their attributes into a BSP page, proceed as follows:
1. 2. 3. 4.
Choose the Layout view for the required BSP page. Switch to Change mode. Click the switch button Tag Browser in the navigation area of the Object Navigator. Under BSP Extensions, choose the appropriate extension. 5. Expand the tree display and click the required BSP element. 6. Double-click the selected entry in order to display the documentation for the BSP element. 7. Using Drag and Drop, drag the selected element or element attribute to the appropriate position in the layout editor.
Result
When you select an element in the tree display, the corresponding start tag and end tag, including all the obligatory element attributes, are inserted at the selected cursor position in the BSP page. If you enter an element attribute, the system takes the predefined standard value. With the first element of a BSP extension, the extension directive for the page is automatically created. The system adopts as prefix the default prefix that was specified when you created the BSP extension. By typing over the prefix value in the extension directive, however, you can rename the prefix. This means that all tags entered subsequently from the Tag Browser already contain the new prefix.
If documentation was created for a BSP element, you can call this by pressing F1 in the layout editor of the BSP page.
Example
The following example demonstrates the usage of the BSP extension HTMLB in a BSP application.
<%@page language="abap"%> <%@ extension name="htmlb" prefix="ui" %> <ui:content> <ui:page> <ui:form> <ui:label id for text design width = "myLabel" = "carrier" = "Airline" = "LABEL" = "65" />
<ui:inputField type
id
onClick = "FIND" design <br><br> <ui:tableView id table = "myTable" = "<%=flights%>" = "STANDARD" />
headerVisible = "true" footerVisible = "true" fillUpEmptyRows= "true" selectionMode = "MULTISELECT" design </ui:form> </ui:page> </ui:content> Note on the prefix: The BSP extension HTMLB is imported into the BSP page through the extension directive (2nd line). A prefix serves as a unique identification of this extension within the page. This directive is automatically crated after you have inserted the first BSP element for the page. In the standard version, the default prefix is taken. However, you can rename the prefix by overwriting the corresponding value in the extension directive (in our example: ui). = "ALTERNATING" />
Composite Elements
Use
When you create BSP applications with BSP extensions, it may not be easy to use elements that are essentially simple BSP elements. To generate the layout you require, you often need a number of special elements. In such cases, you can create composite BSP elements to facilitate handling several special elements, and to minimize the amount of work required to develop BSP applications and their layouts. The following uses a complex, typical task to display possible solutions. A simple BSP extension is presented and implemented.
Although the example is restricted to three simple input fields, the composite element solution is intended for cases where a number of variable input fields should be displayed, including labels and tableformat displays. Task Three input fields with labels should be displayed on a screen. Users should enter their name, password and e-mail address in these input fields. The three fields should be arranged under each other. You should use BSP extension HTMLB to solve this task, with the following predefined layout elements: <htmlb:gridLayout> <htmlb:label> <htmlb:inputField>
Process 1. Create a test BSP application. 2. First use the already existing BSP extension HTMLB on page before.htm. 3. Then create the composite element and use it on page after.htm.
Integration
Composite BSP elements use other, already existing BSP elements to generate the output within the layout framework by including and wrapping the BSP elements that already exist.
Prerequisites
You already understand the concept of BSP extensions and their implementation.
Activities
Create page before.htm Design solution Create a new BSP extension with elements Create page after.htm Dynamically process BSP elements Create a new BSP extension with composite elements Step 1 a) Implement <sf:SimpleFormItem> Step 1 b) Use <htmlb:SimpleFormItem> Step 2: Create <sf:SimpleForm> Step 3: Changes to the Look and Feel
Prerequisites
You have created a BSP application (see also has the name BSP_TUT_COMPLEX. Creating BSP Applications). In our example, this
Procedure
1. In your BSP application, create page before.htm as a page with flow logic 2.
(see also Creating Pages). Define three page attributes for the three input fields:
Auto x x x
for = "email" /> </htmlb:gridLayoutCell> <htmlb:gridLayoutCell columnIndex = "2" rowIndex = "3"> <htmlb:inputField id = "email" value = "<%=email%>" /> </htmlb:gridLayoutCell> </htmlb:gridLayout> </htmlb:form> </htmlb:page> </htmlb:content> 4. Save and activate your page and the BSP application.
Result
The generated output is as follows:
Analysis
You need more than 40 lines coding to code the simple three input fields. Also, because of the <htmlb:gridLayout> element, you cannot always immediately recognize at a glance the coding structure. This element is not absolutely necessary for our example, although it makes sense to use it with more complex layouts. For these flow-type layouts, most attributes can now be calculated automatically, especially counters for rows and columns. It is exactly the same when you connect <htmlb:label> to <htmlb:inputField>. Many of the attributes can also be hard-coded in a set of wrapper elements. It is therefore recommended that you design a BSP extension library that also contains inherent information (that is, hard-coded elements) for the layout of a specific BSP application or a group of BSP applications. Ideally, the individual BSP extensions in this library will be "slim" and easy to create. These can be used to create "toolboxes" that encapsulate the appearance and the whole layout centrally. As a result, you can also make changes to the whole application very quickly. You can do all this using the Design Solution.
Design Solution
After analyzing the page before.htm, you need a set of elements that are easy to use and which can be used for the outlined task area. As a result, this is not a universal solution, but a solution for a clearly delimited application area. Starting with the example, the initial situation is as follows: All row and index counters are calculated automatically All values for the layout (such as width, style, and so on) are hard-coded Elements <htmlb:label> and <htmlb:inputField> are linked to each other. The flexibility of the <htmlb:inputField> is still available, so that you can carry out functions such as password handling without any problems
The format of the layout can be specified with BSP elements as follows: <sf:SimpleForm id = "sf" > <sf:SimpleFormItem id = "name" label = "Name:" value = "<%=name%>" />
<sf:SimpleFormItem id = "password" label = "Password:" value = "<%=password%>" password = "TRUE" /> <sf:SimpleFormItem id = "email" label = "Email:" value = "<%=email%>" /> </sf:SimpleForm> Here you require a new BSP extension, which contains all of the necessary elements. You also need a test page, of course. Finally, you also need to implement the elements.
Procedure
The following describes the procedure for implementing this solution:
1. Generate your new BSP extension 2. Create the page after.htm 3. Specify that the BSP elements are processed dynamically
1. Create a new BSP extension in the ABAP Workbench (see also Creating BSP
Extensions). In our example, this has the name BSP_TUTORIAL_COMPLEX.
3. In your new extension, create element <SimpleForm> (see also Defining BSP
Elements).
We recommend that you integrate the default BSP extension prefix with the name of the element handler class. In our example, the name of the element handler class is CL_BSP_TUTCMPLX_SIMPLE_FORM. 4. Define and configure the BSP element as usual. In our example, the element content consists exclusively of inner BSP elements and therefore does not have any freely-defined text. In our example, the element has an (obligatory) attribute called id of type string.
a. To do this, branch to the BSP extension HTMLB for element <inputField> and on
the selected element in the context menu choose Copy....
c. Use the tabstrip Properties to change the connection to the element handler
class and enter CL_BSP_TUTCMPLX_SIMPLE_FORM_IT.
d. Add the additional attributes that you require for processing <htmlb:label>. In
this simple example, you only need one new attribute, which is the label name. On the tabstrip Attributes, enter the additional attribute label of type string. 1. Save the BSP extension and generate it.
Result
At this point, the empty implementations for the elements were already generated. You can now create a simple test page (although this does not create any output).
Procedure
1. In the Web Application Builder, use the context menu to copy the existing page 2.
before.htm to the name after.htm. Change the layout coding:
<%@page language="abap"%> <%@extension name = "HTMLB" prefix = "htmlb" %> <%@extension name = "BSP_TUTORIAL_COMPLEX" prefix = "sf" %> <htmlb:content> <htmlb:page> <htmlb:form> <sf:SimpleForm id <sf:SimpleFormItem id label value <sf:SimpleFormItem id label value password <sf:SimpleFormItem id label value </sf:SimpleForm> </htmlb:form> </htmlb:page> </htmlb:content>
= "sf" > = "name" = "Name:" = "<%=name%>" /> = "password" = "Password:" = "<%=password%>" = "TRUE" /> = "email" = "Email:" = "<%=email%>" />
Result
Everything runs as usual, although there is no output. In the next step, implement dynamic BSP element processing
Source: DATA: e123 TYPE REF TO CL_LIB_ELEMENT. CREATE OBJECT e123. e123->a1 = v1. e123->parent = page->current_element. page->current_element = e123. e123->context = page->context. e123->DO_AT_BEGINNING( ). e123->DO_AT_END( ). page->current_element = e123->parent.
An element can, however, also require its own writer, and possibly also validation. The element can either contain body text only, or it can include inner, embedded elements that must be processed. Element: <lib:element2 a1 = "v1" /> ... </lib:element2> Source: DATA: e124 TYPE REF TO CL_LIB_ELEMENT2. CREATE OBJECT e124. e124->a1 = v1. e124->parent = page->current_element. page->current_element = e124. e124->context = page->context. e124->m_out = context->PUSH_WRITER( ). e124->RUNTIME_VALIDATION( ). IF e124->DO_AT_BEGINNING( ) = CO_ELEMENT_CONTINUE. context->current_writer->PRINT_STRING( `....` ). ENDIF. e124->DO_AT_END( ). context->POP_WRITER( ). page->current_element = e124->parent.
Furthermore, an element can specify that its body requires iteration. This suggests that the body of the element is processed more than once. Element: <lib:element3 a1 = "v1" /> ... </lib:element3> Source: DATA: e125 TYPE REF TO CL_LIB_ELEMENT3. CREATE OBJECT e125. e125->a1 = v1. e125->parent = page->current_element. page->current_element = e125.
e125->context = page->context. e125->m_out = context->PUSH_WRITER( ). e125->RUNTIME_VALIDATION( ). rc125 = e125-> DO_AT_BEGINNING( ). WHILE e125 = CO_ELEMENT_CONTINUE. context->current_writer->PRINT_STRING( `....` ). rc125 = e125->DO_AT_ITERATION( ). ENDWHILE. e125->DO_AT_END( ). context->POP_WRITER( ). page->current_element = e124->parent.
Obviously, the compiler uses the additional information about the BSP elements definition to generate the optimum code for processing the element. The same flexibility is now required for processing BSP elements externally of the actual BSP, that is, externally of the page.
From the examples above, you can see that to set an elements attributes you need a reference to the actual class, and not to interface IF_BSP_ELEMENT. Also, elements do not have methods to actually set attributes. The attributes are set directly as public attributes of the element classes. It is not effective to encapsulate the actual element class reference, or the phase in which attributes are set. If an element is processed dynamically, you must know the element class (you can find it in the BSP extension workbench). You can, however, pack the remaining code in one or more methods. You cannot encapsulate body processing, since it is not known if the body is a string, or if it consists of several embedded elements that have to be processed. Due to these design constraints, the following pseudocode can be written: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. processing_before_body( eX ). ...body processing... processing_after_body( eX ).
This code is still not sufficiently flexible to handle element iteration. After the body has been processed, you must decide whether iteration is carried out, or if it should be stopped. The pseudocode can therefore be written as follows: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. WHILE process_element( eX ). ...body processing... ENDWHILE. This enables users to set the element attributes first of all. Furthermore, users can be flexible when determining how inner elements are to be used.
This type of element processing method with the name ELEMENT_PROCESS is available in interface IF_BSP_PAGE_CONTEXT, which is available in every element. If a body is not required, or only a simple string body is required, processing continues as far as possible (until it is complete, if this is possible), provided that the optional body string is available. Now to processing an "empty" element. In this case, "empty" means that the element is flagged in the Workbench as empty; it does not mean that there is only an optional body. Element: <lib:eX a1 = "v1" /> Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS ( element = eX ). If the simple element requires a body as well, this can be done when the body string is provided. Element: <lib:eX a1 = "v1" /> body string </lib.eX> Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS ( element = eX body = body string). The body can also be written dynamically during the processing step.
Note however, that the active writer is used for writing the body. Each time a new element is (partly) processed, new writers may be pushed on the stack. The writer that is used must be the last writer that was added. Element: <lib:eX a1 = "v1" /> body string </lib.eX> Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS ( element = eX ). DATA: out TYPE REF TO IF_BSP_WRITER. out = m_page_context->GET_OUT( ). out->PRINT_STRING( `body string` ). m_page_context->ELEMENT_PROCESS( element = eX ).
You can process inner elements by starting your processing when the external element is processed.
Ensure that you do not transfer a body to the processing code. If the body is transferred as a parameter, the system assumes that this body represents the whole body, and therefore then ends processing for that element. Element: <lib:eX a1 = "v1"> body before <lib:eY a1 = "v1"> body inside </lib:eY> body after </lib:eX>
Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS( element = eX ). DATA: out TYPE REF TO IF_BSP_WRITER. out = m_page_context->GET_OUT( ).
out->PRINT_STRING( `body before` ). DATA: eY TYPE REF TO CL_LIB_ELEMENTY. CREATE OBJECT eY. eY->a1 = v1. m_page_context->ELEMENT_PROCESS( element = eY body = `body inside` ). out = m_page_context->GET_OUT( ). out->PRINT_STRING( `body after` ). m_page_context->ELEMENT_PROCESS( element = eX ). Iteration implies that the same body is processed until the element has enough. Element: <lib:iterator repeat = "3" /> body string </lib:iterator> Source: DATA: iterator TYPE REF TO CL_LIB_ITERATIR. CREATE OBJECT iterator. iterator->repeat = 3. WHILE m_page_context->ELEMENT_PROCESS ( element = iterator body = body string ) = CO_ELEMENT_CONTINUE. ENDWHILE.
In principle, it is always correct to write a WHILE loop around the ELEMENT_PROCESS()- call. This is the recommended technique for using this method.
As soon as an element has been processed, the element instance can not be reused, since you cannot rest all element default values like the BSP compiler does. The create object call must therefore always be executed when the same element is to be processed again. Element: <lib:eX a1 = "v1" /> <lib:eX a1 = "v1" /> Source: DATA: eX TYPE REF TO CL_LIB_ELEMENTX. CREATE OBJECT eX. eX->a1 = v1. m_page_context->ELEMENT_PROCESS ( element = eX ). CREATE OBJECT eX. eX->a1 = v1.
m_page_context->ELEMENT_PROCESS ( element = eX ).
Now create the new BSP extension with the composite elements.
Finally, you will see how you can change the layout of all pages simply by changing the new elements.
Procedure
Step 1 a) Implement <sf:SimpleFormItem> Step 1 b) Use <htmlb:SimpleFormItem> Step 2: Create <sf:SimpleForm> Step 3: Changes to the Look & Feel
Since the <sf:SimpleFormItem> requires an HTML <table> wrapper, first create the <sf:SimpleForm> element to render the correct HTML in the output stream. Within class CL_BSP_TUTCMPLX_SIMPLE_FORM, overwrite and implement the following two methods: method IF_BSP_ELEMENT~DO_AT_BEGINNING . DATA: out TYPE REF TO IF_BSP_WRITER. out = me->GET_PREVIOUS_OUT( ). out->PRINT_STRING( '<table>' ). RC = CO_ELEMENT_CONTINUE. endmethod.
method IF_BSP_ELEMENT~DO_AT_END . DATA: out TYPE REF TO IF_BSP_WRITER. out = me->GET_PREVIOUS_OUT( ). out->PRINT_STRING( '</table>' ). RC = CO_PAGE_CONTINUE. endmethod. For the actual element <sf:SimpleFormItem>, the rendering code is as follows: <tr><td> <htmlb:Label/> </td><td> <htmlb:inputField/> </td></tr> For the implementation, the HTML coding is fetched in the usual way using the current output writer, and written to the data stream.
Processing the <htmlb:*> element is slightly more difficult. Since both elements are empty (that is, they dont have a body), they can be processed in one step. The processing steps are as follows for each element: 1. Create the element class 2. Set the attributes 3. Use method ELEMENT_PROCESS for the final processing. The complete coding is then as follows: method IF_BSP_ELEMENT~DO_AT_BEGINNING .
DATA: out TYPE REF TO IF_BSP_WRITER. out = me->GET_PREVIOUS_OUT( ). * <tr><td> out->PRINT_STRING( '<tr><td>' ). * <htmlb:Label/> DATA: label TYPE REF TO CL_HTMLB_LABEL. CREATE OBJECT label. CONCATENATE me->id '_label' INTO label->id. label->encode = 'FALSE'. label->for = me->id. label->wrapping = 'FALSE'. label->text = me->label. m_page_context->ELEMENT_PROCESS( element = label ). * </td><td> out->PRINT_STRING( '</td><td>' ). * <htmlb:inputField/> DATA: inputField TYPE REF TO CL_HTMLB_INPUTFIELD. CREATE OBJECT inputField. inputField->id = me->id. inputField->description = me->description. inputField->disabled = me->disabled. inputField->firstDayOfWeek = me->firstDayOfWeek. inputField->invalid = me->invalid. inputField->maxlength = me->maxlength. inputField->password = me->password. inputField->required = me->required. inputField->showHelp = me->showHelp. inputField->size = me->size. inputField->type = me->type. inputField->value = me->value. inputField->visible = me->visible. inputField->width = me->width. m_page_context->ELEMENT_PROCESS( element = inputField ). * </td></tr> out->PRINT_STRING( '</td></tr>' ). rc = CO_ELEMENT_DONE. endmethod.
Note that you cannot make any changed to the actual output writer structures. The coding, exactly like the inner elements that are processed, is executed on the current writer. This is automatically controlled by the development environment (indirectly using the PROCESS_ELEMENT call). You can now test page after.htm. The following task appears:
You can add additional methods to the BSP event handlers, which implement additional functionality, and which can in turn be used by "lesser" elements. The element handler classes are normal ABAP classes that can be processed in the Workbench. The simple coding will be as follows: method ADD_ITEM . DATA: out TYPE REF TO IF_BSP_WRITER. out = me->GET_PREVIOUS_OUT( ). out->PRINT_STRING( out->PRINT_STRING( out->PRINT_STRING( out->PRINT_STRING( out->PRINT_STRING( endmethod. The only task for ADD_ITEM at the moment to render the string immediately. In the next step, the coding is changed within <sf:SimpleFormItem>. For each internal element that is used, the element output must not be written to the current writer under any circumstance. As a result, this ensures that a new writer is pushed on the stack. Furthermore, all new elements will write to this new writer, and the context can be extracted from this new writer at any time. The changed coding is then as follows: method IF_BSP_ELEMENT~DO_AT_BEGINNING . DATA: my_out TYPE REF TO IF_BSP_WRITER, label_html TYPE STRING, inputField_html TYPE STRING. * Add own temporary writer on stack my_out = m_page_context->PUSH_WRITER( ). * <htmlb:Label/> .... label_html = my_out->GET_CONTENT( ). my_out->CLEAR( ). * <htmlb:inputField/> .... inputField_html = my_out->GET_CONTENT( ). '<tr><td>' ). label_html ). '</td><td>' ). inputField_html '</td></tr>' ). " <tr><td> " <htmlb:Label/> " </td><td> ). " <htmlb:inputField/> " </td></tr>
my_out->CLEAR( ). * Remove my writer from stack m_page_context->POP_WRITER( ). * Copy Text to <sf:SimpleForm> DATA: sf TYPE REF TO CL_BSP_TUTCMPLX_SIMPLE_FORM. sf ?= me->GET_CLASS_NAMED_PARENT( 'CL_BSP_TUTCMPLX_SIMPLE_FORM' ). sf->ADD_ITEM( label_html = label_html inputField_html = inputField_html ). rc = CO_ELEMENT_DONE. endmethod. Note the following points: The use of PUSH_WRITER() at the beginning to add an additional writer to the stack. All new elements that are now processed write to the top writer on the stack. At the end of this method, the additional writer must be removed from the stack using method POP_WRITER(). The use of methods GET_CONTENT() to extract the current string to the output, and CLEAR() to ensure that the two elements are in separate strings. The use of method GET_CLASS_NAMED_PARENT() to receive a reference to an element that is located "further up" in the element stack. The call of method ADD_ITEM(), which represents a local method that is defined by the element.
You can now execute page after.htm again to ensure that it still runs correctly. The element <sf:SimpleFormItem> is then complete. This section has described how BSP elements are processed on the stack. We have also described how the output of this type of element can be written to a string, so that it can be rendered later. For more information, see Step 2: Creating <sf:SimpleForm>
The next step after Step 1: Using <htmlb:SimpleFormItem> is similar. You must first enhance the simple form handler class so that the entries are not written as soon as they are added. The entries must be collected and rendered at the end. Add two string tables as class attributes to class CL_BSP_TUTCMPLX_SIMPLE_FORM: Name LABELS INPUTFIELDS Type Instance attribute Instance attribute Visibility private private Typing Type TYPE TYPE Reference Type STRING_TABLE STRING_TABLE Description Table of strings Table of strings
Change the ADD_ITEM method to collect the entries: method ADD_ITEM . APPEND label_html TO labels. APPEND inputField_html TO inputFields. endmethod.
Ensure that an element handler class can be reused several times. This is triggered by the code generator for the BSP. This is why the whole local data structure must be reset each time that a new element is restarted. The coding that is executed at the beginning must be changed as follows: method IF_BSP_ELEMENT~DO_AT_BEGINNING . CLEAR labels. CLEAR inputFields. RC = CO_ELEMENT_CONTINUE. endmethod.
In the last step, the whole rendering should be executed at the end tag of the element. The coding for the output would therefore be as follows:
<htmlb:GridLayout > LOOP AT labels/fields <htmlb:GridLayoutCell > output "label" string </htmlb:GridLayoutCell> <htmlb:GridLayoutCell > output "inputfield" string </htmlb:GridLayoutCell> ENDLOOP. </htmlb:GridLayout> Here, the most interesting point is that tags must be processed with bodies. An element would usually be processed by a WHILE loop, while PROCESS_ELEMENT is called at the end. As a result, both the start and the end tag are processed. After the first processing call, the element was pushed on the processing stack and is therefore available as if the compiler had generated the code. After the inner tag has been processed, the second call of PROCESS_ELEMENT is required for processing the end tag. The <htmlb:gridLayout> is processed in the first part of the coding. There then follows a LOOP, in which all of the calls are executed, and finally the end tag </htmlb:gridLayout> must be processed. Ensure that the whole output is written to the currently active writer. The coding is as follows: method IF_BSP_ELEMENT~DO_AT_END . * <htmlb:gridLayout> DATA: gridLayout TYPE REF TO CL_HTMLB_GRIDLAYOUT. CREATE OBJECT gridLayout. gridLayout->id = me->id. gridLayout->cellSpacing = '0'. gridLayout->cellPadding = '2'. gridLayout->rowSize = lines( labels ). gridLayout->columnSize = 2. gridLayout->width = '100%'. m_page_context->ELEMENT_PROCESS( element = gridLayout ). * Output all cells. DATA: label TYPE STRING, inputField TYPE STRING. LOOP AT labels INTO label. READ TABLE inputFields INTO inputField INDEX sy-tabix. ....code to process gridLayoutCell for label and for inputField ENDLOOP. * </htmlb:gridLayout> m_page_context->ELEMENT_PROCESS( element = gridLayout ). rc = CO_PAGE_CONTINUE.
endmethod.
Processing the <htmlb:gridLayoutCell> element is slightly more complex. The reason for this is that for each cell, the current body (the HTML string that was previously collected) must be written to the output stream. The coding is therefore split into three steps. First the start tag is processed, then the body is written to the current output writer, and finally the end tag is processed. For the <htmlb:label> string, the coding is as follows: * <htmlb:gridLayoutCell> for label DATA: gridLayoutCell TYPE REF TO CL_HTMLB_GRIDLAYOUTCELL. CREATE OBJECT gridLayoutCell. gridLayoutCell->rowIndex = sy-tabix. gridLayoutCell->columnIndex = 1. gridLayoutCell->horizontalAlignment = 'LEFT'. gridLayoutCell->verticalAlignment = 'MIDDLE'. m_page_context->ELEMENT_PROCESS( element = gridLayoutCell ). * print content DATA: out TYPE REF TO IF_BSP_WRITER. out = me->m_page_context->GET_OUT( ). out->PRINT_STRING( label ). * </htmlb:gridLayoutCell> m_page_context->ELEMENT_PROCESS( element = gridLayoutCell ).
Ensure that the output writer that is currently active is not received until just before it is used. It is important that GET_OUT() is called each time an element is processed. Every element can push additional writers on the stack, even the BSP framework can add its own writer to the stack from time to time. If only one single writer is received at the start of the method, this is therefore probably the parent writer of the gridLayout, that is, all of the new output is written to the parent writer of the gridLayout. It is therefore important that the new active writer is always received after a PROCESS_ELEMENT call and before the new output. The method PROCESS_ELEMENT is aligned with element processing, even if they require iteration. In theory, after every write/processing cycle the system should check explicitly whether the element has finished. In this case, the element does not include iteration. PROCESS_ELEMENT can therefore be called again without any problems. In cases where only one body must be written, particularly if the body is already present as a string, the body can be transferred as a parameter of the PROCESS_ELEMENT method. A writer is
not required, and the processing code automatically writes the body correctly and finished processing the method. The more simple coding is as follows (here string inputField is used as an example): * <htmlb:gridLayoutCell/> for inputField CREATE OBJECT gridLayoutCell. gridLayoutCell->rowIndex = sy-tabix. gridLayoutCell->columnIndex = 2. gridLayoutCell->horizontalAlignment = 'LEFT'. gridLayoutCell->verticalAlignment = 'MIDDLE'. m_page_context->ELEMENT_PROCESS( element = gridLayoutCell body = inputField
).
Ensure that the gridLayoutCell object is not reused. This is expressly forbidden. It must be newly created each time a new element is required. In the last step, you make changes to the look and feel.
to: CONCATENATE '<b>' me->label '</b>' INTO label->text. causes the following task:
Integration
The MVC design pattern is integrated in the BSP programming model and the Web Application Builder of the ABAP development environment (Transaction SE80) from SAP Web Application Server 6.20.
Functions
A BSP application can consist of one or more controllers and Business Server Pages, as well as known elements such application classes, MIME objects and themes. A BSP can have different characteristics; it is either a page with flow logic (as before), or a view or a page fragment:
Within a BSP application, there can be several controllers, several views and several pages with flow logic.
Controllers
A controller is the instance of a central controller class. In the BSP-MVC environment, each controller is directly or indirectly derived from the same base class CL_BSP_CONTROLLER2, where the central method is DO_REQUEST. There is a URL for every controller that can be addressed externally, such as using a browser. A controller can therefore be used as the initial point of entry to a BSP application. The mapping of the URL to the controller class is determined in the BSP application. A controller is the controlling instance in the MVC design pattern, where it also acts as the controlling mechanism. It carries out the following tasks:
It provides the data It is responsible for selecting the correct layout It triggers data initialization
Layout selection A controller will usually call a view instance for creating the HTML / XML output. The controller can call a view that is created using a factory method. The theme or the browser variant, for example, can be used here as the selection criteria. If a controller passes the control to a view, it can and should set attributes to the view. These attributes may just be data, or a reference to one (or, in extreme cases, several) model(s). A reference to the controller is automatically transferred.
A controller has access only to views in its own application. A controller can, however, delegate processing to another controller, and this controller can be located in a different application.
A controller should not work with too many views, since all of these requests are processed centrally. On the other hand, the controller should jump to all views that have the same or very similar input processing. Data provision Although a controller does not have any pre-defined attributes, they can be set and read using generic methods. However, a controller should provide a method init_attributes, which is responsible for filling the attributes. There is a service method that facilitates filling the attributes. Event handling The controller also takes care of event handling. It takes on all of the tasks that were executed in the previous BSP programming model by the event handlers: It carries out initialization and request processing, manages data transfer and is responsible for managing views and controlling a views lifetime.
Redirects from the controller or page to the controller or page can be easily implemented. See also Navigation If it cannot be decided until input processing which page should follow, we recommend that you let the controller branch to different views (for example, if it is checked internally whether the user has registered as a customer, and the corresponding data is then queried).
A controller can also be used to delegate control over screens to the sub-controller. A controller can delegate the control for a whole screen or a screen section to one or more different sub-controllers. This can result in a complex tree structure of controllers and components can be formed (that consist of both cascading controllers as well as their corresponding views). You can find information about the life cycle of controllers in Lifetime.
View
Views are only responsible for the layout; they visualize the application data. Views are very much like pages, although they do not have event handlers nor auto-page attributes, nor their own URL. Unlike auto-page attributes, normal page attributes can be used, which are then filled by the controller. Controllers should control calling views and communicate with a model. If the type of controller class is known for a view (see the Properties tab for the view), the view can also access the attributes of the controller class. You can find information about the life cycle of views in Lifetime.
Models
The model is used to obtain all necessary application data from the database. It represents the internal data structures and corresponds to the application class used in the remaining BSP programming model. The model is responsible for carrying out the central actions of reading, modifying, blocking and saving data. When used with controllers, this controller can create a reference to a class that is used as a model. Class CL_BSP_MODEL is available for this (see also Data Connection).
For more information, refer to: Using MVC for BSP Class CL_BSP_CONTROLLER2 Navigation Lifetime BSP Component Call Options Components
Activities
Creating a Controller Creating a View Calling a Controller Calling a View Creating Error Pages
A simple Tutorial is available for your first steps with the MVC design pattern. The general bookshop tutorial for BSP contains a more extensive MCV tutorial: Our Online Bookshop Using MVC and HTMLB.
Example
You can find an example of MVC in the system in BSP application BSP_MODEL. Furthermore, the following Architecture Examples are outlined:
BSP Application with Controllers and Views BSP Application with Several Views per Controller Combination of the Previous Examples Calling Controllers of Other Applications Calling Several Controllers from a View
Since the model does not recognize either views or the controller, internal data processing is detached from the user interface. As a result, changes to the user interface have no effect on internal data processing and the data structure. You also have the option, however, of displaying the data in different formats; you can display election results as a table, a bar chart or as a pie chart. You can find additional information about the MVC design pattern on the Internet and in current specialist literature.
You can combine the technology of the previous implementation model for BSPs with the new MVC design pattern. In an application, there may be pages with flow logic as well as controllers and views The views can only be called by the controllers. Redirects from pages to controllers and back can take place with the help of redirect using the navigation methods. In the page layouts you can use the <bsp:call> element or the <bsp:goto> element to call a controller. You cannot use these elements to call pages.
Process
Use the top controller as a point of entry to your BSP application and its process flow. First create a controller (see Creating Controllers). Then a call a view from this top controller. Next create a corresponding view (see Creating Views). Now test your controller. Then call the controller or the sub-controller (see Calling Controllers), and then the view (see Calling Views). If necessary, you can also create error pages.
Creating a Controller
Use
You create a controller to use a Model View Controller design pattern in your BSP application. You can use a controller for the initial access (see also Testing Controllers).
Prerequisites
You are in a system from SAP Web AS 6.20.
Procedure
1. Use the Web Application Builder in the ABAP Workbench (Transaction SE80) to create a
controller object as a sub-object of your BSP application. In doing so, you determine the controller name and the class name of the controller. The URL is automatically inserted from the name of the BSP application and the controller name.
2. In the Class Builder (Transaction SE24), create the class that is derived from
CL_BSP_CONTROLLER2.
If you create your class directly from the Web Application Builder by double-clicking on the class names, then the inheritance of CL_BSP_CONTROLLER2 has already been configured.
Example
You can find examples of controllers in BSP application ITMVC2.
Creating a View
Use
You create views to use the view of the Model View Controller design pattern in your BSP application.
Prerequisites
You are in a system from SAP Web AS 6.20.
Procedure
1. Use the Web Application Builder in the ABAP Workbench (Transaction SE80) to create a
page with the page type View as a sub-object of your BSP application. 2. Specify the layout and any attributes that may be required. 3. Save and activate your view.
Example
You can find examples of views in BSP application ITMVC2.
Testing Controllers
Use
You can use a controller as an initial point of entry to your BSP application. In the BSP programming model without MVC, you have always used a central page as the initial page that you called start.htm, for example. Use the main controller instead in connection with the MVC design pattern.
Prerequisites
You are in a system from SAP Web AS 6.20. You have successfully activated your BSP application and the controllers and views to be tested.
Procedure
1. Place your cursor on the top controller in your BSP application. 2. Click on (Test/Execute) in the application toolbar. The browser starts and a logon screen may be displayed. 3. Log on to the system if this is necessary.
Result
The selected controller is started in the browser.
We recommend that a subordinate controller in method DO_INIT creates a sub-controller, sets the parameters accordingly and then calls the sub-controller from the appropriate view.
Prerequisites
You are in a system from SAP Web AS 6.20. You have crated at least one controller for your BSP application, or at least a main and a sub-controller.
Calling a Controller
1. Create the controller instance. You have the following options: o data: l_ctrl type ref to cl_bsp_controller. l_ctrl = create_controller( key = navigation_key ). or o l_ctrl = create_controller( application_namespace = 'fred' application_name = 'hugo' controller_name = 'do_something.do' ). application_namespace and application_name are optional. Unless you specify otherwise, the system uses the current values.
You can also specify each of the controller IDs. 1. If necessary, set the request parameters: l_ctrl->do_initattributes( ). 2. Set additional attributes: l_ctrl->set_attribute( name = name value = value ). 3. Call the request: call_controller( l_ctrl ).
Ensure that the controller_id is specified. 2. Call your sub-controller. a. You can execute the call from the controller. This makes sense in particular if the calling controller does not control a layout. There are two call options here: data: l_ctrl type ref to cl_bsp_controller. l_ctrl = create_controller( key = navigation_key ). or l_ctrl = create_controller( application_namespace = 'fred' application_name = 'hugo' controller_name = 'do_something.do' ). application_namespace and application_name are optional. Unless you specify otherwise, the system uses the current values.
a. You can execute the call from the view. There are three call options here, which
are all implemented using the <bsp:call> BSP element. The comp_id used here corresponds to the controller_id from create_controller. <bsp:call comp_id = ""/> Note that the instantiation using the controller_id must have already taken place. <bsp:call url = "" comp_id = ""/> A controller instance is generated if no controller is created under the comp_id. <bsp:call key = "" comp_id = ""/> A controller instance is generated if no controller is created under the comp_id. The key is taken from the navigation table.
1. Determine the parameter transfer. a. You can execute the parameter transfer from the controller. sub_controller -> set_attribute (name value) To do this, use any public method of the sub-controller if you know its class. Of course, you can also set the sub-controllers public attributes directly.
a. You can execute the parameter transfer from the view. <bsp:call> <bsp:parameter name = "" value = "" /> </bsp:call>
Calling a View
Prerequisites
You are in a system from SAP Web AS 6.20. You have created at least one view for your BSP application.
Procedure
1. Create the view instance. data: l_view type ref to if_bsp_page. l_view = create_view( key = navigation_key ). or l_view = create_view( view_name = 'next.htm' ).
Note that you can call views only from your own application. 2. Set the attributes of the view: l_view->set_attribute( name = 'model' value = my_model_instance ). or l_view->set_attribute( name = 'hugo' value = 'Hugo-Text' ). 3. Call the view layout: call_view( l_view ).
of this (other) page or this controller, the system automatically processes the assigned error page and sends it to the browser. If no error page is assigned to a page/a controller, in case of a runtime error, the system displays a standard page. If runtime errors occur in a called controller or view and there is no error page, this section remains empty. If different types of exception occur, you can use the ERROR_OBJECT error object from class CX_ROOT in your error page. You can implement this object using dynamic ABAP and use GET_TEXT or GET_LONGTEXT methods to output an appropriate error text for your application (message short or long text).
Use the functionality in the HTTP service tree (Transaction SICF) to create error pages if short dumps occur. See also Error Pages.
Prerequisites
1. You created the page (the controller) you want to use as error page. See also: Creating Pages or Creating Controllers. 2. You cannot assign an error page to a page or a controller that itself is marked as error page. 3. With views you must not assign a controller class, because an error page is always called implicitly by the BSP runtime.
Procedure
To identify a page / a controller as an error page: 2. ... 3. Select the page or the controller for your BSP application. 1. Go to the properties display and switch to Change mode if necessary. 2. In section Error Handling, mark the checkbox Is Error Page. 3. Save your entries and activate the page or controller.
Result
You can now assign this page or controller as Assigned Error Page to another page or another controller.
Example
The BSP application BSP_MODEL in the system contains an example of how to implement and use an error page.
Normal pages are different from controllers especially with regard to event handling and programming. The events of the pages can be matched with the controller methods: Page events and main controller methods Page events and sub-controller methods
A main controller handles both input and output processing, where it uses the central method DO_REQUEST to call the methods specializing in input processing: DO_HANDLE_DATA, DO_HANDLE_EVENT and DO_FINISH_INPUT. In method DO_REQUEST, input processing must be triggered using DISPATCH_INPUT. This corresponds to the processing steps in the purely pagebased BSP programming model that are executed using events OnRequest, OnInputProcessing, OnManipulation and Layout. Page events and sub-controller methods From method DO_REQUEST, the three following methods required for input processing are called: DO_HANDLE_DATA DO_HANDLE_EVENT DO_FINISH_INPUT
The calls are different from views or pages. You can use the following elements of BSP extension bsp to branch from a view or a page to a controller: <bsp:goto> Forward <bsp:call>
Insert These two elements are based on the same technology as when a controller is called by a controller. As inner elements, both can only have elements of type <bsp:parameter>. You hereby determine the parameters that are passed to the controller.
Navigation
There are two options for navigating to a different URL: navigation->goto_page for a page or a controller <bsp:goto> element for a controller.
navigation->goto_page
With goto_page, there is a redirect to the specified page (or to the controller), that is, the browser is informed that it may request a different page. There is then a new browser request to the destination page. This has the following effect: The browser recognizes the URL for the destination page, since it requested it itself. In the page does not run in a frame, its URL is displayed in the address line of the browser. An additional browser request is required, which leads to increased network load. Even if the amount of data is extremely small, this may slow down performance with very slow networks (such as via satellite). In a stateless case, all temporary data from previous processing is lost.
<bsp:goto> Element
With the <bsp:goto> element, the new controller or view is called to provide the content for the current request. This means that: The browser does not recognize the URL for the destination page, but tries to communicate with the existing page. No additional browser request is required. If no target has been entered in the form of the target page, the request that results from sending the form (or also from a refresh) is sent to the requesting page. As a result, the target page only has the task of creating the HTML (view) and does not usually have to worry about input. The calling page is responsible for this and thereby takes over the controller functionality.
The work process does not change, that is, the context remains the same even in a stateless application and you can therefore access the data and objects that have already been created. The controller must be able to use the input to decide on its current "status" if it should display several views after each other. It should not store this status on the server, otherwise the "Back" processing would not function correctly. With different URLs, this is easier using redirects. When you use different views, the URL does not change. As a result, you cannot use bookmarks on these pages.
What does page_name point to? runtime->page_name always points to the externally addressed page or the controller. You get the name and URL using page->get_page_name() or page->get_page_url(). Lifetime of the View that is Called The lifetime of the view that is called is limited to the call only. For more information, see Lifetime and Note 545847.
Lifetime
Controllers
You determine the lifetime of components or their controllers in the usual way using the Properties tab page of the controller. You can specify the lifetime as one of the following three options in Status: To page change For the duration of the request For the duration of the session
The setting is usually To page change. By default, the lifetime of controller instances is limited to the one call. If the controller instance is passed with id, then its lifetime is the same as that specified in the controllers properties (Properties tab). The id can be specified as follows: From a page or a view: <bsp:call/goto comp_id = "id"> From a controller or a page event: create_controller(controller_id=id)
The controller_id or the comp_id of the <bsp:call> element must not contain an underscore (_ ). The underscore is reserved as a separator between controllers. The lifetime of the top-level controller ranges from the first CREATE_CONTROLLER for a subcontroller to DELETE_CONTROLLER for the sub-controller. If sub-controllers should occasionally be hidden, so that they are not involved in event handling for a while, then use method CONTROLLER_SET_ACTIVE. A controller that is set to inactive in this way will not be called for input processing.
Views
This section concerning the lifetime of views concerns the use of MVC in SAP Web AS 6.20 up to and including Support Package 9. Unlike controllers or pages, views have only a very short lifetime. Their life cycle looks as follows: 1. They are created. 2. They are supplied with parameters. 3. They are called. 4. They are now no longer required and therefore expire, since views cannot be reused. Views therefore only exist for the duration of the call, that is, they are destroyed after they have been called. As a developer of BSP applications with MVC, you must explicitly recreate the view, since you cannot reuse it in a controller. The following provides an example of correct and incorrect coding: Use: DATA: view TYPE REF TO if_bsp_page. view = create_view( view_name = 'main.htm' ). Do not use: DATA: view IF view IS INITIAL. view = 'main.htm' ENDIF. TYPE REF TO if_bsp_page. NOT BOUND. " or IS NOT create_view( view_name = ).
DATA: view TYPE REF TO if_bsp_page. view = create_view( view_name = 'main.htm' ). " ... set attributes .... call_view( page ). CLEAR view.
Data Binding
To make programming easier for you with the MVC design, the framework for the model of an application provides you with basic class CL_BSP_MODEL, which you can use in your own model class as a class that passes on its properties. The model class represents the data context of your application and, as a result, receives a copy of the data (or references to the data) that are relevant for the view from the database model. The model class provides:
The data that are used for the views, with the corresponding type and data Dictionary information. Input conversions Information about input errors that occurred for which data
A controller can instantiate a model class or even several model classes (see also Calling the Model Class Using the Controller). The controller has a list of all model instances, analogous to the list of sub-controllers. The controller assigns unique IDs to each model instance.
If you are using the MVC Design Pattern, you do not need to use the Application Class. Instead of the usual application class with purely page-based BSP applications, you should use controllers and model classes in the MVC environment.
Data binding is particularly important with HTMLBextension elements inputField and label (see also the documentation for these elements in the system). It is also implemented for HTMLB elements dropdownListBox, radioButtonGroup, checkbox, textEdit and tableView. A model class can either be designed quite simply or it can be used with more complex application cases.
1. Structures
2. Tables In the most simple case, the model class has these attributes only and so can easily be used for data binding as part of a BSP application. This type of simple model class provides the following functionality:
The controller can create a model instance and initialize the attributes, since they are public attributes. The controller transmits a reference to the model instance to the view. The data binding to the model is specified in the view for each view element using a path expression (//...). Example: A BSP application contains an input field that is implemented using HTMLB, in which users can write data. model is defined as a page attribute. For the input field you can then write: <htmlb inputField value=//model/<Attribut> This ensures that the content of value is bound to the corresponding attribute of the model class. The process flow is now as follows:
1. The content of the attribute is assigned to the input field value using the above statement. 2. This generates the ID from the model. 3. Additional attributes are also generated, for example, one that determines whether fixed values exist. 4. User input is transferred to the model class at the next request. 5. Data conversions including connection to the Dictionary (conversion exists, for example) are automatically executed by the base model class.
In the default case, if a conversion exit for a field exists in the ABAP Dictionary, this conversion exit is called. All data contained in the ABAP Dictionary structure for the field are available. If, however, separate setter/getter methods (see the following section) are written, the conversion exit can be switched off.
If necessary you can also add your own methods to your model class for further processing attributes.
Naming convention for getter methods: GET_<attribute> for a field GET_S_<attribute> for a structure GET_T_<attribute> for a table An example of implementing a getter method for structure fields/structure attributes: method GET_S_FLIGHT . field-symbols: <l_comp> type any. assign component of structure flight to <l_comp>. value = <l_comp>. if component eq 'CARRID'. translate value to lower case. endif. if component eq 'CONNID'. shift value left deleting leading '0'. endif. endmethod. The ABAP keyword assign component assigns the structure component component for the structured field flight (with reference type sflight) to the field symbol <l_comp>. The value of <l_comp> is output as follows: If the structure component component points to an airline (CARRID), the name of the airline is translated in lowercase. If the structure component component points to a single flight connection (CONNID), then some of the introductory zeros may be deleted.
As soon as a setter or a getter method is set, it is used automatically. Data binding is automatically available because the name is the same. In method DO_HANDLE_DATA (see also Process Flow) of class CL_BSP_CONTROLLER2 all controllers automatically fill the form fields with data. The path specifications for the model data have the following syntax:
Simple field attribute value=//<field name> Structure attribute value=//<structure name>.<field name> Table attribute value=//<table name>[<line index].<field name>
A model class is called or managed by a controller, that is, a controller can hold one or several model classes (or instances). The controller class provides methods for creating, getting, setting and deleting this type of model class. There are also methods for passing incoming data on to the correct model instance, which is identified by the model_id.
Components
Use
Complex BSP applications that are based on the MVC Design Pattern have many extensive components. Each individual part, consisting of a complex BSP application, contains precise application logic and well thought out presentation logic. It makes sense to create the individual BSP components as reusable modules. These reusable modules are:
Controllers One or more views A Model
Integration
The use of components is integrated in the MVC design pattern.
Prerequisites
You are in SAP Web AS 6.20.
Functions
A component consists of a controller, whose class is derived from CL_BSP_CONTROLLER2, as well as one or more views, which can result in regular nesting. This is outlines in the following graphic:
Central features of components are: 1. With components, there are complex call sequences during an HTTP request. 2. The individual parts, of which a page in the browser consists, are dynamically assembled during runtime. 3. One component can call a different component. It should therefore be placed in a view. This is done using the <bsp:call> element. 1. Initialization can be called by the controller using method create_controller. This method is available for all controller classes. It creates a controller or finds an existing one.
The parent controller contains a list of the individual sub-controllers and forwards all input to the relevant controller. This is done by prefixing all IDs with the path of the controller IDs. The controller has a hierarchical tree. Every controller controls its view or views, its model as well as the list of sub-controllers. Basis class CL_BSP_CONTROLLER2 controls the sub-controllers. The controller developer is responsible for controlling the view and the model. If you want to use data binding functionality, you can add a model class to your component. For more information see Data Binding.
Activities
5. 6. 7. 8. 1. 2. 3. 4. 4. ... Creating the top-level controller Creating a Component Calling the Component Determing the Input Processing
Process Flow
Uses
The methods of class Class CL_BSP_CONTROLLER2 are used to create components as part of the Model View Controller design pattern.
The whole hierarchy level is processed with every request. The hierarchy itself is defined at output.
Process
1. First call DO_INIT. 2. Then call DO_INITATTRIBUTES. 3. Then call DO_REQUEST.
With a main controller, DO_REQUEST takes care of both input and output processing. a. Input processing The browser request is sent directly to the top-level controller. This dispatches the input to the sub-controllers. Service function DISPATCH_INPUT is available for this. DISPATCH_INPUT reads the form fields from the request and dispatches them to the sub-controller. Prefixes are added to the form fields.
The prefixes are written automatically for BSP elements, for example, by BSP extension HTMLB. If, however, you have pure HTML or HTML tags, then you must add the name of the controller as a prefix to your input data. In this case, service function GET_ID is available for adding prefixes. All data that do not belong to one of the sub-components must be processed using method DISPATCH_INPUT in the main controller. The following methods are called: DO_HANDLE_DATA DO_HANDLE_EVENT DO_FINISH_INPUT
These three methods are called by the parent controller only with the form fields for the current controller. a. Output processing Determining output processes contains the output for the next page. A view is created and displayed. Depending on the status of the top-level controller, you can also set a sub-controller to inactive or create new controllers. The process flow of the output is displayed in the following graphic: Page Output
DO_REQUEST determines whether data must be fetched from the model or from the global attributes. DO_REQUEST fetches the table with the object keys from the top-level controller. DO_REQUEST requests a view. DO_REQUEST sets the correct attributes for the view. DO_REQUEST calls the view.
If a component contains events, DISPATCH_INPUT calls the HTMLB manager. The HTMBL manager collects the relevant information, including the ID, that is, the ID of the object that triggered the event. DISPATCH_INPUT then calls method DO_HANDLE_DATA. DO_HANDLE_DATA is called by all controllers (that is, for all active components), that is, by the top-level controller as well as by all sub-controllers. The model class is filled with DO_HANDLE_DATA (see also Data Binding): The system transfers form fields and messages for the global messages object (see below).
If your model class is based on CL_BSP_MODEL and you have defined your setter and getter methods accordingly, the form fields are filled automatically.
The process flow with DO_HANDLE_DATA is displayed in the following graphic: Page Input (DO_HANDLE_DATA)
Once DO_HANDLE_DATA has filled all data, method DO_HANDLE_EVENT is called for the controller that is responsible for the input event. This also states the event ID and the event is dispatched to the controller. DO_HANDLE_EVENT also outputs parameter GLOBAL_EVENT (a string). If the event is an HTMLB event, object HTMLB_EVENT is filled accordingly.
Events are only dispatched to the relevant controller if the element ID was assigned to the HTMLB element (attribute id). DO_HANDLE_EVENT also has access to the global messages object and can carry out additional steps if necessary. For example in the case of an error, this method can have data displayed again. The process flow with DO_HANDLE_DATA is displayed in the following graphic: Page Input (DO_HANDLE_EVENT)
Note that only a sub-controller is called here. Method DO_FINISH_INPUT is always called (for every controller, that is, for all active components). You can use it to react to events in a component that occur in a different component. To do this, use parameter GLOBAL_EVENT, which is set in method DO_HANDLE_EVENT. Using this global event, at the end of input processing each component should know exactly which events are present and how to react to them. The process flow with DO_FINISH_INPUT is displayed in the following graphic: Page Input (DO_FINISH_INPUT)
Global Messages
Parameter GLOBAL_MESSAGES is shared by all components. Use this parameter to handle incorrect user input, for example to display that an error occurred, or that the end date entered by the user is before the start date, and so on. The main controller creates the global messages and forwards them to all sub-controllers. On the other hand, the messages object is local. If the local messages object is now filled in a controller, then you can forward this information to the global messages object and react to it using any component you like.
The attribute output takes place either in the view or in the top-level controller.
COMPONENT_ID always identifies the controller. The COMPONENT_ID has a reference to the controllers concerned. In method CREATE_CONTROLLER this reference is parameter COMPONENT_ID, and in the <bsp:call> element it is attribute COMP_ID: When a controller is created, a reference is sent to the parent controller, which has a list of all the sub-controllers that belong to it. Every subcontroller can query its parent controller for the COMP_ID of each additional sub-controller.
You create components to use them independently as well as together with other components for BSP applications. You can create a component for a search in an online shop, for example, and create an additional one for the detail display of the article that was found. When you develop components, you can also form teams, so that one team is responsible for developing controllers, a different team is responsible for the views, and a third team is responsible for developing the models.
Process
1. 2. 3. 4.
Create the top-level controller Create a component Call the component Determine the input processing
(Redefine):
method DO_REQUEST . data: main_view type ref to if_bsp_page. * * * * if input is available, dispatch this input to subcomponent. this call is only necessary for top-level controllers. ( if this is not a top-level controller or no input is present, this call returns without any action) dispatch_input( ).
* if any of the controllers has requested a navigation, * do not try to display, but leave current processing if is_navigation_requested( ) is not initial. return. endif. * output current view main_view = create_view( view_name = 'main.htm' ). call_view( main_view ). endmethod.
b. If necessary, overwrite method DO_INIT. c. In order to react to user input, overwrite methods DO_HANDLE_DATA and
DO_HANDLE_EVENT. 10. Activate your class. 11. Create a view within your BSP application.
Creating Components
Procedure
1. Create a controller (including classes) in a BSP application. This controller may belong to an already existing BSP application or it can be located in its own BSP application.
Note that the basic class of this controller and the top-level controller is class CL_BSP_CONTROLLER2 (see also Creating Top-Level Controllers and Views).
2. If this controller should always be used as the component controller, then change method
DO_REQUEST so that only views can be displayed. If not, DO_REQUEST would look exactly the same as the DO_REQUEST from the top-level controller.
b.
Calling Components
Use
You can call a main controller, sub-controller in two ways: A. By creating the sub-controller in a method of the main controller B. By creating the sub-controller from a view
Option A is more flexible than Option B, especially if the sub-controller should be initialized once only in method DO_INIT.
Procedure
Option A 1. In method DO_INIT or DO_REQUEST, for example, add the following coding:
... data: addresscontroller type ref to CL_C_MYPROJ_ADDRESS. * create the controller addresscontroller ?= create_controller( controller_name = 'address.do' component_id = 'ad' ). * set some attributes with a self defined method addresscontroller->Init_data( ... ). ... 2. 3. or ... data: subcontroller type ref to CL_BSP_CONTROLLER2. * create the controller subcontroller ?= create_controller( controller_name = 'address.do' controller_id = 'ad' ).
* set some attributes with standard method subcontroller->set_attributes( name = 'address' value = ship_address ). ... 4.
Option B
In this option, you do not need to create the sub-controller in the coding of the main controller. Instead you should only add the parameters to the view call, which then creates and calls the controller. In the following example, ship_address is an attribute of the view and is set by the controller: <%@page language="abap"%> <%@extension name="htmlb" prefix="htmlb"%> <%@extension name="bsp" prefix="bsp"%> <htmlb:content id="ComponentTest" > <htmlb:page title = "Component Test"> <H1>Component Test</H1> <htmlb:form id="myFormId" method="post"> <htmlb:tray id = "tray1" title = "Address" design = "form" width = "350" isCollapsed = "false" > <bsp:call url="address.do" comp_id="ad"> <bsp:parameter name="address" value="<%=ship_address%>"/> </bsp:call> </htmlb:tray> <htmlb:tray id = "tray2" title = "Flights" design = "form" width = "350" isCollapsed = "false" > <bsp:call url="flights.do" comp_id="fl"> </bsp:call> </htmlb:tray> <p> <htmlb:button id="SAVE" text="SAVE DATA" onClick="SAVE" /> <htmlb:button id="CANCEL" text="CANCEL" onClick="CANCEL" /> </htmlb:form> </htmlb:page> </htmlb:content>
Use
The browser sends its request to the top-level controller. This main controller dispatches the input to the appropriate sub-controller. This is why it is necessary to call method DISPATCH_INPUT in the top-level controller.
Procedure
Input processing consists of three steps: 1. Filling data For every controller, method DO_HANDLE_DATA is called with a list of form fields that should be handled by this method. If an error occurs during the data conversion, then this method can also pass one or more messages to the global error object (global_messages). 2. Handle event Method DO_HANDLE_EVENT is called for exactly one controller. The event is passed on and object htmlb_event is filled if it is an HTMLB-event. Method DO_HANDLE_EVENT has access to object global_messages, in order to determine the additional steps that are necessary, depending on the error. For example, in the case of an error, you can specify that you want to display the data again. You can also set a global_event using method DO_HANDLE_EVENT. 3. Finish input processing For every controller, method DO_FINISH_INPUT is called with a global event, which is set by the event handler method. The closing input processing is carried out here.
Class CL_BSP_CONTROLLER2
Overview
Class CL_BSP_CONTROLLER2 is used to create controllers and components. Every controller class automatically inherits all methods and attributes from this central basic class.
If the basic class of your controller class displays CL_BSP_CONTROLLER instead of CL_BSP_CONTROLLER2, change the inheritance hierarchy accordingly. Class CL_BSP_CONTROLLER2 enables you to: Retain a list of sub-controllers Create unique IDs for the sub-controllers, where the sub-controller is assigned the controller ID prefix Use models Forward data to the correct controller as well as fill model classes (if they exist)
Methods
Below you can find an overview of all methods in a controller class. Processing Process provides details on the most important methods. The individual methods can be separated into different categories:
You must overwrite this method. In DO_REQUEST you specify the request processing, that is, this method is called for every request. This method does the "main work"; in particular it should branch to the correct view. DO_REQUEST can be used in two different areas: If it is the top-level controller of a component, then this method handles both input and output processing. If it is a sub-controller of a component, then this method only handles output processing.
Processes events if the component contains them. Exactly one view controller is called to handle the event, which contains an event such as a save button, for example. DO_FINISH_INPUT Ends the input processing.
Service functions
You can call these methods: Method CREATE_VIEW Description Creates or fetches a view instance Use either the name of the view, or the navigation. object
A view must always belong to the same BSP application as its controller.
Calls the request handler of the view instance. Creates or fetches a controller instance Calls the request handler (method DO-REQUEST) of the controller instance. Returns the specified page attributes. Generic method for reading an attribute value. Returns the lifetime of this page (only for the top-level controller) Returns the URL of the page or the current controller Sets the specified page attributes. Generic method for setting an attribute value. Changes the lifetime of this page (only for the toplevel controller) Creates a formatted string Writes a formatted string in the output Fetches the current output writer Changes the MIME type of the page or the content type of the header field Instantiates the parameter from the request using the request data Changes the caching values There are two types of caching: Browser cache Server cache Caching BSPs.
GET_ATTRIBUTE GET_LIFETIME GET_PAGE_URL SET_ATTRIBUTE SET_LIFETIME TO_STRING WRITE GET_OUT SET_MIME_TYPE INSTANTIATE_PARAMETER SET_CACHING
See also
You can only use limited caching here. Note that the server cache is not user-specific. If you change the page, you should reset the cache that may be set.
DISPATCH_INPUT
Dispatches the input processing (only for the top-level controller). For each input, DISPATCH_INPUT calls the correct methods in the correct sequence. This method fetches data from the request.
This method does not have any attributes. GET_ID SET_MODEL CREATE_MODEL GET_CONTROLLER CONTROLLER_SET_ACTIVE Calculates the ID from the specified ID and the component ID Creates and registers a model instance Creates and registers a model instance Fetches a sub-controller Sets a controller to active/inactive. This is relevant with input processing, since you can use it to hide a controller. See also Lifetime Deletes a model instance Fills the model data Deletes a sub-controller Fetches a model instance Is this controller a top (main) controller (0: no, 1: yes)? Has a controller requested a navigation (0: no, 1: yes)?
Framework functions
These methods are provided as part of the framework and are only included here for the sake of completeness. They are not usually relevant for application development. Method IF_BSP_DISPATCHER~REGISTER Description Registers a sub-components
Processes or dispatches: end of input processing. Processes or dispatches: handling values Processes or dispatches: Handle event Finds components for a field name Finds model for a field name
Examples of Architecture
Previous BSP Application
With SAP Web AS 6.10, normal BSP applications usually consisted of an application class and several BSPs. Navigation between the pages was controlled using redirects.
This is how it looks with SAP Web AS 6.20: BSP Application with Controllers and Views
With several views for a controller, the whole thing looks as follows: BSP Application with Several Views per Controller
What does a combination of these two examples look like (this one here and BSP application with controllers and views)? Like this.
There can also be a page in place of the calling controller and view (in the graphic on the left-hand side). There cannot be a page, however, at the level of the called areas (in the graphic on the right-hand side). With help from the views that are allocated, these controllers provide the contents for a sub-area of the main views. A reference to the model can also be specified with the call.
The general bookshop tutorial for BSP contains a more extensive MCV tutorial: Our Online Bookshop Using MVC and HTMLB.
Prerequisites
You are in an SAP Web AS 6.20 system You know how to use MVC for BSPs
Functions
Creating a Controller
Creating a Controller
Prerequisites
You have created an empty BSP application for this tutorial.
Procedure
1. Create a controller within your BSP application. To do this, choose Create Controller.
2. On the following dialog box, give the controller a name and add a short description.
3. Choose
. 4. On the following screen, assign a class name to the controller. The class does not have to exist yet.
5. You navigate to the Class Builder by double-clicking on the controller class. If the class does not already exist, the system asks you if you want to create it. Choose Yes so that you create a class with the specified name that is derived from CL_BSP_CONTROLLER2.
6. Choose the 7.
method DO_REQUEST . write( '<html><body><H1>' ). write( 'This is my very first controller' ). write( '</H1></body></html>' ). endmethod. 9. Activate your class and your BSP application. 10. Before you can test the controller, in Transaction SICF you must also activate the new entry that was automatically created for your BSP application (see also Activating and Deactivating an ICF Service). In Transaction SICF, select the entry for your BSP application and choose Service/Virt.Host Activate.
Confirm the following confirmation prompts. 11. You can now test the new controller page that you have created.
Result
Creating a View
Use
If you do not always want to use the write function to create the HTML page content (as described in Creating a Controller), and you want to create it as pure HTMLO layout instead, then create a view that you can call from the controller.
Procedure
9. 5. ... 1. Begin as if you are creating a normal page with flow logic in your BSP application.
To do this, choose Create Page.
10.
2. In the following dialog box, enter a name and short description of the view and select View as the page type:
11. 12.
3. Choose . 4. Create the attributes for the variable parts of the view.
You cannot define auto-page attributes, since views cannot be called directly from the browser. Create the following attribute:
13.
<head> <link rel="stylesheet" href="../../sap/public/bc/bsp/styles/sapbsp.css"> <title> Layout for Controller </title> </head> <body class="bspBody1"> <H1>View Example</H1> <H3>Hello, user <%= name%></H3> </body>
</html>
14. 15.
6. Activate the view. 7. Finally, adjust the DO_REQUEST method to the controller class.
Here, the schema is always the same. First you create the view, then you set the attributes, and then you call the view. (For the time being you can ignore the warning concerning exception CX_STATIC_CHECK, or you can set a try-catch block around the calls):
method DO_REQUEST . data: myview type ref to if_bsp_page. myview = create_view( view_name = 'view_test.htm' ). myview->set_attribute( name = 'name' value = sy-uname ). call_view( main_view ). 16. endmethod. 8. Activate your class and test your controller.
Result
You have created your own view for the layout.
Calling a Controller
Use
You can call a controller from a page with flow logic, or from a view.
Procedure
1. Create a page within your BSP application. Ensure that you select Page with Flow Logic as the page type.
2. In the Tag Browser, select BSP extension bsp and drag it to the second line of your
BSPs layout under the page directive.
3. Now drag the <bsp:goto> directive of BSP extension bsp to the body of the HTML
layout and add the URL parameter. The source now looks as follows: <%@page language="abap"%> <%@ extension name="bsp" prefix="bsp" %> <html> <head> <link rel="stylesheet" href="../../sap/public/bc/bsp/styles/sapbsp.css"> <title> Initial page </title> </head> <body class="bspBody1"> <bsp:goto url="example.do"></bsp:goto> </body> </html> 4. You can now activate and test the page. The page looks as follows:
Ensure that the page you have tested looks exactly the same as when you tested the controller. The URL is different, however. You can use View Source in the browser to see that nothing remains of the HTML text from the BSP, but that only the content of the view is displayed: <html> <head> <link rel="stylesheet" href="../../sap/public/bc/bsp/styles/sapbsp.css"> <title> Layout for Controller </title> </head> <body class="bspBody1"> </head> <body class="bspBody1"> <H1>View Example</H1> <H3>Hello, User GREBEL</H3> </body>
</html>
5. You can now try out the difference between the <bsp:goto> element and the
<bsp:call> element. If you use the <bsp:call> element instead of the <bsp:goto> element, the calling page text remains the same. In the view that is inserted, you should therefore delete the HTML text available on the outline page, otherwise these texts will be transferred twice.
6. You can add another attribute to the controller. This is a public class attribute.
It is set using the <bsp:parameter> element. You can use it for example to control which view is called, or this value can be passed to the view.
Session Handling
BSP applications can be implemented as both stateful and stateless applications. The term stateless does not mean that request data for a running application is not retained on principle; it refers to whether in the SAP Web Application Server the application context (also called Roll Area) is retained for individual requests, or whether it is released following each request. If you want to keep large datasets about request limits in the server (in internal tables), this can be done either by working in stateful mode, that is, retaining data using the Application Class or by Using Server-Side Cookies in a stateless application. Both ways have advantages and disadvantages, which are explained in the following sections. A running BSP application regardless of whether it is HTTP stateful or stateless is referred to as a session from here on. The start and end of a session is determined either by the user externally (compare System-Specific URL-Parameters) or by the application itself and then only the end is determined. The following topics are dealt with: Stateful BSP Applications Stateless BSP Applications Hybrid Forms Setting Stateful or Stateless Stateful or Stateless Programming?
Advantage
The main advantage of stateful BSP applications is that they are simple to program. As usual, you have access to data determined previously and reading or re-calculating data can often be omitted. For database-intensive applications, this can lead to considerably better system performance compared to a procedure where identical read operations have to be executed for every request.
Disadvantage
This significant advantage is at the same time however a disadvantage the improved runtime is offset by a larger memory requirement. The number of possible parallel sessions in an SAP Web Application Server is restricted not least by the amount of available memory space. When this space is exhausted, no further sessions can be started and users cannot log on. A further advantage is the fact that, unlike SAPGUI, Web browsers do not log off servers, that is, if users navigate in their Web browsers to a different Web site, the SAP Web Application Server is not be informed. Thus, an open session cannot be terminated and is retained in the application server until the context is released by the timeout mechanism. Since this can take some time, scarce resources are unnecessarily blocked in the application server.
Note that with stateful applications, the application status can be easily distinguished from the status users accept based on their interface. This can be caused by users navigating in the browser history or using the browser Back button - information that is not necessarily passed on to the server. So a user may navigate back to a Web site and the Web site sends the information again even though the application is expecting other requests. Measures are required in the application to deal with this. In the next release, we plan to provide at least one detection mechanism.
See also: Stateless BSP Applications Hybrid Forms Setting Stateful or Stateless Stateful or Stateless Programming?
Session Cookie
Definition
A cookie is an HTTP mechanism that enables an HTTP server to store limited amounts of data in an HTTP client. This data can then be sent back to the server for requests based on specific criteria. There are two types of cookie: persistent cookies, which are usually saved on the hard disk of the client until an expiry date and session cookies, which are not saved in the file system; they are kept only in the memory of the client (for example, the Web browser) until this is closed. As such, session cookies involve no security risks and are deleted immediately the browser window is closed. Some browsers now differentiate between these two cookie types and, if required, only inform the user when persistent cookies are received, which require the users confirmation.
Integration
The next version of the SAP Web Application Server will also support applications with no cookies at all.
Stateless applications allow - at least from the viewpoint of the memory resource optimal scaling regardless of the number of users. On the other hand, releasing the application context after every request may mean that identical data is read from the database and formatted multiple times. In this respect, the runtime may offset the memory saving. This should be evaluated and analyzed on a case by case basis.
You can include hidden fields by implementing a page fragment, which is embedded in each page of the application. You can easily define the attributes you want to save in the application class itself. The page fragment is then embedded in each Web site. The application attributes from the request (we are working in stateless mode) are restored in the OnRequest event handler of the page (or preferably in the ONREQUEST method of the IF_BSP_APPLICATION interfaces. You should pay particular attention to hyperlinks and to including the parameters you want to save, for example, in the query string part of the URL from the application. Storing Data in Client-Side Cookies: You must ensure that the size and number of cookies that can be saved in a Web client/browser is strictly limited. Server-Side Cookies: The BSP runtime provides a generic mechanism known as server-side cookies that can be used to efficiently store data types of any kind and number. For more information see Class CL_BSP_SERVER_SIDE_COOKIE as well as Data Persistency With Server-Side Cookies. Application-Specific DB Table for Temporary Data Storage
The application provides a database table specially designed to meet the specific requirements of the data to be saved. Unlike server-side cookies appropriate typed tables can be used here. These tables can provide for better performance than the generic solution. However, this solution involves considerable application programming (in particular, release of the database entry). The session ID can be used to identify an entry and can be accessed through the programming interface IF_BSP_RUNTIME. See also: Stateful BSP Applications Session Cookie Hybrid Forms Setting Stateful or Stateless Stateful or Stateless Programming?
Server-side cookies are persistent data, similar to the usual client-side cookies. Whereas the size of cookies on the client is restricted to four kilobytes per cookie, 300 cookies in total, and 30 per server or domain, server-side cookies do not have any size or quantity restrictions.
Server-side cookies consist of large datasets that are customized and stored on the server. They are not transferred between client and server.
Functions
In the specified event handlers you use the following ABAP expressions and class methods: OnManipulation: o o export (required page + controller + page attributes) to buffer XSTRING. CL_BSP_SERVER_SIDE_COOKIE->method for buffer(XSTRING).
OnRequest: o o CL_BSP_SERVER_SIDE_COOKIE->method for retrieval(XSTRING). import (required page + controller + page attributes) from buffer XSTRING.
The steps listed here are explained in more detail in the example below.
Example
In the following example you can see how, in a BSP, simple ABAP statements are used to group the page parameters (strings) using export in one object. The cookie is then stored with method SET_SERVER_COOKIE of class CL_BSP_SERVER_SIDE_COOKIE. Similarly the cookie can be fetched again with GET_SERVER_COOKIE and returned with import.
Page Attributes
This example contains some important page attributes that are to be defined as persistent. The list of page attributes looks like: Page Attributes Attribute Name LAST_STRING_ADDED NEXT_STRING STRINGS x Auto Typing Type type type type Reference Type STRING STRING STRING_TABLE Description Last string added by user Next string Table of strings
Not all page attributes should be persistent- only the strings added by users. They are displayed in a table on the interface. Therefore, in this BSP application only the strings LAST_STRING_ADDED and STRINGS are to be made persistent.
Event Handler
In this BSP application the following event handlers are important:
OnRequest This event handler is always triggered with inbound requests to restore the persistent data.
OnManipulation This is the last event handler before the response is sent. In this event handler the new values of the page attributes are stored in the form of server-side cookies.
OnManipulation is described first of all to explain the storage concept. OnManipulation In this event handler the values of specific page attributes are saved in the server-side cookie. Both parameters are saved on the server and then combined in one object. The user details are written to the page data using the ABAP statement export.
The export syntax is: export object1 from F ... Objectn from F to data buffer F. A data cluster is stored in data buffer f, which must be of type XSTRING. All page attributes that are relevant here are described in a byte sequence of variable length (XSTRING).
In this BSP we use the following code to receive XSTRING: data: PAGE_DATA type XSTRING. data: NAME type STRING.
export LAST_STRING_ADDED from LAST_STRING_ADDED STRINGS from STRINGS to data buffer PAGE_DATA.
Next we have to make the server-side cookie XSTRING persistent: NAME = SY-UNAME.
call method CL_BSP_SERVER_SIDE_COOKIE=>SET_SERVER_COOKIE exporting NAME = 'my_page_data' APPLICATION_NAME = RUNTIME->APPLICATION_NAME APPLICATION_NAMESPACE = RUNTIME -> APPLICATION_NAMESPACE USERNAME = NAME SESSION_ID = 'same_for_all' DATA_NAME = 'page_data' DATA_VALUE = PAGE_DATA EXPIRY_TIME_REL = 3600 . The export parameters mean: Parameters NAME APPLICATION_NAME APPLICATION_NAMESPACE USERNAME SESSION_ID DATA_NAME DATA_VALUE EXPIRY_TIME_REL Details of relative expiry time. Name and value of the data; these parameters must match. Meaning Any name can be chosen for the cookie Parameters which refer to the cookie and uniquely identify it. These are the name of the BSP application, the namespace of the BSP application, the user name and the session ID.
OnRequest
In this event handler the internal data structures of the requests are restored. The persistent page attributes are returned by the server-side cookie. So there are many parallels with the event handler OnManipulation. The server-side cookie is fetched by calling method GET_SERVER_COOKIE of class CL_BSP_SERVER_SIDE_COOKIE. The meaning of the parameters is essentially the same as for the parameters for the event handler OnManipulation (see above); only that here DATA_VALUE is a changing parameter. data: PAGE_DATA type XSTRING. data: NAME type STRING.
* User administration can, for example, use the ABAP system name NAME = SY-UNAME.
* The server-side cookie is fetched call method CL_BSP_SERVER_SIDE_COOKIE=>GET_SERVER_COOKIE exporting NAME = 'my_page_data' APPLICATION_NAME = RUNTIME->APPLICATION_NAME APPLICATION_NAMESPACE = RUNTIME -> APPLICATION_NAMESPACE USERNAME = NAME SESSION_ID = 'same_for_all' DATA_NAME = 'page_data' CHANGING DATA_VALUE = PAGE_DATA .
Provided that the data values do actually have values and therefore are not empty, the persistent page attributes are now restored by the server-side cookie. This is implemented by the ABAP statement import.
The syntax of import is: import Object1 = F ... Objectn = F from data buffer F. The data object (or several data objects) are imported from the specified data buffer F, which must be of type XSTRING. All data that has been stored using export ... to data buffer (see above) in the data buffer F and listed here, is imported. The system checks that the structure for export and import corresponds. In our example the call to restore the persistent cookies is: if PAGE_DATA is not initial. import LAST_STRING_ADDED = LAST_STRING_ADDED STRINGS = STRINGS from data buffer PAGE_DATA. endif.
See also:
You will find this example in the system in BSP application it00 (package SBSP_TEST) on page misc_page_persistence.htm.
Hybrid Forms
Realistically, the situation often arises in applications where neither one or the other model is the most suitable at all times. A typical example of this would be the online store, where browsing and navigating through the product catalog can very well be done in stateless mode, but where the actual ordering operation including first-time registration is, for technical reasons, very often realized in stateful mode. These scenarios are handled by switching the mode can be switched between stateful and stateless at runtime. See also: Stateful BSP Applications Stateless BSP Applications Stateful or Stateless Programming?
You can define a BSP application as stateful by selecting the BSP application characteristic Stateful. If the checkbox is deactivated, the BSP application is working in stateless mode.
As described in Stateless and Stateful Model, the underlying framework supports both stateful (user context in SAP System is maintained) and stateless (user context is terminated and regenerated for every request) modes. This process is represented in the following graphic:
1. 2. 3. 4. 5. 6. 7.
The first user enters the shop. The second user enters the shop. User 1 puts a book in his or her shopping basket. The third user enters the shop. User 3 puts a book in his or her shopping basket. User 1 places his or her order. User 2 performs an action.
The numbers indicate which user performs each action. The time progression clarifies the sequence of events.
You do not have to use all event handlers, for example a BSP can consist of just the layout, or it only contains the layout, OnInitialization and OnInputProcessing. Since event handler OnDestroy is used infrequently, it is irrelevant here. The following cases should be distinguished: stateless BSPs stateful BSPs
See also:
Interface IF_BSP_PAGE
Stateless
In the stateless case, the context is created each time that a request is received. The context is always destroyed when the response is sent. For the BSP runtime stateless means: runtime->keep_context = 0 When creating the output of a page, processing is the same as described in the following graphic. Output of a BSP (Stateless)
When creating the input for a page, processing is the same as described in the following graphic. Input for a BSP (Stateless)
With stateless BSPs (the default is stateless), the navigation can be executed either on the same page or on other pages.
Stateful
In the stateful case, the context is held by gone request to the next. For the BSP runtime stateful means: runtime->keep_context = 1
When creating the output of a page, processing is the same as described in the following graphic. Output of a BSP (Stateful)
When creating the input for a page, processing is the same as described in the following graphic. Input for a BSP (Stateful)
With stateful BSPs, there can be three different variants of lifetime: Up to the page change (lifetime_page) The page is destroyed if a different page is used. For the duration of the request (lifetime_request) The page is destroyed after each individual request, that is, is only available for the duration of each request. For the duration of the session (lifetime_session) The page is destroyed at the end of the session.
Examples
BSP only with Layout BSP with Layout and Initialization BSPs with Layout, Initialization and Navigation BSPs with Layout, Initialization and Input Processing
In the Web Application Builder, the layout of this BSP looks as follows: <%@page language="abap"%> <html> <body> <center> <% do 5 times. %> <font size=<%=sy-index%>> Hello World! <br> </font> <% enddo. %> </center> </body> </html> See also: tutorial_1 in packet SBOOKSHOP or First Steps with the Business Server Pages
Processing Process
The individual steps that are followed when processing this BSP are as follows: The user calls a BSP application in the browser or enters an appropriate URL. An HTTP-GET request is sent to the BSP runtime.
The BSP runtime determines the suitable BSP application and the BSP that is called. Since the BSP only consists of the layout, the page layout that is established there is determined and the scripting code is processed. The BSP runtime then generates a suitable response. and sends it to the browser that displays the BSP.
<tr> <td><%= wbook-title %></td> <td><%= wbook-publisher %></td> <td><%= wbook-ISBN %></td> </tr> <% endloop. %> </table> </body> </html> OnInitialization select * from bsbook into table books where publyear = '2000'. Page Attributes Attribute Name books automatic Typing Type TYPE Reference Type BOOK_TAB Description Booklist
Processing Process
The individual steps that are followed when processing this BSP are as follows: The user calls a BSP application in the browser or enters an appropriate URL. An HTTP-GET request is sent to the BSP runtime. The BSP runtime determines the suitable BSP application and the BSP that is called. In the BSP, data is retrieved using OnInitialization. Table BSBOOK is read for those book entries that were made in the year 2000. The scripting code is processed in the layout and the page is rendered: An HTML table is output and filled with content. The BSP runtime then generates a suitable response and sends it to the browser that displays the BSP.
This example can be enhanced by adding a second BSP with navigation: BSP Application with Layout and Initialization
</form> </body> </html> Layout of page2.htm <%@page language="abap"%> <html> <body> <h2> Book list </h2> <table border=1> <tr> <th>Title</th> <th>Publisher</th> <th>ISBN</th> </tr> <% data: wbook like line of books. loop at books into wbook. %> <tr> <td><%= wbook-title %></td> <td><%= wbook-publisher %></td> <td><%= wbook-ISBN %></td> </tr> <% endloop. %> </table> </body>
select * from bsbook into table books where publyear = year. Page Attribute of page2.htm Attribute Name books automatic Typing Type TYPE Reference Type BOOK_TAB Description Booklist
Processing Process
The individual steps that are followed when processing this BSP are as follows: The user calls a BSP application in the browser or enters an appropriate URL. An HTTP-GET request is sent to the BSP runtime. The BSP runtime determines the suitable BSP application and the BSP that is called: startpage.htm. The layout is assessed, since this page only has layout. The BSP runtime generates the page and sends it to be displayed at the browser. In the pulldown menu, the user selects the required year of publication and selects the pushbutton. An HTTP-POST request is now sent to the BSP runtime. This POST request requests a different page, page2.htm. Event handler OnInitialization is assessed by this second page. Table BSBOOK is read for those book entries that were published in the year specified by the user. The scripting code is processed in the layout and the page is rendered: An HTML table is output and filled with content. The BSP runtime then generates a suitable response and sends it to the browser that displays the BSP.
Overview
These BSPs are as follows in the Web Application Builder: Layout of select.htm <%@ page language="abap" %> <html> <body> <h2> Select CDs or Books! </h2> <form method="post" > <select name="sel_category"> <option value="0001"> Books <option value="0002"> CDs </select> <input type="submit" name="OnInputProcessing(select)" value="Select"> </form> </body> </html>
OnInputProcessing of select.htm * event handler for checking and processing user input and
case event_id.
when 'select'.
if cat = '0001'. navigation->goto_page( 'books.htm' ). elseif cat = '0002'. navigation->goto_page( 'cds.htm' ). endif.
<table border=1> <tr> <th></th> <th>Title</th> <th>Author</th> <th>Publisher</th> <th>ISBN</th> </tr> <% data: wbook like line of books. loop at books into wbook. %> <tr> <td><img src="../../bookstore2/<%=wbook-category%><%=wbook-id %>_s.jpg"></td> <td><%= wbook-title %></td> <td><%= wbook-author %></td> <td><%= wbook-publisher %></td> <td><%= wbook-id %></td> </tr> <% endloop. %> </table>
</body> </html> OnInitialization of books.htm select * from bsparticle into table books where category = '0001'.cds
Page Attribute of books.htm Attribute Name books Layout of cds.htm <%@ page language="abap" %> <html> <body> automatic Typing Type TYPE Reference Type TARTICLE Description list of books
<table border=1> <tr> <th></th> <th>Title</th> <th>by</th> <th>Label</th> <th>number</th> </tr> <% data: wcd like line of cds. loop at cds into wcd. %> <tr> <td><img src="../../bookstore2/<%=wcd-category%><%=wcd-id%>_s.jpg" border=1></td> <td><%= wcd-title %></td> <td><%= wcd-author %></td>
<td><%= wcd-publisher %></td> <td><%= wcd-author %></td> </tr> <% endloop. %> </table>
</body> </html> OnInitialization of cds.htm select * from bsparticle into table cds where category = '0002'. Page Attribute of cds.htm Attribute Name cds automatic Typing Type TYPE Reference Type TARTICLE Description list of cds
Caching BSPs
Use
With the Internet Server Cache (see also ICM Server-Cache) you can considerably increase the performance and scalability of your BSP application. The ICM server cache provides a dynamic and active content caching technology, resulting in the following advantages for developing BSPs: The resources required for creating BSPs are reduced You do not have to repeatedly execute BSPs that are frequently requested
Functions
The features and the architecture of the ICM server cache are described in Cache. You have the following options to control BSP caching: In the Web Application Builder (Transaction SE80), you can set the following properties for caching on the Properties tab page: o o o Expiry date for caching in the Internet server cache Expiry date for caching in the browser (client-side) Flag whether page caching should be browser-dependent Internet Server
In your BSP application you can control the behavior of the ICM server cache using response object method calls.
Activities
Setting Caching Properties in the Web Application Builder
You can set the caching properties for the page on the Properties tab page of a BSP:
For both the browser cache and the ICM server cache you can determine how long the page should be held in the cache. If you do not enter any data, this means that the cache is not used for the page. Set flag Browser Dependent if you want the ICM server cache to fetch the page from the cache only if the request comes from the same browser type. If you do not set the flag, note that all of the elements used by the page must not be browser-dependent.
Note that when you use the browser cache, the client cannot tell when a page has changed. If the URL is the same, it always returns the same page from the cache until the expiry date has passed. If you use the ICM server cache, by using the invalidation methods you can ensure that the page stored in the cache is upto-date.
Use appropriate automatic expiry times. For example, a banner displaying stock market tickers is updated every n minutes, whilst a product catalog should be updated only every n days or weeks. You refresh (invalidate) objects asynchronously using the methods of class CL_HTTP_SERVER (see also IF_HTTP_SERVER): You can use method SERVER_CACHE_INVALIDATE() to invalidate an individual object that can be identified by the following data: Complete name, that is, URI path, form fields and BSP application context Prefix of the name (hierarchical wildcards) E-tag, that is, the entity tag and the unique ID that was assigned at the time of creation You can use method SERVER_CACHE_INVALIDATE_LIST() to invalidate a list of objects (internal tables).
The system automatically forwards this data to other application servers, thus ensuring cache integrity.
You should avoid too frequent invalidations, so that system-wide transfers to other application servers are avoided. See also:
Example
You can find a simple example in the system in BSP application TUTORIAL_4, BSP results.htm in the event handler OnInitialization: * cache result page in case Plattner's books are searched
if 'PLATTNER' cp author. response->server_cache_expire_abs( expires_abs_time = '180000' browser_dependent = 'X' ). endif. The result list for querying the books from Hasso Plattner is only stored in the cache because you know that these are requested especially often. The cache entry is invalidated every night at 18.00. This function may be useful for things that must be recalculated every day (such as current prices). See also: Further Developing the Online Bookshop
Page Layout
Prerequisites
Before you can choose from the various options available for the layout of your BSP application, you need some knowledge of following: Page-based programming model HTML Work method of graphical Web design tools
The easiest option is to design a page with pure HTML. You either use the text editor in the BSP development environment (see also the documentation on the Web Application Builder) and design the page textually. This presupposes a good knowledge of HTML and it is usually a lengthy process. The advantage of it is: script can be added immediately to the correct parts of the page. Moreover, the Web Application Builder in the development environment has a preview function so that you can check the static layout of a page at any time.
From SAP Web AS 6.20 you can use BSP extensions as an ideal mechanism for easily integrating interface elements such as tableviews, buttons, input fields or charts into your BSPs. In particular, you can use the BSP extension HTML Business (HTMLB) for BSP applications. A more elegant solution is to design a page with a design tool such as AdobeGoLive5.0, Dreamweaver 4.0, Frontpage and so on. The SAP Web Application Server lets you check in Web pages created with such tools and directly edit such pages managed on the server. This is done by means of the WebDAV access of the SAP Web Application Server (see also Using External Tools). WebDAV is supported by the above-mentioned tools (Frontpage together with the WebFolders). After check-in, you can add script to the pages. If the pages checked in to the server are edited again using the tool, you should flag the server-side script parts so that a designer can recognize them as such. Thus, developers of Web applications using the SAP Web Application Server are subject to no design restrictions whatever.
Accessibility
Use
The Accessibility Guidelines (Section 508) established in many countries are intended to enable partially sighted users to use software interfaces. In general, all texts on an interface are read out using an external tool, provided that all screen elements, such as symbols, pushbuttons and so on have been assigned quick infos. In the context of BSP applications, you can use BSP extensions HTMLB,XHTMLB and PHTMLB to structure interfaces with the Tag Browser.
In particular, you should think about accessibility with BSP applications that contain tables, tabstrips and tree controls. These three types of interface elements are not always easy for Screen Reader to read out.
Integration
When developing BSP applications, you can specify whether or not you want to follow the accessibility rules.
The accessibility specification is integrated in the BSP runtime: 6. ... 17. 1. Specify the accessibility in the URL or use the corresponding parameter in the logon application:
...?sap-accessibility=X Defining the accessibility is also part of the new system logon for SAP Web AS 6.40 SP2.
18.
This option sets an internal flag in the BSP runtime, which can be used by BSP applications to output additional information in the HTML output stream, so that screen reader programs can better present the visual information on the screen. BSP extensions HTMLB, XHTMLB undPHTMLB use this flag to change its rendering behavior. These parameters are not used after the logon.
Note that setting this indicator does not make any statement about that applications accessibility. The indicator merely indicates that additional help is required for that application.