We identify our WEB object using DOM but We've found ourself developing our algoritms to find objects in WEB Application.
I have problem to get my team back to QTP identification,Object Repository and Keyword View.
They claim that DOM ensures script run in next product version.
'*********** DOM *********************
Set objTable = Browser("Browser").Object.Document.getElementByID( "table_report")
Using Descriptive Programming (DOM) code does not ensure QTP scripts run in next version but I feel they are more likely to run as the objects are usually identified by 1 key unique property than the 2,3 or 4 that QTP can use depending on the way you have object identification configured.
Another advantage is you can use different properties to indentify the same type of object with Descriptive Programming.
Thrud, don't know if you have noticed but the code posted above looks like it is using the SOR so whats Mercurina's "back to Object Repository" problem ???
As to your question, In my circumstances using Descriptive Programming rather than amending object definitions in the SOR is quicker, my object names are more meaningful, the code is "tidier" (i.e. it does not disappear off the end of the screen), objects are easier to locate and amend compared to drilling down thru the OR trying to locate an object and add/remove properties.... But that's my opinion, others may find doing this in the SOR quicker but non of my QTP friends/associates seem to disagree.
I'm not against recorded code & SOR, for repetative data loading tasks where the interface is pretty static you can't beat it.
As to the DOM, there are some tasks I need to do which I believe can only be achived using DOM rather than QTP recorded code & SOR.
Mark - Certainly one can modify the OR at the object level, allowing each object to be identified by one (different) key unique property, just as one can type a different identifier using DOM. Is there therefore any difference between manually identifying objects in the OR vs under DOM beyond the amount of work it takes to do so?
Mercurina - without knowledge of your product's planned future changes, I agree with Mark in that DOM does not ensure future compatibility; certainly, forethought and careful selection of key properties will help using the OR or using DOM. If you are not editing the objects' descriptions, as Mark seems to indicate, then one would expect DOM to be a better choice. My question is this: WHY are you trying to get your team back to OR? If you can explain this to us, it allows us to provide information and testimonials that are relevant to your specific position, rather than merely debating the pros and cons of OR and DOM.