Thanks for clearing that up, now I see where this is coming from.
Putting compatibility aside for a second, I’d agree that maybe merging Get Visible Text and Get Full Text could be a worthful simplification (they’re in the end very similar in use and switching between the 2 would be easier), but from my experience they serve a different purpose than Get Text.
So far there were 3 types of scenarios where I wanted to get text from somewhere:
- I know the exact element or a direct selector -> Get Text
- I know the element roughly but it could have f.e. additional nesting or other structure variants -> Get Visible/Get Fulltext (depending on what tests show, usually Get Fulltext, as I fnd it faster and more reliable, unless I need WordsInfo)
- I can’t access the element -> OCR based activities
Not once (so far) I’ve had a situation where I wasn’t sure if I should use Get Text or Get Visible/Fulltext, primarily because Get Text is under Control, while others are Screen Scraping (so implicitly they’ll need parsing).
That’s a pretty big distinction in my perspective, as it needs a different workflow design. ScreenScraping based data reads, even if not OCR based, should be IMHO handled almost the same as OCR (minus character accuracy checks). Being able to easily switch between scraping and direct read may be detrimental to design pipeline, as it’s very easy to get completely different data changing one parameter, introducing more confusion than it would solve.
(of course, that’s just my opinion)
Now for the compatibility:
“Theoretically backwards compatibility is possible” is not reassuring. If I can break a workflow permanently by just opening and saving it in a different version, is a huge risk. In essence it would mean that we’d need to have a forced workflow upgrade that’s very easy to mess up - if I open in the new version, to update properly, I will see different activities, so the only way to do it is to have it open on 2 machines at once.
From what you wrote, there will be no in-place xaml update, so I’d see default Method in all of them? If not, how would it choose which one to set?
This is scary.
And this is for essentially ALL workflows (I can’t think of anything that is not a small test that doesn’t use Get * Text, unless it’s completely OCR based).
Please take a closer look at the backwards compatibility. It is 100% essential to any longterm projects.
As a quick idea even a new, separate activity would be better. Give a grace period when there are both, then remove the old ones (or move them to a compatibility package, like with V7 activities), similar to what code API’s do with Deprecated and Obsolete attributes. This would solve the compatibility and also allow for a much smoother upgrade process.
Aside of that, proposed naming seems ambigious to me a little. I can’t discern at first glance the actual differences between Blocktext background and detailed. It might be just a change resistance at this part, so take it with a grain of salt, but Get Visible Text I think was a really descriptive name. Fulltext might need a rename, but that one was great.
And I’d personally leave Get Text out of the merger. While it may be similar from parameters, it’s purpose is I think different than the other two.