OO ABAP and Design Patterns 3: Docking Containers’ Controller
h4. Introduction This weblog is about a class that produces and destroys docking containers (good old Controls Framework technology) on demand while arranging them on the screen. Although far from being the hot topic, the Controls Framework (CFW) technology is still in use, and for those of you who didn’t completely migrate to BSPs or WebDynpros (I suppose there are a few girls and guys out there), this might be a chance to get a fully functional handy little component plus an innovative idea in object-oriented ABAP program design. h4. Docking containers Just short explanation for those who might be less familiar with docking containers: Docking containers are ABAP objects of class CL_GUI_DOCKING_CONTAINER which serve, like other containers, to store controls like ALV grid, trees, other containers etc within. They are specific by their characteristic that they don’t need a dynpro screen control to open in, and they don’t float freely like dialogbox containers. They rather “dock” at specified side of a screen. In their constructor, it’s possible to define their size and docking side (left, right, top or botton). If more containers are created, they dock at each other from outside towards inside of the screen. h4. The standard way The problem here is managing space. When you create the first container, it’s easy. You want it to occupy the entire screen because there’s no reason to save space, and you want user to have the best possible overview. So you can exaggerate with dimensions – SAP is clever and the container will fit to screen nicely. I have created a demo to show you this. I put a Dynamic Document control in a container with a “close” button and a caption with ordinal number and docking side. This is just to see something in the container and to be able to close it. Otherwise it performs no functionality. In real programs, of course, containers will contain something useful. Let’s see how it looks if I dock it at top: DATA: o_container TYPE REF TO cl_gui_docking_container. CREATE OBJECT o_container EXPORTING extension = 1500 “exaggerated by far side = o_container->dock_at_top. And I’ll get 
It looks good. But if I create another one I get 
Now you probably think “this guy is fooling us – it’s the same picture”. But it’s not. Take a good look – there’s a little barely visible bar under the container. It’s the new container placed below the first one. It docked properly at its bottom, but noone told the first one to resize and make space! Now it’s user’s task to realize that this is not an error. The user should reach at the bottom and resize the first container to see the new one, like 
The same works for destruction when user chooses to close a control and its container. If done in an usual way, by o_container->free( ) the container would just disappear and leave a hole in the screen. What do you think? Would users like my new application? I would probably end with pizza remaining over my face. Today’s remaining, if I’m lucky. h4. Containers’ controller What is the solution then? You can have your application counting containers and redistributing space evenly every time the new one is added, as well as when an obsolete one is removed. This sounds reasonable, but why having each application dealing with this? The algorithm might not be simple (destruction gave me a hard time), and once tuned, there’s no need to repeat this over and over. I think that the best would be to create a generic and reusable component to manage containers. I created a component that has 2 public methods: GET_CONTAINER and DESTROY_CONTAINER. It’s a class that never instantiates and all its attributes and methods are static. Why is this? This is because only one program can run in one session, and it has only one screen where docking containers can open. Therefore it would make no sense to have more “container controller” objects in one program. This is why it’s a class that only has static components. When I want a container, I’ll simply do: DATA: o_container TYPE REF TO cl_gui_docking_container. o_container = lcl_cont_controller=>get_container( ). When I want it to disappear I’ll do: lcl_cont_controller=>destroy_container( o_container ). I have created a demo program which has a command tree to the left. Note that the command tree is NOT controlled by the container controller, so it will always stay as is (unless resized by user). You can freely combine “independent” containers with those controlled by this component. The tree has 4 commands, for creating containers docked at left, right top and bottom. 
I played with it by clicking the commands by random and observed the result. For example: * TOP * * LEFT * * BOTTOM * * RIGHT * * TOP * * BOTTOM * It resulted with: 
And then I closed them, again in randomly chosen order: 
User can open indefinite number of controllers, but of course, at certain point it stops making sense. But it’s up to user to decide because technically it’s not limited. No matter how many opened, they will be distributed evenly, and the same will work in reversal process, when user starts to close them. 
There’s a drawback, however (or an advantage – depends on how you look at it). The program has total disrespect for the user. No matter how user resizes containers, they will be distributed evenly at the next container creation or destruction. Feel free to adapt this to your needs. h4. Demo Implementation I use this handy component daily in my applications. You can try it in a demo which is actually one single ABAP. It’s an object program, and it’s heart is the class LCL_CONT_CONTROLLER which you can easily make a dictionary class and reuse. For your better overview, here’s the program’s static UML diagram: 
It looks good. But if I create another one I get Now you probably think “this guy is fooling us – it’s the same picture”. But it’s not. Take a good look – there’s a little barely visible bar under the container. It’s the new container placed below the first one. It docked properly at its bottom, but noone told the first one to resize and make space! Now it’s user’s task to realize that this is not an error. The user should reach at the bottom and resize the first container to see the new one, like The same works for destruction when user chooses to close a control and its container. If done in an usual way, by o_container->free( ) the container would just disappear and leave a hole in the screen. What do you think? Would users like my new application? I would probably end with pizza remaining over my face. Today’s remaining, if I’m lucky. h4. Containers’ controller What is the solution then? You can have your application counting containers and redistributing space evenly every time the new one is added, as well as when an obsolete one is removed. This sounds reasonable, but why having each application dealing with this? The algorithm might not be simple (destruction gave me a hard time), and once tuned, there’s no need to repeat this over and over. I think that the best would be to create a generic and reusable component to manage containers. I created a component that has 2 public methods: GET_CONTAINER and DESTROY_CONTAINER. It’s a class that never instantiates and all its attributes and methods are static. Why is this? This is because only one program can run in one session, and it has only one screen where docking containers can open. Therefore it would make no sense to have more “container controller” objects in one program. This is why it’s a class that only has static components. When I want a container, I’ll simply do: DATA: o_container TYPE REF TO cl_gui_docking_container. o_container = lcl_cont_controller=>get_container( ). When I want it to disappear I’ll do: lcl_cont_controller=>destroy_container( o_container ). I have created a demo program which has a command tree to the left. Note that the command tree is NOT controlled by the container controller, so it will always stay as is (unless resized by user). You can freely combine “independent” containers with those controlled by this component. The tree has 4 commands, for creating containers docked at left, right top and bottom. I played with it by clicking the commands by random and observed the result. For example: * TOP * * LEFT * * BOTTOM * * RIGHT * * TOP * * BOTTOM * It resulted with: And then I closed them, again in randomly chosen order: User can open indefinite number of controllers, but of course, at certain point it stops making sense. But it’s up to user to decide because technically it’s not limited. No matter how many opened, they will be distributed evenly, and the same will work in reversal process, when user starts to close them. There’s a drawback, however (or an advantage – depends on how you look at it). The program has total disrespect for the user. No matter how user resizes containers, they will be distributed evenly at the next container creation or destruction. Feel free to adapt this to your needs. h4. Demo Implementation I use this handy component daily in my applications. You can try it in a demo which is actually one single ABAP. It’s an object program, and it’s heart is the class LCL_CONT_CONTROLLER which you can easily make a dictionary class and reuse. For your better overview, here’s the program’s static UML diagram:
I am new to patterns and although i dont use patterns as an abapper its fascinating and i want to learn and start using them in near future!
I have some questions for you:
how often do you use patterns in your day to day abap development?
what are the advantages and disadvantages?
I am looking to buy your book, would it be a good start or is it better to start with a generic design patterns book then read yours?
thanks
naresh
I am happy that you liked my blog, and thanks for your feedback!
To be honest, I very rarely use patterns in daily work, as well as objects. The advantage of OO/DP is growing with complexity of software that you are working on. If you are only doing simple reports/batch-inputs/enhancements/forms on a typical implementation project, you won't benefit much from OO/DP, if at all. Functional SAP knowledge (one or more modules or products) is highly more appreciated than sophisticated programming skills on such projects.
However, if you find yourself in a situation that you have to work on something bigger, then your work can be GREATLY improved by use of OO/DP!
As for my book, it does assume basic knowledge of object-oriented programming. I would recommend learning basic principles of objects (preferably ABAP, but any other can do too) and then my book. Attending the BC401 course would be ideal. Other generic DP book is advisable too - that is how I started. Without previous experience with objects, I started with "Design Patterns Explained" by Shalloway/Trott - a light reading beginners' book on patterns.
I hope I helped you!
KR,
Igor
thanks for your reply and suggestions! i was on hols for few weeks hence late reply!
I use OO ABAP a lot in my day to day job and also familiar with C++ and Java! But like you said as a sap tech consultant working on implementation projects or support projects we might not benefit from DP! however just out of interest i wanted to learn a bit about design patterns!
as per your suggestion i will make a start with "Design Patterns Explained" by Shalloway/Trott and see how it goes.
once again thanks a lot for your kind suggestions!
Thanks
Naresh
Sorry for delayed reply - I didn't see your post till now.
I think it is not possible to put docking container in a subscreen. You can use custom container (class CL_GUI_CUSTOM_CONTAINER) for this purpose, but first you need to create container screen area (you draw it in a graphical screen painter) and pass it's name as CONTAINER_NAME parameter to the constructor when you create your container. For more details, please search in SCN.
KR,
Igor
Very nice demonstration! I like it very much although or maybe because I don't understand it... 😉
Therfor I do not find the error on the code:
If you create any first container everything is okay. But the next container will not be created as desired. Example: If you first create a TOP-Container and next create a left-container, the 2nd container will be placed _under_ the first one instead of the left side! Teh next Left-container will be placed right.
Qould you like to have a look on this behaviour?!
Thanks a lot. I am awaiting some more pattern-demonstrations in future!! 😉
Design Patterns are cool and I read your book although I didn't understand very much as design patterns are really hard stuff IMHO. So lots of demonstrations might good to crack these design patterns sometime... 😉
Enno
Thanks for the kind words, although I am not happy to learn that you have problems understanding the book. This always makes me wonder: what could I do better to make it more clear for the readers?
As for the container behaviour, this is simply the inherent nature of the docking containers. In example that you mentioned, the "left" container doesn't neccessarily appear to the left of others. It actually "docks at left", which means that it will look for the next available left screen border, looking from the inside out, and then stick to it. This "from inside out" makes the difference. So the next available "left screen border from inside out" is actually the right side of the command tree and the new "dock-to-left" container sticks to it. You can test it like this: can you reach on it's left border and resize it to make a hole in the screen? No, you will "drag" the command tree border too, because it is "docked at left". However, you can resize it on the right side and leave a hole in the screen.
The problem is, however, that the previous "dock-at-top" container occupied the entire sceen height, so initially we couldn't see the second one at all. Therefore, we need to resize them both vertically so that they occupy the equal space. That's what this component is all about: just resizing.
Did I hopefully make it more clear?
On the rest I will have to think a while...
Enno
I adapted the code so that I could see where the Dynpro is and then it is clear: The next docker of course docks at the chosen side of the dynpro. The terrific resizing function made me cofused... 😉
Thanks! Enno
Hi Igor,
Can you please explain this with the piece of code?
Thanks in advance