1. Integration
   1. Adobe Document Service
   2. Enterprise Portal
   3. Business Graphics Server
   4. MS Office
   5. CAF / Guided Procedures
      1. Entity Service Model
      2. Application Service Methods
      3. Integrating Web Dynpro applications with GP
   6. Visual Composer
   7. User Management Engine
2. Design Concepts
   1. Model-View-Controller
      1. Original idea
         1. Invented by Trygve Reenskaug
            1. 1978, Xerox PARC
         2. MVC was the first design pattern that explicitly separated data presentation from data processing
         3. How does the user perceive the information in the business process?
            1. What is the user's mental model?
            2. A "Model" represents the user's mental concept of the data
            3. An "Editor" manipulates the user's concept of the data I.E. the Model
            4. "Controllers" decide which view to show next and handle the business logic required to make the application function correctly
            5. Act is either generators or consumers
            6. With respect to Models, controllers are consumers
            7. With respect to Views, controllers are generators
            8. Model data is visualised through "Views"
            9. A "View" is always a consumer of data either from
            10. Another controller in the same component
            11. The client device (E.G. Keyboard, Mouse, Barcode Reader)
            12. A "Model" is always a generator of data
            13. Create software that duplicates the user's mental model
      2. SAP's alterations to the original specification
         1. Two categories of controller
            1. Non-visual
            2. Acts as a data consumer with respect to a model
            3. Acts as a data generator with respect to a visual controller
            4. Visual
            5. Always acts as a consumer of data
         2. The "Component" concept
            1. Performs a similar role to that of the Editor in the original MVC pattern
      3. Separation of data generators from data consumers
         1. Fundamental concept
         2. Use cases
            1. Separating data processing from data presentation
            2. In Web Dynpro
            3. Visual controllers
            4. Always acts as data consumers
            5. Non-visual controllers
            6. Act as data consumers with respect to models
            7. Act as data generators with respect to visual controllers
            8. UI element binding
            9. Data generator role played by the visual controller's context
            10. Data consumer role played by the UI element property
            11. Context mapping
            12. Data generator role played by the mapping origin node
            13. Data consumer role played by the mapped node
   2. SAP's design requirements
      1. Overcome the limitations of existing web development tool sets
         1. Difficult to achieve consistency of corporate look and feel
            1. SAP developed the concept of Unified Rendering
         2. Data presentation layer not sufficiently decoupled from the data processing layer
         3. Reuse is possible, but at a lower technical level, not at the business level
      2. Code reuse at a business level
      3. As much of the UI code as possible should be generated
      4. Declarative approach to defining an application's architecture
      5. Library of generic services for routine tasks
   3. Karen Holztblatt
      1. Focus Groups
         1. Grouping UI elements together in a manner that best captures the user's business requirements
         2. The term "Focus Group" is not used explicitly within Web Dynpro
            1. This concept influenced the design of View Controllers
3. Content Administrator
   1. Usage Guide
4. User Interface
   1. Separated from the data processing layer by use of the MVC design pattern
   2. Design time specification of UI elements is client agnostic
      1. No client specific scripting is written at design time
         1. No HTML, JavaScript or CSS
         2. From NetWeaver CE 7.1 onwards, JSF and Flash Islands can be used to create custom UI elements
      2. Client specific details are calculated at runtime
         1. UI element tree is defined in an abstract manner
         2. Server side rendering
5. Programming Model
   1. The Web Dynpro Component
      1. Fundamental Concepts:
         1. Building block for all applications
         2. Basic unit of reuse
         3. Basic unit of development
      2. Aggregation of individual controllers
         1. Visual Controllers
            1. Always fulfil the role of data consumers
            2. Types
            3. Interface View Controller
            4. NW 04 and NW 7.0
            5. Runtime implementation of a Window
            6. Shows only the subset of views required to form the current screen
            7. Known as a "View Assembly"
            8. Potentially changes after every server round trip
            9. Limited developer control
            10. Only navigation plugs and their implementation can be defined
            11. No access to this controller's context
            12. No standard hook methods available
            13. NW CE
            14. Defines the interface implemented by a Window Controller
            15. Window
            16. When declared, a corresponding Interface View Controller is created automatically
            17. Design time entity
            18. Navigation links between views are defined here
            19. Hard coded associations between inbound and outbound plugs
            20. Cannot be reassigned programmatically
            21. Defines the superset of all views to be displayed in the current window
            22. Manages an aggregation of views
            23. NW 04 and NW 7.0
            24. Only a design time entity
            25. No programmatic control available to the developer
            26. NW CE
            27. Has a distinct controller
            28. Programmatic control available to the developer
            29. View Controller
            30. Will only be visible if embedded into a Window
            31. Created only by explicit developer declaration
            32. Should only contain logic related to UI processing tasks
            33. Should not contain any processing related the business process
            34. Life span
            35. Framework Controlled
            36. A single instance persists for the duration of the component's life span
            37. When Visible
            38. A single instance persists only for so long as it is a member of the current View Assembly
            39. If removed from the View Assembly, the view controller instance is destroyed
            40. Manages an aggregation of UI elements
            41. View layout
            42. UI Elements
            43. Data supplied from local context by data binding
            44. Specified in a client independent manner
            45. No need to write HTML, JavaScript or CSS
            46. Window Controller (NW CE Only)
            47. A distinct controller for managing processing at the window level
            48. Can implement one or more interface view controllers
            49. Can be used to define abstract screen layouts
            50. Allows mapping definitions between actual embedded view containers and abstract view containers defined in an implemented interface view
            51. Instantiation
            52. On demand when required by the component's visual interface
            53. Automatic by the WD Framework
            54. All visual controllers are singletons with respect to the component controller acting as their parent
         2. Non-visual Controllers
            1. Instantiation
            2. All non-visual controllers are singletons with respect to the component controller acting as their parent
            3. On demand when one of their methods is called by an:
            4. Explicit call in developer written coding
            5. Implicit call within the WD Framework
            6. Automatic by the WD Framework
            7. Fulfil the role of
            8. Data consumers with respect to a model
            9. Data generators with respect to a visual controller
            10. Types
            11. Component Controller
            12. This controller is the component itself
            13. Custom Controller
            14. Created only by explicit developer declaration
            15. Interface Controller
            16. Is an independent controller in NW04 and NW7.0 versions of WD
            17. Is a true interface in NWCE version of WD
      3. Development process
         1. Coding Tasks
            1. Manual coding
            2. Always placed between the //@@begin and //@@end comment markers
            3. Implementation of the business process within the generated framework created as a result of your declarations
            4. Input validation, error handling and navigation processing across multiple components must be designed into the application from the start
            5. Errors detected before or after navigation?
            6. Before: handle in wdDoBeforeNavigation()
            7. After: handle in wdDoPostProcessing()
            8. During a round-trip, child components must report errors up to their parent before the wdDoBeforeNavigation() method is reached.
            9. Do not blur the functional boundaries between controllers acting as suppliers of data and those acting as consumers
            10. Non-visual controllers generate the data consumed by visual controllers
            11. View controllers are consumers of data supplied to them from outside their own scope
            12. #1 error made by new WD developers is to place business logic (I.E. direct interaction with model objects) into view controllers. This results in applications that are difficult and costly to maintain DON'T DO IT!
            13. View controllers handle:
            14. Reaction to user events in the UI
            15. Input validation.
            16. Invocation of business functionality found in other controllers
            17. Generated Controller Class
            18. Standard Hook Methods
            19. Interface between WD Framework and your own business logic
            20. Immutable
            21. Automatically called by the WD Framework during Phase Model processing
            22. Coding is generated based on design time declarations
            23. Typed access to the Context
            24. Method/Event Handler stubs
            25. Access to methods in other controllers
         2. Declarative Tasks
            1. All Controllers
            2. Context Definition
            3. Hierarchical storage structure for controller data
            4. Defined at:
            5. Design time by explicit declaration
            6. Runtime by explicit coding
            7. Architecture
            8. Nodes
            9. Types
            10. NW 04 and NW 7.0
            11. Model
            12. Data type defined by being bound to a model object
            13. Mutable definition
            14. Model object created by the Model Wizard during the import process
            15. Enterprise Java Bean
            16. Web Service
            17. Adaptive RFC
            18. Java Bean
            19. Value
            20. User defined data type
            21. Data type defined by structure binding
            22. Immutable definition
            23. Structure defined in Java Dictionary either by:
            24. Model Wizard
            25. Manual declaration
            26. NW CE
            27. Universal Context Node
            28. No distinction anymore between previous "Model" and "Value" node types
            29. Explanation
            30. For Java programmers: Node = Type-safe collection
            31. For ABAP programmers: Node = Internal table possibly containing deep structures
            32. Properties
            33. Cardinality
            34. Selection
            35. Defines the maximum and minimum number of elements that may be flagged as "selected"
            36. 0..1
            37. Default
            38. Up to one element may be selected
            39. 1..1
            40. One element will always be selected
            41. 0..n
            42. Any number of elements may be selected
            43. 1..n
            44. At least one element will be selected
            45. Collection
            46. Defines the maximum and minimum number of elements the context node may contain
            47. 0..1
            48. The node may contain no more than one element
            49. 1..1
            50. The node will contain exactly one element
            51. 0..n
            52. Default
            53. The node may contain any number of elements
            54. 1..n
            55. The node will contain at least one element
            56. Supply Function
            57. No
            58. The node collection must be populated by explicit coding E.G. by binding it to a model object of a suitably structured vector object
            59. Yes
            60. The coding for the supply function must be written by the developer at design time
            61. Called every time the node is accessed if the contents is considered to be "dirty" E.G. if the node has never been populated before if the node has been invalidated or if the lead selection in the parent node has changed
            62. Defined declaratively
            63. All "singleton" node must have a supply function defined for them
            64. Any context node may have a supply function
            65. Used to automatically populate nodes with data
            66. Called automatically by the WD Framework
            67. Disposer Function
            68. Yes
            69. NW04 and NW7.0 only
            70. Executed only if all conditions are met:
            71. Data has been changed via the UI - not programmatically!
            72. The internal event LeadSelectionChanged has been raised
            73. Once lead selection in parent node has changed, this cannot be undone or vetoed due to any errors being detected in disposer function
            74. NW7.1 only
            75. Executed unconditionally
            76. At the end of a controller's lifecycle, if disposer functions are defined for nodes in the context, they will be called after wdDoExit() has been processed.
            77. This can be overridden by forcibly invalidating such nodes in wdDoExit()
            78. No
            79. Any data held in the node will not be preserved if the node is invalidated
            80. Cannot be created declaratively
            81. Manually created subclass within a non-visual controller
            82. Must implement the abstract class IWDNodeCollectionDisposer
            83. Any node may have a disposer function
            84. Disposer functions should be written to work together with supply functions
            85. Gives you the chance to preserve node data before it is invalidated
            86. Called automatically by the WD Framework
            87. Structure/Model Class
            88. Type Access Required?
            89. Yes
            90. Default
            91. Switches on the generation of typed methods to make context coding easier
            92. No
            93. The data in the context can only be access using the generic context API
            94. Attributes
            95. Data type
            96. Any data type you like
            97. Cannot act as a data source for a UI element property
            98. Predefined SAP dictionary data type
            99. Can act as a data source for a UI element property
            100. Read Only?
            101. Yes
            102. Can be updated programmatically
            103. Cannot be updated via the UI
            104. This is typically used for calculated attributes
            105. No
            106. If this is also a calculated attribute, then consider the difficulties associated with writing a setter method!
            107. Calculated?
            108. Yes
            109. Need to write your own getter method
            110. Is the process implemented by the getter method reversible?
            111. Yes
            112. It is feasible to write a corresponding setter method?
            113. Do you really need a setter method?
            114. Is the implementation effort required to write a setter method worth the benefit it would provide? E.G. You may have to write a complex text parser in order to reverse the functionality provided by the getter method
            115. No
            116. It will be impossible to write a corresponding setter method
            117. No
            118. Data is either stored directly in the context attribute or is derived via a mapping relationship
            119. Must be populated by an explicit assignment
            120. NW04 and NW7.0 only
            121. Data is never stored in a calculated attribute
            122. NW7.1 only
            123. Data is stored in a calculated attribute based on the value of the bufferMode property
            124. Unbuffered
            125. Data is never stored
            126. The getter method is called every time the attribute is read
            127. Make your coding as efficient as possible!
            128. Transient
            129. Data is stored after first call to getter method
            130. Stored data does not persist after a suspend/resume cycle
            131. Buffered
            132. Data is stored after first call to getter method
            133. Stored data is suspended along with the application and restored when the resume plug is fired
            134. Hierarchical structure
            135. Anchored to a "root" node
            136. NW 04 and NW 7.0
            137. Value node
            138. NW CE
            139. Universal Context Node
            140. Always has immutable properties
            141. Singleton
            142. Cardinality of 1..1
            143. Accessible via wdContext() helper method
            144. Child node can be a:
            145. NW 04 and NW 7.0
            146. Value node
            147. Model node
            148. NW CE
            149. Universal Context Node
            150. Recursive node
            151. Design time place holder
            152. The repeatedNode property must be configured to point to a parent node in the direct route back to the root node
            153. At runtime, an instance of parent node is created and occupies the place holder's position in the hierarchy
            154. Used to create structures whose depth is unknown at design time E.G. file system directory structures
            155. Singleton property
            156. The usage of the term "Singleton" here refers to the number of child node instances with respect to the parent node in the context, not the Java VM
            157. Yes
            158. Only one instance of the child node exists at runtime - irrespective of the number of elements in the parent node's collection
            159. Default setting
            160. A Supply Function must be written for such a context node.
            161. Reduced memory requirements at runtime
            162. No
            163. For every element in the parent node's collection, there could be a distinct instance of the child node
            164. Non-singleton child node instances are only created if an attempt is made to read the data
            165. Increased memory consumption
            166. Required for displaying information in tree structures
            167. Space occupied at runtime
            168. Every node/attribute declared at runtime will have coding generated to define its existence at runtime
            169. Avoid unnecessarily large context structures
            170. typedAccessRequired = false can be used to stop the generation of the typed API coding for any particular context node
            171. Context node can now only be accessed using the generic API instead
            172. Reduces size of generated coding
            173. Makes context coding more awkward though -> generic API must be used
            174. The "byte code minimiser" will reduce generated code more efficiently than switching typedAccessRequired to false
            175. Removes un-referenced methods from the Java byte code
            176. Settings of "auto" or "wd-only" affect only generated WD classes
            177. Setting to "max" affects all Java coding in your application
            178. Do not use this setting if you use Java reflection!
            179. Context Mapping
            180. Mechanism for sharing data between controllers
            181. Mapped nodes are simply references to the data held in the mapping origin node
            182. Mapped nodes can maintain their own local selection information
            183. Mapped nodes may have local attributes added that store data locally
            184. Instance Methods
            185. Declared declaratively
            186. Normal methods
            187. Event handlers
            188. Usage Declarations
            189. Required before context mapping can be performed
            190. Causes a typed API to be created to give access to functionality in other controllers and/or components
            191. Visual Controllers Only
            192. Actions
            193. Defines the response to be taken when a client side event is triggered
            194. Is a distinct runtime object
            195. May be flagged as
            196. Enabled
            197. Any associated UI elements will be enabled
            198. Disabled
            199. Any associated UI elements will be disabled
            200. May be associated with multiple UI element events to form a generic event handler method
            201. The UI element must supply extra identifying information in order for the action event handler to be able to respond correctly
            202. May be defined as
            203. Validating
            204. Data supplied from the client must successfully pass dictionary validation before any further processing takes place
            205. Dictionary validation performed automatically
            206. Non-validating
            207. You don't care whether the data supplied from the client is valid or not
            208. E.G. When shutting down the application
            209. Dictionary validation is still performed, but WD Framework ignores validation error
            210. Plugs
            211. Inbound
            212. Outbound
            213. UI Layout
            214. No HTML, JavaScript or CSS need be written
            215. Hierarchical arrangement of UI elements
            216. Large number of UI Elements predefined
            217. Client independent definition
            218. User defined UI elements are not supported
            219. NW CE
            220. Flash Islands
            221. Embedded Java Server Face applications
            222. A UI element is any graphical entity that occupies a position in the UI Layout hierarchy
            223. Some UI elements may well be invisible!
            224. All UI elements are derived from the abstract base class of IWDUIElement
            225. All UI elements are the children of the "RootUIElementContainer"
            226. Of type "TransparentContainer"
            227. Immutable properties
            228. UI Element properties are supplied with data via "context binding"
            229. Almost all UI element properties can be bound to a context node or attribute
            230. E.G. the "id" property
            231. Such properties are defined as "not bindable"
            232. Data type of context node/attribute must match that required by the UI element property
            233. See package com.sap.ide.webdynpro.uielementdefintions
            234. See the packages in com.sap.ide.webdynpro.uielementlibraries.*
            235. Data to be displayed is not stored in the UI element object itself
            236. Context binding supplies data to the UI element property
            237. Data Supplier/Consumer principle at work here
            238. Fundamental concept in Web Dynpro development
            239. Do not try to call the setter method for each UI element property you wish to set. Use context binding instead
            240. Position of UI elements controlled by the parent's Layout Manager
            241. Flow Layout
            242. UI elements "flow" from left to right
            243. If screen is resized, then the UI elements will be repositioned according to the new screen width
            244. No vertical alignment of UI elements
            245. Row Layout
            246. UI elements "flow" from left to right
            247. If screen is resized, then the UI elements will be repositioned according to the new screen width
            248. UI elements can be explicitly positioned at the start of new row
            249. No vertical alignment of UI elements
            250. Matrix Layout
            251. UI elements are positioned in rows and columns
            252. UI elements can be explicitly positioned at the start of new row
            253. Vertical alignment of UI elements into columns
            254. Unequal number of columns in each row is permitted
            255. Grid Layout
            256. UI elements positioned in a grid of fixed width
            257. Each row must have exactly the same number of columns
            258. NW CE
            259. Column Layout
            260. Maintains vertical alignment across multiple view containers
            261. UI Element types
            262. Simple
            263. UI elements that require no child UI elements
            264. Client Independent
            265. Content supplied by Web Dynpro server
            266. Button
            267. Input Field
            268. Label
            269. Text Edit
            270. Image
            271. etc...
            272. Content supplied by external Software
            273. Business Graphics
            274. Geo map
            275. Office Control
            276. BI Application Frame
            277. etc...
            278. Client Specific
            279. RFID Reader
            280. Barcode Reader
            281. Function Reader
            282. Composite
            283. All composite UI elements require "relation roles" with other UI elements in order to function correctly
            284. Table
            285. Will not function without at least one:
            286. Table Column
            287. This is also a composite UI element
            288. Column header
            289. Cell Editor
            290. A table UI element is considered to be an aggregation of columns, not an aggregation of rows.
            291. May also have:
            292. Table Header
            293. Grouped Column
            294. Legend Pop-in
            295. Master Column
            296. Pop-in
            297. Toolbar
            298. Cell Variants
            299. Tree
            300. Will not function without at least one:
            301. Tree Node
            302. Implement the onLoadChildren event
            303. Data for child node is only obtained when the user expands the tree node
            304. May also have:
            305. Tree Item
            306. Tree depth known at design time?
            307. Yes
            308. Static context structure can be used to supply data
            309. No
            310. Dynamic context structure must be used to supply data. I.E. recursive context nodes
            311. Non-singleton nodes must be used to supply data to a tree UI element
            312. Group
            313. Remember that a Group UI element already contains a child TransparentContainer UI element. You don't need to add another one!
            314. Container
            315. Used to hold a subset of UI elements that may have their own layout manager
            316. Transparent Container
            317. IFrame
            318. Don't use an IFrame if it is to contain a stateful application obtained from a different server! The remote application's state within the IFrame will be lost during a WD server round trip
            319. Tray
            320. Scroll Container
            321. View Container
            322. Pattern
            323. Contextual Panel
            324. Navigation List
            325. Pattern Sequence
            326. etc...
            327. Non-visual Controllers Only
            328. Events
            329. Trigger mechanism for invoking functionality in other controllers or other components
            330. Used for loose coupled communication between child components and their parent component
   2. Runtime Data Storage
      1. Context
         1. Used to decouple data storage entities (context nodes) from data presentation entities (UI elements)
         2. Used to share information between different controllers
            1. Context Mapping
      2. POJOs
         1. Should be used when runtime data is not needed for display
            1. Lighter weight than context nodes
         2. Cannot be used for data that needs to be displayed on the client
   3. Web Dynpro Application
      1. A Web entry point to the functionality found in one or more Web Dynpro Components
         1. Via the interface view controller
         2. The component pointed to by the Application is known as the "root" component
      2. One component can have multiple applications
      3. Invoked by calling a URL
         1. Parameters can be:
            1. Added as a query string to the URL
            2. Hard coded in the application definition
   4. Models
      1. Metadata definition
      2. Created at design time
      3. Access to back end functionality
         1. Web Service
            1. SOAP
            2. Open Standard
            3. Cannot adapt to changes that occur after design time interface is created
            4. This is because SOAP has no syntax for communicating field extensions
            5. FAQ on Adaptive Web Service Models
         2. Adaptive RFC
            1. Remote Function Call (RFC)
            2. SAP specific protocol
            3. Highly efficient mechanism for invoking functionality in a remote ABAP system
            4. Implemented as jRFC.jar
            5. API to jRFC.jar has been greatly simplified by the JCo layer
            6. Can adapt to certain changes in the ABAP interface structure that occur after the design time interface was created
            7. .APPEND
            8. .INCLUDE
            9. Developer must code their application to look for changes in the interface, and then accommodate any differences
            10. Metadata cached within the SAP Java Server
            11. Adaptive RFC Cache
            12. Java Dictionary Cache
            13. Metadata Interface Cache
            14. Use of JCo Connections
            15. Same concept as SM59 logical destinations in R/3
            16. Quick Summary
            17. FAQ on Adaptive RFC Models
            18. Coding Guidelines
            19. Trouble Shooting
         3. Java Bean
            1. Any class that has:
            2. A set of private attributes
            3. Getter and Setter methods to access the private attributes
            4. A public constructor requiring no arguments
         4. Enterprise Java Bean
            1. Invoked by
            2. Direct execution
            3. Exposure as a Web Service
            4. Do not use this technique if WD application and EJB reside on the same server
            5. Communication protocol overhead incurred
            6. RMI
            7. Aggregation of classes
            8. Interfaces
            9. Descriptors
            10. Usage contracts
            11. Management contracts
            12. Types
            13. Entity Bean
            14. Container Managed Persistence
            15. Bean Managed Persistence
            16. Session Bean
            17. Stateful
            18. Stateless
            19. Message Driven Bean
      4. Typically packaged into a specific Model DC
         1. Exposed via one or more Public Parts
         2. Ensures that the coding is compiled only once and then referenced
         3. Greatly speeds up the development process
      5. Common Model Interface
         1. Gives all model objects a consistent interface irrespective of the underlying communication protocol
   5. Interaction with NWDI
      1. Always use a DC of type "Web Dynpro"
      2. Define the DC Metadata
         1. Functionality to be used outside the scope of the DC must be added to one or more Public Parts
         2. Declare use of Public Parts needed from other DCs
   6. Naming Conventions
   7. Mobile Devices
   8. Adobe PDF Documents
6. Other Information Sources
   1. Books
      1. Inside Web Dynpro For Java
      2. Maximising Web Dynpro For Java
   2. Training Courses
      1. JA310
      2. JA312
   3. SAP Developer Network
   4. SAP NetWeaver Library Documentation
7. Runtime Behaviour
   1. Application Instantiation
      1. The WD Framework examines lifecycle property of all components in the declared component hierarchy
         1. manual
            1. Component instance must be created by explicit coding
         2. createOnDemand
            1. WD Framework instantiates such components as soon as they are referenced - either by the Web Dynpro Framework or by an explicit method call
            2. wdDoInit() method called automatically
      2. Client limitations?
         1. Certain UI elements are not supported by certain clients
         2. For instance, an standard browser does not typically support the use of the BarCode UI element
   2. User Interaction
      1. Event raised in the client device
         1. Initiates round trip to server
            1. Initiates component instantiation if the application is being run for the first time.
            2. The associated action event handler method is called at the appropriate point in the Phase Model processing
      2. UI Elements must have an action associated with one of their events in order to trigger a round trip
   3. Web Dynpro Framework
      1. Interaction with business application via a delegation layer
      2. Interacts with your business functionality through standard hook methods
      3. Phase Model
         1. Phase Model in NW04 and NW7.0
         2. Only handles round trip processing
            1. Client Abstraction Layer
            2. Remove incoming data from client specific container
            3. Client Independent Processing
            4. Before Navigation
            5. doApplicationStateChange
            6. Process resume request if present
            7. Perform Dictionary Validation
            8. Type of action determines whether subsequent processing takes place or not
            9. Validating action: respond to validation error
            10. Non-validating action: ignore validation error
            11. Call Service Event Handlers
            12. unload
            13. abort
            14. logoff
            15. valueHelp
            16. suspend
            17. NW CE
            18. ContextMenu
            19. NW CE
            20. doBeforeAction
            21. Application Event Handlers
            22. The action event handler method onAction${act} associated with the event raised in the client is called
            23. doBeforeNavigation
            24. wdDoBeforeNavigation() method called for all components in the hierarchy
            25. Always called using a top down traversal of the hierarchy
            26. In multi-component applications, navigation processing should be delayed until this point in time
            27. After Navigation
            28. Navigation and View initialisation
            29. Lifecycle management of view controllers takes place here
            30. Navigation queue processing takes place here
            31. Dynamic UI manipulation
            32. wdDoModifyView() method is called for all views in the new view assembly
            33. It cannot be predicted in which order this methods will be called for each view
            34. Retrieve data for UI tree
            35. For HTML clients, the entire screen is rendered
            36. Used to force all supply functions to execute during application processing
            37. doPostProcessing
            38. wdDoPostProcessing() method is called for all components in the hierarchy
            39. Methods are called using a top down traversal of the hierarchy
            40. In multi-component applications, the processing of serious or fatal error message should be managed by this method
            41. doApplicationStateChange
            42. Process suspend request if present
            43. Client Abstraction Layer
            44. Package output data into client specific container
            45. Server Side Rendering
            46. Generates the required markup and scripting instructions for the specific client device
         3. Not directly responsible for component lifecycle management
            1. Handled by the WD Framework
8. Designing Large Web Dynpro Applications
   1. Planning
      1. Analyse the business process from different perspectives
         1. Clock Maker Analogy (See "Inside Web Dynpro for Java", section 3.4.11, page 111)
            1. Mayor
            2. Director of Public Services
            3. Clock Maker
         2. Staff members
            1. Business Process Expert
            2. Management
            3. Board Members
      2. Functional scope
         1. Business process layer
            1. Re-engineered?
            2. Modified?
            3. Left untouched?
         2. UI layer
            1. To existing business process?
            2. To modified business process?
            3. To re-engineered business process?
      3. Access to business functionality?
         1. Web Services?
         2. ABAP via Remote Function Call?
         3. Java Beans?
         4. Some combination of these?
   2. Design
      1. Component Hierarchy
         1. n Tier design?
         2. 3 tier design?
            1. Typical structure
            2. Top level
            3. Master Component
            4. Component life cycle management
            5. Implements child components via standalone component interfaces for increased configuration flexibility
            6. Middle level
            7. UI Components
            8. Localisation functionality
            9. Integrate units of business functionality found in lowest level
            10. Tightly coupled to child components
            11. Low level
            12. Global Data Components
            13. Model Components
            14. Utility Components
            15. Know nothing of parent component implementation
            16. Loosely coupled to parents
         3. Inter-component relationships
            1. Loose coupling in an upwards direction
            2. Tight coupling in a downwards direction
         4. Focus on reuse
            1. Faceless components
            2. "Faceless" means that the component does not contribute to the business application's user interface. This does not mean that the component has no user interface at all.
            3. Can have a UI for testing or admin purposes only
            4. Model Components
            5. Simplify access to complex business API's
            6. Utility Components
            7. This component type provides the only legitimate use case for external mapping
            8. Global Data Component
            9. Configuration Component
            10. Design time reuse
            11. Runtime reuse
            12. Referencing mode
            13. Individual component instances
         5. Component granularity
            1. Too small
            2. Reuse not possible because one component does not contain enough functionality
            3. Results in a "sea" of functional fragments
            4. Excessively complex inter-component relationships
            5. Increased system overhead at runtime due to component instance management
            6. Correct
            7. Good reuse
            8. Minimum maintenance effort
            9. Effective distribution of work between team members
            10. Too large
            11. Poor reuse because components contain more functionality than required for the use case
            12. More complex interface
            13. More complex internal structure
            14. Distribution of work between team members difficult because component boundary spans several functional boundaries
      2. Standalone Component Interface Definitions
         1. Different components share a common interface
         2. Multiple UI components required to front-end a single business processing component
      3. Configuration Requirements
         1. Configuration held locally?
         2. Configuration held in a back end system?
         3. Configuration hard-coded into application parameters?
         4. Configuration received through URL query string?
      4. Localisation Requirements
         1. Multi-language UI required?
            1. If "yes", then build support in from the start
         2. Compliance required with country specific business laws?
         3. Country/Region specific UI layout required?
      5. Location of business processing
         1. Back end SAP system?
         2. Web services?
         3. Enterprise Java Beans?
         4. Some combination of the above?
   3. Implementation
      1. Inter-component Communication
         1. Context Mapping?
            1. Internal?
            2. External?
            3. Avoid complex mapping relationships between components
            4. Increased maintenance complexity
            5. Increased chance of unexpected behaviour
            6. Multiple components all updating the same node or attribute
            7. Unexpected changes in lead selection
            8. Consider a custom business object as a data transfer mechanism
         2. Pass values as parameters?
         3. Event handling
            1. Loose coupling mechanism
            2. Upwards communication from child to parent component
      2. Make correct use of standard hook methods
         1. wdDoPostProcessing()
            1. Handling errors detected after navigation
            2. Round-trip method
         2. wdDoBeforeNavigation()
            1. Handling errors detected before navigation
            2. Navigation processing
            3. Error Handling
            4. Round-trip method
         3. wdDoModifyView()
            1. Only used for dynamic UI construction
            2. Don't modify the context here!
            3. Don't fire navigation plugs here!
            4. Don't try to get or set UI element properties! Use context binding instead
            5. Round-trip method
         4. wdDoInit()
            1. Lifecycle method
            2. Behaves like the controller's constructor
         5. wdDoExit()
            1. Lifecycle method
            2. Behaves like the controller's destructor
      3. Internal data storage
         1. Memory Considerations
            1. Context?
            2. Typed access required?
            3. Byte code minimiser
            4. Model Objects?
            5. Custom Business Objects?
         2. Store or calculate?
      4. Centralised functionality
         1. Server-side caching of data?
            1. External Library?
            2. Service in the Engine?
         2. Examples
            1. Message text management
            2. Help values
      5. Management of child component instances
         1. On Demand
         2. Manual
            1. Referencing mode?
            2. Child component instances used in referencing mode must be managed carefully!
            3. Root component should manage lifecycle
            4. Dynamic component usage
         3. Instantiate late
         4. Dispose early
9. Administration
   1. Runtime Environment
   2. Text Mapping
10. Background
    1. Predecessors
       1. Internet Transaction Server
          1. Protocol translation tool for converting SAPGUI's proprietary DIAG protocol into HTTP based HTML pages
             1. Each SAPGUI dynpro could be represented by an HTML template
          2. Originally a standalone server that sat between the ABAP system and the web server
             1. The web server needed a small plug in known as the "wgate" or "web gateway"
             2. The ITS functionality was implemented by a program known as the "agate" or "application gateway"
          3. Now embedded within the Basis layer of ABAP system
          4. Considered obsolete and only to be used for compatibility with legacy applications
          5. No new developments should be performed based on the ITS
       2. HTMLB
       3. Business Server Pages
    2. Origins
       1. Created from the need to remove the repetitive and error-prone nature of web development. Tradition web development techniques created applications:
          1. That work perfectly with one browser, but then develop “unexpected features” when viewed in a different browser
          2. That require significant rework in the user interface layer because the structure of the business data changed
          3. In which short-cuts were taken during the design phase in order to get a quick result - only to find that the costs “saved” during development came back to haunt you during the maintenance phase
       2. The first concepts of Web Dynpro were discussed in 2001
       3. Existing web development tools did not meet all of SAP's requirements, therefore a custom tool was written
          1. 1. Create a user interface (UI) programming paradigm that would become the standard for all future SAP software. Ease of use is the key here.
          2. 2. Eliminate the repetitive coding tasks currently experienced by Web developers. The fewer lines of hand written code there are in the UI, the better.
          3. 3. Make full use of abstract modelling. The application should not care about either the communication technology required to access a back-end system or the client technology used to render its screens.
          4. 4. Make full use of generic services. Functionality that is frequently required should be made available from a standard library of services. For example, if the user is asked to enter a date, then a date picker should automatically appear next to the input field without requiring extra coding effort on the part of the developer.
          5. 5. Use a declarative approach for application design. This approach is where the developer tells the development toolset what should be done, but not how to do it. This concept should extend into all areas of application design. (e.g., screen flow and component reuse).
          6. 6. Change the focus of software reuse from low-level units of code to high-level units that represent distinct steps in a business process.
11. Architectural Concepts
    1. Focus on component reuse
    2. Component Hierarchy
    3. Faceless Component
       1. Provides no visual interface to the business application
       2. Simplifies the interface to a complex unit of back end functionality
    4. UI Component
       1. Provides only the UI layer
       2. May handle input validation logic
    5. Data Supplier/Consumer Concept
       1. Most fundamental concept in WD development
       2. Seen in multiple places and on different scales within the architecture
    6. NW04 and NW 7.0 only
       1. Dispatcher Component
          1. Handles navigation logic
          2. Sits in between the UI component and the faceless components in the hierarchy
          3. This type of component is no longer necessary in the Composition Environment version of Web Dynpro
          4. Superceded by functionality available in the new Window Controller
    7. Division of Processing
       1. Before Navigation
          1. All processing that takes place before navigation is concerned only with application business logic
          2. React to client side event
          3. Validate input from user
          4. Call appropriate functionality in back end business system
             1. Do not do this from a visual controller! Very bad style!
             2. Only from a non-visual controller
          5. Handle errors and navigation requests
             1. Child components report errors up to the parent component
             2. Centralise error and navigation processing in the root component
          6. Fully populate the context with the data required for UI rendering
       2. After Navigation
          1. Concerned only with constructing the new view assembly
          2. Treat the context as read only!
          3. Do not perform any business logic
          4. If necessary, construct UI layouts dynamically
             1. Don't forget to check the firstTime parameter in wdDoModifyView()
          5. Any errors trapped after navigation should relate only to problems constructing the new view assembly.
    8. Use of External Libraries
12. NWDI
    1. NWDI Component Model
       1. Hierarchical Structure
       2. Product
          1. Very large unit of code
          2. Corresponds to an entire delivered SAP system
          3. Composed of one of more Software Components
       3. Software Component
          1. The unit of software delivery, installation and upgrade
          2. An aggregation of Development Components
          3. One Development Component may belong to one and only one Software Component
       4. Development Component
          1. DC Types
             1. Composite Application Service
             2. Dictionary
             3. Java
             4. J2EE
             5. Enterprise Application
             6. EJB Module
             7. Web Module
             8. J2EE Server Component
             9. Library
             10. Interface
             11. Enterprise Portal
             12. Standalone Application
             13. Application Module
             14. UME Permissions
             15. Web Service
             16. Standalone Proxy
             17. Deployable Proxy
             18. Web Dynpro
          2. Always a member of a Software Component
          3. Metadata wrapper around actual software functionality
             1. Determines how DC should be compiled and deployed
             2. Defines what internal functionality is exposed via the Public Parts
             3. Defines what functionality is consumed from other DCs
    2. Used for compilation, migration and delivery of software