Prevent Angular from adding a blank option in SELECT tags?

[Michael Bielski]

I was taught that there are a few things you just don't do when it comes to developing applications of ANY type. Among them are:

Don't change the default system keyboard mappings (this totally screws up users)

Don't re-define the native language of the region (ALL should mean ALL, DONE should mean DONE)

Don't automatically insert blanks into the beginning of a pre-defined list (Pre-defined lists should not be changed at run-time) <--- Angular Violates This

Has anybody found a way to prevent Angular from adding a blank option to every SELECT tag on the page? Having it added is extremely undesirable behavior. It totally blows away the selection from any pre-selected items in those tags, and I need certain ones to be selected by default. It's in the specs for the project, and I can't change them.

(Note: the "selected='selected'" attribute still appears in the source HTML, but when the form is submitted the inserted blank option is what ends up being shown as chosen.)

[Jorge Sousa]

Maybe you should not submit the form in the html normal way. 

But rather POST your data using ajax or through a $resource service.

Jorge

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en.
 
 

--
-------------------------------
Jorge Sousa

[Michael Bielski]

Well, that's the thing... I'm not submitting the form. I'm using a button click to call a method on the controller, which in turn would be doing a POST. The thing is, my POST data has to be in JSON, and I have yet to figure out how to get Angular to output JSON without a bunch of garbage in it (see this topic: 

https://groups.google.com/forum/?fromgroups#!topic/angular/gjoA-7Ivhfs).

Regardless, I don't consider it good practice to do what is being done. 

[Jorge Sousa]

Hi Michael,

I cannot run the provided jsFiddler, it gives me an error. But by looking at it, here are my thoughts.

In the input fields you are using;

ng-model="customer.active"

ng-model="customer.customerid"

This will be translated to something like:

 $scope.customer = {'acive': '', 'name': '' };

So your MODEL is the object $scope.customer!

At the alert line you are just dumping HTML Form content as JSON. Thats why you are seeing all that mess. 

POSTing data. 

You are POSTing to the REST method with empty params.

  var NC = Customers.$save();

You should send the your model as an argument. eg:

var NC = Customers.$save($scope.customer);

You have 3 players:

- HTML Form -> in angular terns it just feeds your field's model through the directive ng-model. The HTML Form itself is useless. 

- The MODEL 

- The $resource that needs data do its work. 

Hope this makes sense?

Have fun

Jorge. 

--

You received this message because you are subscribed to the Google Groups "AngularJS" group.
To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en.
 
 

--
-------------------------------
Jorge Sousa

[ProLoser]

You're doing it wrong.

Set the model's default value in the controller, NOT in the HTML. Imagine what would happen if your HTML has the ability to clobber or change your javascript variables upon init.

Again, you can avoid a blank option by simply doing $scope.mySelect = 'someValue';

[Michael Bielski]

@ProLoser

There is nothing wrong with setting a default option in HTML. It is a part of the standard that is fully supported by every browser and has been for a very long time. In a form where a new customer/user/whatever is to be added, having defaults is certainly acceptable and to be expected. Wanting to use Angular methods to easily parse the form and convert it into JSON should not require me setting default values via Angular just to get around something that I don't think that Angular should be doing in the first place.

That being said, thank you for answering my question. Just because I don't like your answer doesn't mean that you didn't give one, nor that it doesn't satisfy the need.

@Jorge

I do apologize for the jsFiddle. It gave me fits trying to get it to work and finally I just gave up and left the code there in hopes that someone would be able to decipher it. You appear to have done a pretty good job! However, I have since moved away from using $resource as I just don't understand it and nobody seems to be willing to take the time to document it better or provide better examples. I'm able to use $http just fine and it does everything I need. The extra couple of lines of code that using $http requires isn't going to kill anyone or any browser for the stuff that I am doing. Thank you very much for trying to help! I do appreciate the effort.

[Dean Sofer]

You misunderstand, I know it's acceptable to put a pre selected item in html. But I'm talking about in angular which is a different thing entirely.

Let's say you bind a select to a model and have option C with a selected attribute. Let's also say you have that same model set to option B in your JavaScript controller. Which one should take precedence when the page loads? Now let's imagine you load in a partial with another select on the same model set to option D, what should happen then? Keep in mind these are defaults. Find loading more html really change model values?

I'm not the core team, but I believe they choose to ignore all html default values for the sake of sanity, and not just on select elements. My thought would be you would find yourself running around trying to find the code that is randomly changing the value of your JavaScript variable for quite a while before you realize your designer negligently set the selected attribute, or if you have multiple references to the same model.

If you don't use ngmodel then of course you don't run into this problem altogether. But you are trying to mix angular with non angular. Why parse the form if you can just grab the model variable.

I didn't see a fiddle link anywhere but my suggestion is to digress a step. Explain what your ultimate end goal is, perhaps you are going about it wrong? I can try to help if I knew why you cared about inline defaults. Are you using native form posting behavior? Do you not have access to the JavaScript?

--

[Alex Figueiredo]

I agree with Michael, this really bothers me.

Because of this behaviour I have to, like @ProLoser said, set my default value in the controller.

But it sucks when I want to do things like this (it's just an example, please don't tell me I shouldn't be doing this):

<select>
    <option value="0">Option 0</option>
    <option value="1">Option 1</option>
    <option value="2" <?= $my_session_var ==  "my_expected_value" ? 'selected' : '';  ?> >

        Set me as default please
    </option>
</select>​ 

I could make an ajax request at my controller to check if the session has some value and update the model, but this would be just as boring.

It is wrong to try to mix Angular with Non-Angular, so I can get just the best things from Angular I want?

[Michael Bielski]

On Wednesday, August 8, 2012 9:59:50 AM UTC-7, ProLoser wrote:

You misunderstand,

This would probably be the case with most things that I am trying to do with Angular. I do appreciate the detailed explanation, though. It does help me as I to try to understand things.

 

I know it's acceptable to put a pre selected item in html. But I'm talking about in angular which is a different thing entirely.

As I am finding out! It really is appearing that Angular is much like the .Net platform in that respect. It either handles everything or you have a hell of a time with work-arounds. 

Let's say you bind a select to a model and have option C with a selected attribute. Let's also say you have that same model set to option B in your JavaScript controller. Which one should take precedence when the page loads? Now let's imagine you load in a partial with another select on the same model set to option D, what should happen then? Keep in mind these are defaults. Find loading more html really change model values?

In any of those cases, I believe that Angular should be checking for default values and respecting them instead of just blindly over-writing them. Even .Net does this.

I'm not the core team, but I believe they choose to ignore all html default values for the sake of sanity, and not just on select elements. My thought would be you would find yourself running around trying to find the code that is randomly changing the value of your JavaScript variable for quite a while before you realize your designer negligently set the selected attribute, or if you have multiple references to the same model.

I don't concur. Instead of a process of elimination (usually the longest way to determine something,) the better course is to look at where un-wanted change is being noticed and then see if the options all point to this area. If you, as the developer, expect the selected option to be X and you see that it isn't, your first place to check the problem should be to look at the HTML source (which is, after all, what the browser begins the render based upon) and see if there is a reason there. While I am new to unit testing, I believe that test results that indicate that your scripts were correct would also lead you to look at the HTML to see what was going on. I could be wrong, though.

If you don't use ngmodel then of course you don't run into this problem altogether. But you are trying to mix angular with non angular. Why parse the form if you can just grab the model variable.

Well, to solve the problem I did exactly that: removed the ng-model and parsed the form with a simple jQuery routine. I'm not having any luck getting the ng-model data to be available to my controller methods, which is probably the source of the problem. I follow the examples and it just isn't translating.

I didn't see a fiddle link anywhere but my suggestion is to digress a step. Explain what your ultimate end goal is, perhaps you are going about it wrong? I can try to help if I knew why you cared about inline defaults. Are you using native form posting behavior? Do you not have access to the JavaScript?

Ok, here goes:

We have a form that is used to enter new customers. Certain defaults are set so that the average user only needs to type in the first and last name at the very least before saving and moving on. These defaults are contained in dropdowns. Just because the dropdowns have pre-selected items doesn't mean that the others can't be chosen. For example

<select name="customer_type" id="customer_type">

<option value="0">Local</option>

<option value="1" selected="selected">Regional</option>

<option value="2">National</option>

</select>

The majority of new customers are "Regional" but now and then one of the others comes in. Having that value pre-selected makes sense and speeds up the process. All we need Angular to do is parse the data from the form and ship it out to a remote service. Data NEVER gets populated back to this form, so there is no real need for data-binding. We tried putting the ng-model into the form to simplify the parsing, but all it did was convolute things. The simple solution was to use jQuery to grab the form data, put it into JSON, and then pass it to Angular for sending it out to the remote service. The form is not using native post behavior. Rather, a button click calls a method on an Angular controller the does the parsing, xhr, and then redirection via Angular routing, and that part works great.

I have access to all of the JavaScript (I'm the guy writing it) but much of it can't be posted for privacy reasons. Thank you very much for your efforts.

[Dean Sofer]

Alex: I'm sorry, but that code looks... ugly. I mean putting business logic so tightly laced into your HTML. I'd prefer doing it in the controller. Your example would require that if-statement check on each and every option. Or lets say you only have it on one option, why have that logic in your HTML? You could alternatively use ng-repeat (although this behaves strangely on <options>) but at least you'd only write the check once. I honestly think it's cleaner to do it in the controller for such a specific check.

Michael: responses inline

On Wed, Aug 8, 2012 at 11:57 AM, Michael Bielski <michael...@yahoo.com> wrote:

On Wednesday, August 8, 2012 9:59:50 AM UTC-7, ProLoser wrote:

You misunderstand,

This would probably be the case with most things that I am trying to do with Angular. I do appreciate the detailed explanation, though. It does help me as I to try to understand things.

 

I know it's acceptable to put a pre selected item in html. But I'm talking about in angular which is a different thing entirely.

As I am finding out! It really is appearing that Angular is much like the .Net platform in that respect. It either handles everything or you have a hell of a time with work-arounds. 

Let's say you bind a select to a model and have option C with a selected attribute. Let's also say you have that same model set to option B in your JavaScript controller. Which one should take precedence when the page loads? Now let's imagine you load in a partial with another select on the same model set to option D, what should happen then? Keep in mind these are defaults. Find loading more html really change model values?

In any of those cases, I believe that Angular should be checking for default values and respecting them instead of just blindly over-writing them. Even .Net does this.

What if 2 inputs on the page are binded to the same model but have different defaults? What do we do then? Does .Net even bother with the JS? That last question is just my own lack of knowledge. 

Why are you comparing this to .Net? I don't know how often people feel .Net is 'the best approach'. And the previous comment didn't seem to think so either. I've worked with .Net and was frustrated by the lack of control I had over the view layer. You're also not locked into angular. You just chose to use the ngModel directive, and this is how it works. Don't use ngModel on the input/select and you're shiny.

I'm not the core team, but I believe they choose to ignore all html default values for the sake of sanity, and not just on select elements. My thought would be you would find yourself running around trying to find the code that is randomly changing the value of your JavaScript variable for quite a while before you realize your designer negligently set the selected attribute, or if you have multiple references to the same model.

I don't concur. Instead of a process of elimination (usually the longest way to determine something,) the better course is to look at where un-wanted change is being noticed and then see if the options all point to this area. If you, as the developer, expect the selected option to be X and you see that it isn't, your first place to check the problem should be to look at the HTML source (which is, after all, what the browser begins the render based upon) and see if there is a reason there. While I am new to unit testing, I believe that test results that indicate that your scripts were correct would also lead you to look at the HTML to see what was going on. I could be wrong, though.

You're going about things with the idea that it's all about DOM. AngularJS requires a mentality that your JS should stand alone from the DOM. Let me reiterate: Your JS should NOT rely on your HTML. That's too tightly coupled and defeats one of the main intentions of Angular; standalone testability.

Fine, if you're building HTML and JS very closely together, you may check the DOM first. But as I said, if you have 100s of inputs generated on the page all attached to the same model, that could make things difficult and complex. Compare this to setting model defaults upon controller initialization. 

If you don't use ngmodel then of course you don't run into this problem altogether. But you are trying to mix angular with non angular. Why parse the form if you can just grab the model variable.

Well, to solve the problem I did exactly that: removed the ng-model and parsed the form with a simple jQuery routine. I'm not having any luck getting the ng-model data to be available to my controller methods, which is probably the source of the problem. I follow the examples and it just isn't translating.

I didn't see a fiddle link anywhere but my suggestion is to digress a step. Explain what your ultimate end goal is, perhaps you are going about it wrong? I can try to help if I knew why you cared about inline defaults. Are you using native form posting behavior? Do you not have access to the JavaScript?

Ok, here goes:

We have a form that is used to enter new customers. Certain defaults are set so that the average user only needs to type in the first and last name at the very least before saving and moving on. These defaults are contained in dropdowns. Just because the dropdowns have pre-selected items doesn't mean that the others can't be chosen. For example

<select name="customer_type" id="customer_type">

<option value="0">Local</option>

<option value="1" selected="selected">Regional</option>

<option value="2">National</option>

</select>

The majority of new customers are "Regional" but now and then one of the others comes in. Having that value pre-selected makes sense and speeds up the process. All we need Angular to do is parse the data from the form and ship it out to a remote service. Data NEVER gets populated back to this form, so there is no real need for data-binding. We tried putting the ng-model into the form to simplify the parsing, but all it did was convolute things. The simple solution was to use jQuery to grab the form data, put it into JSON, and then pass it to Angular for sending it out to the remote service. The form is not using native post behavior. Rather, a button click calls a method on an Angular controller the does the parsing, xhr, and then redirection via Angular routing, and that part works great.

I have access to all of the JavaScript (I'm the guy writing it) but much of it can't be posted for privacy reasons. Thank you very much for your efforts.

So I'm a little surprised this confuses people, but my coworker had a nearly identical problem. With no code to look at, perhaps this example may point you in the right direction:  http://plunker.no.de/edit/BDNaZs?live=preview

Note how all defaults are kept together in one place, and declared when the containing object is declared? Note how we don't have to modify the data at all because it's already in the structure the backend is expecting.

I prefer this approach whole-heartedly because I find it WAY easier and cleaner than serializing, mapping, formatting, etc. AND the $scope.data is updated in real time, making it ridiculously easy to allow change of values to affect other parts of the page OR to allow other parts of the page to affect the form inputs.

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en.
 
 

--
Dean J Sofer
Dean...@gmail.com

BS Computer Information Systems
California State Polytechnic University, Pomona
Telephone: 714-900-2254
Website: www.DeanSofer.com 

Github: github.com/ProLoser

[Alex Figueiredo]

The if-statement is for one option only. In my case, I didn't need to check every option. Thanks, anyway!

[Michael Bielski]

On Wednesday, August 8, 2012 12:43:13 PM UTC-7, ProLoser wrote:

Alex: I'm sorry, but that code looks... ugly. I mean putting business logic so tightly laced into your HTML. I'd prefer doing it in the controller. Your example would require that if-statement check on each and every option. Or lets say you only have it on one option, why have that logic in your HTML? You could alternatively use ng-repeat (although this behaves strangely on <options>) but at least you'd only write the check once. I honestly think it's cleaner to do it in the controller for such a specific check.

Ok, glad it wasn't just me that looked at that and had that thought. Reminded me too much of my old ClassicASP days.

 

Michael: responses inline

On Wed, Aug 8, 2012 at 11:57 AM, Michael Bielski <michael...@yahoo.com> wrote:

On Wednesday, August 8, 2012 9:59:50 AM UTC-7, ProLoser wrote:

You misunderstand,

This would probably be the case with most things that I am trying to do with Angular. I do appreciate the detailed explanation, though. It does help me as I to try to understand things.

 

I know it's acceptable to put a pre selected item in html. But I'm talking about in angular which is a different thing entirely.

As I am finding out! It really is appearing that Angular is much like the .Net platform in that respect. It either handles everything or you have a hell of a time with work-arounds. 

Let's say you bind a select to a model and have option C with a selected attribute. Let's also say you have that same model set to option B in your JavaScript controller. Which one should take precedence when the page loads? Now let's imagine you load in a partial with another select on the same model set to option D, what should happen then? Keep in mind these are defaults. Find loading more html really change model values?

In any of those cases, I believe that Angular should be checking for default values and respecting them instead of just blindly over-writing them. Even .Net does this.

What if 2 inputs on the page are binded to the same model but have different defaults? What do we do then? Does .Net even bother with the JS? That last question is just my own lack of knowledge. 

No, .Net doesn't even bother with JS. MS does fully support jQuery in the IDE, though.

To answer your question: 2 inputs bound to the same model just seems like bad design to me. You already have the inputs separated, so why are you trying to set both of them from one piece of data? Regardless, if Angular checked for and respected pre-defined defaults in HTML this problem would never come up.

 

Why are you comparing this to .Net? I don't know how often people feel .Net is 'the best approach'. And the previous comment didn't seem to think so either. I've worked with .Net and was frustrated by the lack of control I had over the view layer. You're also not locked into angular. You just chose to use the ngModel directive, and this is how it works. Don't use ngModel on the input/select and you're shiny.

I'm comparing it to .Net because that is where I come from. When all else fails, you tend to go back to what you know.

 

I'm not the core team, but I believe they choose to ignore all html default values for the sake of sanity, and not just on select elements. My thought would be you would find yourself running around trying to find the code that is randomly changing the value of your JavaScript variable for quite a while before you realize your designer negligently set the selected attribute, or if you have multiple references to the same model.

I don't concur. Instead of a process of elimination (usually the longest way to determine something,) the better course is to look at where un-wanted change is being noticed and then see if the options all point to this area. If you, as the developer, expect the selected option to be X and you see that it isn't, your first place to check the problem should be to look at the HTML source (which is, after all, what the browser begins the render based upon) and see if there is a reason there. While I am new to unit testing, I believe that test results that indicate that your scripts were correct would also lead you to look at the HTML to see what was going on. I could be wrong, though.

You're going about things with the idea that it's all about DOM. AngularJS requires a mentality that your JS should stand alone from the DOM. Let me reiterate: Your JS should NOT rely on your HTML. That's too tightly coupled and defeats one of the main intentions of Angular; standalone testability.

This is where you lose me.

 

Fine, if you're building HTML and JS very closely together, you may check the DOM first. But as I said, if you have 100s of inputs generated on the page all attached to the same model, that could make things difficult and complex. Compare this to setting model defaults upon controller initialization. 

If you don't use ngmodel then of course you don't run into this problem altogether. But you are trying to mix angular with non angular. Why parse the form if you can just grab the model variable.

Well, to solve the problem I did exactly that: removed the ng-model and parsed the form with a simple jQuery routine. I'm not having any luck getting the ng-model data to be available to my controller methods, which is probably the source of the problem. I follow the examples and it just isn't translating.

I didn't see a fiddle link anywhere but my suggestion is to digress a step. Explain what your ultimate end goal is, perhaps you are going about it wrong? I can try to help if I knew why you cared about inline defaults. Are you using native form posting behavior? Do you not have access to the JavaScript?

Ok, here goes:

We have a form that is used to enter new customers. Certain defaults are set so that the average user only needs to type in the first and last name at the very least before saving and moving on. These defaults are contained in dropdowns. Just because the dropdowns have pre-selected items doesn't mean that the others can't be chosen. For example

<select name="customer_type" id="customer_type">

<option value="0">Local</option>

<option value="1" selected="selected">Regional</option>

<option value="2">National</option>

</select>

The majority of new customers are "Regional" but now and then one of the others comes in. Having that value pre-selected makes sense and speeds up the process. All we need Angular to do is parse the data from the form and ship it out to a remote service. Data NEVER gets populated back to this form, so there is no real need for data-binding. We tried putting the ng-model into the form to simplify the parsing, but all it did was convolute things. The simple solution was to use jQuery to grab the form data, put it into JSON, and then pass it to Angular for sending it out to the remote service. The form is not using native post behavior. Rather, a button click calls a method on an Angular controller the does the parsing, xhr, and then redirection via Angular routing, and that part works great.

I have access to all of the JavaScript (I'm the guy writing it) but much of it can't be posted for privacy reasons. Thank you very much for your efforts.

So I'm a little surprised this confuses people, but my coworker had a nearly identical problem. With no code to look at, perhaps this example may point you in the right direction:  http://plunker.no.de/edit/BDNaZs?live=preview

Note how all defaults are kept together in one place, and declared when the containing object is declared? Note how we don't have to modify the data at all because it's already in the structure the backend is expecting.

I prefer this approach whole-heartedly because I find it WAY easier and cleaner than serializing, mapping, formatting, etc. AND the $scope.data is updated in real time, making it ridiculously easy to allow change of values to affect other parts of the page OR to allow other parts of the page to affect the form inputs.

I need a bit of time to work with what you've posted and see if I can get it to work for me. Thank you very much for all of your time into this! 

[Dean Sofer]

It's not poor design to have 2 inputs binded to the same model. There have been a few useful times this has come up for me, and I don't see the problem. For instance, what if you have 2 divs and only one is ever shown at a time? By default, HTML doesn't encounter this issue because HTML doesn't share values. Actually... that's not true, if 2 inputs have a name on the form, when you hit submit the last input on the page takes precedent. But then, the last input on the page's default could potentially override the previous input's value.

The reason this ISNT bad design in angular is because editing the value of 1 input updates the value for the other, so they are kept in sync (even if you can't see the other input). This is part of why setting the default in 1 place (in the controller) is safer than setting it in the html.

That's the ultimate reason why you can't use standard HTML mentality. You don't bind data to inputs in native HTML.

--

You received this message because you are subscribed to the Google Groups "AngularJS" group.
To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en.
 
 

[Michael Bielski]

On Wednesday, August 8, 2012 1:35:12 PM UTC-7, ProLoser wrote:

It's not poor design to have 2 inputs binded to the same model. There have been a few useful times this has come up for me, and I don't see the problem. For instance, what if you have 2 divs and only one is ever shown at a time? By default, HTML doesn't encounter this issue because HTML doesn't share values. Actually... that's not true, if 2 inputs have a name on the form, when you hit submit the last input on the page takes precedent. But then, the last input on the page's default could potentially override the previous input's value.

The reason this ISNT bad design in angular is because editing the value of 1 input updates the value for the other, so they are kept in sync (even if you can't see the other input). This is part of why setting the default in 1 place (in the controller) is safer than setting it in the html.

That's the ultimate reason why you can't use standard HTML mentality. You don't bind data to inputs in native HTML.

I think what you've described is part of why people switched to accessing elements on a page by the ID value... there can be only one. The only place I tend to use NAME is on radio buttons so that they get grouped together.

After working with what your example showed me I can at least bind my returned JSON data to the model on the page. Progress! Yay! Getting it off and into JSON to send back may be a whole different story. I'll have to get back to you on that. Thank you for being patient and explaining as much as you have.

[Michael Bielski]

On Wednesday, August 8, 2012 3:02:01 AM UTC-7, ProLoser wrote:

You're doing it wrong.

Set the model's default value in the controller, NOT in the HTML. Imagine what would happen if your HTML has the ability to clobber or change your javascript variables upon init.

Again, you can avoid a blank option by simply doing $scope.mySelect = 'someValue';

Ok, so back to setting the default on a dropdown. I tried it how you have shown above: no dice; I tried it as you had it shown in your example: no dice. Here's what I'm using:

HTML

<select tabindex="7" id="share_type" ng-model="customer.share_type" ng-options="t.name for t in shareTypes" name="share_type" class="span12">

</select>

JS

$scope.shareTypes = [{ name: 'Local', value: '1' }, { name: 'Regional', value: '2' }, { name: 'Global', value: '3' }, { name: 'Not Shared', value: '3'}];

Later on, in a switch, I try to set the selected item via: $scope.share_type = '2';

Again... no dice. So where am I missing this?

BTW, I managed to get the data from the form and post it with just the $scope.customer object. That made me VERY happy! Many thanks!

[Michael Bielski]

At long last, here is what works:

HTML

<select tabindex="7" id="share_type" ng-model="customer.share_type" name="share_type" class="span12">

<option value="1">Local</option>

<option value="2">Regional</option>

<option value="3">Global</option>

<option value="4">Not Shared</option>

</select>

JS (in the controller)

$scope.customer = {

origin_application:'webclient',

active:"TRUE",

customer_id:"",

title_sid:"",

info1:"",

info2:"",

first_name:"",

company_sid:"",

mark1:"",

mark2:"",

last_name:"",

share_type:"2"

};

Many thanks for your help ProLoser!

[Dean Sofer]

Glad you got it sorted out. I think you'll come to find that having Angular directly pluck data out of your JS and directly deposit it back in actually makes life TREMENDOUSLY easier. If you ever need more help I'm always on IRC trying to help most people.

I also recommend checking out my tips and tricks post:

http://deansofer.com/posts/view/14/AngularJs-Tips-and-Tricks-UPDATED

and AngularUI to make development easier:

http://angular-ui.github.com

--

You received this message because you are subscribed to the Google Groups "AngularJS" group.
To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en.
 
 

[Dean Sofer]

I just found this...

http://docs.angularjs.org/api/ng.directive:ngSelected

Hah.

[Michael Bielski]

Yeah, I looked at that but didn't try it. Ah well, hindsight and all. I'll try to remember my IRC account and login... been a few years since I was there. Not even sure if this office will let me go there, but I'll find out. Thanks again!

[James Wright]

I use the angular select and it is a bit screwed up.

I do some stuff where i grab data from a controller, then pass it into the select just like the angular docs.

This works fine, but when i refresh data and come back to the partial with the select, it inserts an empty item with no value.

Once you select something, the empty line goes away.

It's weird, but only happens in an edge case for me.

Jamey

[Dean Sofer]

James: The empty value is created by AngularJS if the ng-model associated with the select is not set to a value in the list of available options. As soon as you choose an option, the blank value is no longer needed and is therefore removed.

--

You received this message because you are subscribed to the Google Groups "AngularJS" group.
To post to this group, send email to ang...@googlegroups.com.
To unsubscribe from this group, send email to angular+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en.
 
 

[Michael Bielski]

You need to let the JS control your HTML, not the other way around. The JS is the application, the HTML is just what it uses to present data. It took me a bit to get my head around this concept, but once you do things start to fall into place.

[levyuk]

How would you set the default selected value of a select which is inside an ng-repeat?

At the moment it always adds the blank option. ng-selected doesn't seem to work. Really stuck on how to set the selected option within an ng-repeat where the data for both the select and the outer ng-repeat comes from JSON.

[Michael Bielski]

Can you put the default values into the JSON? Angular would pick them up from there.

[levyuk]

Amazingly I've just figured it out. It's a bit annoying but once the data comes back from the server I loop over the options and if they match I update some things. I think it's the complexity around having a select within an ng-repeat where the select is a complex type, rather than something simple like an int.

[James Wright]

Yes in my case, the select is a 2-3 property object, not just a simple value.

[dis...@gmail.com]

I'm also getting a problem in this area.

I have a model:

potential_user.working_hours

Setting the model before loading the controller:

$scope.potential_user = {}

$scope.potential_user.working_hours = "Full time"

Is not picked up when rendering the form. If I don't have a nested object ($scope.working_hours) it's picked up correctly.

[Michael Bielski]

I got mine to work by doing something like this:

function yourController ($scope) {

     $scope.potential_user = {"working_hours":"Full time"};

     $scope.someFunction = function() {

          //blah

     }

}

This makes the assignment happen when the controller loads.

[blac...@gmail.com]

Not sure if it will help, but here is one example of selects and defaults.

You will have an empty option unless the data bound select (ng-model) has a matching value.

<select ng-model="selectedChild" ng-options="child.firstName for child in children" />

function MyCtrl($scope, Child) {

        $scope.children = Child.query({}, function (children) {

            $scope.selectedChild.child = children[0];

        });

}

select is populated via 'children' which is the results of an async resource, an array of children.

[{firstName: 'Jimbo', lastName: 'Jones'}, {firstName: 'Bob', lastName: 'Barker'}]

once the resource returns, it simply assigns the data bound model (selectedChild) to the first child in the array as default.

[codewar...@yahoo.com]

I found some good solutions to this problem here:  http://stackoverflow.com/questions/12654631/why-does-angularjs-include-an-empty-option-in-select

[Dean Sofer]

You are doing it wrong.

Set the selected item in the controller, not the html.

--
You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/YX3_JDVGoqo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.

To post to this group, send email to ang...@googlegroups.com.

Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/groups/opt_out.