The changes to the management of the Object Repository are among the most significant in the new version, and though I haven't been through enough with the product to have a comprehensive opinion, I wanted to post my initial thoughts, and to invite comments from anyone whose experience is similar or different.
First off, let me say that on our team, where possible, we use programmatic descriptions. We minimize our interaction with the OR because we find that this is usually the first area that breaks when something changes in the interface. But we still do use the OR, and we rely on having an easy way to interact with it. I'm happy to report that they have made improvements in version 9, but there are still cases where they didn't go far enough.
The Set Up
In the description below, I opened a new test and associated my AUT's shared repository with the default action. My first inclination was to remove the association between the action's default Local Repository, but then I found that you can't remove the association. In an initial fit of consternation I talked it over with Will, and he was happy about the new behavior.
The Team-Oriented Object Repository
The local vs shared OR is their solution for how to make a team repository easier to manage: during test development, you have read-only access to the objects currently in the repository, but new objects are added to the local repository for that action. At some point later, one test developer goes back in and merges all the objects that should be shared, and either trims the rest from the local, or leaves them there if there's no chance of them being used outside that action.
I'm undecided about this method, but I understand why they've done it. One thing is for sure: this beats the heck out of trying to run the external merge tool every few days, not having any idea when new objects are being created, and all the other stuff we had to do in 8.2 to get it working.
The New Object Repository Interface
When you open the new Object Repository, the first thing you'll notice (besides the fact that it now takes about 5 seconds on my machine, as opposed to less than half a second for version 8.2), is the tree view on the left and the properties frame on the right. Further, the default size for the OR is more like what you'd expect: with the hierarchy collapsed to 3-deep, you can really see things well. The frame is big, and you probably don't have to scroll around much. When you click on an object, the properties frame on the right automatically refreshes to show the selected object's properties.
You'll further notice that the tree is mostly grayed out - that's the shared repository in read-only mode. Local objects are read-write, and any new objects you add go into that. The nice thing about this is how the trees merge seamlessly - if you're adding a new WebElement under a particular browser/page object, one that exists in the shared OR, its hierarchy is copied into the local rep so that it looks like your new WebElement is actually under the same parent as all the other WebElements on that page. This allows you to view the OR the way you always have, and since the files are separated, you won't be stepping on someone else's code, forcing a merge.
Here's the BIG problem with the interface: For the read-only objects (in the shared OR), you can't get extended attribute properties. You can't view them at all. The only properties you can see are the Description Properties, used to identify the object, the Ordinal Identifier, and whatever Additional Details you have turned on with Smart Identification for that object type. Now, I believe 8.2 worked in the same way if you were working with a read-only repository, but since that's the rule now and not the exception (on our team, anyway), it becomes tiresome to go through the steps necessary to view the additional details.
This probably wouldn't gall me so much if I didn't see all that space below the properties that are listed... space where they could have put reams and reams of information, separating TO Properties and Method calls, allowing you to view anything and everything at will. It's a missed opportunity to put all that good information right there on the page.
So what do you have to do to see the properties? Well, you have two options, one easy, one hard. The easy one is this: select the object whose properties you want to view, then click ObjectsCopy to Local from the menu bar (there's no hot key), then click the plus + sign in the Properties frame... this will allow you to CRUD all the TO properties. The side effect of this is that, if you end up making a change to the object, the change will only be made in your local repository, and will not be carried back to the shared OR.
The other option is to open up the Object Manager, a standalone app that allows you to merge ORs, edit properties, reparent, etc., independently from the main QTP interface. I'll be doing a separate write-up about the new OM, because though it's similar to the OR editor, it has its own set of features, annoyances, and tricky behaviors.
Locate in Repository - the Coolest New Feature
This is the coolest thing in the new OR - the ability to click on an object in the AUT, and have it highlighted in the OR. Was it just me, or did everyone else spend an awful lot of time searching for objects in the OR, navingating through trees and trees of crap, when the object on the page was just sitting there laughing at you? Now you click the "Locate in Repository" button, click on the object in the AUT, and it goes right there - if it can find it. It's a safe bet that if QTP can locate the object during a test run, it can locate it in an OR. It doesn't always work, but it's better than the nothing we had before.
Update from Application
Another cool feature: Select an object in the OR hierarchy, then click on its counterpart in the AUT, and its properties will be updated from the AUT. This is useful for when something is out of date, but I can see it being a pain if a whole page's worth of objects has changed and you have to update them all one-by-one. I don't know if there's an effecient way out of this yet, but it's possible that I've missed it. At any rate, I like the fact that it's there.
...and the Bad
They didn't put the "Locate in Application", "Copy to Local", "Highlight in Application", or any of the other object-specific functions in the right-click menu when these objects are highlighted... and it makes me want to scream. There are no appreciable hot keys, no ways to make management of these things more efficient, and you end up getting just about as frustrated as you did in version 8.2.
A really big problem, one that I'm afraid is going to cause many headaches for some really smart people, is that under the File Menu there's an option called "Export Local Objects". When my eye first hit that, I read it the same way I read "Copy to Local" from earlier, that it would perform some sort of merge with the shared OR. So, I could copy the objects to the local OR, edit them at will, then export them back out to the shared OR. No problem, right? Well, this options actually creates a new OR (the binary .tsr file format, not an XML file, by the way), containing the objects from the Local Repository. The intent is that you can create a standalone OR, and maybe use that as a shared OR for other actions. The actuality is that I once overwrote my humongous shared OR with objects from a local one, because like most normal people, I didn't read the warning message that said "this will replace the selected OR!!", clicked OK, and immediately heard groaning coming from a cube or two away. We're all version controlled here, so it was fine, but I'll bet dollars to donuts that someone less organized is going to lose a Lot Of Work as a result of this little detail.
Overall
In the end I haven't worked with the new OR enough to have a firm grasp of what's great and what's bad about it. These are my initial impressions, and I would invite anyone (even from Mercury, since we know you're reading ;) ) to help me to understand if I'm wrong on the new features. I've tried to stick mainly to the in situ OR dialog, because this is already long enough, so next time I'll cover the standalone Object Manager application.
