Tips and Tricks (or Treats) for Orion

OK, fall is here and I'm getting excited about going to ECE. This is the teaser post for my talk "Bringing first class JavaScript and web tooling to Orion". At ECE I'll be showing off the tooling work that the Winnipeg Wonders Mike Rennie and Curtis Windatt have been slaving away at so if you're at ECE be sure to come see ! This is on top of the work that we've already done over the last year...see the N&N's here  and here.

Rather than fill this post with spoilers for the ECE talk I'll instead take a look at a few of the lesser known (but quite useful) features of the Orion editor. Aside from all the language tooling work we've been making a lot of progress on the polish of Orion. We have a completely new look, performance optimizations for clients with many projects and new additions to the 'views' available in the UI...



The 'Breadcrumb' has moved:

As you can see from the above comparison we've removed the line that used to show the breadcrumb
in order to give the space back to the editor. You can now access the breadcrumb from hovering over file name in the header of the editor.



Search Scoping:

One of the great things about having Orion be used in Bluemix is that it exposes us to a variety
of enterprise customers, some having many projects (some of those rather large). As part of the ongoing efforts to improve the performance of Orion we identified that in these cases our default
of searching the complete workspace was causing severe performance issues. We've since adopted a
strategy whereby the client can choose to scope their searches to only the same project as that of  the editor they're viewing, greatly speeding not only the performance of user initiated searches but also the searches that our tooling has to perform.



Global Search:

Also as part of the search refactoring we've combined the old 'Quick Search...' to re-use the existing search panel in the UI rather than its own dialog (the panel didn't exist when quick search was implemented). The search panel is more flexible and has the great advantage of maintaining the list of 'hits' so you can look at different results without having to re-run the search (which was a major UX problem with the original approach).

Problems 'View':

OK we have terminology issues here in that Orion seems to have come up with a different paradigms;
'Side Panels' and 'Slideouts' but they're essentially views in the eclipse sense. This is a truly hidden piece of our UI, one that deserves better visibility. It's basically a cousin of the eclipse Problems View. It shows you all the Errors / Warnings that exist in a particular folder. Unfortunately since it's folder based the only access to it is through the context menu of the navigator.

This comes with a few useful options:

•   Filter by message or file name
•   Sort the results grouped by files or errors/warnings
•   Show the full path of the resource

Note that we expect to extend this view to allow access to all the defined 'quick fixes', giving the client an easy way to clean up their code.

Moving Forward:

We're also just starting a push to make sure that our tooling is capable of helping our clients with meeting the new web accessibility standards. This is of real importance now that governments are becoming much more stringent on these requirements as more functionality moves to the web. As usual we'll be using our own tooling to fix any accessibility issues in Orion...;-).

Let's put Orion into Context !

OK, try 2 (for those that noticed my earlier, empty, post...;-).

A small aside to start:

I've recently joined the Eclipse Orion team; after >10 years on the eclipse platform it was time for a change. Working on the eclipse UI was easily the highlight of my career so far. The opportunity to work with many truly exceptional people in such an energetic ecosystem made the work even more rewarding. While I missed out on EclipseCon this year I *will* find my way to at least one more so that I can properly thank (in person...with Beer !) at least some of the crew that has been instrumental in moving eclipse forward over the years; far too many to name individually...you know who you are..and thanks !!

Now on to the future and Orion...

It took me literally no time at all to realize that Orion needed some tooling work. Immediately upon my first attempt to work on some JS code I realized that the tooling that made me look effective in JDT just didn't exist. I was reduced to regex searches and the like to wend my way through the maze of JS / CSS / HTML files comprising Orion. This made going up the learning curve for the codebase seem more like climbing a mountain of molasses. Something had to be done...

...and has ! Take a look at the Orion 8 N&N to see the new tooling in Orion 8 and for those lucky enough to be at EclipseCon don't miss Simon Kaegi's talk: "JavaScript Language Tools. In Orion.". These are just the first fruit of the efforts to make the Orion editor more that just a fancy notepad, more are on the way.

Since the new functionality has already been announced  this post will look more closely at where we're going with the tooling. It's worth noting that all the Orion 8 feedback needed was a change in how the existing hover tooltip got its information and 'quick fix' commands (pretty good bang for the buck IMO).

It's all about the context

Most of the help from JDT comes from its crawling large statically analyzed parse trees(AST's). Since this is largely impossible in JavaScript what can we do ?

There are (loosely speaking) three different types of tooling feedback:

Information: Regular tooltip style giving JSDocs or showing a color when hovering over parts of a
file...

Manipulation: The is for feedback that allows the user to modify their files in some way (think quick fixes and, eventually, refactoring and color/font definition).

Navigation: This is the ability for the editor to recognize and locate files referenced from the one they're editing.

Of these three the one that is most important is 'Navigation'. One of the first problems we encountered was that the code is (of course) always written reflecting the directory structure of where it is *deployed* (i.e. where it lives on the server). In cases where anything but the 'null' deploy is used (the code is in the same structure for development as it is when deployed) we needed some sort of 'File Map' to allow us to properly locate the development file given a reference in a deployed file. This is currently available through the file navigation hovers in Orion 8 but this is just the beginning. It's more than just 'require' and 'import' but should also be capable of deeper introspection such as locating a specific CSS class used in a JS snippet that is assigning a class to a classlist (by searching the available CSS classes for that specific class name).

With the ability to navigate from 'required' references in one file to the actual JS (or 'imported' CSS files) we also gain the ability to walk dependencies looking for useful info to show the user (i.e. JSDoc content assist for methods declared in a required JS file...). As we become more proficient in parsing relevant info we will start to gain the ability to answer some of the trickier questions like "Where is this JS / CSS class used ?" and "Where is this method used ?" (needed for eventual refactoring).



Orion 9 and beyond


Here are some of the things we'll be focused on for future releases...

Type Inferencing

Due to its inherently mushy nature JavaScript is effectively tooling resistent. Our goal is to not
restrict what the developer wants to do but instead warn them if they're doing something that will
make the tooling ineffective. For example Orion uses RequireJS to access instances of various JS
services. The 'required' service instances are assigned to variables in the object doing the requiring. The tooling will work only if the code never assigns a different, unknown, value to this var. To help here the tooling will produce a warning should such an assignment be used (preventing us from doing content assist...on that var).

Note that can (and should) be generalized to account for new techniques to 'typify' JS. If we parse a 'type' (whether from JSDoc or some other type description) the underlying mechanisms will be common enough to show the warning any time a 'typed' var is assigned to regardless of how that type was originally specified (unless of course the value being assigned is of a matching type).

Deeper Context Introspection

It's the union of all the references within a web project that truly define its 'context'. Being able to infer as much as possible about the resources being used in a particular scenario is proportional to the tooling support we can provide. One of the possibilities we're looking at is the ability to specify the HTML doc we're doing our development in the context of. This would provide access to the specific CSS files used by that page (which may be different from those used on a different page), allowing us to provide more accurate feedback; in the end everything has some page at its root.

Since the tooling relies heavily on the file map we'll be making it simpler to create and maintain the map for your particular setup as well as providing this functionality 'in the UI' (i.e. allowing the user to define explicitly the file being referenced and having the UI remember this choice, some sort of support people writing the deploy scripts...). The goal here is to make this as simple (for you) as possible so that the advantages of having access to great tooling far outweigh the effort needed to provide the file map for your project.

As a complete noob to the Web development world one of the first differences I noticed is that web pages are the result of the *merge* between the HTML, JS and CSS files. I found that working on these files in separate tabs was a pain. We'll be working on various ways of allowing the coder to focus more closely on working and less on navigation issues. I don't think it'll take 10 years to show multiple editors on one tab within Orion...;-).

What I'd like to see is something like this:

This uses everything we've seen so far. Type inferencing tells us that '_thumb' is a DIV, meaning that we can infer that 'splitLayout' is a CSS class name. We can then search in the appropriate CSS files to locate the actual CSS class and extract it to show in the tooltip. Ideally in this scenario the tooltip would allow you to edit the contents of the class to allow you to 'tweak' it without ever having to open it.


I wish that this was available when I started...;-)

Orion: Let's Tool it Up !!