I have a form I'd like submitted as usual, so I stuck a non-bindable attribute on it. That works. But I have the need for a field to be filtered on input (specifically, converting a string to a clean version of itself on the fly, thus turning Some Input to some_input while it's still being typed) and this would be very easily achievable in Angular but since the entire parent element (the form) is non-bindable, Angular ignores all children.
I tried putting non-bindable on the submit button alone, but this produces no effect. How can I tell Angular to submit a form as usual, but to still allow angular directives and functionality inside said form, without resorting to vanilla JS and "onkeyup"?
On a more careful readthrough of the form API, I noticed this:
For this reason, Angular prevents the default action (form submission
to the server) unless the element has an action attribute
specified.
Specifying an action attribute was all it took. The form is now being submitted as usual, and I can use Angular within it.
I haven't used non-bindable attribute, but I don't think that it is possible with angular to have non-bindable parent element and use data-binding with children elements at the same time.
I would forget non-bindable and instead solve your scenario by a doing regular angular $http request on form click. You can configure it to look the same as regular form submit.
Or do you have any particular reason why you need browser to make your request from the form for you?
Related
I understand that the solution will be non-ideal -- I'm working with legacy code and have many constraints.
On a page in my app, the user choose between one of several forms they want to fill out. When selected, we use JQuery to load the selected form into the DOM. In this newly loaded form, we need to use an angular directive, but angular doesn't know that anything has changed (since JQuery handled the state change), so it doesn't recompile the markup that contains our directive.
How can I let angular know that it needs to make another pass through the DOM?
$scope.apply() will trigger a new check of the DOM.
If you use it with no check, it may fire an error inside angular.
You can use it, wrapped into a $timeout(), so that it will be triggered after a current digest (if there was)
$timeout(function(){
$scope.$apply();
});
I have a very simple use case in my application. when user double click on a record it will show an input box and after submitting new text and hit enter. that will update the record.
all I want to do is grab input elements value and fire service.
<input type="text" ng-model="updatedListTitle" ng-enter="updateList(list.id, updatedListTitle)">
as you can see I am using ngmodel to grab data in my controller. the problem is with every keystroke it is firing all my watchers unnecessarily (even though i know angular is fast and you can fire like 1000 watcher and all ). but just grabbing the element using jquery would be more efficient.
is there any better approach to handle these situation where i really don't care about 2 way binding
Well..., in my opinion the way you have done it is perfectly idiomatic angularjs and I wouldn't start to micro-optimize it.
(Remember "Premature optimization is the root of all evil" as well as Michael A. Jacksons rules about optimization and other quotes - http://en.wikipedia.org/wiki/Program_optimization )
No, I don't think there is any sensible way to do it without jQuery (or at least jqLite or manual dom access).
If you do that, you should encapsulate it in a directive (which arguably is the only place explicit DOM access/manipulation should be).
Can you use ng-blur here instead of ng-enter and then check to see if the model is dirty and then do the service call?
AngularJS sets the CSS classes ng-pristine and ng-dirty on any input field you've used ng-model on, and your controller has the properties $pristine and $dirty which you can check to see if the form is dirty or not.
That might be a bit more optimized. I would still do this in a directive though.
I have a form that gets completed on a webpage by the user,
when the user submits the form, I bring up a bootstrap modal dialog, this dialog has an iframe in it that loads the form from the parent window calling a function in it like so:
//parent window
var formToSubmit;
function getForm(){
return formToSubmit;
}
$("#submitButton").click(function(){
//alterations to the elements in $("mainForm")
formToSubmit = $("mainForm");
$("#modalDialog").modal();
//...
});
//modal iframe
var parentForm = parent.window.getForm();
$("#mainDiv").append(parentForm[0].outerHTML);
$("form").submit(function(){
parent.window.closeModalWindow(); //not sure whether this will close AFTER the form is completely submitted yet
});
$("form").submit();
My problem is that I'm submitting these forms to microsoft sql server reporting services and it takes every input element as a parameter. I have no control over this.
So when the user clicks submit in the main form, I disable all the elements that must not be set as parameters, the thing is; as soon as I get the form from the parent window and append it to the modal iframe, it seems as all of those changes are lost, is there any way to preserve this?
Your problem likely has to do with the call to outerHTML on the form. First of all, implementations of outerHTML have been different across browsers, so I would avoid using it if possible. Second, outerHTML does not necessarily contain the live DOM element, but merely a dump of it as a string.
Therefore, I suggest deep cloning the form before passing it to your IFRAME.
With jQuery (see docs):
$("#mainDiv").append(parentForm.clone(true));
Or plain JavaScript (see docs):
document.getElementByid('mainDiv').appendChild(parentForm[0].cloneNode(true));
I ran some tests to verify this, and as long as you're cloning the form, you will get the results you're expecting.
As a side note, why are you duplicating the form in a modal? Are you re-creating it as a "please review" type thing for the user? It seems like a strange process. I only ask, because perhaps there are better ways to do what you're asking. Anyway, the answer I've given should help.
I had problem triggering server side button click events so I found a solution on the net that I should do something like
<input type="submit" name="button" id="loginButton" value="Submit"
class="button-orange" alt="Register" title="Register" runat = "server" onclick ="this.disabled=true;__doPostBack('loginButton','')"/>
I did it, and it worked, but I would like to know what is going on!
Check this article:
Understanding the JavaScript __doPostBack Function
This method is used to submit (post back) a form to the server and allows ASP.NET framework to call appropriate event handlers attached to the control that raised the post back.
You usually (in simple scenarios) don't use the method directly - it is internally used by the controls you drop on the page.
The parameters passed to this function are stored in a hidden field and picked up by ASP.NET framework on the server-side in order to find the control that raised the post back.
simply said, it is used mainly by controls with AutoPostBack property
http://www.dotnetspider.com/resources/189-AutoPostBack-What-How-works.aspx
if you want to implement autopostback for your custom control, then you need to implement IPostBackDataHandler
The solution might be working but it's not a real fix.. better way will be to find why the button events are not triggering and fix the core of the problem.
Now to answer your questions.. PostBack is the term used to describe when the form is being submitted (posted) back to the same page. Simple as that.
Ordinary submit button would have been enough, but part of PostBack is the ability to identify which control triggered it, meaning what button or link was clicked.
To do such a thing ASP.NET is automatically adding hidden fields to the form and when clicking on element that should cause PostBack, JavaScript code is used to update the values of those hidden fields to the proper values indicating what was clicked - the argument you pass.
The name Microsoft chose to give to the JS function doing the above is __doPostBack - it's just a name of a function, ordinary JavaScript function that ASP.NET automatically writes to the browser.
Hope things are bit more clear now.
In my application i am enabling and disabling a button according to the value selected by the user from the <h:SelectOneMenu>. I am using a valueChangeListener for the same operation.My doubt is whether it is good to use javascript or the valueChangeListener for better performance.
Rule #1: JavaScript can be disabled.
By the way, the valueChangeListener already won't be fired automatically without a little help of JavaScript. The onchange="submit()" part is JavaScript.
Depends on what you want to do once the value changes. With javascript, the only way to trigger a server side action is to submit() the form via the onchange attribute. This simply submits all information to the backing bean. The valueChangeListener on the other hand gives you more control on the server side (what element changed, what was the old value, what was the new value)