This is what I'm trying to achieve. I want to build an application with an admin and client portal. So I want to build a single RoR application for both these portals and I would like to keep the code of each portal separated at the root level. So basically following is the folder structure I want to have in my project.
/admin
/client
/modals
/config
/db
...
...
So I want to keep controllers, views, and other stuff relevant to each project in each folder separately.
So I want to move the modal folder to the root level as well. I read about the namespaces in RoR, but as I understand I'm unable to do it with namespaces alone. I guess I need to do some configuration level changers, don't I?
Please let me know if there is a way to do this.
Thank You.
What you're suggesting sounds like 5 Rails apps running independently. Does each one of those directories have its own Gemfile, database?
It would be possible to do what you want, but it will almost certainly be more trouble than it's worth. You'll have to override some path configurations, make adjustments to connect the models/views/controllers directories for each entity (https://guides.rubyonrails.org/action_view_overview.html#view-paths), and probably much more. Rails is an opinionated framework and it doesn't do things like this gracefully.
The 'Rails' way to do it would be to:
Add some namespace routes for each of your directories
Add app/models/admin app/views/admin app/controllers/admin etc. directories
Namespace your model/view/controller files. e.g. class Admin::SomeController < ApplicationController
If each of those is really its own app, then you would probably want to create a repository for each of them so that they're in version control separately.
Related
When using Rails to only write an API, the term "app" seems less appropriate than something like "api". Is it possible to configure Rails to use a different folder besides "app" to load controllers, models, etc.? Preferably, I'd like my frontend code(outside the Rails asset pipeline) to live in "app", so creating a symlink isn't a preferable solution.
You can probably get it working by adding some hacks and fixes here and there. And then it will break again with the next gem/tool/IDE/plugin/...
Rails is strongly based on conventions, the app directory is one of them. Leaving as it is will save you lots of troubles.
Is there any way to package your code by feature in rails? I would like to structure my project so that each feature has its controllers, jobs, mailers, layouts and helpers in its own folder. e.g.
app
----user
--------jobs
--------controllers
--------mailers
--------layouts
--------helpers
----company
--------jobs
--------controllers
--------mailers
--------layouts
--------helpers
where user and company are seperate features.
I've done this in my app and its pretty easy.
You create your file structure the way you want it and then you just put config.autoload_paths += %W(#{config.root}/app/user/jobs) or whatever other subdirectory you want into your application.rb folder.
People might say this is not the rails way but I feel your pain when your project gets really big and hard to navigate.
Checkout Trailblazer gem. It is an extension on the basic MVC pattern.
I like to keep things organized in my applications and since I have only been coding in ROR for a year. I have known how to use the app/controllers/concerns directory for custom modules to be included in a controller.
This is great however I am wondering if there is a way to add sub folders to the concerns folder to allow for better organization.
For example app/controllers/concerns/members/profile_methods.rb and the module is named 'ProfileMethods'. If I include 'ProfileMethods' RubyMine see's the module and allows me to include it, including offering it as an option in the tooltip pane. However the Rails Server says that 'ProfileMethods' is an undefined constant if it is in a sub folder of app/controllers/concerns .
Is there something I have to add to the rails application configuration? Any input would be great as it seems a little illogical that you could not further organize the concerns directory with sub folders.
The best way to keep things organized is to name the module the following way. That way you have your code organized in both files and code itself.
module Members
module ProfileMethods
extend ActiveSupport::Concern
...
end
end
This way it will load your modules fine. Other one option is to tweak eager_load_paths in config/application.rb for instance.
I am working on a project where the current developers have put their "Plain Old Ruby Objects" in the models directory of our Rails app.
I have seen most examples online where the PORO files go inside lib instead, but some say models.
Is there even a logical / specific reason why people put them in the models directory over the lib directory?
"Idiomatically" the models directory intended for code used to hold state. Most of the time this would be ActiveRecord subclasses corresponding to database tables. However frequently people put other stuff in the models directory. One thing often seen are code dropped here in order to take advantage of auto-reloading. (the lib dir doesn't normally auto-reload)
Based on the Getting Started Rails guide, the app/models/ directory is pretty much anything, whereas lib/ is for modules that are used across the entire app (e.g. extensions).
As #seand said, yes, one advantage is that the app/models/ directory automatically reloads, but I tend to think of it as any class that "interacts with other classes" should live in app/models/, with the only exception being a service class (which I tend to think of as "a class which manipulates the state of another class"), which I tend to put into app/services/.
I know a lot of developers would disagree with me - many I've talked to even create a separate directory namespaced to their app (e.g. if your app is named "MyBlog", they would create an app/myblog directory for any object not explicitly backed by the database, but not a module or a service class either.
That said, I think ultimately it boils down to a) personal preference and b) where you feel is best to place the PORO with respect to your app.
There is no hard and fast rule on where to put POROs. The rails community has been hashing this out for a while now. At one point the convention was to put stuff in the concerns directory but that seems to have fallen out of favor with some folks.
One rule of thumb for the difference between /lib and app/{blah} is that code in the /lib folder is code that you presumably can reuse across several projects e.g. general purpose class or utilities. for example if you have some custom monkey patches to core ruby or rails classes that you will use in multiple projects, a good place to but them would be in the lib folder. Anything in app/{blah} should pertain specifically to current project.
One way to think of lib folder is as the poor cousin of plugins and gems.
Just my 2 cents on the subject
For every project it's like having two parts: the Rails application and then all documents and pictures related to it.
I wonder how you organize them both.
Do you put everything under the same project root folder and apply Git on that folder or don't you protect your documents with Git at all?
Then, what if the docs are too sensitive or only for owners of that project. Then I probably should't have it under the same folder right?
How have you structured both your Rails code and belonging business documents?
Share your solutions!
If you're deploying with capistrano, as a lot of Rails apps are, the standard solution seems to be to keep these sorts of assets within the shared folder, and then get cap to symlink them into the application at the point of deploy.