Working with the Web Editor – Part 2

Watch this video to get introduced the the advanced parts of the Web Editor.

In this video

  • Capture hidden elements
  • Strategy fields
  • Capturing lists of elements
  • Found element/Source properties
  • Querying found web elements

Watch part 1.

Go to next video.


Watch this video to get introduced the the advanced parts of the Web Editor.

In this video

  • Capture hidden elements
  • Strategy fields
  • Capturing lists of elements
  • Found element/Source properties
  • Querying found web elements

Watch part 1.

Go to next video.


In this video we going to take a deep dive into the Web Editor
and look at some of the real advanced features.

If you haven’t watched the “Working with the Web Editor part 1” video yet,
I strongly suggest that you do so.

You can find a link to the video in the description of this video post.

We will continue using the same simple test case as in the previous video.

I have a Start Web Browser block and I have a Find Web Element block right after.
I’m using a simple table for this demo, and you can find the URL in the description of this video.

My first task will be to select a specific row based on the text in the row.
I also showed this in the first video, so I will run through this without to much explanation.

First I will capture a cell – as I can’t get to capture a row directly.

I then select a strategy that contains the row,
and remove the elements below the row.

I then click validate to make sure that new changed conditions will give me a row,
and verify it in the browser.

On the web tree tab, that is shown when we click Validate,
I can see a blue background on the selected element.

I right-click the row element and select Capture.

This will re-evaluate the list of strategies so the list now contains strategies for the row,
and not for the cell I started by capturing.

So if I could have captured the row directly from the browser,
I would very easily have ended in this exact state.

I just wanted to show you, that any element can be captured, but sometimes you have to
start by capturing another element, modify some condition and then re-capture from the web tree.

If I just wanted to select directly from the web tree, I could have pressed Validate
right after I captured the cell at the beginning,
then clicked my way through the web tree to the right row element and then captured it.

If we look at the strategy list, it now contains strategies for the row.
the first strategy is based on the text in the row, and more specifically,
just one string made up of the collective content in the cells.

So if I change the text in the strategy I would end up selecting another row.
What if I could pass in the text that should be in this row.
Well we can.

I will just copy the text in the conditions and then remove it.

I can then right click the field and select “Insert token” followed by add new field.
If you have worked with leaptest previously you probably know how the fields works.
When I press Save, a Field1 property is now added to the Find Web Element block.
This means we can add the text that we want in the strategy directly from the flow.

To demonstrate this, I’ll add a Set Text block to the property, and add in the
value I copied from the conditions.

Let’s run the case.

*** Run case

We can see in the log and on the video, that it found the correct row based on the text input.

You can add these so called strategy fields to any of the elements in the conditions list.
And if you want to add a new parameter you can do these directly in the condition section
or add a property for the selected element from the web tree.

In the Web Editor you can find all fields defined for a Web block on the Token Field tab.
You can add a default value to the field in this list, so if not input is added, the value
specified here will be used.

The next thing we will look at is how you can select lists of elements. For instance
what if we would like to select all blog post on a page or all items in a catalog and then
iterate them one by one.

Well it’s actually relatively simple and I will again use the table to demonstrate.
I would like to iterate all the rows in the table.
I start by selecting one of the strategies, and my goals is to change the
conditions, so it’s not pointing at just one row, but include all the rows.

If I select the “Self-Parent-Ancestor” I can see, that this strategy looks for the
5th occurence of a row in the table body. If I delete the number in the occurence field
and press validate, we can see, that these conditions are now pointing at 10 different rows.

By pressing the arrows I can click through the rows and see them selected one-by-one in the browser.
If I want to use one specfic row, I can press the “Use as occurence”, but in this case
I want to select them all, so I just press save.

With these conditions, I now get a list of rows returned when the building block executes,
and I can now iterate these rows, just like I can iterate any other list in Leaptest.

If I expand the Find Web Element, I can select what occurrence in the list of rows I
would like to work with. I select “All” which means I will now iterate all rows found.

For each row found, the top connector on the building block will be triggered,
so whatever flow I add to this connector, it will be executed for each row.
Further the “Found element” property will contain the individual element,
in this case the row, for each iteration.

Once all rows have been iterated, the Completed connector is then triggered and the flow can continue if needed.

Previously I showed, how to use a strategy field to do filtering in the selection of elements.

When we iterate a list a found elements, in this case the rows,
we have the possibility of filtering the rows as part of the iteration.
You could say that we inspect all the rows and find the ones that we want to use,
instead of just selecting the right ones upfront as we did when we added the field.
It will typically come donw to the exact situation what the best option is.

To do the post filtering I will add a Get Web Text block and remove the Set Text block so it won’t interfear.
I add the “Found element” from the Find Web Element block to the Source property on the Get Web Element block.

This way the individual row is tranferred to the Get Web Text block for each iteration.

I then add a filter. In this case a “Contains” filter, that allows me to specify a string
that must be present in the source element in order for the Get Web Text block to succeed.
I also adjust the timeout – no need to wait 10 seconds if the text is not present. I set
ït to 1 second.

I select one of the words in the table and insert this into the Value field.
So if this word is present in the text of a row,
then the top connector on the Get Web Text block will be triggered.
In this case only one of the rows will match, but it will show the principles.

If the value is not present, then the Not Found connector is triggered.
We will not connect anything to this connector,
which means it will end the current iteration and continue with the next row.

*** Let’s run the case

As we can see in the log, it iterated all the rows and it found one row that matched the filter.

The last thing I will show in this video, is the possibility of doing queries inside the found elements
using the Web Editor. In this case, we can actually use a Find Web Element to search for a specific
element inside the rows that were found in the first added Find Web Element block.
I want to read the value of the 4th cell in the rows that matches the filter in the
Get Web Text.

At the top connector I will add yet another Find Web Element, and then connect the Source property
on the Get Web Text block with the source property on the Find Web Element block.

When we add a web element into the source propery, then the building block will operate
on this source only and not the entire web page.
This can be used to drill down into complex DOM structures.

When I click ‘Capture new web element’, I can select any element on the page.
With our knowledge of the flow and the source element, it doesn’t make sense to select an
element outside of a row. In this case I select one of the cells in the forth column,
and open the Web Editor.

Because we are using the row as the source, we have to manually change the conditions to match this.
For instance we won’t have a TBODY present as part of the element to search in, so we typically just
have to delete from the top of the conditions, until it matches a query in the element that we have added as the source.

To get the 4th column I would look for a strategy containing something about the fourth column
and then delete everythig above it. The “Root-Descended-Child” strategy is always good
for this kind of operations.

By deleting the TBODY and the TR I end with only one conditions: look for the fourth cell in the row.

I click Save and add a Get Web Text block to read the value in the cell. I connect the Found Element
to the source and connect the Text found property to a pass block. This way we can see the value
read from the cell in the pass statement in the log.

Let’s run the case.

*** Run case

In this video we covered how to capture an element from the web tree, when the element is hidden by other web elements when using the UI capture feature.
We looked at how to use Strategy fields to add parameters to the conditions of a strategy, and how to add more conditions to a strategy.

We also saw an example of capturing list of elements and how to use the Found element and Source property to pass the found web elements between building blocks.

Finally we demonstrated how to use the Get Web Text blocks as a filter in an interaction of elements and how to do queries in previously found elements.

Thanks you.