I have looked around but can't decide on the best way for a 'share via email' form in my rails app without using services such as 'add this' etc...
I want to create a form thats takes 1 email. When submitted it will send an email to that email with a link to the current article and some other pre determined text.
Any way I can do this within my articles controller? Just with a simple method? If so what would the form look like?
I know I could use simple form but I don't want to create a separate controller just for sharing via email.
NB
I know how to handle the sending of the emails etc.. Im just unsure of the best was to interact with the controller via the view. Thanks!
Related
On submission of the contact form in my app I am looking to have the form data be sent to my email.
I looked into using action mailer, but on the rails guides it shows configurations for an automated email from you to a new user on signup.
Is there a potential solution out there using simple form?
I can create the form, just need a little help with configuration so it sends to my email.
I appreciate any advice!
You can just do it like a normal form, submit request to your rails server. Then your server collect the data and send email to you using ActionMailer.
If you don't want to do like that, maybe this GEM can help you:
https://github.com/plataformatec/mail_form
I would like to create a simple contact form on a one page site for the user, where the will write to the website owner.
I just need a basic form with this simple fields:
Name
Email
Message (text)
The logic is simple: a user write a feedback in the form >> the app check if everything is correct (I need a validation),take the form inputs and send a mail to a specific email (the admin email).
No data saved, just send a mail.
I am new to RoR (really at the beginning) and I have tried to find some tutorials and gems to create this form with controller, models etc.
But I didn't find a solution...
Everybody could help me?
Please let me know, thanks
We want to send emails to registered users on our site.
As of now we programmatically create emails and send them like that, too.
What we would like would be a way that a moderator of the site can create an HTML email using a rich text editor on the Rails app, select users from the database, and send it out.
In essence it would behave a little like a web mailer, like gmail. But: mails would be composed as templates and could use some ERB, so they can be re-used to email users, etc.
A sample application could be a newsletter or a broadcast search that is sent to all, or only some users.
Is there a gem that does this?
If no, how would you set this up?
I don't know of a gem that does this specifically, but you can check out action mailer, which is included in Rails by default.
It's very good for sending out templated emails (account confirmation, etc). You create a view, and it renders the content of that view (with ERB) into the body of the email.
You might be able to use this for more customization, but I haven't played around with it too much.
Another option, if you're programmatically sending mail through the UNIX mail command, is to specify the content type as HTML. The command I use is:
mail -a 'Content-type: text/html' -s 'Subject' to_address#example.com < file_containing_message.html
Ah, sorry -- I didn't understand the question. I don't think there's a gem for your case, because it's a very specific use case.
What I would recommend is storing a blob of ERB text in the database for the email template. Then you can use something like this to render the email:
require 'erb'
name = user.name
email_html = ERB.new(email.template).result(binding)
See the ERB Documentation for more info.
I'm stuck figuring out the best practice...
I want to create a "following" system in a way that a user can follow a car (getting email updates when car price changes, etc). The part of implementation that's giving me headaches is when I want to introduce lazy registration by only using email.
Everything needs to work as AJAX requests.
In the interface, there will be a button to trigger the follow action, which will check if the user is registered or not. If a user is logged in, create a new CarSubscription item, otherwise display a form where he could type his email address. Once submitted, the form should create a user with no password (if email exists, ask for the password and log in) and then it should create the relationship item.
The challenge here is to use redirection after submission of the form to the CREATE action of the CarSubscriptionController. Since I can't redirect using POST I can't simulate the CREATE or DESTROY action.
The non-RESTful solution would be to create 2 actions under cars_controller: follow and unfollow and let them do the logic of creating entries and deleting them. That would enable me to just store the request path and use it after the user enters their email and logs in.
How can I achieve what I want using RESTful resources?
After trying to describe my problem here, it seems it's way too complicated and I am indeed very stuck... There are 3 different controllers and possibly 4 requests in this scenario.
Any help would be tremendously appreciated!
Please see my flow chart below:
Not an expert here, I don't know if it's the best solution, but what I have done in similar situation is :
In your controller, respond with javascript instead of redirecting the user
In your javascript file, use $.post(...) to issue a POST to your controller action
Et voilà!
You can also use ActiveResource to achieve this, but I actually never tried that solution : http://api.rubyonrails.org/classes/ActiveResource/Base.html#label-Custom+REST+methods
Person.new(:name => 'Ryan').post(:register)
Hope this helps
I had a very similar need and had trouble pulling the various bits of info on how to do this with Devise and Rails together into a working example. Here's a fully working example based on Rails 4, Ruby 2, and Devise 3.0:
https://github.com/mwlang/lazy_registration_demos
How do miscellaneous account management pages fit into a RESTful design in Rails 3?
For example, a user registers (create action) and is then forwarded to a registration success page (? action) where they are asked to now verify their email address via a url with a token (emailed to them).
When they click the link in the email, technically they are "updating" their account as part of the verification process right? So I'm thinking that would somehow map to the "update" action but the update action is expecting a PUT request. Is that correct? How do you make that work via the email?
I'm also wondering how forgot password, reset password, etc also fit into a RESTful design? Just trying to wrap my head around this.
Just because you have a result design, doesn't mean you HAVE to restrict yourself to only CRUD verbs that map 1:1 to Get/Post/Put/Delete. That said, if you want to get really RESTful, you can start to think of some of these things in terms of being their own resources. For example user verification:
User signs up, and gets sent a verification email, you already have that all squared away RESTfully it looks like
Verification url looks like: http://app.com/user_verifications/new?token=foobar (GET)
They follow the url and maybe are presented with a "Hello Dan, welcome back! Click here to verify your account" at that point you submit a form to http://app.com/user_verifications to trigger the create action there. Now on the backend, you can perform whatever actions you want, updating the user, setting them to active, or actually creating a "UserVerification" model.
Not a perfect example, but the idea is that the RESTful interface you are providing has an additional resource, in this case "user_verifications" and a user is acting upon it via HTTP methods in order to achieve the user's goals. You can apply similar logic to reset/forgot password either with a "UserSession" type resource or even as specific as a specific "ForgotPassword" resource.
Success page is just create.html.erb file. Usually you are redirecting from create action, but here you can just render success template.
Verifying. If you want to stay REST you should add one more step: GET verify, where is the form with your token present, which will lead to PUT update action. User recieves a link to this page.
But I prefer to use simple GET request here, which will update information without any additional clicks.
The same way you work with restoring passwords and other functionality. You add a page to with form that gets email, then you send a letter with link to a page with form filled with tokens and so on.