I know what you are thinking..."Could he have come up with a cheesier title?!?!" (haha)....but it did get your attention...and well, we are talking about trees here...in a manner of speaking. I think by now we are all quite familiar with "tree" controls (aka. "Tree View") in the world of user interface design. Things like....
....where a hierarchical relationship among elements lends itself easily to this visual display. Now, in the "new" world of FPM based forms for HCM P&F, making a nice tree view component and using it within your "form" is fairly simple (especially when I showed you how to do this in my other blog, HCM Processes & Forms: Google Maps and how to step up your FPM forms game!, hahahaha) You can easily do this...
But what about the people still in the Adobe forms world? You can't just plop a nice little "tree view" widget into your form. But you can "easily" build your own....in a manner of speaking. :wink:
First off, since we are in the HCM P&F world, we have to think of how this relates to our "form fields" in config. For myself, I visualized my "tree" as actually a "table" of fields. My tree would be represented by...
...where:
- TREE_SELFLG_LIN is the selection flag for the node (X = selected, blank = not selected)
- TREE_NODE_LIN is our node's ID number (ie. key)
- TREE_NODETXT_LIN is our node's displayed text
- TREE_NODETYPE_LIN is our node type (we want to be able to "style" our nodes based on their "type", like "document, folder, image, etc" that might
tell us "what kind of node" we have
- TREE_NODEPARENT_LIN is the parent node ID of our node (because of course, nodes can be a parent to child nodes which in turn can be parents to
other child nodes and on and on)
- TREE_NODE_ISDIRTY_LIN is just a little extra field I use to tell if the user has changed the value of this "row" from what was selected before. It makes
it easier to tell later instead of looping through what the backend records are versus what my TREE_SELFLG_LIN value
shows for each and every row...especially in very large trees. Once I need to "merge" what the form values are with what
was selected/stored before, I simply have to look at this "is dirty" row and use only those records. Make sense? haha
As you see, I have a habit of naming my form fields with "_LIN" at the end. This is simply to tell me (and others) that these form fields represent a table (since HCM P&F handles tables in and odd "columns of arrays" kind of way covered in yet another blog I did, HCM Processes & Forms: The Trouble with Tribbles...er, Tables ).
Now on the HCM P&F side, I will assume that just like I did, you have some generic service that you will use to not only "construct" your "tree" of data as our "table" of form fields, but that you will also check "where ever" to see which of those "nodes" have been selected by the user (if done before and we are displaying it) or you will have them set by whatever initialization you need. This discussion does not cover generic services and how to populate you "table" of form fields. It assumes your fields are now filled with the information to visualize the tree hierarchy on the form.
The next step is to lay out our Adobe Interactive Form and bind our fields as needed. We will use the menu option to insert a table element on our form and set it as ....
Notice that I made the first column a "checkbox" field with no caption (on the "layout" tab for the element, select "none" form the caption setting at the bottom). The rest of my cells are text fields set as display (read only) and some are hidden. We only want a checkbox and then our node text to show to the user.
We now will bind our backend HCM P&F form fields to each "cell" in our table on the form. This is as easy as dropping our data fields onto each cell as needed. This discussion does not cover the basic "how to" of binding your HCM P&F config form fields to your Adobe form elements as you can find this information easily elsewhere (or should already be well acquainted with it if you have been doing HCM P&F work).
Now that we have our backend form fields now bound with our table, we can check to see if this is working correctly. What we will get is a very basic "table" which looks nothing like our "tree" that we want.
This is because our REAL work is now ahead of us. Through the use of Javascript on specific events, we will turn this table into a "tree view" before all is said and done.
The first step is adding 2 empty columns between our "selected" radio box column and our node "text" that is shown to the user. I make these as wide as the "checkbox" cell (as we will be "shifting" our checkbox by that same amount of space as you will see later).
The number of these columns that you will need will largely depend on the "depth" of your tree (how many levels it goes) as you will see later. In my case, I know my tree goes down 3 levels....so I count the selection column plus my 2 empty columns....three....which is what I need to make it all work correctly.
Now it all comes down to some clever scripting. You will want to place this kind of script in your "form ready" event, and I like to place it in the subform that contains my "table".
I will not go into all the details of the script you will need because I want you to figure it out yourself. I will give you some hints though. What you are basically doing is looping through your rows. As you loop, you will "look" to see if a node has a parent. If not, it is "top level" node. If it has a parent, we look to see if any other rows have it as their parent (ie. 2nd level). Any other nodes are 3rd level children. Through the script, we will be "shifting" our columns (hide some and span others across multiple columns., ie. colspan) in order to duplicate a "tree view" kind of layout. Think of it like this....
My snippet of script, looks like this...
...and a little more...
And because I know the "type" of node I have as well, I am also applying some "style" to it (making row colors different depending on level). You could do the same to color cells, show/hide images, change fonts, etc. to fit your styling needs.
Now, if I load my form again, I now see what appears to be a "tree view" for all intents and purposes.
I added further scripting on the "click" event of my "select box" in order to show/hide child nodes as well as changing the selection flag. Just for kicks, I threw in some error handling that makes sure a user can not deselect a node if it has child nodes under it that are selected. But I will leave all that "fun" coding to you.
That's about all there is to growing your own tree...view....on an Adobe form. (haha) It just comes down to looking at what your "tree view" is in a different way. Now, using this same kind of "out of the box" thinking, you can mimic other fun UI elements using tables with scripting on your rows (like an "accordion" control for example). Go have some fun with this. Come up with your own use case. As always, in the meantime, I will keep blogging if you keep reading. Till then....
- SAP Managed Tags:
2 Comments
