After a bit of help here, I am writing a functional web test using Geb and want to test the disabled attribute value of an form submit button both before and after an event has occurred, the flow should be as follows:
Load page, submit button is declared as disabled in page source so should be disabled e.g. <input type="submit" class="submit" disabled="true"/>.
Check a checkbox on the page, this should result in a piece of JQuery code executing which will enable the disabled submit button programatically using: $('input.submit').attr('disabled', false);
My first attempt was to use the assertion $('input.submit').#disabled == 'true', this appeared to work for the initial check after page load however after executing my JQuery code to enable the button a subsequent check still returns the same result. This has caused me to wonder if this kind of check is only able to report the value at page load time and doesn't see any subsequent programmatic changes?
I then discovered Geb's jquery itegration, I was hoping I could use this to return the value of the submit button and do my assert on this e.g. $('input.submit').jquery.attr('disabled') == false however the Geb documentation confirms that all calls to the .jquery property return the Geb Navigator instance so sadly I don't think I can return the information I want.
I have also doubted whether the JQuery code was actually toggling the submit button disabled state, I have tested this extensively using Firebug and can confirm that this is working perfectly in the browser, so I suspect this is either an issue with my understanding of Geb or perhaps a limitation of Geb itself?
It strikes me that checking the value of element attributes after performing some action on a page might be a common use-case, hence I'm rather hoping that I've missed some trivially simple way of doing this. Would be most grateful for any pointers to help me get this sorted.
Cheers,
Edd
Have done a bit more testing and have now achieved a satisfactory result. I was doing a couple of things which I now believe are inproper, namely trying to set the disabled attribute value to illegal values of true and false like this:
$('input.submit').attr('disabled', true);
$('input.submit').attr('disabled', false);
Looking at the HTML forms specification the disabled attribute is shown not to take a value, rather it's presence alone indicates that an element is disabled. Modifying my code to honour this and remove the attribute to indicate enablement of an element seems to have done the trick:
$('input.submit').attr('disabled', true);
//This time we remove the disabled attribute rather than setting it to false.
$('input.submit').removeAttr('disabled');
Note: I am still setting the value of disabled to true since I can't determine how to set the attribute without setting a value, see this SO post for further details.
Using the above I am now able to use Geb to assert the disabled/ enabled status of elements like this:
//Check that something is disabled.
deleteSelectedButton.#disabled == 'true'
//Check that something is enabled.
deleteSelectedButton.#disabled == 'false'
Note: Geb seems to require a string literal indicating the expected status rather than a boolean, which iirc caused my assertions to fail.
So that's it - all is now working nicely and I'm running along writing loads of Geb tests! Hope this explanation is of some use to others.
Rebroadcasting my post on the Geb mailing list:
After you execute the jQuery code that enables the button, is it possible that you are checking the result before the code has actually enabled the button? For example, are doing something like:
waitFor { $("input.submit").#disabled == "false" }
Related
I have multiple buttons and form inputs in one page. All these buttons and form inputs need to be disabled or enabled depending on a condition.
I know that it is possible to use the disabled keyword inside a tag to disable a specific input or button. Also, I can just add the code
:disabled="true"
to disable the inputs depending of the boolean value of a variable.
However, this solution is not acceptable for me, since I will have to add this line of code to every inputs on my page (I may create new pages in the future, containing as many inputs).
I would like to know if there's a way that allows me to simply disable the parent container of all the inputs so that the children item (the inputs) are disabled.
If you inspect the Vue instance itself of the VM when running your code you can have something like this when you console.log(this),
It will give you output similar to this if you use the correct scope:
{
$attrs
$options
.......
$el
}
Inside $el there's object properties for accessing firsElementChild, previousElementChild, previousElementSibling, etc. There's a lot of HTML related properties, however, accessing HTML element this way can get messy pretty fast. I think that your best solution is the one you already mentioned or changing the CSS class dynamically.
If you use v-if to conditional render on a parent you can achieve pretty similar functionality too.
See: Conditional rendering
I have a button which triggers a rest call and upon click of that button until the rest call triggers I disable the button.
I am writing a test case using selenium web driver and nodejs
button = driver.findElement(By.class("btn"));
await button.click();
console.log(await button.isEnabled()) //outputs true
But I can see that the button is being disabled and I am sure Iam selectingthe correct button the findElement statement.
The documentation for .isEnabled() says:
Is the element currently enabled or not? This will generally return true for everything but disabled input elements.
So what you are seeing is expected behaviour.
To test your scenario, you will need the following approach:
click your button
click the same button again
the second click you are expecting to fail, so you will have to wrap it in whatever is the node.js equivalent of try..catch (sorry, I'm a Java guy)
inside of the catch, set a variable to true
afterwards test the variable has been set
The scenario you have described is to click a button, verify it becomes disabled, and then verify it becomes enabled. There are probably a few ways to do this. I'm looking at the documentation and here is one way:
button = driver.findElement(By.class("btn"));
button.click();
driver.wait(until.elementIsDisabled(button));
driver.wait(until.elementIsEnabled(button));
If the button never becomes disabled, an exception will be thrown. If the button never becomes reenabled, an exception will be thrown. So, the fail condition is either one throwing an exception. The pass condition is no exceptions.
NOTE: disabled and enabled, in Selenium terms, is generally referring to an INPUT tag. If your button is not an INPUT tag, then this won't work. You will need to detect some CSS style being applied/removed to determine disabled/enabled.
I have a page where I wanted to use the "enableModifiedFlag" property, to let users know that their edit was not saved if they want to leave a page before saving.
I also have a search box in that page, and when I set the field to the static value "true", the message was popping because the search box was considered part of the page, and the field was modified. This all makes sense.
Since the "enableModifiedFlag" property can be computed, I decieded to set it to true only if the document was in edit mode, as the search box is not available at that time. The behaviour I got was that the message was not appearing anymore. I then tested with returning true as the value of the property, and it didn't change anything: the message was just gone. I then used the static values and set it to true, and the message was then appearing.
My conclusion is that there is a bug that prevents any computed value to be considered for that property.
So I had to find a workaround to prevent the message from popping up when users used the serach box. Here is the solution I came up with.
On the client side, we have access to the XSP object. One of its method is XSP._setDirty(). you can either set it to true or false, and it will affect if the page diplays the popup message or not. So in my search button, I added this code on the onclick event, on the client side:
XSP._setDirty(false,""); //so we don't get the "do you want to leave this page" message
showStandBy(); //show standby in case search is long or slow
return true;
That way, I tell my page not to show the message and the popup is not displayed.
It's still a shame you can't use the computed value for that property, but at least we have a workaround. Hope this will be useful to somebody!!!
GOT SOMETHING WORKING I THINK
This is what I have now, that controls teh flag:
<xp:this.enableModifiedFlag><![CDATA[${javascript:context.getUrlParameter("action")=="editDocument";}]]></xp:this.enableModifiedFlag>
I would rather use the document1.isEditable() function, but I wasn't successful with it so far, neither computed dynamically nor on page load.
At leaset I have something that seems to be working. Time to submit that code to the end users!
I have dojo validation textbox in my xpage with required property computed (compute dynamically) as below
var syn = getComponent("SynCboxGrp").getValue();
if (syn == "Yes")
{return true;
}else{
return false;
}
Here the component SynCboxGrp is radio button. The text box is required based on the radio button value. But its not working properly. Changing radio button value doesnt change the required behaviour.
Appreciate any help
Update
Thanks stwissel, Per Henrik Lausten and Eric.
I only have this ssjs in required property
<xe:djValidationTextBox id="UBOCAgent" value="#{dsRacDoc.UBOCAgent}" disableClientSideValidation="true">
<xe:this.required><![CDATA[#{javascript:var syn = getComponent("SynCboxGrp").getValue();
if (syn == "Yes")
{
return true;
}else{
return false;
}
}]]></xe:this.required>
</xe:djValidationTextBox>
I also tried this partial refresh code on my radio button onclick event XSP.partialRefreshGet("#{id:UBOCAgent}");
This still doesnt change the behaviour. It works based on the initial radio button value. On the negative side since its a get request it updates the field content from the server. I also tried Eric's suggestion disable client validation but that didnt help.
Eric, I am also trying to go with CSJS wherever possible but in this case the required property only has the SSJS option. So not sure how to try CSJS. Should i try creating my own dojo field instead of using one from entension lib? If so i am not sure how to compute required property for that. If you can help me with some sample code that would be great help.
Thanks for your time.
You're doing a partialRefreshGet, which is updating the Dojo Validation Text Box. But you never post back the updated value from the radio, so the server-side value for the radio button is still the initial value. Consequently, required is still false.
Check the markup when required is true on the Dojo Validation Text Box, but the validation triggers client-side, so there should be an attribute in the markup that you can manipulate via CSJS, if that is your preferred route.
Do you have particular latency issues that you need to work around? Picking up on this and the other question you have about doing a lookup to a database on click of a button, you're hitting a few problems. I don't know how experienced you are in XPages development, but it's not an approach I would recommend without a good understanding of client-side output and server-side component trees. The initial page load of your XPage will also be slower and the size of the HTML passed to the browser will be larger, because of the amount of CSJS passed to the browser.
I would recommend using the in-built partial refresh except for situations where browser to server network is a significant issue, and only then falling back to coding your own partial refresh posting a subset of data. In my experience, it's easier and quicker to develop, easier to debug and more flexible.
For this particular scenario, regardless of whether you code the partial refresh yourself or use inbuilt functionality, one point I'm not certain of is this. That once you set validation on the Dojo Validation Text Box, that validation runs client-side and may impact any attempt to un-set the required property by posting to the server. I haven't tested, so can't be certain.
One of two things:
as previously mentioned, to trigger your SSJS value change, ensure a partial (at least) refresh of the element containing your above code; can be done with a container element. Also, check to see if your field's disableClientSideValidation parameter is set (All Properties view).
convert your SSJS code (which merely returns a binary assessment of a Yes or otherwise, I'm assuming No, value) to CSJS
Of late, after the primary development of my current project, I have started favoring the CSJS approach, for the sake of decreasing server-side call backs; most especially in situations where display/rendering of a component is all I'm trying to achieve. If you go this route, remember that dojo.byId("#{id:myControlsServerNameHere}").value (for a text field, see below for scraping a radio button value) combined with setting the display or visible CSS properties can be very handy. As the docs describe, if you want it to exist on the page but not show (for formatting purposes, also, can preserve default value), go the visibility route, otherwise display property.
The CSJS scrape of radio values that I'm currently using is as follows:
var result=null;
for(i=0; i<document.forms[0].elements.length;i++){
if(document.forms[0].elements[i].name=="#{id:serverNameOfRadioElement}"){
if(document.forms[0].elements[i].checked == true){
result=document.forms[0].elements[i].value;
break;
}
}
}
//then handle your result, either with an if, or switch statement
Hope this helps. If there's more you're having trouble with, post back with more code to give the bigger picture.
I hope someone can help me solve a very serious problem we face at the moment with a business critical application losing data when a user works in it.
This happens randomly - I have never reproduced this but the users are in the system a lot more than me.
A document is created with a load of fields on it, and there are 2 rich text fields. We're using Domino 8.5.3 - there are no extension lib controls in use. The document has workflow built in, and all validation is done by a SSJS function called from the data query save event. There is an insane amount of logging to the sessionscope.log and also this is (now) captured for each user in a notes document so I can review what they are doing.
Sometimes, a user gets to a workflow step where they have to fill in a Rich Text field and make a choice in a dropdown field, then they submit the document with a workflow button. When the workflow button is pressed (does a Full Update) some client side JS runs first
// Process any autogenerated submit listeners
if( XSP._processListeners ){ // Not sure if this is valid in all versions of XPages
XSP._processListeners( XSP.querySubmitListeners, document.forms[0].id );
}
(I added this to try and prevent the RTF fields losing their values after reading a blog but so far it's not working)
then the Server-side event runs and calls view.save() to trigger QS code (for validation) and PS code to run the workflow agent on the server.
95% of the time, this works fine.
5% of the time however, the page refreshes all the changes made, both to the RFT field (CKEditor) and the dropdown field are reloaded as they were previously, with no content. It's like the save hasn't happened, and the Full Update button has decided to work like a page refresh instead of a submit.
Under normal circumstances, the log shows that when a workflow button is pressed, the QuerySave code starts and returns True. Then the ID of the workflow button pressed is logged (so I can see which ones are being used when I am reviewing problems), then the PostSave code starts and finally returns true.
When there is a problem, The QuerySave event runs, returns true if the validation has passed, or false if it's failed, and then it stops. The ID of the workflow button is also logged. But the code should continue by calling the PostSave function if the QuerySave returns true - it doesn't even log that it's starting the PostSave function.
And to make matters worse, after the failure to call the PostSave code, the next thing that is logged is the beforePageLoad event running and this apparently reloads the page, which hasn't got the recent edits on it, and so the users loses all the information they have typed!
This has to be the most annoying problem I've ever encountered with XPages as I can find no reason why a successful QuerySave (or even a failure because mandatory fields weren't filled in) would cause the page to refresh like this and lose the content. Please please can someone help point me in the right direction??
It sounds as if in the 5% use cases, the document open for > 30mins and the XSP session is timing out - the submit causes the component tree to be re-created, and the now empty page returned back to the user. Try increasing the time out for the application to see if the issue goes away.
I would design the flow slightly different. In JSF/XPages validation belongs into validators, not into a QuerySave event. Also I'd rather use a submit for the buttons, so you don't need to trigger a view.save() in code. This does not interfere with JSF's sequence of things - but that's style not necessarily source of your problem.... idea about that:
As Jeremy I would as a first stop suspect a timeout, then the next stop is a fatal issue in your QuerySave event, that derails the runtime (for whatever reason). You can try something like this:
var qsResult = false;
// your code goes here, no return statements
// please and if you are happy
qsResult = true;
return qsResult;
The pessimistic approach would eventually tell you if something is wrong. Also: if there is an abort and your querySave just returns, then you might run in this trap
function noReturn() {return; } //nothing comes back!
noReturn() == true; --> false
noReturn() == false; --> false
noReturn() != false; --> true!!!!
What you need to check: what is your performance setting: serialize to disk, keep in memory or keep latest in memory? It could be you running foul of the way JavaScript libraries work.
A SSJS library is loaded whenever it is needed. Variables inside are initialized. A library is unloaded when memory conditions require it and all related variables are discarded. so if you rely on any variable in a JS Function that sits inside a SSJS library between calls you might or might not get the value back, which could describe your error condition. Stuff you want to keep should go into a scope (viewScope seems right here).
To make it a little more trickier:
When you use closures and first class functions these functions have access to the variables from the parent function, unless the library had been unloaded. Also functions (you could park them in a scope too) don't serialize (open flaw) so you need to be careful when putting them into a scope.
If your stuff is really complex you might be better off with a backing bean.
Did that help?
To create a managed bean (or more) check Per's article. Your validator would sit in a application bean:
<faces-config>
<managed-bean>
<managed-bean-name>workflowvalidator</managed-bean-name>
<managed-bean-class>com.company.WfValidator</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
</managed-bean>
</faces-config>
Inside you would use a map for the error messages
public Map<String,String> getErrorMessages() {
if (this.errorStrings == null) { // errorStrings implements the MAP interface
this.loadErrorDefinitions(); //Private method, loads from Domino
}
return this.errorStrings;
}
then you can use EL in the Error message string of your validators:
workflowvalidator.errorMessage("some-id");
this allows XPages to pick the right one directly in EL, which is faster than SSJS. You could then go and implement your own custom Java validator that talks to that bean (this would allow you bypass SSJS here). Other than the example I wouldn't put the notes code in it, but talk to your WfValidator class. To do that you need to get a handle to it in Java:
private WfValidator getValidatorBean() {
FacesContext fc = FacesContext.getCurrentInstance();
return (WfValidator) fc.getApplication()
.getVariableResolver()
.resolveVariable(fc, "workflowvalidator");
}
Using the resolver you get access to the loaded bean. Hope that helps!
My experience is that this problem is due to keeping page in memory. Sometimes for some reason the page gets wiped out of memory. I'm seeing this when there is a lot of partial refreshes with rather complex backend Java processing. This processing somehow seems to take the space from memory that is used by the XPage.
The problem might have been fixed in later releases but I'm seeing it at least in 8.5.2.
In your case I would figure out some other workaround for the CKEditor bug and use "Keep pages on disk" option. Or if you can upgrade to 9.0.1 it might fix both problems.