Case:
I have an array of answers which I want to show in the view as radio inputs. When one of the answers is already answered it must be [checked] and if it's [checked] a textarea shows, so far so good.
Next I want to check another radio input and I want the current selected to be deselected and its textarea hidden, then the new selected radio input should be [checked] and it's textarea should show.
I use the FormBuilder and FormArray and have following issues.
I can't use index without intrapolation, I see many examples where the index is used without.
If I select another radio input, first my data disappears and it's not checked and on the second click it get's checked but now both are checked.
- I don't have access to the checked event, I can show it in the view with {{tempVar.checked}} as you can see above, if I use a template variable #tempVar, but I don't have access to it in the textarea below *ngIf="tempVar.checked". If I do use it in the ngIf I get the following error
Expression has changed after it was checked. Previous value: 'false'. Current value: 'true'.
Questions:
Is this the right approach?
An example of a Reactive Dynamic form with FormBuilder and FormArray with Radio inputs
Here is my code
https://gist.github.com/webwizart/121c85a0f316f47977cc0c99455af7bf
I would think using the tags should be reserved for unique identifiers? I wouldn't be surprised if dom renderer will update all elements with the same id.
Not sure if this will help, but you could use an answer view model instead (containing the same data) but that also has a 'checked' property
This way you can be sure that it will behave as you would expect.
e.g.: (in your component.ts)
let answers = this.question.Question.PossibleAnswers
.map(a =>
{ return Object.assign({}, a, { checked: false });
}
);
then in html you use: 'answer.checked' instead of 'radio.checked'
ps: also you could use ng-container instead of span, so you don't have an extra DOM imprint in your html
Related
I am building a multi-step application form with React. Having first built it with pure internal state I am now in the process of refactoring to Redux using redux-form.
Having used the example here as a basis: http://redux-form.com/5.2.5/#/examples/wizard?_k=oftw7a we have come a good way.
However the problem appears when i have two forms which are supposed to have the same value. During one of the pages i have a name field, that is supposed to be duplicated on the name field of the next page. The opposite should happen if you go back from the last page. Any tips to how this could be achieved?
Using the wizard, you are basically working with the exact same form that's split into multiple pieces. Ultimately it's the same form, because redux-form tracks them by name. It is how the library identifies the pieces of the same form - using the name.
form: 'wizard',
Here you can see that the exact same instance of the form will be shared throughout the pieces. fields work in a similar manner. Each field is defined as part of a form.
As long as you use the same field constants inside the fields object that you pass into the reduxForm function and as long as the value for form is the same, so that they use the same underlying form object, it should work for you just fine.
On one page you should pass in
export default reduxForm({
form: 'wizard',
fields : {
'fieldIWantOnBothPartsOfTheForm',
'someOtherFieldThatShouldOnlyBeHere',
},
...
And then on the other page:
export default reduxForm({
form: 'wizard',
fields : {
'fieldIWantOnBothPartsOfTheForm',
'thirdFieldHere',
},
...
Also, make sure you keep destroyOnUnmount equal to false if you want to navigate back-and-forth.
Hope that helps.
When creating a form in Orbeon Form Builder, you can define a list of values for a dropdown list box.
When running the form in form runner, is it possible to remove the "[Select...]" value from this dropdown list box?
I would like to restrict the possible values only to the given ones and restricting the user from selecting an "[Select...]" value when filling in the form. I hope you understand what I mean :)
Here is a screenshot
It's not possible without changes to Orbeon Forms to remove the empty option.
The best way to achieve what you want is to make the field required. When that's the case, the user will have to select a value or validation won't pass.
(The rationale for adding/keeping an empty option at the top is to force the user to make a selection. Otherwise it is possible that users might not even look at the option selected by default, and involuntarily select an incorrect option.)
OK, so first off, let's start with me acknowledging that the bind( ... ) way of binding Lift forms is so last week! :) I do know that, and I just haven't gone back to update this code yet. Also, I trust now that there's some really slick Lifty way to do this. That's what I seek. I'm stumped as to even how to hack something together. That said...
I have a list of Items that I initially display non-editable, and the title of each Item is an ajax-enabled link that calls to the server and replaces that line-item with an editable form of the Item (I use SetHtml to swap the form in at the < li> that listed that Item).
"parent" Items List view looks something like this
< form data-lift="form.ajax">
< div data-lift="creategamewizard?multipart=true" id="wizardform">
< ul>
< li>Item 1< /li>
< li>Item 2< /li>
< /ul>
some more form elements
< button>Submit< /button>
< input type="hidden" id='298356928734' />
< /div>
< form>
This ajax submit (via the hidden field) calls processSubmit().
The SetHtml that swaps in the editableItem form looks something like this.
NOTE: At the end of the following listing, the "save" binding has no server-side code tied to it because the "parent" submit button is already on the page, and when I put another hidden field in this binding or tried to tie any code directly to the Edit Item Save button, that code and the "parent" submit got triggered. So the approach below was to try to use the "parent" submit for both the parent submit as well as the Edit Item submit.
<a href="javascript://" onclick={ajaxOnClickHandler(editItemClickHandler(item.id.get))}>{item.title.get}</a>
def ajaxOnClickHandler(jsHandler: ()=>JsCmd) =
{
SHtml.onEvent( e => jsHandler()).toJsCmd+";return false;"
}
def editItemClickHandler(itemId: String): ()=>JsCmd = ()=>
{
trace.logAjaxComm("ExistingItem.Edit()")
JsCmds.SetHtml("LiId"+itemId, getEditableItem(promo) )
}
def getEditableItem(itemId) =
{
bind( ...
"promotitle" -> SHtml.text(editablePromo.get.promotitle.is,
(s:String) => {
trace.logUIDataManipulation("Saving new promo Title["+s+"]");
editablePromo.get.promotitle(s)
}, "id" -> "promotitle"),
"save" -> SHtml.button("Save", ()=> {})
)
}
Then when the user selects an Item, and the editable Item form is plugged in, there's "another" submit button that should ajax submit the form data for that item, and then swap back in the (now updated) nonEditable version of the data.
The problem for me is the submission. In addition to the Edit Item form above, I've got a ajaxified submit button on the "parent" non-editable list page to handle submitting some fields below the list. The Edit Item "save"-> binding adds a button, which should do (and in fact does) nothing for itself, but it does trigger the "Parent" submit button. And I route that submit to do the save of the Edit Item form.
The non-editable Item and the editable item code swaps fine, but changes made in the editable Item form is not saved, and I figured out that that was happening because the elements in the editable Item form are not being submitted at all, following is an example of a log message I don't see at all...
bind( ... "promotitle" -> SHtml.text(editablePromo.get.promotitle.is,
(s:String) => {
trace.logUIDataManipulation("Saving new promo Title["+s+"]");
editablePromo.get.promotitle(s)
}, "id" -> "promotitle")
)
In a normal ajaxified form, all element handlers are called (if there are changes to the field, I guess...) in order of rendering, with the submit/hidden elements' handlers being called last (if they're last in the bind list.
so finally, let's get around to my question:
if you're doing in-place editing like this, how do I manage 2 submit buttons (the one for the non-editable list page plus the additional one that gets added when editing an item)?
I'm sure I don't need to refresh the page, but I can't figure out how you'd do this with Ajax.
Maybe alternatively, the in-place editable form can be submitted as a non-submit ajax action, ie. somehow that doesn't trigger the parent submit?
For anyone tripping over this question, I figured I'd share the solution I eventually found...
1)The problem was that the submit (for AJAX this is the hidden html tag) happened before the editable Item's field handlers were called. So when the AJAX update that collapsed the editable Item back into just a non-Editable list item, the data hadn't yet been updated. So what was displayed in non-editable form didn't show the update, yet if I refreshed the page in the browser, the update had been saved to the database and now showed properly.
2)The reason for the mal-ordering is that Lift assigns each form tag's server-side handler an id (which are "monotonically increasing" with an additional string added to the end). That's fine until you do an ajax live-update of a form and add fields (as I did when I inserted the Editable Item fields). These newly-added fields were assigned server-side ids that came after the hidden field that got generated as part of the initial page rendering.
3)The solution was to explicitly shove the hidden field into a much higher id using S.formGroup. See here for more details...
The example from the last link below is as follows (and differs from mine in that it uses SHtml.submit, whereas I use SHtml.hidden). It adds the constant 1,000 to the submit button's server-side handler id:
"type=submit" #> S.formGroup(1000) {
SHtml.submit("Submit", process)
}
Discussion of a problem that is essentially the same as mine: https://groups.google.com/forum/#!topic/liftweb/MYJQeVlOYFM
Description of id assignment and S.formGroup under heading "Server side function order.":
https://www.assembla.com/spaces/liftweb/wiki/cool_tips
And lastly, linked to from the last link is some example code:
https://groups.google.com/forum/#!topic/liftweb/E9z7PVhogQw
I have a form done with Zend. I load it with ajax in a dialog. It has 2 selects. Depending on what is selected in the first select, it loads the content of the second one. However, when I submit the form I get a validation error because the options of the second form weren't there at the time of creating it.
Is there a way to fix this "issue"? It does what it needs to do but I don't want it to verify that field anymore. Any way to specify that I don't want that?
You can disable the inArray validator. When constructing the form's select element, set
'registerInArrayValidator' => false
Also, a different solution would be to overload the isValid method, inspect the selected option for the first select element and then populate the options for the second element. Then call parent::isValid to check if the form is in fact valid or not.
I have divided form in to two sections: sec1 and sec2. Each section is part of a div named as sec1Div and sec2Div. Based upon some selection one of div is hidden. But the problem is that still fields in hidden section are submitted. Please suggest a way so that all of fields in a div are not submitted on submit.
There are several ways to do that. You can hook a function to the form submit's event, or you can remove the name attributes of the fields inside the hidden div. You can also disable the fields, by setting disabled="disabled".
If you are using jQuery, you can do those examples.
To disable all fields in the hidden div, you can do something like:
function hideDiv(el) {
$('input', el).each(function(){
$(this).attr('disabled', 'disabled');
});
$(el).hide();
}
And, the appropriate show div function:
function showDiv(el) {
$('input', el).each(function(){
$(this).removeAttr('disabled');
});
$(el).show();
}
Please remind that this is just a code example. But you can take the idea from that.
The reason this is happening is because the elements are still within the form element. Hiding a div using CSS won't change this - they're still present in the DOM.
It would likely be easiest to add a hidden input field to each div that can be used to identify server side which one you should be processing. You can then simply ignore the data from the hidden form.
If you really must stop the data from being posted, it's a little messy but you could move the hidden div's contents outside of the form element so that the fields won't be submitted. If you wanted to display the div again, you'd then need to move the fields back in. Depending on how complex your CSS is, this could cause problems in some browsers, so I'd advise using my first suggestion.