Click here to load reader
Upload
sktsuresh
View
218
Download
0
Embed Size (px)
Citation preview
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 1/10
1
Table of Contents
A. WebDynpro Programming Standards and Guidelines
1. Programming model
1.1 Naming Conventions ------------------------------------------------------------------- 2
1.2 WebDynpro Controllers ---------------------------------------------------------------- 3
1.3 Development Component (DC) based development --------------------------- 4
1.4 Context ------------------------------------------------------------------------------------- 4
1.5 WebDynpro Runtime API -------------------------------------------------------------- 5
2. User Interface ------------------------------------------------------------------------------------ 5
3. WebDynpro Colour scheme ----------------------------------------------------------------- 6
4. Performance Monitoring ---------------------------------------------------------------------- 7
5. General Tips ------------------------------------------------------------------------------------- 7
B. Portal Naming Guidelines ----------------------------------------------------------------- 8
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 2/10
2
WebDynpro Programming Standards and Guidelines
1. Programming model
1.1 Naming Conventions
General rules for Naming: Since the WebDynpro standards are based on the Java standards, the naming rules that applyfor Java, also apply for WebDynpro.
• Each coding entity name should start with an uppercase letter, and try to use assimple and concise terminology as possible.
• Each coding entity can consist of one or more nouns with first letter Capitalized.• Context name should use only the characters A..Z .a..z, 0..9 or _ , Use the digits only
form the second position• Application Name should reflect the business process name followed by App. The
initial letter should start with Upper case. Eg PackageSummary• Component name should start with uppercase and with suffix Comp or Component
(but avoid the suffix ‘_comp’).•
All Package names should be in lower case.• Methods should be verbs, in mixed case with the first letter lowercase, with the first
letter of each internal word capitalized Eg: addIntegers()• Variable name should be in upper case separated by underscore• Statements like for, while, if, switch, try catch follow the coding convention :
- Only one variable should be declared per line.- Local variables should be initialized when they are declared.- Variables should be declared only at the beginning of the block and same
variable name is not used in inner block.
WebDynpro Entity Rule for Naming Example
DevelopmentComponent Prefix <module name>_ Grm_UpiSearch
Application Suffix App DonorSearchApp
Component Suffix Comp (but no ‘_comp’) DonorSearchComp
Custom Controller Suffix Cust OVSCust
Model Suffix Model CustomerModel
Inbound Plug Suffix In DisplayDetailsIn
Outbound Plug Suffix Out CompletedOrderOut
Component InterfaceDefinition Prefix I combined with suffix
Comp (again no ‘_comp’)IDataProviderComp
Component Usage name of component +purpose of usage SearchCompDetails
View Suffix View MainView
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 3/10
3
Viewset Suffix ViewSet ActivitiesViewSet
Window Window name, no suffix Customers
Context
Nodes (cardinality x..1) singular BookingNodes (cardinality x..n) plural Orders
Supply functions prefix supply supplyDetails
Calculated attributes suffix Calc FullNameCalc
Used WebDynproComponents
UC_<name> UC_TFSearch
Activities act_<module>_<Briefdescription>_<date, time> @Onsite/Offshore
act_GRM_Changingexecution labels _ 10Sep 07 6:15 pm @Onsite
Packages wb.org.<module>.<name> wb.org.grm.upisearch
Simple Type ST_<name> ST_UpiField
1.2 WebDynpro Controllers
Any re-usable code used across different views of a DC should be written in the ComponentController or a Custom Controller. The code written in the View Controller should be restricted tothose related with the UI. No application logic should be written in an Interface Controller; instead
it should be used ONLY as a delegator.
• Don’t implement monolithic component controllers:Component controllers are automatically launched at component creation time (normallyon application startup). Therefore, component controllers containing extensive codingand declarations in their wdDoInit() methods will require a longer creation time. Only addcoding to a controller’s wdDoinit() method if the results of its execution are actuallyrequired at the start of the controller’s lifecycle.
• Use additional custom controllers to keep the component controller as efficient aspossible. Custom controllers should be used when you have identified a specific reusecase or when a distinct unit of functionality can be identified and separated from the maincomponent controller.
• Custom controllers are created on-demand . Therefore, moving functionality into a customcontroller will delay its initialization from the start of the component controller’s lifecycle tothe point in time when it is actually needed. This can reduce the time taken for acomponent to start.
• Optimize the View Controller’s lifespan- Use lifespan == framework controlled by default- Set lifespan == when_visible to improve memory performance.
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 4/10
4
Example : views that both require a lot of memory (for data and layout) and are(usually) used once and then not needed anymore.
1.3 Development Component (DC) based development
• Optimize the development performance with the best deployment granularity :o Keep the development components (WebDynpro DCs) as slim as possible; but
do not make WebDynpro components too small the application might not performwell and the resulting ‘sea’ of components might reduce maintainability
o Do not make WebDynpro components too large, reusability would be reducedo Design DCs with maximum reuse in mind
• Split your WebDynpro Application into separate WebDynpro DCs :o Create a single root component which embeds and layouts separate UI
components .o Create a model component which is created by the root component and
referenced by the UI components (use component instance in referencing mode).o Create faceless (without any UI/View) WebDynpro components for exposing
libraries, images or services to other WebDynpro components.o All URLs (including server dependent ones) should be managed through a
configuration file. A separate DC should hold the configuration file and exposemethods for reading the entries.
o Place Models and Dictionaries in separate DCs. Centralize all dictionary typeswithin a WebDynpro application
• Keep UI components and faceless components independent of each other to be able toexchange the other part, if necessary
• Use the component interface controller as a delegator only. Do not implement applicationlogic within public methods of the component interface controller. Only delegate to thecorresponding methods of the component or custom controller (starting from NW2004sthe Interface controller does not provide an option to write custom code)
1.4 Context• No attribute should be declared directly under the Context. Instead create a 1..1 singleton
node and the necessary attributes should be added under that.• Do not declare mapped context elements when the target context belongs to the same
WebDynpro component and when it is used for non-visual purposes only (but not for databinding). Access the target context withwdThis.wdGet<target>Controller().wdGetContext() instead.
• Prefer defining singleton child nodes to non-singleton childnodes as singleton nodesminimize the memory footprint of a controller context at runtime.
• Do not make a context node in an interface controller a mapping origin node . Instead,map the component interface controller context to another controller within the samecomponent or use external mapping (isInputElement = true). So in the interface controllercontext:- No attributes would be directly under context- Any node accepting data from an outside DC would have the property
‘isInputElement’ set to true.- A node which has ‘isInputElement’ set to false should be mapped to the component
controller or a Custom controller.
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 5/10
5
1.5 WebDynpro Runtime API:The current WebDynpro API documentation for NW2004 can be accessed at the following URL:
http://help.sap.com/javadocs/NW04/current/wd/index.html
Only WebDynpro (WD) interfaces that begin with IWD and classes that begin with WD are part ofthe published WebDynpro API. Hence only use interfaces that start with IWD and classes thatstart with WD for the following reasons:
• Source-Code CompatibilityOnly for those types starting with IWD or WD the WebDynpro runtime developersguarantee that they will remain source-code compatible, meaning that older WebDynproapplications can run against a newer WebDynpro runtime after a rebuild. All otherclasses and interfaces are private and they do not belong to the API.
• Changes in Future ReleasesFurthermore, the internal interfaces and classes can and will change their semantics oreven disappear from support package to support package or release to release withoutfurther notice. There is no commitment to backward compatibility for these types in anyway. It may happen at any point in time, without prior warning, that the names, packagesor behavior of the non-public classes change. In addition, applications might no longer beable to access any other WebDynpro classes or interfaces in future releases at all!
Never ever hijack internal WebDynpro classes and interfaces
The prefixes wd, IWD or WD should not be used in application coding. The various forms of the“wd” prefix are used by the WebDynpro Tools during the generation of internal coding entities.Therefore it is very likely that a naming conflict would occur if user-defined names start with oneof the above prefixes.
2. User Interface
The UI elements should have a defined hierarchy of containers. No more than one UI elementshould be preferably added directly under the Root container. Instead have a meaningfulhierarchy of containers (Transparent Containers/Groups as applicable) and the remaining UIelements should be added under them.
• The auto-generated IDs of the UI elements should be preferably replaced bymeaningful Names. Eg: UPI_Container, Submit_Button etc.
• The hook method wdDoModifyView() should be used only for the following types ofcode:
- Adding parameters to Action Event handlers- Responding to runtime changes in the context structure
The hook method wdDoModifyView() should not be used for the following types of code:- Altering UI property values – use context binding instead- Changing the context in any way!- Creating or changing modifiable simple types- Storing UI element object references that you then attempt to- access outside this method
• The properties of dynamically created UI elements should be controlled throughcontext binding.
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 6/10
6
• Don’t store static references to UI elements in the View Controller• Don’t attempt to refer to static UI element references in any event handler or supply
function • Use IWDAction.setEnabled() to disable UI elements. Don’t enable/disable those UI
elements which are bound to an action, by binding their enabled property to acontext attribute of type boolean. Enable/disable the corresponding action objects
instead.
3. WebDynpro Colour scheme
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 7/10
7
4. Performance Monitoring
In order to determine the performance breakdown between the client and the server, add theparameter ‘sap-wdshowInfo’ to the URL and set it to any non-null value (e.g. “X” or “true”).Thebrowser then displays the following time values [ms] in the status line
Browser- parsing: time for parsing HTML- HTML: time for rendering HTML- JSBefore: time for processing JavaScript code
J2EE- Server side processing time: - Time to process and dispatch an incoming request to the WebDynpro Runtime- Time needed by the WebDynpro Runtime to process the complete phase model
Backend- Length of time for accessing the backend (executing model classes)
5. General Tips
• Deleting Cached filesAny code written to open a file on the server space should also ensure that the file is
deleted after the usage. Eg: The code currently used for Download to excel, IRISattachment functionalities
• Meaningful CommentsHave proper comments wherever necessary eg: for all the method definitions, placeswhere control flows between the different DC etc.
• Release JCO connections after a RFC callWhenever an RFC call is made, make sure to release the JCO connection after the RFCexecution (applicable for stateless RFC calls).wdContext.current<RFC_Name>_InputElement().modelObject().modelInstance().disconnectIfAlive();
• Try Catch blocksMake sure that all possible exceptions are caught & a corresponding meaningfulmessage is printed before the application is deployed to the Production box.
• Common trackAny new JDI track being created should be linked to the Common Track (WB_COMMON)and the existing DCs should be used for common functionalities (Eg: UPI Search, IRISattachment), instead of creating separate copies.
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 8/10
8
Portal Naming Guidelines
Ideally a single folder ‘Worldbank’ should be added at the root level of the Content Administrationtab. Any new Portal object should be created inside a hierarchical folder structure. The folderstructure should ideally be Worldbank Æ <Project Name> Æ <Module Name> Æ <Object type
folder> Æ Object. The folders created directly under the Module to hold different Object typesshould have the name as the Object type itself. A pictorial example is given in the next page.
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 9/10
9
Worldbank
iLAP
eTF
TFP
GRM
Pages
Worksets
Roles
iViews
TFP_TTL
TFP Approver
TFP_Summary
TFP Details
TFP_Page1
TFP Page n
TFP_iView 1
TFP iView n
Folder
Projects
Modules
8/13/2019 NetWeaver Coding Standards
http://slidepdf.com/reader/full/netweaver-coding-standards 10/10