Anyone can make a tree display, but tree navigation involves much more. What you really want on a tree includes all of the following:
1. Only load nodes that are necessary.
2. Provide the option to reload every time the tree is expanded or only load a sub-tree once and never load it again.
3. Include the ability to insert, update or delete a node on the fly programmatically.
4. Include the ability to right-click a node and have a menu appear in the right place.
5. When editing an object and clicking another node on the tree that will then change the object focus, include an alert that prompts me to save or cancel my edits.
6. Provide the ability to change fonts, icons, tool tips etc. on the fly.
7. Easily drive population from an SQL statement without a lot of hand coding.
8. Easily have different queries occurring at different levels of the tree or even on different nodes.
9. Don’t require the use of a single “treeView” for the tree object.
I think we have done this as well as anyone in the Formspider™ tool (www.theformspider.com) but it is still not easy to make all of the tree “stuff” work correctly. Once you have coded it, when you add things to the application, you may find that your easy solutions now no longer work. To be fair, some of the new code isn’t any harder to write than the old code, but there is still some real work necessary to get it all done properly.
For example, in our CRM demo application, Customers are divided into folders which are then divided by status. When I edit a customer, I might change the name (which would change the display of the node) or I might change the status (which might move the customer to another folder on the tree).
The “RIGHT” way to do this would be to detect the various cases and directly update the nodes on the tree accordingly. I elected to be lazy, so the strategy is as follows (in pseudocode):
If customerDataIsDirty then
Delete the customer node (this will remove it from the current tree folder)
Requery the subtree where the updated customer now belongs
Set the focus in the tree to the customer
End if
In the FormSpider, the code for this is easy enough. The following is the code on the “Save” button:
if api_datasource.isdmlnecessary(‘CRM_CUSTOMER’) = ‘Y’ then
V_NODECODE := ‘cust:’||api_datasource.getcolumnvaluenr(‘CRM_CUSTOMER.CRM_CUSTOMER_OID’);
— OK for new records, removing a non-existent node does not throw an error
api_tree.removenode(‘leftTree.mainTree’,v_nodecode);
–set the bind variable and fire the folder query to the spider model layer
api_datasource.setbindvar(‘treeCust.status_cd’,
api_datasource.getcolumnvaluetx(‘CRM_CUSTOMER.STATUS_CD’));
api_datasource.executequery(‘treeCust’);
– Set the name of the folder node
v_parentnode_tx := ‘custStatus:’||api_datasource.getcolumnvaluetx(‘CRM_CUSTOMER.STATUS_CD’);
relogin;
api_application.docommit;
— populate the folder api_treenode.populatechildren(‘leftTree.mainTree’,v_parentnode_tx,’treeCust’);
— set the focus of the node in the tree
api_treenode.setselected(‘leftTree.mainTree’,V_NODECODE);
api_alert.setlabel(‘info’,’Your changes are saved!’);
api_alert.show(‘info’);
else
etc.
As I write this, it doesn’t seem so bad, but there are lots of similar cases where editing something in the application can impact the tree. You can always have a REFRESH button and give up, but I think it is nicer to try to keep the tree in synch.
The bottom line is that I don’t see that tree coding is ever going to be a junior developer task.
Leave a Reply