I was recently working on an application, that lets people from all over the world apply for a programme at the place I work.
The application works well and does what it should, but we were seeing quite a lot of double submissions, that is to say, the same person applying multiple times in short succession.
Here’s how I fixed that.
The problem: you have a RESTful resource with default routes. The form to create a new item is located at
http://mydomain.com/resource/new/. When you submit the form with valid input, a new item is created and that works fine.
However, when you submit the form with invalid input, the controller re-renders the form and the URL is changed to
http://mydomain.com/resource. This is potentially confusing for end users.
How can we avoid this?
In Rails, virtual attributes allow you to create form fields that do not map directly to the database.
This can be useful in a variety of situations and can help you customize your interface to make it more intuitive and user-friendly.
In this short tutorial I will show you how to create three text fields to allow a user to enter a date (day, month, year), then combine the values entered into these ‘virtual’ fields and save the new value to the database.
At work, I’m currently working on a rather large form. And when I say large, I mean seriously large – I just counted, it has 136 fields.
Now when a user submits the form, the input is validated. If everything is correct the user’s data is saved to a data base, otherwise the form re-renders, displaying appropriate error messages.
I have written unit tests to test the form’s logic, but nonetheless I still want to test the form manually, just to be 100% sure that things are displaying as expected.
But there’s no way that I’m going to manually fill out 136 fields over and over again. No Sir! A much better solution would be to use Tampermonkey to do it for me.
It often occurs that I make changes to an existing website for a client, then send the client a mail informing them of what I have done.
However, it is not an infrequent occurrence that I then receive a mail back from the (sometimes disgruntled) client, saying that they cannot see any changes.
Hmmm… I know I made the changes and I’m viewing them on the live site, so why can’t the client see the same thing?
The answer is because of browser caching.
One of the main reasons behind jQuery’s meteoric rise to popularity was its use of the CSS selector syntax to select DOM elements and the ease with which it could then traverse these and modify their content.
I was recently tasked with converting a Rails app from Rails 2.3.x to 3.2.x.
“Shouldn’t be too difficult” I thought, but one of the first things that came out and bit me is that the
error_message_on helper method, which was previously used to display error messages next to the form fields that had caused them, has been deprecated.
It took me a little while to figure out how to reinstate this functionality. Here’s how I did it.
I had recently started work on a Rails project and was setting up my local dev environment which I wanted to make it as similar as possible to the environment on the server I will deploy to.
The remote server currently runs Ruby 1.9.2 and Rails 3.x, so this is what I installed on my local machine.
Recently, I made a tab-based menu system which loaded various content via Ajax whenever a user clicked on any of the tabs.
The only problem with this was, that when my page loaded the widget remained empty until the user had actually clicked something.
This left me wondering how best to simulate user interaction and initialize the widget programmatically.
jQuery’s implementation of the Promise pattern (introduced in version 1.5) centres around the Deferred object , the predominate use of which is to attach success and failure callbacks to Ajax requests.