While end-to-end testing our app, I am often waiting for a state transition (a modal to close, a button to appear, etc). Blind experimentation has led me to sometimes use browser.wait(ExpectedConditions.presenceOf(someElement), and other times use browser.wait(someElement.isPresent()).
To me, the names imply they're interchangeable. But it isn't so. Is there something about the situations in which I use these that will help me tell which to use when?
In my experience, I have used element.isPresent() for when I do not want to specifically verify something. For example I can write:
element.isPresent().then(function(elm){
if(elm) { //if the element is present, do something }
else { //if the element is not present, do something else }
});
But if I need some element to be present/visible/clickable in order to execute an expect or something else, then I would use a browser.wait(EC.presenceOf/visibilityOf/elementToBeClickable(element))
It also depends on the element you need to wait for. If its a button that you need to click, you'll have to use elementToBeClickable
If we take a look at the code, we will see that isPresent method looks like this
isPresent(): wdpromise.Promise<boolean> {
return this.count().then((count) => {
return count > 0;
});
}
While presenceOf is dependent on isPresent
presenceOf(elementFinder: ElementFinder): Function {
return elementFinder.isPresent.bind(elementFinder);
};
In fact they are doing the same. But note, that ExpectedConditions operators, like not, or and etc. expecting ExpectedConditions function as an argument whichpresenceOf is, while isPresent is not.
Sometimes you need more complicated conditions, than to check that one particular element is present browser.wait(someElement.isPresent()). This is where ExpectedConditions constructions are incredibly useful and this is where you would need presenceOf.
Related
This is going to sound very weird but it will make the code for this app very compact.
Is there a way to call a .operator conditionally. Here is an example
say I have a class with three values that I can do a . on.
class A {
int intOne;
int intTwo;
int intThree;
}
to get the intOne in class A you can do A.intOne right....
but what if you you wanted the string at the right of the . to conditionally be there.
A."conditionalvariable"
so if a user clicks a button say button A then the conditional variable will be A.intOne.
and if the user clicks button b then the value of "conditionalvariable" will be intTwo and therefore you will be getting the data.
please assume that I am not stupid, and I am needing this exact thing for a specific use case. If you post an answer that is not this exact solution it will not be accepted.
example:
var a;
switch (name) {
case "intOne":
a = A.intOne;
break;
...
}
//this is not an acceptable answer
I realize that this would be an "answer" to this question, but it actually isn't I need the exact thing stated because I am using streams.
here is that use case I was talking about. I could explain away all day as to why I need it this way, but either way this either does exist or doesn't so a simple no this doesn't exist is an acceptable answer.
return StreamProvider.value(
value: classDataNotif.homework,
)
based on what is clicked before this widget the "homework" will need to change to "notes", or "tests".
You cannot do a switch above this because it will be calling the stream to early and cause the widget to crash. doing a switch inside the widget and copying code over would defeat the purpose. in order to make the code as compact and as easy to write as possible i need the string at the right of the . operator to change.
thanks in advance :)
I have a piece of code which returns nothing useful:
/**
* Close the web server
*
* #param {function} callback - Called after web server is stopped
*/
PolyApp.prototype.stop = function(callback) {
if (!this._listeningServer) {
if (callback) {
return callback();
}
return;
}
this._listeningServer.close(callback);
};
This function makes use of return to control the execution flow. Given it returns nothing useful I want to avoid documenting it. That gives me the following benefits:
The documentation is more clear as it documents the intention of use
The code is less cluttered with comments that provide no value
I avoid signing a contract of returning something that I do not want to maintain.
On the other hand:
I am returning a value which is not being documented
I think that I should not document it as I do not want people to rely on any returning behavior.
What do you think about? Am I doing right being pragmatic?
What you want to document is up to you. You have to ask yourself the question: "Will I, or other people, ever need to see this documentation to get additional knowledge?". In the case of callbacks that don't need any specific return behavior, you don't need to document anything of it. You should speficy for stop that it'll return whatever the callback returns. People might get confused otherwise.
Ok, I've been stuggling with this one for a while, and have spent a lot of time trying different things to do something that I have done very easily using PHP.
I am trying to iterate over a list while keeping track of a variable locally, while spitting out HTML attempting to populate a table.
Attempt #1:
#{
var curDate : Date = null
for(ind <- indicators){
if(curDate == null || !curDate.equals(ind.getFirstFound())){
curDate = ind.getFirstFound()
<tr><th colspan='5' class='day'>#(ind.getFirstFound())</th></tr>
<tr><th>Document ID</th><th>Value</th><th>Owner</th><th>Document Title / Comment</th></tr>
}
}
}
I attempt too user a scala block statement to allow me to keep curDate as a variable within the created scope. This block correctly maintains curDate state, but does not allow me to output anything to the DOM. I did not actually expect this to compile, due to my unescaped, randomly thrown in HTML, but it does. this loop simply places nothing on the DOM, although the decision structure is correctly executed on the server.
I tried escaping using #Html('...'), but that produced compile errors.
Attempt #2:
A lot of google searches led me to the "for comprehension":
#for(ind <- indicators; curDate = ind.getFirstFound()){
#if(curDate == null || !curDate.equals(ind.getFirstFound())){
#(curDate = ind.getFirstFound())
}
<tr><th colspan='5' class='day'>#(ind.getFirstFound())</th></tr>
<tr><th>Document ID</th><th>Value</th><th>Owner</th><th>Document Title / Comment</th></tr>
}
Without the if statement in this block, this is the closest I got to doing what I actually wanted, but apparently I am not allowed to reassign a non-reference type, which is why I was hoping attempt #1's reference declaration of curDate : Date = null would work. This attempt gets me the HTML on the page (again, if i remove the nested if statement) but doesn't get me the
My question is, how do i implement this intention? I am very painfully aware of my lack of Scala knowledge, which is being exacerbated by Play templating syntax. I am not sure what to do.
Thanks in advance!
Play's template language is very geared towards functional programming. It might be possible to achieve what you want to achieve using mutable state, but you'll probably be best going with the flow, and using a functional solution.
If you want to maintain state between iterations of a loop in functional programming, that can be done by doing a fold - you start with some state, and on each iteration, you get the previous state and the next element, and you then return the new state based on those two things.
So, looking at your first solution, it looks like what you're trying to do is only print an element out if it's date is different from the previous one, is that correct? Another way of putting this is you want to filter out all the elements that have a date that's the same date as the previous one. Expressing that in terms of a fold, we're going to fold the elements into a sequence (our initial state), and if the last element of the folded sequence has a different date to the current one, we add it, otherwise we ignore it.
Our fold looks like this:
indicators.foldLeft(Vector.empty[Indicator]) { (collected, next) =>
if (collected.lastOption.forall(_.getFirstFound != next.getFirstFound)) {
collected :+ next
} else {
collected
}
}
Just to explain the above, we're folding into a Vector because Vector has constant time append and last, List has n time. The forall will return true if there is no last element in collected, otherwise if there is, it will return true if the passed in lambda evaluates to true. And in Scala, == invokes .equals (after doing a null check), so you don't need to use .equals in Scala.
So, putting this in a template:
#for(ind <- indicators.foldLeft(Vector.empty[Indicator]) { (collected, next) =>
if (collected.lastOption.forall(_.getFirstFound != next.getFirstFound)) {
collected :+ next
} else {
collected
}
}){
...
}
In my current project I have to deal with more complex forms. Fields (i'll name them 'A' and 'B') are automatically filled if a specific field (i'll name that one 'C') received user input. But also if the user inputs data into field A, the fields B and C are automatically filled out.
(This is only a simple example, the current logic is a bit more complicated)
What I have to take care of is that no cycles happen (C -> A -> C -> A -> ...). So I need to now if the current value change was due to user input or another field that had received input and then triggered the value change of the current field. And I also need to now in the second case which field exactly triggered the value change because then I must trigger other specific actions corresponding from who/what triggered that value change.
Is there a general approach in Vaadin to deal with this kind of form
structure? The problem at the moment is that I simply don't now who
or what triggered what ValueChangeEvent.
Are there frameworks to deal with this or am I overlooking an existing Vaadin pattern?
Handling of valueChange events in Vaadin is a bit of pain, since it always fires, no matter if the user has changed something, or the application has used setValue(....) on the component.
The only solution for this is to remember when you do a setValue(....) in your application and then disable the trigger code in the other components.
For example in this case (endless loop):
field1.addValueChangeListener( field2.setValue('Updated by field1');
field2.addValueChangeListener( field1.setValue('Updated by field2');
Change it that way:
boolean inTrigger= false;
field1.addValueChangeListener(
{
if (!inTrigger)
{
inTrigger= true;
field2.setValue('Updated by field1');
inTrigger= false;
}
});
field2.addValueChangeListener(
{
if (!inTrigger)
{
inTrigger= true;
field1.setValue('Updated by field2');
inTrigger= false;
}
});
That way you can prevent update loops and let execute your code exactly once.
I've been using filters in Sinatra the way it has been declared in the documentation: with no match string, with a match string or with a match regexp. It has been working fine til now. Now, I have a particular use case. Let's say I have this route:
/resources/1
According to REST, and depending of the request method, this can either be a GET method, PUT method or DELETE method. First question is: How to write filters that are only called when it is a GET request? (currently I'm letting all of them get filtered and only then I test the method. It works, but I don't like it). Second question, and more important: let's say a PUT request like this is triggered:
/resources/
This is of course wrong, because the PUT request has no resource id associated. I would like to know if there is something in Sinatra that enables me to do something like this:
before "/resources/", :method => :put do
error_message
end
just this possibility does not exist (before accepts only one argument). How could I achieve this result at best?
Actually, filters do take conditions. You don't have to use a condition though, you could use a conditional within the filter:
before "/path/" do
if request.request_method == "PUT"
# do something
end
end
If you want to use a condition, I think you'll need to write one, perhaps something like this:
set(:accepted_verbs) {|*verbs|
condition {
verbs.any?{|v| v == request.request_method }
}
}
before "/path/", :accepted_verbs => ["GET","POST"] do
# do something
end
before "/path/", :accepted_verbs => ["PUT"] do
# do something else
end
See conditions for more.