Skip to Content

Resizable Text Boxes in WebDynpro for ABAP

h3. Resizable Text Boxes in WebDynpro for ABAP  In the web, resizable text boxes are getting more and more popular. Even here in SDN, you can easily increase the height of the text boxes in the forums just by dragging the lower right corner.image For UIs that purely rely on HTML, this is not too hard. You just search for some reusable JavaScript libraries and add that JavaScript to your page. In WebDynpro, this is not that easy. However, there is also a reason for it. WebDynpro applications are designed for all kinds of output formats, and HTML is just one of the possible ways. In future, your WebDynpro application might also be running as a Flash application, or run on a handheld device with a proprietary UI technology.  Therefore, WebDynpro does not allow you to add any self-made JavaScript to your application. So, what can we do? Is there no chance to implement resizable text boxes with WebDynpro? Well, resizing by just dragging the corner of the box is hard to realize. Also, a text box that increases automatically while you enter more text (a feature that you might have noticed on Facebook recently) is almost impossible, because the underlying JavaScript events like “OnKeyUp”, “OnFocus” or “OnBlur” are not available in WebDynpro.  *However, there is hope.*(see {code:html}SDN Community Code Gallery{code} )(see {code:html}SDN Community Code Gallery{code} )0.1. Create DDIC Structures (just 2…)  (see {code:html}SDN Community Code Gallery{code} )0.1. Add resizer-list to your component controllerimage0.2. Enable resizers for each text box (see Code Sample 3 above) 0.3. Add an action RESIZE and action handler ONACTIONRESIZE in view (see Code Sample 4 above)image
You must be Logged on to comment or reply to a post.
  • You have a nice idea, but not a recommended implementation.  First, it is never recommended to pass control of the View object outside the WDDOMODIFYVIEW. Changes to the View rendering should only be done within WDDOMODIFYVIEW. Changes to the rendering in other parts of the phase model can lead to unexpected results and will not be supported.

    This is also a violation of the MVC design approach since you are tying your logic directly to the UI element IDs. 

    Furthermore using WDDOMODIFYVIEW and directly chaning the UI elements isn’t necessary nor the easiest way to acomplish what you want to do.

    Instead you should create a context attribute and bind the rows property of the TextEdit UI element to this attribute.  Then in your event handlers you need only modify the value of the context attribute.

    The manipulation of UI element properties in Web Dynpro should always be done primarily via context binding.  The WDDOMODIFYVIEW approach is only there as a last resort when you absolutely need dynamic UI – which is not at all the case here.

    • Hello Jung,

      I did not understand your point when you say,

      ” First, it is never recommended to pass control of the View object outside the WDDOMODIFYVIEW. Changes to the View rendering should only be done within WDDOMODIFYVIEW. Changes to the rendering in other parts of the phase model can lead to unexpected results and will not be supported. “

      Is not passing the view reference to another method that is executed in the modifyview itself and making changes to the view same as making changes to the view in the modifyview itself ?

      I don’t know if it is mentioned in the Library that passing the view reference to another method call in modifyview and doing the processing in that method is not allowed.

      Could you please let me know the the relevent information on this.

      The reason being, in my project I had to create ui elements dynamically and I’m passing the view instance to a class method and doing the creation there. I’ve seen some standard webdynpro components doing the same.

      Please let me know if it is a wrong approach?


      • Hi Priya

        I understand for Tom comment that the call to resize method should be done inside wddomodifyview method instead of onactionclick event handler methods. Event Handlers should be used to modify some context value attributes and then catch that change in wddomodifyview and realize the resize method call. MVC design avoids direct calls from event handlers to UI elements, binding of even handlers to context is the right way.


      • Calling another method from WDDOMODIFYVIEW to simply better organize your code is OK.  My point is that you don’t want to interact with the View or dynamically change the UI in another part of the Phase Model (action handlers – as in this example).  Dynamic render in another part of the phase model is not supported.
    • Hi Thomas,
      thanks for the feedback.

      You are right, modifying properties of UI elements via Context Binding is the better way than doing it programmatically.
      The reason why I went the dynamic way is that I needed a solution that I can easily “switch on” for hundreds of textboxes in several applications.
      The nice thing about a the dynamic way in my case is that you just need to add few lines of code to each view, without having to define additional context nodes and bindings.

      Your other point is even more valid. UI elements should be modified only in WDDOMODIFYVIEW, not in event handlers. This is something I will change in my implementation. In the event handlers, I will just inform the resizer objects about the new height, so that I can change the height in WDDOMODIFYVIEW.

      I will update the blog soon.

      @Sergio: I will be happy if such a feature will find it’s way into the WebDynpro Standard. Until this has happened, or for all of you running on releases that do not support this, my implementation might be helpful.

  • changing the size of a text area programmatically it’s quite easy indeed.
    I would change the scope of your blog to become a request for an enhancement. A standard new attribute of the textarea UI control it’s a good idea.
    I even don’t see to many problems thinking about Flash support (Island) or other devices(mobile?).
  • Hi Daniel

    thanks for this blog and sharing your ideas, I celebrate that the “hacking spirit” is also present inside SAP.


  • why we can’t use javascript in wdp, and I really don’t buy this “WebDynpro applications are designed for all kinds of output formats” bullshit. I find it hard for developers to believe in such crap..

    each client rendering technology has it’s own strengths and weakness, we all know that.. wdp does not leverage anything on Mobile for instance – you have limited functionality and so on – something being rendered on a browser differs from a pocket browser.. javascript would be just one more thing that wouldn’t be “supported” in certain clients.. what a big deal!

    adding to the topic, Thomas is completely right about the Phase Model, and this is something that some developers don’t really understand when creating an App.. – however, I respectfully disagree with the Context Binding vs Direct UI Manipulation – it will really depend on what you need to implement.