-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Functional prototype for static values in Scripts #3059
Conversation
@@ -4,6 +4,8 @@ | |||
module ScriptsHelper | |||
def create_editable_widget(form, attrib, format: nil) | |||
widget = attrib.widget | |||
name = "#{form.object_name}[#{attrib.id}][value]" | |||
#attrib.html_options = { class: 'real-field', autocomplete: 'off', name: name } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please ignore this part, I was doing some testing on submitting the form parameters as a hash to avoid the field_property
notation used for exclude/min/max/fixed
Probably a checkbox and we can use the currently selected/input value as the value we fix to (saying the same in a help message).
Yes - though I think it's just a boolean. |
Checking your demo in the other ticket - the UI you show is about what I was thinking. |
:cluster, :auto_accounts, :auto_accounts_exclude, :auto_accounts_fixed, :auto_scripts, :auto_scripts_exclude, :auto_scripts_fixed, | ||
:auto_queues, :auto_queues_exclude, :auto_queues_fixed, :auto_batch_clusters, :auto_batch_clusters_exclude, :auto_batch_clusters_fixed, | ||
:bc_num_slots, :bc_num_slots_min, :bc_num_slots_max, | ||
:bc_num_hours, :bc_num_hours_min, :bc_num_hours_max |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can start with fixing bc_num_slots
and bc_num_hours
instead if it's easier to start with number fields instead of select fields.
I can start to comment on this if you're ready. I think yes, we should use the |
OK - thanks. Let me improve a bit the implementation and then it will bre ready for review |
@johrstrom this is ready for a review |
c1e2ecd
to
2127fc1
Compare
2127fc1
to
c17ce11
Compare
I have improve a bit the code, added the comment and added a check in the |
apps/dashboard/app/views/scripts/editable_form_fields/_editable_number.html.erb
Outdated
Show resolved
Hide resolved
5900c45
to
6e0f2b6
Compare
Tests are currently failing for another reason - I'm fixing that shortly. |
} | ||
|
||
function toggleFixed(event) { | ||
event.target.disabled = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we disabling the event target here just to re-enable it afterwards?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is usually a good practice to avoid double submitting/processing while the first click is being handled.
In this particular case might too much. I can remove if you think it is not needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is usually a good practice to avoid double submitting/processing while the first click is being handled.
First click? Are you saying this event is triggered twice by 1 click (click up and click down events?) or do you mean double clicking?
We can keep it if it serves some purpose, as you say as a good practice, I'm just curious mostly now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant double clicking. But I think in this particular case even a double click will have no side effects.
dataElement.disabled = true; | ||
const input = $('<input>').attr('type','hidden').attr('name', dataElement.name).attr('value', dataElement.value); | ||
$(checkbox).after(input); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to change the HTML tag type or can we just toggle the readonly
attribute?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Select elements do not have readonly state, so to get the current behaviour we need to disable
and add hidden
field.
Do we need to change the HTML tag
Not sure if this means to change from select
to input type=text
to make it readonly
, but it seems a more complex solution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Select elements do not have readonly state, so to get the current behaviour we need to disable and add hidden field.
Editing the page on FF seems to respect the readonly
- though MDN docs say it shouldn't. Further reading suggests it was deprecated in html5? But it's unclear how to find official RFC for the same.
Not sure if this means to change from select to input type=text to make it readonly, but it seems a more complex solution
I thought that's what this was doing - but now see it adds a hidden element instead of replacing the original. I guess this is because the browser won't send a disabled form element? Seems like it'll send readonly
- but I cannot actually find if it's actually been deprecated on select fields or what.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - I think what you have is what we should go with. That is (if I'm reading it right),
- disabling the original element
- creating a new hidden element with the same name so that it'll be passed in the form
and of course the inverse too.
Maybe there's a way to clean this up so it's a little more apparent what's going on? It's created in one place and removed in another. Maybe just colocate these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - I think what you have is what we should go with
I think this because I cannot find any docs on why my example shown works. The currrent RFC (below) for html5 doesn't specify it and MDN docs (also below) explicitly call it out as not working.
Which is to say - relying on adding readonly
to a select widget is likely unstable (not to mention how other browsers react, I only looked doing this on firefox).
https://www.w3.org/TR/html5-author/the-select-element.html#the-select-element
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/readonly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is disabling and adding a hidden field with the same name as the disabled field will not be sent in the request.
I tried the readonly first as it was more intuitive, but in my Firefox did not work. Reading later I came across that select elements do not have a readonly and I found the recommended way of adding the hidden field when disabled.
I will colocate the methods and add comments to make it more obvious what is happening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some comments. The add/remove code is close to each other. Not in the same method to reuse the add in the initialization code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
Fixes #2948
Prototype to implement fixes values within new Job Composer scripts.
I am not sure about the UI as the combination of the dropdown + Add/Remove actions + Set as static are all linked.
I am not sure either of using the SmartAttributes
fixed
property to implement this feature, but seems like the right approach.This PR shows what I had to do to make it work with SmartAttributes and the
fixed
property, but it is more a hack than a PR.@johrstrom what is your idea for the UI?
And for the backend? Should the fixed property be use for this feature?