hi,
go to spro>>> Collaboration projects>>>global enhacment to project element>>>>shou additional tab page in cproject..you can display your own tab pages for project elements or show them as an additional initial view. You can restrict the new tab page to a single project type or make it available for all project types.
follow the steps:
procedure is given.
Requirements
You have created your own WebDynpro components in which you specified the content of the tab pages. SAP supplies the DPR_CUST_EXT_INTF_DEMO component as a demo implementation.
You have implemented the WebDynpro interface DPR_CUST_EXT_INTF that supplies your WebDynpro component with events to which the component can react. The interface defines the startup plug, the methods for data input, and the WebDynpro events for information output:
Startup Plug
The WebDynpro window of your component is called WI_CUSTOMER_VIEW and it defines an inbound plug of the type Startup. It has an input parameter called CUST_INPUT_VALUES of the type DPR_TS_CUST_EXT_TABC_INPUT. It transfers the following values:
OBJECT_TYPE: CGPL object type, for example, DPO for project definition, PPO for phase, and so on.
GUID: Internal ID of the project element
ROOT_GUID: Internal ID of the corresponding main object (usually the project definition)
ROOT_OBJECT_TYPE: CGPL object type of the corresponding main object (usually the project definition, DPO)
ELEM_LEVEL: Information about where your WebDynpro component is assembled (STR=structure level, DET=detail level)
CHANGE_MODE: 0=display, 1=change
LANGUAGE: Language of the current data in SAP-1-char format
LANGUAGE_ISO: Language of the current data in ISO format
DATA1: Customer-defined data field that does not map via the relevant CI structure but is managed by means of a demo subsystem (see class CL_DPR_DEMO_SUBSYSTEM). SAP recommends that you only use this type of customer-defined data management if, by way of an exception, it is not possible to use the CI structures.
Use these values to set up the display for your components.
Important Component Controller Methods
ON_AFTER_SAVE
Time of call: The user selected Save in the application and the data has been updated.
Use this method to discard buffered UI data from your component where necessary if it is no longer valid after the Save action.
In this demo implementation, the UI does not buffer any of its own data, so no action is required here.
This method is also called if the changed data was saved before the switch from 'Change' to 'Display'.
If you want to update the customer-defined data in your component, the following rules apply:
If the customer-defined data is stored as fields in the relevant CI structure of the object, the data is updated automatically. SAP recommends this procedure.
If you do not use the CI structures and the customer-defined data is totally independent of the object model in cProjects and the update can also take place independently of cProjects, you can enter the data straight in the customer-defined table or change or delete it. Do not use a COMMIT WORK in the current LUW. If you have to use one, you have to set up your own application LUW (for example, via 'Submit Report xy and Return'), which can be used to transfer the data via the memory and in which a COMMIT WORK can take place afterwards.
If you do not use the CI structures and the customer-defined data has to be updated in the cProjects context, you should use a customer-specific subsystem: see class CL_DPR_DEMO_SUBSYSTEM. The subsystem takes control when you save the current view. However, you have to manage the data transfer between the UI and the subsystem yourself, see the methods START and ON_REPORT_CHANGES for the field DATA1.
SAP recommends that you only use this alternative if, by way of an exception, it is not possible to use the CI structures.
For details about the system response when saving the current view, see Notes below.
ON_CLEANUP
Time of call: The user exited the current view or chose Home.
Use this method to discard buffered UI data from your component where necessary if it is no longer valid after the Exit current view orHome action.
In this demo implementation, the UI does not buffer any of its own data so no action is required here.
If you want to invalidate the customer-defined data in your component, the following rules apply:
If the customer-defined data is stored as fields in the relevant CI structure of the object, the data is discarded automatically. SAP recommends this procedure.
If you do not use the CI structures and the customer-defined data is totally independent of the object model in cProjects and the update can also take place independently of cProjects, you can invalidate the customer-defined data here.
If you do not use the CI structures and the customer-defined data has to be discarded in the cProjects context, you should use a customer-specific subsystem, see class CL_DPR_DEMO_SUBSYSTEM. The subsystem takes control when you exit the current view.
SAP recommends that you use this alternative only if, by way of an exception, it is not possible to use CI structures.
For details about the system response when exiting the current view, see Notes below.
ON_REPORT_CHANGES
Time of call: The UI triggered an event somewhere in the application.
You use this method to determine and process changes made to your own (or a third-party) component. If the customer-defined data is updated via the subsystem, you can transfer the determined data of your component to the buffer of the subsystem here. See the implementation of DPR_CUST_EXT_INTF_DEMO.
Notes:
This method is called each time the user carries out a UI event, for example, when the user exits the current view, although it is not called automatically after an action such as 'Save'. However, since the context change service is activated for the component using the method WDDOINIT (see below), ON_REPORT_CHANGES is also called for all other UI events that follow, outside your own component.
In the existing demo implementation, the data transfer is also explicitly triggered (for demonstration purposes) if the 'Mark as Changed' button is pressed (see the event onAction = CHANGE of button, method ONACTIONCHANGE in the view VI_MAIN for more details).
Alternatively, you can use the onEnter event in the VI_MAIN view for each customer-defined field to process the customer-defined data in the same way as for ONACTIONCHANGE. This option is not used in this demo implementation.
You can use the singleton of the class CL_DPR_SESSION_STATE to obtain information about the current UI status. This enables you, for example, to use the method GET_DETAILVIEW to check whether your own component is currently active. Note that internally, the system only uses the first three characters to identify the tab, in this case 'CUS' and not 'CUSTOMER'.
Take the ON_UPDATE method, which always occurs together with ON_REPORT_CHANGES, into account too.
ON_SET_CHANGE_MODE (importing new_mode type i)
Time of call: The user triggered the switch between display and change mode. The event is only used if the switch was successful.
If new_mode = 0, the system switches to display mode. If new_mode = 1, the system switches to change mode.
In this demo implementation, the context element READONLY is set accordingly in the node UI.
ON_SET_DATA_LANGUAGE (importing new_language type sylangu, new_language_iso type laiso)
Time of call: The user changed the text language.
The new text language is made available both in SAP's own single-figure format as well as in ISO format.
Use this method if you have to manage language-dependent data.
No actions of this kind are required on the UI in this demo implementation.
ON_UPDATE
Time of call: The UI triggered an event somewhere in the application. This could be for your own component. First of all, the ON_REPORT_CHANGES event was sent (see above).
You use this method to update the format in your component so that changes to cProjects data appear straight away or to update dependent values (for example, headings or inspection texts) for changed, customer-defined data.
No actions of this kind are necessary on the UI in this demo implementation.
SET_CHANGED
Time of call: Handles the action CHANGE (ONACTIONCHANGE method) from the view and triggers the CHANGES_OCCURRED event (see below).
In this demo implementation, none of the methods from the window, view, or component controller register on this event.
START
Time of call: This method is called in the inbound plug DEFAULT from the window WI_CUSTOMER_VIEW.
The context attributes are set in the view here. In addition, the customer-defined non-CI field 'CustomerDate1' is initialized for each object as required.
WDDOINIT
Time of call: Initialization of WD component.
The component activates the context change service to be able to get the context changes on the UI from the WD framework when using ON_REPORT_CHANGES.
Important Events in the Component Controller
You can use the following events to communicate with the rest of the application:
CHANGES_OCCURRED
Your WebDynpro component indicates to the other components that a change has been made to the data and that this change has not been updated. If the user wants to exit the current view in cProjects or return to the home page, the system displays a popup to check whether the user wants to save the data. If the user does not want to save, the system calls the ON_CLEANUP method in the WebDynpro component. If the user does want to save, the system calls the ON_AFTER_SAVE method so that the component can react accordingly.
SEND_EVENTS
Notifies the rest of the application that a UI event (for example, clicking a button) has taken place in your component and could cause the data to be updated.
Note: Your own methods ON_REPORT_CHANGES and ON_UPDATE are also called if your component triggers the SEND_EVENTS event.
Important Method of the View VI_MAIN
ONACTIONCHANGE
The method is the event handler for CHANGE and informs both the component controller (method SET_CHANGED, see above) and via cProjects' own event manager. This causes ON_REPORT_CHANGES and ON_UPDATE to be called in the component controller of your own and all other registered ('listening') components.
Important Actions of the View VI_MAIN
CHANGE
Is used by the ONACTIONCHANGE event handler and is linked to the onAction event of the 'Mark as Changed' button. As mentioned above, it would also be conceivable to define an ENTER action for an ONACTIONENTER event handler and link it to the 'CustomerDate1' field.
Notes
1. System actions when the user saves the current view.
a) The methods ON_REPORT_CHANGES and ON_UPDATE are called for the customer-specific component.
b) All cProjects data is searched for changes. The method IF_DPR_APPL_PLUG_IN_SUBSYSTEM~HAS_CHANGES is called for this purpose for all SAP and customer-specific subsystems.
c) If at least one change exists, all changed cProjects data is checked and formatted for update if necessary. The method IF_DPR_APPL_PLUG_IN_SUBSYSTEM~PREPARE_TO_SAVE is called for this purpose for all SAP and customer-specific subsystems.
d) If all checks ran correctly, all changed cProjects data is transferred to the update by calling the IN UPDATE TASK function module. The method IF_DPR_APPL_PLUG_IN_SUBSYSTEM~SAVE is called for this purpose for all SAP and customer-specific subsystems.
e) The back-end carries out a COMMIT WORK and the update LUW is started.
f) Once the update LUW has finished, all changed cProjects data is reset, that is, the changes that have accumulated since the user last saved, are initialized. The method IF_DPR_APPL_PLUG_IN_SUBSYSTEM~INITIALIZE_AFTER_SAVE is called for this purpose for all SAP and customer-specific subsystems.
g) The method ON_AFTER_SAVE is called for the customer-specific component.
h) The user is still in the application.
2. System actions when the user exits the current view
a) The methods ON_REPORT_CHANGES and ON_UPDATE are called for the customer-specific component.
b) All cProjects data is searched for changes. The method IF_DPR_APPL_PLUG_IN_SUBSYSTEM~HAS_CHANGES is called for this purpose for all SAP and customer-specific subsystems.
c) If at least one change exists, the confirmation prompt is processed. Afterwards, the action is either canceled, the update is started (1c) ff), or the system exits the application (2d) ff).
d) All changed cProjects data is reset, that is, the changes that have accumulated since the user last saved, are initialized. The method IF_DPR_APPL_PLUG_IN_SUBSYSTEM~FREE is called for this purpose for all SAP and customer-specific subsystems.
e) The method ON_CLEANUP is called for the customer-specific component.
f) The user is on the application homepage.
award points for useful answer
thanks
amit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.