= Conventions This guide goes over conventions for directory layout and file layout for Roda applications. You are free to ignore these conventions, but following them will make your code similar to other Roda applications. == Directory Layout Which directory layout to use should reflect the size of your application. === Small Applications For a small application, the following directory layout is recommended: Rakefile app_name.rb assets/ migrate/ models.rb models/ public/ spec/ views/ +app_name.rb+ should contain the Roda application, and should reflect the name of your application. So if your application is named +FooBar+, you should use +foo_bar.rb+. +views/+ should contain your template files. This assumes you are using the +render+ plugin and server-side rendering. If you are creating a single page application and just serving JSON, then you won't need a +views+ directory. For small applications, all view files should in the +views+ directory. +public/+ should contain any static files that should be served directly by the webserver. Again, for pure JSON applications, you won't need a +public+ directory. +assets/+ should contain the source files for your CSS and javascript assets. If you are not using the +assets+ plugin, you won't need an +assets+ directory. +models.rb+ should contain all code related to your database/ORM. This file should be required by +app_name.rb+. This keeps your model code separate from your web code, making it easier to use outside of your web code. It allows you to get an IRB shell for accessing your models via irb -r ./models, without loading the Roda application. +models/+ should contain your ORM models, with a separate file per model class. +migrate/+ should create your database migration files, if you are using an ORM that uses migrations. +spec/+ should contain your specifications/tests. For a small application, it's recommended to a have a single file for your model tests, and a single file for your web/integration tests. +Rakefile+ should contain the rake tasks for the application. The convention is that the default rake task will run all specs/tests related to the application. If you are using the +assets+ plugin, you should have an assets:precompile task for precompiling assets. === Large Applications Large applications generally need more structure: Rakefile app_name.rb assets/ helpers/ migrate/ models.rb models/ public/ routes/ prefix1.rb prefix2.rb spec/ models/ web/ views/ prefix1/ prefix2/ For larger apps, the +Rakefile+, +assets/+, +migrate+, +models.rb+, +models/+, +public/+, remain the same. +app_name.rb+ should use the +multi_route+ and +view_subdirs+ plugins. The routes used by the +multi_route+ plugin should be stored in routing files in the +routes/+ directory, with one file per prefix. For specs/tests, you should have +spec/models/+ and +spec/web/+, with one file per model in +spec/models/+ and one file per prefix in +spec/web/+. You should have a separate view subdirectory per prefix, and use +set_view_subdir+ in your routing files to specify the subdirectory to use, so it doesn't need to be specified on every call to view. +helpers/+ should be used to store helper methods for your application, that you call in your routing files and views. In a small application, these methods should just be specified in +app_name.rb+ === Really Large Applications For very large applications, it's expected that there will be deviations from these conventions. However, it is recommended to use namespaces in the +multi_route+ plugin, and have subdirectories in the +routes/+ directory, and nested subdirectories in the +views/+ directory. == Roda Application File Layout === Small Applications For a small application, the convention in Roda is to layout your Roda application file (+app_name.rb+) like this: require 'roda' require './models' class AppName < Roda SOME_CONSTANT = 1 use SomeMiddleware plugin :render plugin :assets route do |r| # ... end def view_method 'foo' end end You should first require +roda+ and +./models+, followed by any other libraries needed by the application. You should subclass Roda and make the application's name the name of the Roda subclass. Inside the subclass, you first define the constants used by the application. Then you add any middleware used by the application, followed by loading any plugins used by the application. Then you add the route block for the application. After the route block, define the instance methods used in your route block or views. === Large Applications For larger applications, there are some slight changes to the Roda application file layout: require 'roda' require './models' class AppName < Roda SOME_CONSTANT = 1 use SomeMiddleware plugin :render plugin :assets plugin :view_subdirs plugin :multi_route Dir['./routes/*.rb'].each{|f| require f} route do |r| r.multi_route end Dir['./helpers/*.rb'].each{|f| require f} end After loading the +view_subdirs+ and +multi_route+ plugin, you require all of your routing files. Inside your route block, instead of defining your routes, you just call +r.multi_route+, which will dispatch to all of your routing files. After your route block, you require all of your helper files containing the instance methods for your route block or views, instead of defining the methods directly.