More iSphere Goodies

Before I proceed with this latest installment on the features of the iSphere toolset that plugs into RDi, I want to first update a few items I’ve covered in earlier tips in this series.

First of all, in my first iSphere tip, I neglected to give credit to one of the primary contributors to the iSphere toolset. I had mentioned the team at TaskForce IT, but failed to acknowledge the significant work done by Thomas Raddatz of Tools400. My apologies to Thomas for that omission.

Second, thanks to continued development efforts, a new version of the iSphere plug-in is now available that includes, among many other things, some handy enhancements to features I described in my earlier iSphere tips. For instance, when searching with iSphere you now have the option of opening a member referenced in your search results in browse mode. Originally the only option was edit. In addition, keyboard shortcuts were added for source file search (Ctrl+I,S) and for message file search (Ctrl+I,M). And remember the decorators (i.e., the text from the members and objects) that I showed in my first iSphere tip? Those decorators are also available for code in iProjects as well as RSE. Documentation for the new release includes a change log with a list of other enhancements and can be downloaded here.

Now let’s look at couple of the other tools I’ve used in iSphere.

Binding Directory Editor

I’ve long been baffled at the lack of support in RSE for binding directories; it seems like something developers certainly use. In the past, I created user actions in RSE that simply prompted CRTBNDDIR (Create Binding Directory) and ADDBNDDIRE (Add Binding Directory Entry). But when it came to actually looking at the entries in a binding directory already, I used the green screen commands. No more! Now I use the iSphere Binding Directory Editor.

As you can see in the graphic, it’s not exactly rocket science. In the RSE view, right-click on a Binding Directory and take the iSphere Binding Directory Editor option to bring up the dialog. In my sample, I right-clicked on an entry and took the Change option. Other options for entries include Copy, Delete, and Display for existing entries, and New to add a new entry to the Binding Directory. Note also the up and down buttons to change the sequence of an entry.

I still use my user action to create a new binding directory, but that’s not a problem because I don’t do it that often and it’s pretty straightforward. Editing existing binding directory entries is much nicer now thanks to iSphere.

Task Tags

I should say up front that I have a bit of a love/hate relationship with Task Tags at the moment. I like the idea but I’m not so wild about some of the implementation details. To be fair I should point out that the folks who created iSphere are not responsible for the implementation details. iSphere didn’t invent Task Tags, it simply enabled the support that already existed for the Java editor for other source member types.

To lay a foundation, let me first explain about Eclipse Tasks generically as enabled in RDi right out of the box, even without iSphere installed. At any time, I can create a task associated with a line of code in a source member. To do that, I right-click in the far left margin in the editor, to the left even of the sequence number, and choose Add Task.

After doing that, a dialog pops up that allows me to put in any comment related to that task that I like, such as: “Externalize this proto after testing” or “Subfile displayed here.” If you don’t put in your own comment, it will simply copy the line of code as the task text, which is rarely very useful. The task will then appear in your Tasks view, such as the one you can see in the next figure below. If you don’t have a Tasks view in your perspective (it’s typically placed below the editor in the same area where your Error List and Commands Log) you can bring it in using the Show View > Other. . . option from the Window menu.

I use ordinary Tasks like this regularly, either to remind me to do things I may forget to do or as a sort of bookmark to a section of code that I find myself needing to return to often. When I don’t need these tasks any more, I can clean them up with a delete via right-click menu or I mark them as complete (click the check box) and later delete all the completed tasks via a right click menu option. I’m forgetful sometimes and Tasks help me stay focused and remember what I need to do. Tasks stay around even after you have closed the source members they are associated with. A double-click on a task positions my cursor to the line of code, opening the source member in the editor if necessary.

Task Tags enable a different kind of task, one that is created automatically when I put a specially marked comment into the code. The special marks that appear by default are FIXME and TODO. So a task would automatically be created in my Tasks view for that line of code if I were to put a comment line in my program such as: “// ToDo Externalize this proto after testing.”. Note that you must save the source member after adding the task-tagged comment before it appears. Likewise, once you remove the comment line (or its task tag) from the source and save the source, the task will be automatically deleted. The next graphic shows some ordinary tasks and some of the Task-Tag-created tasks, which have Type=LPEX Task vs Type=Task.

The Task Tags may be enabled/disabled via a preference under the iSphere preferences and you can configure what source types they work with. You may also configure which Tags are the magic words to create tasks when they appear in a comment line. The ones set up by default are FIXME and TODO. You may remove those and/or add your own on the iSphere preferences page for LPEX Task Tags, just click on the “Configure Task Tags” link near the top, then ignore the bit on the resulting dialog that seems to indicate that they will only work in Java comments!

So, what’s not to like? I use tasks a lot and using comments initially seemed a nicer way to create them. I was bothered at first by the fact that I had to remember to save the source before the task appeared, but that’s not a big deal (especially using the shortcut Ctrl+S). Then I noticed that I didn’t have the same level of control over this type of task in the Tasks view. I couldn’t delete a task or even mark it as complete. This probably makes sense given the nature of them, but it required that I rethink how I interacted with these tasks. Still, not a major issue.

Then I opened up a few source members where another developer had put in his own “ToDo” Task Tags. Even if I only open it to browse, those Task Tags created tasks in my view. It took me a while to realize this was happening and by the time I noticed, I now had dozens of tasks that I didn’t want in my Tasks view, cluttering my view and making it difficult to use my own tasks. Remember that I can’t delete or mark them as completed as I could my ordinary tasks. The only way I could find to get rid of them was to either remove the task tag put there by the other developer–not a very nice thing to do–or I could configure my own Task Tags preference to remove TODO from the list (meaning it wouldn’t work for my own TODO tags either). By the way, even after reconfiguring my preference, it seemed that I needed to re-open each source member that had caused them to appear in order to get them to disappear.

So that’s why I have now removed the default Task Tags in my preferences (FIXME and TODO) and I have created my own unique Task Tags for my use. Truth be told, I still primarily rely on the ordinary tasks I used before more than these LPEX Task Tags enabled by iSphere.

But since at least one of my fellow developers clearly finds them very useful, I thought it was a feature I should share with you so that you can give them a try and make up your own mind.

I’ll cover more iSphere features in later tips, so stay tuned.

Susan Gantner is half of Partner400, a consulting company focused on education on modern programming and database techniques and tools on the IBM i platform. She is also a founding partner in System i Developer, a consortium of System i educators and hosts of the RPG & DB2 Summit conferences. Susan was a programmer for corporations in Atlanta, Georgia, before joining IBM. During her IBM career, she worked in both the Rochester and Toronto labs, providing technical support and education for application developers. Susan left IBM in 1999 to devote more time to teaching and consulting. Together with Jon Paris, she now runs Partner400, and appears regularly at many technical conferences, including System i Developer’s RPG & DB2 Summit. Send your questions or comments for Susan to Ted Holt via the IT Jungle Contact page.

RELATED STORIES

Looking For Stuff With iSphere

iSphere Plug-in Expands RSE/RDi Toolset