I have a long form made up of multiple sections, each with its own questions. Each section can be saved independently with an <input type="submit" value="Save" /> button.
Each section is loaded dynamically into the page (and there are a variable number of sections).
Each form is authored separately as an Ajax.Begin() ajax form, but with dynamic loading of the forms it appears UnobstrusiveJavaScript will not bind the submit buttons and they perform a standard postback.
What is the simplest way to reconnect the ajax functionality of the submit buttons?
After checking the source of UnobstrusiveJavaScript (which is quite small) it leaves permanent event handlers using .on('submit') so it should just work with dynamically loaded pages.
Turns out the master form was missing the inclusion of UnobstrusiveJavaScript:
#Scripts.Render("~/bundles/jqueryval")
Worth checking fiddler when this sort of thing occurs :)
Related
I have a straightforward XPage that lets a user answer a question with a simple Yes/No/NA response using radio buttons. I have restyled the radio buttons to look like a bootstrap button group to make it visually more interesting for the user. If the user chooses "Fail" then they are informed that they need to do something else - easily done with a simple partial refresh to a div further down the page.
This all works fine.
The problem I'm having is that I'd like it so that when the user selects an option, I would like to add a new class of "active" to the selected option so that it highlights in a pretty colour. But for the life of me I can't get this to work and though I'm sure it's a straight forward problem, I can no longer see the wood for the trees.
My current (abridged) iteration of the radio button code is this:
<xp:div styleClass="btn-group item-result" id="edit-result" loaded="${Question.open}">
<xp:radio text="${lbl.kwPass1}" id="itemPass"
styleClass="btn btn-pass #{(item.itemResult eq '0')?'active':''}" groupName="itemResult"
selectedValue="1">
<xp:eventHandler event="onchange" submit="true"
refreshMode="partial" refreshId="actionAlert">
<xp:this.script><![CDATA[XSP.partialRefreshPost('#{id:edit-result}');]]></xp:this.script>
</xp:eventHandler>
</xp:radio>
<!-- other radio buttons -->
</xp:div>
<!-- other page compenents -->
<xp:panel id="actionAlert">
<!-- panel content and appropriate rendered value -->
</xp:panel>
This was attempting to do a chained partial refresh on the radio button container so that the EL would evaluate and apply/remove the 'active' style based on the document datasource ('item') value. I have also tried using dojo.addClass, dojo.removeClass, XSP.partialRefreshGet and other options. I don't mind what the solution is as long as it's efficient and works. I'd prefer not to move the actionAlert panel to within the same container as the radio buttons and I can't do a full page refresh because there are other fields which will lose their values.
Some notes:
I'm not using a RadioGroup control because it outputs a table and I haven't got around to writing my own renderer for it yet. Single Radio button controls work fine for what I need them to do.
I originally tried using the full Bootstrap solution of using "data-toggle='buttons'" (source) which sorts out applying the "active" style fine but then, inevitably, prevents the partial refresh from working.
the radio button styles are clearly not Bootstrap standard
Any assistance pointers or, preferably, working solutions would be appreciated.
You need to aim your partial refresh at the div containing all your radio buttons. Give it an id, so you can address it.
Partial refresh, as the name implies, refreshes one element and its content only. So you target the element that covers all of the items you need to recompute.
Stepping away from the problem, a couple of beers and an episode of iZombie later, I realized what I was doing wrong and sorted it out. So, for posterity, here is the simple solution that I swear I tried earlier but clearly works now:
<xp:div styleClass="btn-group item-result" id="edit-result" loaded="${Question.open}">
<xp:radio text="${lbl.kwPass1}" id="itemPass" value="#{item.ItemResult}"
styleClass="btn btn-pass" groupName="itemResult" selectedValue="1">
<xp:eventHandler event="onchange" submit="true" refreshMode="partial" refreshId="actionAlert">
<xp:this.script><![CDATA[dojo.query('.item-result > .btn').removeClass('active');
dojo.query('.btn-pass').addClass('active');]]></xp:this.script>
</xp:eventHandler>
</xp:radio>
<!-- et cetera -->
The many places I was going wrong:
In my code in the question, I was calling XSP.partialRefreshPost in the CSJS script of the radio button when it should have been in the onComplete of the eventHandler. It has to be chained to another partial refresh so that it runs after it, not at the same time. I did end up getting this right - but overlooked something I'll come to in point 3.
In my original attempt to use Dojo, my first mistake was to try and target the ID of the radio button, something like:
dojo.addClass(dojo.byId('#{id:radio2}'),'active');
This actually works as expected, so long as you remember that the ID of the radio button on the XPage refers to the actual radio button control and not the label wrapping; and the label is what I wanted to style. So the class "active" was being actually being added, just not to the element I thought it was. I should have spotted this in my browser code inspector except for the third thing I got wrong:
Ironically, I sorted out the first issue, remembering to put the XSP.partialRefreshPost into the onComplete - and then didn't remove it when trying to run the Dojo.addClass(). So I didn't notice the mistake with the addClass targeting the wrong element because after it ran, the partial refresh updated the container and removed the class I had just added which made me think that nothing was working.
So now I have some neatly styled radio buttons that don't look like radio buttons and it's all managed client side without any unnecessary partial refresh trips to the server barring the one where I actually need to look stuff up from the server. And the vital lesson is - sometimes you just need to step away from a problem and come back to it with fresh eyes later on.
Through much trial and error (mostly error), I have managed to incorporate jQuery Validate, Bootstrap 3 (using Popovers for validation messages), and DataTables to create I suspect a fairly common scenario:
A DataTable that contains a column of checkboxes, and offer a "check all" checkbox that selects all the checkboxes across pagination and filtering in a DataTable, and apply jQuery Validate to ensure a user doesn't submit without choosing at least one checkbox.
Here's a link to a live example of what I'm doing: http://live.datatables.net/lomelono/2/
It works (the script picks up all the checked checkboxes (either via the check all checkbox, or if manually chosen, and across pagination and filtering on the DataTable), and will validate if no checkbox is chosen.
What it doesn't do is:
Clear the validation error if the check all checkbox is chosen
Another odd side effect by using .appendTo() to ensure all checked checkboxes across pagination/filtering are chosen for submit is all the checkboxes (checked or unchecked) will appear at the bottom of the form before submit (the submit is disabled on the example so you can see the behavior).
Obviously I know just enough jQuery to be dangerous, but is there a better way to submit all the checked checkboxes, AND ensure client-side validation works correctly? Of course, I have a server-side catch, but ideally we want to inform the user BEFORE they submit.
I think I am really close to solving this, and hopefully someone can point me towards the finish line, that will hopefully benefit others who have this kind or similar sort of scenario.
SOLUTION
You may need to turn those <input type="checkbox"> that are checked and don't exist in DOM into <input type="hidden"> upon form submission.
For example:
$("#emailCompose").validate({
submitHandler: function(form) {
// Iterate over all checkboxes in the table
table.$('input[type="checkbox"]').each(function(){
// If checkbox doesn't exist in DOM
if(!$.contains(document, this)){
// If checkbox is checked
if(this.checked){
// Create a hidden element
$(form).append(
$('<input>')
.attr('type', 'hidden')
.attr('name', this.name)
.val(this.value)
);
}
}
});
//form.submit();
},
// ... skipped ...
});
DEMO
See jQuery DataTables: How to submit all pages form data for more details and demonstration.
I would have 10 bootstrap buttons on a single html page.
Each button opens a ootstrap modal filled with a html fragmen via an ajax request.
<div class="modal fade" id="myModal"></div>
$('#myModal').modal();
Should I create 10 different divs with 10 different ids? Or even 10 different instances?
var dialogInstance1 = new BootstrapDialog({
title: 'Dialog instance 1',
message: 'Hi Apple!'
});
or
should I create ONE dialog?
I would expect kind of caching problems when I open modal1, then just when I open modal2 I see still for some miliseconds modal1 html fragment from a prvious ajax request.
And how should I create those modals? The samples should this:
$('#myModal').modal();
and the instantiation? This is very confusing.
Can someone please share his experience how to approach with many bootstrap modals?
I would expect kind of caching problems when I open modal1, then just when I open modal2 I see still for some miliseconds modal1 html fragment from a prvious ajax request.
Assuming you're referring to data-remote's caching, you will probably be able to disable that in Bootstrap v3.2.0 (see https://github.com/twbs/bootstrap/pull/13183/ ).
However, I'd still recommend against using data-remote since it doesn't give you much control. It:
doesn't provide or easily let you do any error handling
doesn't give any "loading..." indication
forces you have to generate modal HTML on the server side (as opposed to, e.g., returning JSON from the server and using client-side templating)
IMO, you should:
include just one instance of the blank modal markup
setup your own click event handlers on the buttons that summon your modal
initiate the AJAX request in your click event handler
use client-side templating to generate a corresponding modal using the results of the request
use $(...).modal() or $(...).modal('show') (depends on how your templating works) to show the modal after the templating completes
I need to be able give users a link to my site with a parameter that will control their experience on the destination page, but, of course, Moqui does not allow parameters to be passed as a GET transaction. What are ways that I can work around that? It needs to be something that can be sent in an email, via sms and audibly.
An error message would be helpful know exactly what you are running into, but it sounds like the constraint to mitigate XSRF attacks.
The error message for this situation explains the issue and the recommended solution: "Cannot run screen transition with actions from non-secure request or with URL parameters for security reasons (they are not encrypted and need to be for data protection and source validation). Change the link this came from to be a form with hidden input fields instead."
You can pass URL parameters to screens to be used in code that prepares data for presentation, but not to transitions for code that processes input. The solution is to use a hidden form with a link or button to submit the form (that can be styled as a link or button or however you want). This is slightly more HTML than a plain hyperlink with URL parameters, but not a lot more and there are examples in various places in the Moqui itself.
If you are using an XML Screen/Form you can use the link element to do this with the #link-type attribute set to "hidden-form" or "hidden-form-link" (which just uses a hyperlink styled widget instead of a button styled one). If the #link-type attribute is set to "auto" (which is the default) it will use a hidden-form automatically if link goes to a transition with actions.
In plain HTML one possible approach looks something like this:
<button type="submit" form="UserGroupMemberList_removeLink_0">Remove</button>
<form method="post" action=".../EditUserGroups/removeGroup" name="UserGroupMemberList_removeLink_0">
<input type="hidden" name="partyId" value="EX_JOHN_DOE">
<input type="hidden" name="userGroupId" value="ADMIN">
</form>
Note that the button element refers to the form to submit, so can be placed anywhere in the HTML file and the form element can be placed at the end or anywhere that is out of the way (to avoid issues with nested forms which are not allowed in HTML).
Is there a way using dojo/dijit to disable the submit button till all the fields in a form are valid. Kind of like having a dojo > method > onChange inside the form? So the submit button only becomes enabled when all the form elements have meet their criteria?
Are you using a dijit.form.Form widget as your form? If you are, I would suggest connecting to the Form's onValidStateChange event. The docs for this event specifically state your use case:
onValidStateChange
Defined by dijit.form._FormMixin
Stub function to connect to if you want to do something (like disable/enable a submit button) when the valid state changes on the form as a whole. Deprecated. Will be removed in 2.0. Use watch("state", ...) instead.
The best way to see what events are available for a given widget is to look at the API Documentation for the widget you are interested in under the "Event Summary" heading. The dojocampus reference documentation often leaves out examples for references to some of the more obscure features of the widgets.
I would suggest to have a hidden button which will submit the form. When you click visbile button run a javascript function that validates all the input and then clicks on the hidden button to submit the form. Please find the pseudo code below
<form action="register">
<input dojoType="dijit.validation.TextBox"/>
<button onClick="validateall()">submit</button>
<button id="submitForm" type="submit" hidden="true"/>
</form>
function validateAll(){
if(AllOk){
clearErrorMessage();
dojo.byId('submitForm').click();
}else{
showErrorMessage();
}