Alternative for g:select (multiple values) - javascript

I have a Domain Class Project with a one-to-many property users :
static hasMany = [users: User]
In my scaffolding code the view is created with:
<div class="fieldcontain ${hasErrors(bean: projectInstance, field: 'users', 'error')} ">
<label for="users">
<g:message code="project.users.label" default="Users" />
</label>
<g:select name="users" from="${usermanagement.User.list()}" multiple="multiple" optionKey="id" size="5" value="${projectInstance?.users*.id}" class="many-to-many"/>
</div>
This results in a simple list where I can select multiple users. The user list is expected to be quite big so this selection isn't really viable. Is there a simple way in grails to do this a bit more comfortable? The best solution I can imagine would be a list with an autocomplete searchform and a second list where the selected entries are displayed.
I don't think that there is an easy way to do this and that I probably have to use javascript or jquery (autocomplete etc.)
Any help improving my current status (selection from huge list via ctrl + click)
would be very appreciated.

There is a jQuery plugin called Chosen that will do what you are wanting, it supports multiple selections. I have a use case much like yours in one of my apps and Chosen worked out great:
http://harvesthq.github.io/chosen/

A possible solution is using some javascript based stuff like boostrap select2 or Kendo UI Multiselect. They are based on a html select box that unobtrusively enhanced the selection model of a this html element. So there is no real javascript code to implement, since the selection model for the html form stays the same as with disabled javascript.

Related

Access and Office add-in checkbox checked status

In my Office add-in I have a checkbox like the following:
<div class="ms-CheckBox">
<input id="inputId" type="checkbox" class="ms-CheckBox-input" />
<label id="labelId" role="checkbox" class="ms-CheckBox-field" aria-checked="false" name="checkboxA" for="inputId>
<span class="ms-Label">Text</span>
</label>
</div>
I want to retrieve through JavaScript its checked status (or its aria-ckecked status, I'm still not getting the differences between them), which I thought was through document.getElementById( 'labelId' ).checked, since it's specified in the documentation that they have an optional checked member, but I only get an undefined with it.
I'm very new to these technologies and have a couple concerns:
Does "optional member" mean that I have to explicitly create it so that it exists? If so, how can I do that?
However the checked member may come to existance, do I have to manually handle its value every time it's clicked on by the user or is it already internally managed and I simply haven't found the way to access it yet?
Maybe I just can't see a mistake I've made on the html code for the checkbox?
Thank you in advance!
You have several sources of documentation on Office UI Fabric depend on framework you are using or about to use. Your choices are:
JavaScript only (no framework)
React
Angular
Form the look up table you would choose JavaScript only link and follow it to find the component you are interested in. Before that I would suggest to read "Get Started using Fabric JS".
Now when you have documentation on checkbox component of vanilla JS implementation, follow the steps to set up your checkbox. This would include:
Confirm that you have references to Fabric's CSS and JavaScript on your page
Copy the HTML from one of the samples below into your page.
<div class="ms-CheckBox">
<input tabindex="-1" type="checkbox" class="ms-CheckBox-input">
<label role="checkbox" class="ms-CheckBox-field" tabindex="0" aria-checked="false" name="checkboxa">
<span class="ms-Label">Checkbox</span>
</label>
</div>
Add the following tag to your page, below the references to Fabric's JS, to instantiate all CheckBox components on the page.
<script type="text/javascript">
var CheckBoxElements = document.querySelectorAll(".ms-CheckBox");
for (var i = 0; i < CheckBoxElements.length; i++) {
new fabric['CheckBox'](CheckBoxElements[i]);
}
</script>
To get the status of your checkbox use method getValue() which returns true or false whether the component is checked or not.

AngularJS SELECT doesn't validate properly

This is an AngularJS application (1.2.16). I browse to a dialog to edit some item. One of the controls is a multi-SELECT with the following visible values:
incident
work order
These visible values correspond to the following data values:
INCIDENT
WORK_ORDER
This is done through using the ng-options=" ... as ... for ... in ... " pattern, using an enumeration:
var FlexFieldSubjectTypeEnum = {
INCIDENT:{name:"INCIDENT", description:"incident"},
WORK_ORDER:{name:"WORK_ORDER", description:"work order"}
}
If have a form pretty much as follows:
<form ng-submit="save(formName)" name="formName" class="form-horizontal">
...
<div class="control-group">
<label class="control-label">Subject type:</label>
<div class="controls">
<select name="subjectType"
ng-options="type.name as type.description for type in getEnumAsArray('FlexFieldSubjectTypeEnum') | orderBy:'name'"
ng-model="entity.subjectType"
required></select>
</div>
</div>
Now, if the dialog loads the item ($scope.entity) from the backend and entity.subjectType is set to the first item in the list, the form validation marks it as unset. I have many other dialogs with similar constructs and have not seen this problem anywhere else.
If the item returned from the backend points to the second item (WORK_ORDER), this is nicely represented in the SELECT ("work order") and there is no validation error.
The problem does exist equally when using required or ng-required="true".
The problem does not exist if I remove the required attribute, but then the field also suddenly becomes optional, which is not what I wanted.
Your help much appreciated!
Almost a month later, with meanwhile an upgrade from Bootstrap v2.2.2 to v3.1.1 the problem disappeared.

Manage entered email-contacts in HTML form as removable blocks with [x] button similar to Gmail?

Are there solutions to manage entered email-contacts in HTML forms as removable blocks with [x] buttons, similar to Gmail?
Instead of generic text input with comma-separated e-mails I want to have more advanced field with autocomplete (not a question here) and autoreplace for entered e-mails where each e-mail becomes a block with quick remove [x] button.
Of course, it's not very complicated to write the solution manually, but I'm sure this has been solved before.
Quick example of what I'm looking for: http://jsfiddle.net/JNVgq/4/
<div class="wrap">
<input class="shadow" value="test#email.com, other#email.com" />
<div class="email"> test#email.com × </div>
<div class="email"> other#email.com × </div>
<input class="current" value="second#e" />
</div>
Found myself unable to google this stuff with no exact and clear keywords.
Here we go: Chosen jQuery Plugin
You can modify the code to use a text box instead of list box to accomplish what you are looking for. See the multiple select example.
EDIT:
Tag-it mentioned anpsmn by looks exactly what you are looking for.
Another option that I used for this (which includes the autocomplete part either from static list or server-side endpoint) is jquery-tokeninput

Why are edit in place forms rendered together with the display version instead of being rendered on the fly?

Is there a specific reason that most everyone implements edit-in-place as a shown 'display' div and a hidden 'edit' div that are toggled on and off when somebody clicks on the associated 'edit' button like so?
<div id="title">
<div class="display">
<h1>
My Title
</h1>
</div>
<div class="edit">
<input type="text" value="My Title" />
<span class="save_edit_button"></span>
Cancel
</div>
</div>
Everywhere I look, I see edit-in-place basically handled like this. This approach certainly makes sense when you are rendering all views on the server side and delivering them to the client. However, with pure AJAX apps and frameworks like backbone.js, it seems that we could make our code much more DRY by rendering edit-in-place form elements on the fly as necessary, possibly even making a factory method that determines which form element to render. e.g.
an H1 element with class "title" is replaced by <input type="text" />
a span with class "year_founded" is replaced by <input type="number" min="1900" max="2050" />
a span with class "price" is replaced by an input with the appropriate mask to only allow prices to be input.
Is this practice of rendering all edit-in-place form elements a historical legacy leftover from when pages were rendered on the server-side?
Given the flexibility and power we have with client-side MVC frameworks like Backbone.js, is there a reason for not creating and inserting the form elements on the fly when necessary using a factory method? Something like this:
HTML
<div id="description">
Lorem ipsum dolar set amit...
</div>
<span class="edit_button"></span>
Backbone.js View
events: {
"click .edit_button": "renderEditInPlaceForm",
},
renderEditInPlaceForm: function:(e) {
var el = $(e.currentTarget).previous();
var id = el.attr('id');
var value = el.text();
var tagName = el.tagName();
var view = new editInPlaceForm({
id: id,
type: tagName,
value: value
});
$("#id").html(view.render().el)
},
Where editInPlaceForm is a factory that returns the appropriate edit-in-place form element type based on tagName. This factory view also controls all its own logic for saving an edit, canceling an edit, making requests to the server and rerendering the appropriate original element that was replaced with the .html() function?
It seems to me that if we use this approach then we could also render the <span class="edit_button"></span> buttons on the fly based on a user's editing rights like so:
<h1 id="title">
<%= document.get("title") %>
</h1>
<% if (user.allowedToEdit( document, title )) { %>
<span class="edit_glyph"></span>
<% } %>
where the allowedToEdit function on the user model accepts a model and attribute as its arguments.
It's an interesting idea. The devil is in the detail.
While your simple example is easily rendered as an editable form on the fly, things quickly get trickier when dealing with other data types.
For example - suppose my edit form requires the user to choose a value from a select list. On the display form I can simply display the user's choice, but for the edit form I am going to need those other available choices. Where do I hide them on the display? Similar issues exist for checkboxes, radio lists...
So, perhaps we should consider rendering the edit form, and then deriving our display-view from that?
After 5 Backbone apps I came to same thoughts.
When things are complicated you have forms to show relations between user data,
but in simple cases you just need input, select, checkbox over h1, div or span
Now I am searching for jQuery plugin to make simple in place editing without ajax.
jQuery but not Backbone becuase I don't want to be tight coupled with Backbone for such small thing.
Likely to wright my own jQuery + Synapse plugin http://bruth.github.com/synapse/docs/.
Synapse for binding with model and jQuery for input placing

Speed up :visible:input selector avoiding filter

I have a jQuery selector that is running way too slow on my unfortunately large page:
$("#section").find(":visible:input").filter(":first").focus();
Is there a quicker way to select the first visible input without having to find ALL the visible inputs and then filtering THAT selection for the first? I want something like :visible:input:first but that doesn't seem to work.
[Edit]
Here's the basic idea of what #section looks like:
<div id="section">
<div>
Some text <input type="text">
</div>
<div>
etc. etc. <input type="text">
</div>
</div>
$(":input:visible:first", "#section").focus();
If you first filter for the type of control you avoid checking the :visible on all the #section's elements.
It seems like you need only to catch the first input type="text" visible.
This should be a bit faster.
$("input[type='text']:visible:first", "#section").focus();
How about adding class="default_field" to the default field for each page, then using $('.default_field').focus();?
How easy this is to do depends on your server-side technology of course, but the advantages are that it takes the processing burden off of the client (which is extra important for IE6), and it also gives you the flexibility to choose a default input other than the very first one on pages where it's appropriate.

Categories