Transcript
Hello, friends. So here I have a basic self-checkout restaurant menu and the application as many other applications have some global settings, like their application name, the application description, their contact phone number, contact email, and how would you usually approach, uh, storing this in the application. Option one is just to hot code them, but, uh, then it's not a great pattern because if the, like application name changes or phone number changes, you would want to manually change it in multiple places in the application. So it's not a very sustainable approach. One approach that I took in the specific application is I, uh, moved this kind of global settings to locales. So here I have the application title in the, the top title. I have it, uh, in the application header, and I have started to locales. So if I go to EN NVML here, I have a separate folder that I created for locales with application, name, description, and so on. So if I change the name and, uh, go back to the application here, you see it has been reflected here and here. So just one place to manage this kind of global settings. I, again, can change, like, uh, show or hide this tab. I will set it to false. And you see the tab is hidden, but it's not a very sustainable approach. But of course it requires a developer to open the code and, uh, do some, uh, changes and, uh, redeploy the application. So there's been a lot of discussion of what the good approach to storing kind of application wide settings is. So there's an idea of storing them in application rb in the application config, there's been discussions here suggesting different gems for, uh, storing application, uh, settings, uh, create a via ML file. Uh, another approach I discussed in episode 45 was, uh, the rails feature conflict. Four, that allows you to have, uh, environment specific or global, uh, settings in via ML file. I think it's a quite good approach, but it doesn't solve the problem of, uh, uh, not requiring a developer to participate in change gender application settings. So recently I discovered this, uh, really nice GM rails settings, cached that, uh, creates a database table where you would be able to store, uh, the settings and, and also have some default settings that you can override. So an admin would be able to actually access that database table and change settings without, uh, redeploying the application. So let's try installing this gem in this, uh, application. I'll, uh, run this command rails, uh, bundle, add rails, settings, cached. Uh, I'll run the install command and it's going to create a, a setting model. I could join it with, uh, like another name and it would, uh, store not in the setting model, but in another model that we would like. So anyway, let's use the setting model. So it created a migration and a model. Let's have a look at the migration. The B um, create settings. So it creates a table with the, uh, keys and, uh, values and the setting model. Here, here, we'll given a few, uh, fields, uh, that we can use, uh, uh, as an example. Okay, let's run the migration rails. Did be migrate. Let's, uh, open the rails console and go to setting, setting. Oh, there are no settings yet. Let's, uh, try and comment in one of the settings. So let's, uh, type setting host, um, let's reload setting host. Okay, here we have this, uh, host set. Um, let's, uh, move our application name to this settings. So here I will have, uh, field, uh, app, name, type, stream, and default, uh, my restaurant. Okay, uh, let's, uh, start the application. And here I'm now getting the application name from local. Instead, I will get it from setting. So I will have set, uh, app name here And Let's, uh, refresh our application. And here we have the, uh, name set as a default in the settings. So I add add one in the end, and you see it has changed here and in the tab bar. Okay. But, uh, if we go to our real console, if we go to setting dot count, you see there are no settings actually stored in the database. We're just using the default, and we want to, to let the admins see the defaults and override them if they want. So let's, uh, add an admin interface. Now, if we go to the documentation of the gem, there is an example of, uh, uh, route controllers and views that we can, uh, copy paste into our application and add the settings. I actually recently made, um, blue request into this gem, hopefully bit merged at France. It, uh, as a generated to create these, uh, uh, roots controllers and, uh, views. So it should make, uh, the process faster. I will run it from my branch. So here I have my branch rails and cached, uh, my GitHub and my branch. I will, uh, run bundle once again. Uh, now I will run rail, generate settings, admin, it'll generate the controller, uh, view, uh, roots. So let's have a look. Uh, going to our roots here. We have namespace admin resource, uh, settings. I have another name space admin here. So it's duplicated, but uh, I can put it inside. Okay. Uh, now, uh, here in our settings ib, I was injected with a few example fields. Uh, additionally for tests, uh, go into our controllers have, have this setting controller with the create action. And, uh, uh, we also have the deaf show that is, uh, not defined, but is present, uh, in the views. So here we go to views, um, settings show. Okay, let's try actually accessing it in the rails, uh, server. So going to local host slash uh, settings, oh slash admin slash settings. And here we have the application settings. So we have like the restaurant name, for example, here, have the default restaurant name. I will change it to one to three. Save settings. You see, we have this new restaurant name, and if we go to Rails console, setting, dot count, uh, setting. Oh, uh, you see these other settings have been also saved. But, uh, we also have the application name that, uh, is, uh, taken not from the default, but from what we actually have in the database. So this is really nice. And Jim also provides a lot of, uh, cool things like validations for fields that can be edited by, uh, admins, uh, read only fields that, uh, can be displayed for admins but not edited. So it's really cool. I encourage you to try this gem and, uh, uh, store global, uh, configs in the V place. And it's really cool that the admins can, uh, edit this configs. Now, um, in this, uh, I have to note that in this application I'm using the simple CSS. So I have this, uh, nostalgia script. So if I remove the nostalgia script, then the views for the settings are not, uh, really nicely styled. So you can sell them on your own, but, uh, otherwise you can use, uh, a script like simple CSS, just in this, uh, uh, single show file to make it look, uh, uh, the form look nice. So thanks version, and see in the next one.
0