Im quite new to Angular, so how Im approaching this might be entirely wrong, but some general advice on which direction to take with this would be much appreciated. More or less what I'm trying to do is use Angular to create new "Like" objects (similar to facebook 'likes'). They contain two values, user_id (which used to be set by rails as current_user.id via devise's helper method) and post_id.
My problems:
current_user is not accessible in Angular's ng-controller
You can't provide default input values directly into the form like so:
`
<input type="text" value="<%= current_user.id %>" ng-model="newLike.user_id" >
So more or less what I'm asking is, how could I manage to set default values of the inputs for user_id and post_id. I've come across recommendations for using ng-init, however, from everything I've seen it seems that this only allows setting default input values from the angular controller
EDIT:
It took shockingly long for it to dawn on me to pass the variables in as params to addLike so I've managed to successfully create new objects based off of the current_user.id & act.id.
Rails way
You can write inside your .html.erb (or .js.erb) javascript code that initializes a global / passes a parameter with the value of current_user.id
Angular way
Using ng-init is perfect here (better over the rails way). As Mark Rajcok commented ng-init can be used from your HTML like this:
<input type="text" ng-init="newLike.user_id='<%= current_user.id %>'" ...>
Related
Say I have the following q-input:
<q-input
v-model="form.email"
inverted-light
color="white"
stack-label="Email:"
type="email"
#blur="$v.form.email.$touch"
:error="$v.form.email.$error"/>
I'd like to be able to make it so that if the domain of the email is mydomain.com that the form action will change to another website (without csrf protection) and the POST will be made to that website instead of the main one.
To do this I was thinking I could use jQuery. eg. $('#email').val().replace(/^.+#/, '') == 'mydomain.com' then change the form action and submit.
The only problem is: I don't know how to set an id attribute on q-input.
Any ideas?
As of early Quasar 1.4.2 (November of this year) you can specify the id value on the resulting html generated by q-input by using the "for" property (see the end of the behavior properties: https://quasar.dev/vue-components/input#QInput-API).
So, for example, you could add for="myInputId":
<q-input
v-model="form.email"
inverted-light
color="white"
stack-label="Email:"
type="email"
#blur="$v.form.email.$touch"
:error="$v.form.email.$error"
for="myInputId"
/>
The id attribute with value "myInputField" will end up on the resulting <input> element in your HTML.
Not using the "for" in the elements gave me a lot of headaches because the Jest snapshot generated random IDs
According to the docs for Form Helper's form_for:
The form_for method automatically includes the model id as a hidden
field in the form. This is used to maintain the correlation between
the form data and its associated model. Some ORM systems do not use
IDs on nested models so in this case you want to be able to disable
the hidden id.
This makes sense and is important, but if you have two form_for calls on the same page, it generates two hidden fields with the same markup and the same id. In my case, it generates this twice on the same page:
<input id="clinic_patient_signup_clinic_patient_link_person_attributes_patient_information_attributes_id" name="clinic_patient_signup[clinic_patient_link][person_attributes][patient_information_attributes][id]" type="hidden" value="32" /></div>
Is there a way to overwrite the id attribute of that input? If I remember correctly, it's just the name attribute that is important, and the value can stay the same. Our site has to be WCAG 2.0 accessibility compliant, and it won't allow two tags on the same page with the same id. (That's also not valid HTML.)
Use the form_for :namespace option.
See https://stackoverflow.com/a/26415985/2511083 for a complete answer.
Example, i made a form like this
<form name="register" method="post" enctype="multipart/form-data">
<p><h3>User check</h3></p>
<p>admin ID: <input type="text" name="userid"></p>
<p>admin Pass: <input type="password" name="password"></p>
<input type="submit" name="apply" value="Submit"></p>
<p> </p>
</form>
and my manager wants to change this form to rails form template like this,
<%= form_for(:model) do |form| %>
<p>
<%=form.label :input%>
<%=form.text_field :input, :placeholder => 'Enter text here...'%>
</p>
<%end%>
My question is, it works fine with html based front code. Why do i have to change this to rails code? I just want to keep my front-end code...I don't know why i have to change this :(. Also, I'm new on Ruby on Rails. That is the main reason. I dont' want to change the existing code, if it is working.
I really hate this job. I have to translate all the attributes to the rails code and that makes me really exhausted :(
Form builders are here to help
Form helpers are supposed to make your life simpler. They are quicker to write than their pure html alternative, provided you don't write pure html first.
They also provide a lot of easy implementations for difficult integration pieces, like :
displaying a date selection select group
mirroring the fact that a check box has been unchecked in POST params
automatically adding multipart param on form if you add a file input (not actually difficult to achieve, but easy to forget)
... and many more
Further development
All of this is about comfort, and you may think you could avoid it if you already have a perfectly working pure html implementation.
But what happen if someone later has to add a date select input in your form ? She will have to use the rails helper, since it saves a lot of time in controller part to set date in database. But she won't be able to leverage form builder, since you haven't used it.
Now, she has to choose between using a non builderdate_select tag mixed in pure html or ... to rewrite your form completely. As you may realize, mixing different styles is generally considered ugly, and we don't like ugly in ruby.
Security
Form tag helpers also provide an important security measure : CSRF protection. Every time you use a rails helper to create a <form> tag, it automatically adds an hidden input containing a secret key. That key has to be posted with form data to prove request originated from current website.
If you use plain html forms, you won't have this security. You could of course add the token manually using the correct method, but this would again be more time wasting than simply using form helpers.
Bottom line
The main problem is that you write pure html before using rails helpers - that is what is wasting time.
Some benefits of using Rails form helpers are:
Consistent naming of input elements names and ids
i18n support for labels
generated URL with form_for is less error prone
Better handling of checkboxes
Nice helpers like options_for_select
Less typing
That last ones might be my favourite: less typing.
I am using an AJAX form post to send some form fields to the server, where the data will be updated in the database, and is massaged in the process, so the data may change a bit on the server side. The response of this controller's action is a partial that updates the form field's HTML so that the values of those fields include the new massaged values.
The trouble is, apparently some MVC .js must be executing on the returned partial's HTML to change the value of the text fields back to their originally posted values, so that the massaged values never show up.
I can see how this might be useful in some scenarios, but it's defeating my scenario. How do I suppress this behavior?
EDIT
I've discovered that if in my partial I replace this:
<%= Html.TextBox("FirstName", Model.FirstName) %>
with this:
<input name="FirstName" value="<%= Html.Encode(Model.FirstName) %>" />
that the value in the form field updates as I would expect. So it seems there's some magical side-effects of Html.TextBox that I don't yet understand.
I don't think there's any random javascript being executed. MVC doesn't rely on javascript, and certainly wouldn't be injecting it into your pages.
More likely the issue is that your ModelStateDictionary is holding the original values. Values that exist simply in the form post but that are not applied to the model are not going to show up. See this thread for some helpful pointers.
It seems like everything I look up on this subject has either changed since the release or is wildly different from eachother.
I just want to create a simple form in my view.
Should I be using the Html.BeginForm()/TextBox()/EndForm() methods or should I be using a plain-jane HTML form? Which is preferred?
This is what I have so far:
<%=Html.BeginForm("Create", "Product", FormMethod.Post); %>
<%=Html.TextBox("productTextBox", "Enter a shoe name"); %>
<input type="submit" name="createButton" value="Create Me!" />
<%=Html.EndForm(); %>
What is the "correct" way to create a simple form with a button and textbox in ASP.NET MVC and allow me to submit the data in the form to the /Product/Create action?
How do I then access the form data from within that method? Some people seem to use a "FormCollection" and others just do a Request.Form method. Which way should I use?
Can someone enlighten me?
The Form helpers are the recommended way because it allows you to provide a controller, action and other route data and the URL is auto-generated based on your routes (in Global.asax). The advantage is, if you decide to change your routes, you don't have to update every URL in your site.
The only reason I'd use an actual "<form>" tag was if I needed extra control over the markup that I couldn't get from Html.Form (I can't think of an example right now). Even if you choose to do that, you should use the "Url.Action" helper to get a URL from routing data. For example:
<form action="<%= Url.Action("Create") %>">
As for your second question, I'd suggest using the Model Binder. Check out ScottGu's Blog for some details on this.
Have a look at Link.
It's German text but the code should be understandable.
Have you looked at this:
http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx
It's from the horse's mouth, and is up-to-date with the final release.