Skip to Content
  • Do not put all your data into the context.
  • Do not create a mega context for all data belonging to one application.
  • Put only the data required for the UI element binding into the context.
  • Use the assistance class or other ABAP OO classes for the data exchange.
  • Without any requirement(use in Multiple Controller) dont create Context in Component controller level, If required create local contexts, for example, in views
  • Do not create deep-nested contexts.
  • Use singleton nodes if nestings (master detail) are necessary
  • Do not use dynamic attributes (IF_WD_CONTEXT_NODE_INFO->ADD_ATTRIBUTE)
  • Use data with context structure for BIND_TABLE
  • Update the context only if the data actually has to be updated
  • Do not create long context mapping chains.
  • Use the Context Change Log functions to detect user input. This has particular performance benefits while a user of the application modifies only a small amount of data in a view while displaying a large amount of mixed data.

Please feel free to add more points in this blog,

Thanks!

Mani

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Tom Van Doorslaer

    It looks to me that these rules are aimed at performance improvement.

    I do have some remarks on a couple of these rules:

    • Without any requirement(use in Multiple Controller) dont create Context in Component controller level, If required create local contexts, for example, in views

    The component controller is your central hub for your context. If at any time, you have a context node which is shared across multiple views, you should create the node in the component controller and map it to other views.

    Nodes specific to a certain view may be created directly on the view context, but for readability and uniformality, I often choose to centralize all my context nodes and supply methods in the component controller.


    • Use singleton nodes if nestings (master detail) are necessary

    Singleton nodes are good for performance, because you only keep one instance of your node in memory, rather than having multiple instances for each (inactive) parent object. However, you better know what you’re doing because if you come in the situation where you need multiple active parent elements (row repeater, nested tables, trees, multiselection tables…) the singleton node will dump your application.

    If you don’t know the principle of singleton nodes well, or when performance is not an issue, do not use singleton nodes.


    • Do not use dynamic attributes (IF_WD_CONTEXT_NODE_INFO->ADD_ATTRIBUTE)

    If you can use statically defined context attributes, then use static attributes. There will however be situations in which you have to dynamically create your context. In those cases, you have no other choice than adding dynamic attributes. I do however agree that you must avoid dynamic context programming (and dynamic view programming) as much as possible.


    • Use data with context structure for BIND_TABLE

    Not a hard requirement, Internally, the bind operations use a move-corresponding and keep the original table in a shadow variable. Although the move-corresponding is reportedly bad for performance. (I say reportedly, because I have done tests of myself and could not find any significant difference)


    • Update the context only if the data actually has to be updated

    Depends on what do you mean with update?


    • Do not create long context mapping chains.

    ?


    • Use the Context Change Log functions to detect user input. This has particular performance benefits while a user of the application modifies only a small amount of data in a view while displaying a large amount of mixed data.

    True. The context changelog can be very powerful when used in a dynamic fashion.

    But it’s also very advanced. I have a snippet to go through all changes in a context, assign the data to the appropriate variable in the assistance class (field in structure, or field in a row in an internal table) and dynamically call a handler method (if one exists). I shared this snippet with a lot of highly skilled developers. Up to date, only 2 actually understood what it did, and were capable of applying it on their own components.

    The rules you mention are interesting enough, but like Steve mentioned, you may want to elaborate on the purpose and the underlying idea.

    Cheers!

    (0) 

Leave a Reply