DoodleBlog

The Scaffold Generator Unpacking Scaffold     There is something to be said for generating your new app and building it up from scratch - there is a personal touch there that should not be understated. We have just built a basic application essentially from scratch and, if you followed the last section, built bits of it again using a bit of help from Rails. But an application framework that relies so heavily on convention should also have means of automating most of the construction of an app and, oh boy, does Rails have this. From its debut , Rails has boasted that it knew what you wanted on your web application simply by the contents of your database. You might have already deduced that this is correct from the magic resources line in the routes configuration, and the routes table it generates, which provides the CRUD routes required by an MVC application. However this flex is fully justif

Our ToDoList web app is certainly a beautiful thing, and has seen a lot of love as we've done most of the legwork manually. However, as mentioned several times throughout the guide, most of what has been done above can be bypassed with higher-level Ruby magic in the form of generators , which automated a great deal of the work. This short section will outline which of the steps we've taken to create our app so far could have been automated in this way. If you want to code along with this section, you can cd back into your projects directory and create a separate Rails app (i.e. to_do_list2 ) to test these generators as we go along: $ rails new to_do_list2 Basic Controller Generation Generating Models Next-Level Generator Usage     Our first step was creating our PagesController and its respective views , which seems so long ago now. Doing this manually was extremely val

With our basic app built and refactored, the final step is to get it somewhere on the internet so we can show it off to everyone. This is called deploying , and will run our app's production environment to serve it to the wider web. In this instance we are going to deploy our app to Heroku , which offers a quick and easy process with a reasonable computing power, and all for free ! Setting Up Heroku Preparing the App for Deployment Deploying the App Other Deployment Options     The first thing we will need to do is create an account on the Heroku website using handy link on the home page: and then fill in the registration form, choosing Hobbyist as your role and Ruby as your preferred language: With this done, you'll simply need to confirm your account via email and set your password in the link it provides you with, initialise your account a

We can be proud of ourselves; we have created a neat little app that utilises both the MVC and CRUD principles of web development and helps us keep abreast of all our little jobs. Seriously, well done! However, as we alluded to at several points during the last few sections, we have certain methods in our controllers that duplicate each other and some HTML in unideal locations. Again, this was fine while we were actively developing our application, however we should always put just as much effort into tidying up our code and making it as optimal as possible. This is often referred as making your code DRY: Don't Repeat Yourself. Enter the refactoring stage! Introducting Partials Partial to a bit more Refactoring Tidy Controllers Are Happy Controllers Quite a Title     You may remember that earlier we added a charming site heading & navigation menu, and a nice confirmat

We Am Become Death     With all we've achieved so far we have every right to feel extremely proud, but we're not quite finished with our basic app yet. We are still missing the final element of CRUD - deleting entries from our data store. Let's bring together everything we've learned so far and add some new functionality to achieve this final step. You may have already notice that there is no prefix value for the todos#destroy action in our routes table. If you think about it, this is because there is generally not a dedicated page on a web application to delete something; you just click a button and confirm your choice via a little popup/prompt. This is exactly what we will get Rails to do. Let's start by adding the logic for the todos#destroy action, which will utilise the Rails object's general #destroy method we learned earlier in Data FUNdamentals, to our TodosCont

Updating Entries in the Front-End index : The King of Views Links, 1, 2, 3     Our application can now create new entries into our database and allow users to read them: by the reckoning of the CRUD principles, we have successfully created half of an application! But supposing a user entered a typo in their original submission of a To-Do item, or needed to add something to its description; this is where the update part of CRUD comes in, which we can achieve by adding functionality to edit to our app in similar fashion to how we've developed the existing functions. The routes for this are already set up via our magic line in the routes configuration. Consulting the routes table we can see that the two actions we need to create are todos#edit and todos#update , which will present a form to edit a Todo object and write this change to the DB table respectively. Let's begin by