Using this gem: https://github.com/anjlab/bootstrap-rails
For some reason the forms are not working properly for me. There is not curves when the input is being used.
And I cannot add classes to it like 'form-inline'
Not sure what the problem is. Anyone else facing this/have a solution?
After digging further, and deciding to trial and error, I got it working but have to manually input the classes for each form.
<%= text_field_tag :twitter_contact, nil, class: 'form-control'%>
Now i have this:
Why is the gem not working automatically to do that itself? Am I missing something?
You can write you own helper methods that include this for you. For example
def my_text_field_tag(name, value)
text_field_tag(name, value, class: 'form-control')
end
in your ApplicationHelper would give you something closer to what you're looking for.
The fact is that Ruby gem authors have to be careful injecting too much auto-magic into their code, as it actually conflicts with other Ruby gems. To a certain extent, you have to learn how Ruby works in order to get the full magic that you're looking for.
Related
In Rails 7, Turbolinks is replaced by Hotwire / Turbo. This patches up web links so that they become AJAX-style requests just like Turbolinks did, but also patches up forms. On the whole, we found this broke swathes of our application.
Forms that already had some kind of JS behaviour attached conflicted.
Standard Rails error handling idioms - "set the flash and render :new/render :edit" - break, astonishingly; one must add status: :unprocessable_entity and cross fingers.
If the controller handling a form submission redirects to a URL that includes a patch anchor (...#foo), Turbo strips it.
In the end, there's only so much data: {turbo: false} it makes sense to scatter all over your code base. Worse, we're using SimpleForm, so this becomes the even-more-cumbersome html: {data: {turbo: false}}.
Is there a way to _globally disable Turbo just for forms (ideally all forms, whatever their origin - just leave the <form> tag and everything inside it completely alone please) but leave the rest of its behaviour unchanged?
I posted this Q&A on Stack Overflow as I couldn't find any other solutions out there. Clearly, there are numerous shortcomings and I would much prefer to see a simple configuration flag for Turbo that would make it ignore forms - this would be an overwhelmingly preferable approach.
I still don't have a full solution either way, because forms generated internally by Rails for e.g. a link_to(...method: delete) are still a problem, but I did work around some of it using some monkey patching.
On the one hand there are Rails forms:
Apparently, a data-turbo attribute's value apples to that node and all children so one can wrap e.g. a Rails-generated 'dynamic' form from e.g. a link_to(...method: delete) in a DIV with that attribute set and, at least, work around those problems on a case-by-case basis - though note, I'm having trouble making this work in some cases still.
If you have a lot of these, though, that's going to be intrusive and ugly, so it'd still be nice to have a way to have Turbo just ignore forms completely.
On the other hand there are SimpleForm forms:
SimpleForm provides no way to globally configure data attributes that will be added to form elements that it constructs. Previous requests for this in GitHub issues have so far been explicitly refused.
SimpleForm appears to provide no way to configure a wrapper that would go around the form as a whole, only custom wrappers for inputs within a form. So we can't easily just e.g. write a wrapper DIV as mentioned above.
I happened to be involved in a gem called Hoodoo that provides monkey patching facilities that lets you write patch modules which are more like subclasses - super is available to call up to the patched implementation - and, further, patches can be enabled or disabled dynamically and easily. Hoodoo is actually a Rack application service framework, so this is something of a sledgehammer - I always intended to one day extract this into its own gem, but at the time of writing, I have not got around to it (and several years have gone by) - but we can require just the part we need and ignore the rest.
Here, I patch SimpleForm's builder methods. These just call Rails' form helpers under the hood, so I might have a go at patching lower down in Rails instead, but anyway, the following worked.
In your Gemfile, declare the Hoodoo dependency but don't load all of its component parts as you won't want most of them.
# Hoodoo's monkey patch module is useful sometimes:
# https://rubygems.org/gems/hoodoo
#
# MUST use 'require: false' so that the Rack components of Hoodoo middleware
# do not get activated; this is a Rails app, not a Hoodoo service!
#
gem 'hoodoo', '~> 2.12', require: false
...then write something like config/initializers/simple_form_monkey_patch.rb which looks something like this:
require 'hoodoo/monkey'
module SimpleFormMonkey
module InstanceExtensions
def simple_form_for(record, options = {}, &block)
modified_options = {html: {data: {turbo: false}}}
modified_options.deep_merge!(options)
super(record, modified_options, &block)
end
end
end
Hoodoo::Monkey.register(
extension_module: SimpleFormMonkey,
target_unit: SimpleForm::ActionViewExtensions::FormHelper
)
Hoodoo::Monkey.enable(
extension_module: SimpleFormMonkey
)
...that'll do it. This has some risk as we're patching things which are - in terms of the module name & nesting - technically private to SimpleForm, but the method signature itself is at least public. You could patch ActionView::Helpers::FormHelper with an override for form_for instead, if you wanted to go lower level and patch an API that's been stable for a very long time. The code would be almost identical as the method signatures are the same.
I used Javascript to solve this problem:
document.querySelectorAll('form').forEach(function (el) {
el.dataset.turbo = false
})
No more flaky system tests due to randomly missing flash messages/alerts after form submissions and Devise also works perfectly again.
#kamilpogo your solution worked like a charm! ty!!! currently learning and following this GoRails tutorial before i ran into some turbo trouble trying to render "Thanks!" for anyone else out there.
basically, i added the javascript to in /layouts/application.html.erb like below:
<script>
document.querySelectorAll('form').forEach(function (el) {
el.dataset.turbo = false
})
</script>
<script src="js-bootstrap"></script>
</body>
</html>
UPDATE: comments in the videos have a different work around by setting turbo to 'false' and local to 'true' inside the form:
form_with model: #user, url: sign_up_path, local: true, data: { turbo:false } do |form|
I am using form_for tag and Its working in Rails 3.0.4 environment.
But when I tried to update my project to Rails 4.It gives following errors
wrong number of arguments (3 for 2). Here is my code
<%= form_for #email, :url => alerts_path do |f| %>
<% end %>
Try to remove things that may try to change things in views.
In my case the problem was with client_side_validations gem
Hope this helps.
Not sure why yet, but removing the "meta_search" gem from my Gemfile fixed this exact problem for me on Rails 4.
If you google this problem you may find this GitHub issue that attributes it to the "client_side_validations" gem, but using the suggested "rails-4-quick-fixes" branch of that repo didn't fix the issue for me.
I think that the error with simple_form_for was a red herring, as I was getting the same error even using Rails built in form_for, and was getting wrong number of arguments (3 for 2) regardless of how many arguments I actually passed into either method.
meta_search hasn't had a new release since February 2, 2012, so I can only assume something in the gem wasn't behaving nicely with Rails 4. If I discover what the problem was specifically, I'll update this answer. It seems kind of lame to have to "just stop using" meta_search, but that's as much as I can offer so far. Thanks!
I can't see any issue with your form_for, can you post backtrace of exception ? may be another gem is overriding default form_for ?
Your syntax is correct.
Try changing it like this:
<%= form_for(#email, url: alerts_path) do |f| %>
#form fields goes here
<% end %>
I tried to see if there is any change in source-code for form_for in Rails 4.0 API; It's still the same.
Have a look at Line 262 at https://github.com/rails/rails/blob/master/actionpack/lib/action_view/helpers/form_helper.rb
Let me know if it works
Remove gem 'meta_search' from your gem file, and look into using gem ransack instead. https://github.com/activerecord-hackery/ransack
I've tried a handful of captchas for Rails 3 and none tend to play nicely with Mongoid. I don't need anything too fancy just something to do a quick human check.
How do you guys get one working with Mongoid? Are there alternative solutions?
That's outside mongoid scope, but still applicable. Have a look at Negative Captcha:
Negative captchas create a form that has tasks that only bots can perform, but humans cannot. This has the exact same effect, with (anecdotally) a much lower false positive identification rate when compared with positive captchas. All of this comes without making humans go through any extra trouble to submit the form. It really is win-win.
You can use simple-captcha v1rtual's branch with mongo support. Simple and clean setup and usage:
Just add to your Gemfile as:
gem 'wolcanus-simple_captcha', :require => 'simple_captcha', :git => 'git://github.com/v1rtual/simple-captcha.git'
Run generator:
rails generate simple_captcha
For Controller Based, add the following line in the file "app/controllers/application.rb":
ApplicationController < ActionController::Base
include SimpleCaptcha::ControllerHelpers
end
In the view file within the form tags add this code:
<%= show_simple_captcha %>
and in the controller’s action authenticate it as
if simple_captcha_valid?
do this
else
do that
end
See the branch for more options: https://github.com/v1rtual/simple-captcha
Trying to use my active record translations in config/locales/de.yml also in my views. I thought I am clever using this:
de:
activerecord:
attributes:
user:
login: "Benutzerkennung"
comment: "Bemerkungen"
And in my view this:
<%= label_tag :login, t('activerecord.attributes.user.login') %>
But instead of the translation value ("Benutzerkennung") I am getting the infamous
"translation missing: de, activerecord, attributes, user, login"
Has anybody got this working (not using the label translation plugin (I am wary of potential side effects), or User.humanize_attribute_name)? What am I missing? (it does work when I use "activerecord1" or something else than activerecord, so my setup seems to be fine)
Thanks!
Ok, my bad, it does work just fine. I fell in the YML formatting trap :(
To help you debug along the way, use "script/console" and the following statements:
- I18n.locale --> should output the locale you want to examine
- I18n.t('activerecord.attributes') --> should give you all the key/value pairs for your translation, if not, you made a formatting error in your YML file or it could not be found
And btw - the plugin works quite well http://github.com/iain/i18n_label/
if you don't like the result of ".human_name" (which the plugin uses), just fall back to I18n.t('your key')
Another method:
<%= label_tag :login, User.human_attribute_name(:login) %>
You should upgrade Rails gem to v2.3.11 (I tried to use 2.3.9, but now days it is not available so I suggest you 2.3.11)!
gem install -v=2.3.11 rails
You can find this issues documented here: Rails 2.3.9 Release notes
Hi i converting rails views from erb to Haml .The issue i faced is when use the form_for the haml throws the UNEXPECTED $end error. I am sure i did the space indentation well with in form_for .......Even if i use "each do" loop is says the same error. if i revert the haml to erb it works fine.
Rails version i used : 2.3.2 & i installed haml gem 2.2.19 as well as haml plugin also.
my controller code :
def new
#user = User.new
end
My View code :
.contentContainer.signup
- form_for(#user) do |f|
Make sure your haml indentation is perfect.
.contentContainer.signup
- form_for(#user) do |f|
= f.text_field :name
Are you including - end in your templates? Haml takes care of ends for you, so if you add your own, it won't work.
Can you paste your entire template (in a code block, so it's formatted properly)?
There's also a good command-line tool to make transition easier: html2haml. It doesn't always produce the prettiest haml, but it certainly works.
Hey, there's even a web-based form for this: http://html2haml.heroku.com/
Generally, be sure your indentation is perfect. haml is very particular about indentation. If you use a decent editor (such as textmate or vim) this is an easy task.
If the last line in file is indented there has to be an addidtional, empty line.