I found this similar question How to fill in a datetime-local field with capybara?, and the only answer in this thread is not working. So I decided to open this question. It seems like there's no documentation or tutorial about this. Have any solution? It will be a great help!
The keys different browsers accept for setting a datetime input field are diffrent, however if you're using selenium with chrome and you are actually attempting to fill in a visible <input type="datetime-local"> element, as your question states, then the answer in the question your linked to should work - Here is a gist that shows it working - https://gist.github.com/twalpole/a541746b354afde8e82fa89a35a9b2da
The important part in that answer is the format of the string you send since it needs to match the keys the browser is expecting for setting that input (to_json doesn't match that format)
Therefore, in your case of wanting to set DateTime.current it should be something along the lines of
fill_in 'id/name/label of input', with: DateTime.current.strftime("%m%d%Y\t%I%M%P")
If that doesn't work for you then most likely you're not actually attempting to fill a visible <input type="datetime-local"> field (maybe you're using some kind of JS widget that replaces/hides the input???) and you'll need to specify the exact HTML you are trying to fill in your question.
from what I understand, you need to fill in a string representation of the datetime format
examples of such dates are
1990-12-31T23:59:60Z
or
1996-12-19T16:39:57-08:00
so something like
fill_in datetimeinput, with: "1990-12-31T23:59:60Z"
should work (hope so!)
Related
Im using orbeon 4.10 to collect data and fill back a PDF from a template. I would like to choose how the time is displayed on the pdf. I have seen the oxf.xforms.format.input.time and oxf.xforms.format.output.time properties, but they seem to only control the form itself.
I have also seen this, but it seems to relate to the date format.
What value do I need to change in my properties?
Thanks
UPDATE: I don't think my solution below actually works. I think this might have worked at some point but might not work anymore. We do have an RFE for this.
You can use the following property:
<property
as="xs:string"
name="oxf.fr.resource.$app.$form.$lang.print.formats.time"
value="[H01]:[m01]:[s01]]"/>
where:
$app is the app name
$form is the form name
$lang is the language which applies
You can use wildcards (*) for all of those.
As a workaround i used a Hidden field to format my time correctly for the pdf.
Here is the formating code :format-time($controlname, '[H01]:[m01]') that i used in the calculated value
Here is the visibility code : $fr-mode = 'email' for the pdf generated from email or $fr-mode = 'pdf' for pdf button.
I am trying to format an input field of the type xs:date in Orbeon.
I have tried using the xxf:format attribute, but the datepicker can not understand the date when it has been modified.
The idea now was to change the javascript of Orbeon to use the xxf:unformat attribute to interpret the date and transform it back to ISO format.
I've tried changing the data.js but for some reason none of the changes can be seen.
Am I changing the wrong file?
Edit
I figured out that the xforms.js has a function 'getCurrentValue' which is being as the changes I do there are visible. Now I just need to figure out who is the one that's calling the function.
Edit:
It is the Calendar who requests the value of the input when the user clicks on the symbol. This all happens at the client side, and the generated HTML does not have the format/unformat attributes. However I want to use their value. Can I make a request to Orbeon to get it? How?
In case you're using an xf:input bound to a node of type xs:date, you can control the formatting of the date field with the oxf.xforms.format.input.date property. A few formats are supported, and if you want to add more, the best would be to follow the pattern currently used for the currently supported formats.
E.g.
[M]/[D]/[Y]
[Y]-[M01]-[D01]
I have a custom field in Jira and I want to set the value on the field to match the current user.
This seems as though it should be fairly easy, but it has stumped me. I have trawled for information and have been led to using post functions.
Post functions don't seem to actually pre-set the value of fields on the create issue screen unfortunately? I am able to set a value which appears on the issue once it is created using a post function but I cant seem to find a way to set the value on the form itself.
Is this possible?
There is Default Values for 'Create Issue' screen plugin which seems to be doing exactly what you want.
I needed to create a input mask for a jQuery datepicker in my Rails app, where the first form field uses m/d/yy format and the datepicker populates a hidden input with the proper database format.
I was using SimpleForm, and so I extended my own input so that the input is preceded by the mask.
I got everything set up and when checking out the browser, it all just worked well before I thought I would be done.
The form ends up with two inputs for the same attribute, each with the same id and name. I never thought this would work. Checking the development log I only see one date getting submitted, the second of the two which is the one that has the proper format for the database.
Is this all okay? Should I take some extra steps even though this appears to work fine, and more importantly, can someone explain what's going on under the hood that results in this behavior?
Thanks!!
Rails uses the Hash params to store fields submitted. When you declare two or more inputs using the same name, it happens the same as if you do something like
h=Hash.new
h[:name]="foo"
h[:name]="bar"
Result is bar because the foo was overwritten. So the "winner" is always the field value which the browser last appended to postdata.
But if I where you, I would not rely on the browser that the second field gets appended at last.
Tagsoup is interfering with input and formatting it incorrectly. For instance when we have the following markup
Text outside anchor
It is formatted as follows
Text outside anchor
This is a simple example but we have other issues as well. So we made tagsoup cleanup/formatting optional by adding an extra attribute to textarea control.
Here is the diff(https://github.com/binnyg/orbeon-forms/commit/044c29e32ce36e5b391abfc782ee44f0354bddd3).
Textarea would now look like this
<textarea skip-cleanmarkup="true" mediatype="text/html" />
Two questions
Is this the right approach?
If I provide a patch can it make it to orbeon codebase?
Thanks
BinnyG
Erik, Alex, et al
I think there are two questions here:
The first Concern is a question of Tag Soup and the clean up that happens OOTB: Empty tags are converted to singleton tags which when consumed/sent to the client browser as markup gets "fixed" by browsers like firefox but because of the loss of precision they do the wrong thing.
Turning off this clean up helps in this case but for this issue alone is not really the right answer because we it takes away a security feature and a well-formed markup feature... so there may need to be some adjustment to the handling of at least certain empty tags (other than turning them in to invalid singleton tags.)
All this brings us to the second concern which is do we always want those features in play? Our use-case says no. We want the user to be able to spit out whatever markup they want, invalid or not. We're not putting the form in an app that needs to protect the user from cross script coding, we're building a tool that lets users edit web pages -- hence we have turned off the clean-up.
But turning off cleanup wholesale? Well it's important that we can do it if that's what our usecase calls for but the implementation we have is all or nothing. It would be nice to be able to define strategies for cleanup. Make that function plug-able. For example:
* In the XML Config of the system define a "map" of config names to class names which implement the a given strategy. In the XForm Def the author would specify the name from the map.
If TagSoup transforms:
Text outside anchor
Into:
Text outside anchor
Wouldn't that be bug in TagSoup? If that was the case, then I'd say that it is better to fix this issue rather than disable TagSoup. But, it isn't a bug in TagSoup; here is what seems to be happening. Say the browsers sends the following to the client:
<a shape="rect"></a>After<br clear="none">
This goes through TagSoup, the result goes through the XSLT clean-up code, and the following is sent to the browser:
<a shape="rect"/>After<br clear="none"/>
The issue is on the browser, which transforms this into:
<a shape="rect">After</a><br clear="none"/>
The problem is that we serialize this as XML with Dom4jUtils.domToString(cleanedDocument), while it would be more prudent to serialize it as HTML. Here we could use the Saxon serializer. It is also used from HTMLSerializer. Maybe you can try changing this code to use it instead of using Dom4jUtils.domToString(). You'll let us know what you find when a get a chance to do that.
Binesh and I agree, if there is a bug it would be a good idea to address the issue closer to the root. But I think the specific issue he is only part of the matter.
We're thinking it would be best to have some kind of name-to-strategy mapping so that RTEs can call in the server-side processing that is right for them or the default if it's not specified.