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.
I’ve been doing quite a bit with jQuery and Ajax as of late and have not only been impressed at the ease of implementation, but also the snappy and responsive feel that it brings to your web apps.
To demonstrate this I’m going to show you how to make a simple unit converter, which will allow you to convert units of digital storage without having to make a single page refresh.
Consider this scenario:
You have a form which submits to itself (e.g. a simple contact form). The first time it loads you don’t want to do anything other that render the form.
However, when a user hits Submit, you want to process whatever data you have received, then re-render the form, including (for example) error messages where appropriate.