-
Joomla 5.1
For running J!5.1 you must https://fabrikar.com/forums/index.php?wiki/update-from-github/ or include the new file manually https://fabrikar.com/forums/index.php?threads/joomla-5-1-and-fabrik-cannot-find-files-error.54473/post-285151 See also Announcements
-
Subscription and download are working now
See Announcement
We are still working on the Joomla update.
Need the input type=number in elements
- Thread starter cliccaqui
- Start date
Sophist
Guest
Are you using the field element type?
As far as I can tell, this is not currently supported, but it should be easy enough to add the support via a PR as follows:
I haven't tested this. But because it adds a completely new option, it should be backwards compatible with all existing sites.
Perhaps you would like to test it on your site and if it works OK to submit it as a PR?
As far as I can tell, this is not currently supported, but it should be easy enough to add the support via a PR as follows:
- In /components/com_fabrik/models/element.php in method inputProperties add a "case '6': $type = 'number';"
- In /plugins/fabrik_element/field/forms/fields.xml add "<option value="6">PLG_ELEMENT_INPUTTYPE_NUMBER</option>" to the field definition for "password".
- In /plugins/fabrik_element/field/language/en-GB/en-GB.plg_fabrik_element_field.ini (and matching translations in other language files) add a string definition for PLG_ELEMENT_INPUTTYPE_NUMBER.
I haven't tested this. But because it adds a completely new option, it should be backwards compatible with all existing sites.
Perhaps you would like to test it on your site and if it works OK to submit it as a PR?
cheesegrits
Support Gopher
I added this a week or two ago.
-- hugh
-- hugh
cheesegrits
Support Gopher
Sophist
Guest
Indeed you did - on May 20th, I just looked.
So an update from Github should enable that for you, @cliccaqui.
So an update from Github should enable that for you, @cliccaqui.
cheesegrits
Support Gopher
Just one side note on the number thing ... irritatingly, it doesn't fire change events when you use the control, only when the field is blurred. That's apparently an HTML5 thing, not a Fabrik thing. Not a huge deal, but kind of counter intuitive. I added the feature for one of my client sites, to use in a form with a Stripe payment plugin on it, for selecting the quantity of widgets being ordered. I had hoped that when you click the up/down arrows, a change event would fire so my Stripe plugin JS could recalc and redisplay the total cost as you change the number, but nope. And of course that means if the qty field is the only actual active input on the form, the most likely action to blur the field would be clicking on submit, so my code never really gets a chance to clearly display the total to the user.
When I have some time, I'll see if there's a way of faking it.
-- hugh
When I have some time, I'll see if there's a way of faking it.
-- hugh
cheesegrits
Support Gopher
(the 'oninput' event looks like a good candidate, but as usual with HTML5, it's all very very browser dependent, but from poking around, the Big 3 should now support 'oninput' when an HTML5 control is clicked, but it certainly won't be universal in all browsers and platforms)
-- hugh
-- hugh
Sophist
Guest
Try this fiddle: https://jsfiddle.net/girlie_mac/5Assc/
Change events when mouse leaves the field - appears to be semi-random. But input events seem to be the way to go - though if extra change events are a problem, then you may also need to cancel some of them.
Change events when mouse leaves the field - appears to be semi-random. But input events seem to be the way to go - though if extra change events are a problem, then you may also need to cancel some of them.
cheesegrits
Support Gopher
I already monkey patched the Stripe plugin for 'input':
https://github.com/Fabrik/fabrik/commit/4e2f36f50a7fbc5375d83163256265736de3c6f3
... if the qty element is a field, which works nicely. The total now updates when you type a number or click the HTML5 widget controls, rather than only on blur.
https://www.screencast.com/t/khUzX1DnVzFn
The problem with doing it more generically for element JS events (so a widget click will fire any element 'change' JS) is that although we already have the concept of per-element event types ... so anywhere we need to listen for an element change event, rather than hard coding 'change', we get the event name with el.getChangeEvent() ... which might be blur, click or change depending on the element type and configuration ... that only supports one event type. And we'd need to fire on both 'change' (whatever type that happened to be) AND 'input'.
I could just add 'input' as a new JS event type, and folk could duplicate their code for 'change' and 'input', which would work. It'd just be nice to be able to automagically fire 'change' for 'input', for any element type.
It's not a big enough deal to spend time on atm, but I'm sure at some point one of my direct clients will need it, and I'll put the time into finding a solution.
-- hugh
https://github.com/Fabrik/fabrik/commit/4e2f36f50a7fbc5375d83163256265736de3c6f3
... if the qty element is a field, which works nicely. The total now updates when you type a number or click the HTML5 widget controls, rather than only on blur.
https://www.screencast.com/t/khUzX1DnVzFn
The problem with doing it more generically for element JS events (so a widget click will fire any element 'change' JS) is that although we already have the concept of per-element event types ... so anywhere we need to listen for an element change event, rather than hard coding 'change', we get the event name with el.getChangeEvent() ... which might be blur, click or change depending on the element type and configuration ... that only supports one event type. And we'd need to fire on both 'change' (whatever type that happened to be) AND 'input'.
I could just add 'input' as a new JS event type, and folk could duplicate their code for 'change' and 'input', which would work. It'd just be nice to be able to automagically fire 'change' for 'input', for any element type.
It's not a big enough deal to spend time on atm, but I'm sure at some point one of my direct clients will need it, and I'll put the time into finding a solution.
-- hugh
Sophist
Guest
It seems to me that we only need to do something special for "input type=number" and can use a selector to ensure that we only process input events for that.
The difficulties as I see them are:
a. We need to be certain that having a change event on incrementing a number field and then another second change event when the mouse leaves or it is blurred won't be an issue. Since Chrome already does this (e.g. in Chrome you move the cursor over blank field and click, and click up arrow to get "1" and change event is triggered, but not on subsequent clicks on up-arrow - or click and then use up-arrow to increment which triggers a change event in Chrome, and then move the cursor or tab and get another change event), Fabrik adding yet another change event wouldn't seem to make much difference.
b. We probably need to test in a range of browsers to make sure it is consistent in as many as possible. (As of Feb 2018, Windows 10 Edge browser doesn't trigger input on clicking up or down arrows. And I am not sure why change event is triggered on clicking up arrow and going from "" to "1" but not on "1" to "2" - is that a bug too?)
So if we only do this for "input type=number", then all we are really doing is making it work as it should do.
P.S. I understand that in some browsers navigating a select using up and down arrow also doesn't trigger change when it should. Do we want to fix that too?
When I get a couple of hours spare, I will try setting up a decent test form for it.
The difficulties as I see them are:
a. We need to be certain that having a change event on incrementing a number field and then another second change event when the mouse leaves or it is blurred won't be an issue. Since Chrome already does this (e.g. in Chrome you move the cursor over blank field and click, and click up arrow to get "1" and change event is triggered, but not on subsequent clicks on up-arrow - or click and then use up-arrow to increment which triggers a change event in Chrome, and then move the cursor or tab and get another change event), Fabrik adding yet another change event wouldn't seem to make much difference.
b. We probably need to test in a range of browsers to make sure it is consistent in as many as possible. (As of Feb 2018, Windows 10 Edge browser doesn't trigger input on clicking up or down arrows. And I am not sure why change event is triggered on clicking up arrow and going from "" to "1" but not on "1" to "2" - is that a bug too?)
So if we only do this for "input type=number", then all we are really doing is making it work as it should do.
P.S. I understand that in some browsers navigating a select using up and down arrow also doesn't trigger change when it should. Do we want to fix that too?
When I get a couple of hours spare, I will try setting up a decent test form for it.
cheesegrits
Support Gopher
All the code I've run and fiddles I've fiddled with show it's pretty freakin' random when any given browser issues a change with the HTML5 controls. They usually (but not always) fire one on the first click of the control (but not if you've typed a number first), and it also seems to vary depending on whether you focus into the field then click the control, or focus by clicking the control. Then it gets totally random, sometimes you get both input and change, sometimes you just get input, for successive clicks. If you use the cursor, some browsers always issue both, some issue one or the other. Ditto if you type. That's testing Chrome, Edge, IE10 and Firefox on Windows, Chrome on Android and whatever the heck it is iOS uses. All give different (and inconsistent) results. I daren't even try it on a Linux desktop with any of those zany browsers.
So basically, trying to figure it so only one Fabrik change event always fires will be ... challenging.
I've not looked at the issue with cursor on dropdowns. Not something I recall seeing mentioned in the forums, and I rarely use the cursor for dropdowns, so it's not something I've personally noticed. Definitely something that should be fixed if possible.
-- hugh
So basically, trying to figure it so only one Fabrik change event always fires will be ... challenging.
I've not looked at the issue with cursor on dropdowns. Not something I recall seeing mentioned in the forums, and I rarely use the cursor for dropdowns, so it's not something I've personally noticed. Definitely something that should be fixed if possible.
-- hugh