Either I am not using d3's selection.filter correctly, or it is buggy. I can distill the issue to a few lines. I'm in the Chrome debugger with d3 loaded. Let's start with an empty selection
d3.selectAll("nonexistant").empty()
> true
and bind some data to it.
d3.selectAll("nonexistant").data([1,2,3,4])
> [Array[4]]
Good, so it has size four. Let's check with selection.size:
d3.selectAll("nonexistant").data([1,2,3,4]).size()
> 0
Hmm, I guess that's because there are no DOM elements yet the update selection is empty since there were no previous elements. So let's make access the enter selection.
d3.selectAll("nonexistant").data([1,2,3,4]).enter()
> [Array[4]]
d3.selectAll("nonexistant").data([1,2,3,4]).enter().size()
> TypeError: undefined is not a function
d3.selectAll("nonexistant").data([1,2,3,4]).enter().append("p").size()
> 4
Not sure why the enter selection causes an error, (UPDATE: Fixed in v3.4.12) but anyway, if we try filtering using the example function in the docs,
function odds(d, i) { return i & 1; }
d3.selectAll("nonexistant").data([1,2,3,4]).filter(odds);
> [Array[0]]
d3.selectAll("nonexistant").data([1,2,3,4]).enter().filter(odds);
> []
d3.selectAll("nonexistant").data([1,2,3,4]).enter().append("p").filter(odds)
> [Array[2]]
Why is it silently filtering out all elements when there are no DOM elements bound? It does seem to be working when I already have DOM elements. But that feels pretty useless, since I don't want to create elements for data I'm discarding. Maybe if I put the filter earlier?
d3.selectAll("nonexistant").data([1,2,3,4]).filter(odds).enter().append("p").size()
> TypeError: undefined is not a function
d3.selectAll("nonexistant").data([1,2,3,4]).enter().filter(odds).append("p").size()
> TypeError: undefined is not a function
Nope. It seems the way to go is with JS's native filter on arrays:
d3.selectAll("nonexistant").data([1,2,3,4].filter(odds)).enter().append("p").size()
> 2
The d3 docs do not seem to differentiate between selections that have DOM elements bound and those that do not. It seems that I should be able to stick filter anywhere in my method chain (and call size on any selection), and get the correct result without a type error. Granted, filter also supports CSS selectors that will require DOM elements, but I'm not using them here.
What I want to know: There is a mismatch between what d3 is doing and what I expect. To what extent am I harboring misconceptions about selections and what operations are valid on them? To what extent is the documentation unclear? Does any of this behavior qualify as a bug?
From the documentation of the .enter() method:
... the entering selection only defines append, insert, select and call operators; you must use these operators to instantiate the entering nodes before modifying any content. (Enter selections also support empty to check if they are empty.)
Calling anything else doesn't produce useful results. Whether or not that's a bug, a side-effect or a feature is perhaps debatable. In almost all cases, it doesn't create any barriers, except maybe if you need to know this selection's size() to find out how many datums from the array you pass to data() didn't already have elements created.
Once you call append() on the entering selection though, it behaves well, like any normal selection. In fact, append() is returning a new selection, so it !== the return value of enter().
That's when you can also check the size() of this selection, so really it only counts as an issue if you needed to know the size PRIOR to calling append().
You're correct that using the native array filter is the solution IF you don't need to even append elements where odds(d) == false.
Filter is useful when you've already created the DOM nodes (e.g. <p>s) that are bound to [1,2,3,4], and (e.g. in an event handler, when user clicks a "highlight all odds" button ) you call
d3.selectAll('p').filter(odds).css('color', 'red')
BTW, that was a really well written question.
Related
Suppose I have a long array.
> using MakieGallery
> size(database)
(210,)
If I do
> [d.title for d=database]
it will print it truncated, and if I show it, it will print it into a mess:
> show([d.title for d=database])
I don't know how, but probably I could print values into a column and it would scroll my console far up.
All this is bad. Is it possible to do some sort of simple "watch" of a variable? I.e. open some small widget in separate window with a list control, diplaying an array, which I could scroll as needed?
Internally Julia uses Base.show to display the values in the REPL, you can simply extend this function in any way you like (this example is just a really simple implementation to print every element of array in a new line and you probably shouldn't use it):
Base.show(io::IO, ::MIME"text/plain", x::Array) = x .|> println
You can then go on and add your function to .julia/config/startup.jl to load this every time you start the REPL. Just make sure to have a really solid implementation to handle various edge cases where it might not function properly.
Pluto.jl has a very nice viewer for tabular data (including arrays). It truncats the output per default, but offers a button to show more.
Furthermore, the view automatically updates when you change the data in another cell.
I am attempting to capture all the list items in the WebList elements throughout the entire application, however, while below code works on the WebLists, it does not work on this WebEdit.
When you click on the WebEdit, a long list of values appear (similar to a WebList) and as you type for your value, the list becomes shorter. That is how the WebEdit was set up.
But now, how do I get the values in this list?
Here is the code I have for the WebLists:
Code
Set WebLink = Browser("browser").Page("page")
listval = WebLink.WebElement("xpath:= ((//*[contains(text(), 'Name')]))[1]/following::SELECT[1]").GetROProperty("all items")
listvalues = split(listval,";")
For j = LBound(listvalues,1) To UBound(listvalues,1)
'Print listvalues(j)
writeToTextFile(listvalues(j))
Next
ExitTest
The short answer is: it depends on the implementation.
The long one:
There is no universal widget for comboboxes (Like there is for edit fields or lists / selects, radiobuttons etc) => there is no universal solution but only guidelines.
You need to spy on those objects that appear in the combobox, see their XPath and / or other properties (the css classname they belong to, for example) and then execute a second query that selects all such items. Afterwards you have to extract the value of the selected elements; which might be as simple as getting the innertext Property or you may need to dig even deeper in the HTML hierarchies.
You would need to pay careful attention for synchronisation(Waiting until all search result elements appear), Filtering (using the XPath, Description Objects and ChildObjects method on your WebPage) and then extraction( getting the property /element that contains the actual value of that WebElement)
So again: These combobox solutions are not universal therefore without seeing their code the best what one can provide to you is universal guidelines which should work in most of the situations. (You would need some familiarity with Web Programming and the UFT Framework / Robot)
every time i want to get the Value of my DomAttr i get an TypeError:
My Code:
Wanted = page.getByXPath("//span[contains(.,'Some')]/parent::a/#href");
return this
[DomAttr[name=href value=URLSTRING]]
Now i want to geht the value (=URLSTRING) with Wanted.getNodeName();
but every Time i get the Error
Cannot find function getNodeValue in object [DomAttr[name=href value=
same when i use getValue
please help me
There are some things that make no sense in the code (particularly, because it is not complete). However, I think I can guess what the issue is.
getByXPath is actually returning a List (funny thing you missed the part of the code in which you specify it as a list and replaced it with a Wanted).
Note you should probably also have type warnings in the code too.
Now, you can see that the returned value is in square brackets. That means it is a List (confirming first assumption).
Finally, although you happened to miss that part of the code too, I guess you are directly applying the getValue to the list instead of the DomAttr elements in the list.
How to solve it: If you need more than 1 result iterate over the elements of the list (that Wanted word over there). If you need 1 result then user the getFirstByXPath method.
Were my guesses right?
When using the dollar-dollar-function in prototype I alway get an array of elements back, instead of just one element with the dollar-function. How can I combine the power of CSS-selectors of $$ but still get only one element back?
Changing the structure of the source is not possible, so I can't just select it with the id. It needs to get selected with CSS, but should just return one element.
You can also do
$$('.foo').first()
It looks cleaner than $$('.foo')[0] for my taste :)
It does not make sense to return a single element when selecting by class name because potentially there could be many elements in the DOM that have this class. So you could always use the first element of the returned array if you are sure that it will be unique.
$$('.foo')[0]
I have the following code which detects all the elements in a Silverlight application beneath a certain point
then filters them to be only those of a particular type - CardButton
IEnumerable<UIElement> elementsBeneathCursor =
VisualTreeHelper.FindElementsInHostCoordinates(new Point(xPosn, yPosn), Application.Current.RootVisual);
IEnumerable<CardButton> cardsBeneathCursor = elementsBeneathCursor.OfType<CardButton>();
Even though when I inspect elementsBeneathCursor in the debugger, I can see there are 2 elements of type CardButton
Yet when I apply the OfType<> filter the resultant list is null
what's going wrong?
The resulting list won't actually be null... but the sequence will be empty, if neither of those elements is actually a CardButton. Note that OfType doesn't perform any custom conversions, so if you were expecting those to happen, that may explain it.
Try going through the unfiltered list and printing out the result of calling GetType on each element to see what it really is.