Updated tags wish list
Updated tags wish list

Just carrying over from this thread: https://datatables.net/forums/discussion/80475/autocomplete-tags-and-ajax/p1
Most of those requests were addressed with the Editor 2.5 release (thanks, @allan!), but I wanted to capture the remainder here, not necessarily with the assumption that they'll be added, but just to clean up the conversation.
1) Include the input with the wrap around navigation
The up/down arrows would include the input with the wrap around:
* Arrow down from the input moves to the first record
* Arrow up from the first record moves to the input
* Arrow up from the input moves to the last record
* Arrow down from the last record moves to the input
2) Fully expose the ajax
method
Mentioned as a possible future feature to mirror how the ajax
object is used elsewhere:
new DataTable.Editor({
ajax: '/api/data',
fields: [{
label: 'Counties:',
name: 'county',
type: 'tags',
ajax: {
url: '/api/counties',
data: {
state: 'Texas',
yet_another_param: function () {
let foo = 42
return foo
}
}
}],
// ...
})
3) Ability to use rowGroup
Mentioned the possibility of an optgroup
.
4) Bootstrap floating labels
Not sure how this would look for tags
but perhaps above the dte-tag
?
5) Dropdown occasionally "disconnected" from field
Setting fields.className
to 'block' or entering mobile mode seems to cause the dropdown to be placed lower than what it should be.
To duplicate, view the following link in mobile mode and create a new entry to see the dropdown for the country tags is too low for the control (see picture): https://editor.datatables.net/examples/dropdown/tags-rendering.html
If there was an editor field below the country tag on the form then it would show between the country tag and the dropdown.
6) Option to have an initial AJAX load
I had requested this and the initial answer was to use field().update()
, but I could never get it work.
However I happen to notice in the Editor 2.5.0 release notes that
tags
andautocomplete
didn't respect the update option offield().update()
.
Perhaps that was the issue I was having so I'll try again one day this week.
If so, shouldn't the field().update()
documentation include tags
and perhaps autocomplete
?
Again, I'm very, very grateful to @allan for all the improvements that were incorporated from that initial thread!
Answers
Hi Loren,
Many thanks for the further feedback!
1) Include the input with the wrap around navigation
I do recall that as a suggestion previously, and I did look at it for 2.5, but it was going to hold things up too long. It is still in my issue tracker to look at in future
.
2) Fully expose the ajax method
Agreed. That needs to be included as well and is also in the tracker.
3) Ability to use rowGroup
Nice idea!
optgroup
is something I need to look at more generally.4) Bootstrap floating labels
I hadn't considered that before, although its a good idea. It is something that is specific to Bootstrap, so I'm not sure if I'll be able to make it work more generally (the current floating labels integration modifies the DOM structure after rendering - it might need to be done that way for autocomplete / tags as well.
5) Dropdown occasionally "disconnected" from field
Bug fixed and will be in the next release (2.5.1)
.
6) Option to have an initial AJAX load
The fields will read the options from the JSON data used to load the table, or if you need a separate Ajax request, you could make it and use
field().update()
as you mention. I don't really want to add an option that would cause an extra Ajax request per field on load.I actually think I have a typo in the release notes there -
field().update()
didn't support the append parameter for those two fields. Apologies!Let me know how you get on with trying it again.
Regards,
Allan
Quick note that thedocumentation for
fields.options
andfields.optionsPair
should also include thetags
andautocomplete
field types as well.Good point - fix committed and will be deployed soon
Allan
Another for the wish list:
7) Option to hide the search
I was looking at this example: https://live.datatables.net/jecehixe/4/edit
In this case when only two (or very few) values are available, having an option to hide the search bar could make sense and keep the UI cleaner.
Something like: