A Padrino layer having opinionated decisions about the configuration of a large Padrino app based on multiple gems.
Convention over configuration AND opinionated decissions... as long as it restricts only the workflow for configuration of a "large SOA" style project, not the architecture and/or gems of the apps.
Maybe it will be liberating having some layout/config conventions to quickly test some ideas. Later more research could be done about what is needed for Padrino to implement the same thing in a more generic way.
- reserve the '/assets' path
- some "core" gem must exist when loading a gemified app
- every gem app must have a prefix
- generate virtual gemspecs to share :dev, :test dependecies among all gems
- virtual gem for "spice" recommendations: pry, better-errors, foreman, dotenv... (hate me for these ones: rspec, capybara)
Problems an embedded Javascript app might have:
- Where are the shared Sass files outside this repo?
- What is the prefix name (or any Padrino::Application.settings value) of the gem where I am running?
some features:
- routing (think of Backbone.js router living inside a gemified app
- asset locations
- view templates, partials (Ruby Slim view with dynamic Javascript based partials?)
- settings and some object/app properties (from Ruby classes)
how could we bridge Javascript apps with Padrino? With Restful (maybe localhost only) API
- reserve '/api/ruby|bridge' path ???
For the implementation maybe this should be a Rack middleware? try to ease extension to Rails?
Lots of security issues for three layers:
- public
- private (localhost only)
- offline - only needed for Javascript tools (Grunt) but not online apps?
... but this only solves on direction Ruby > Javascript ... the other way around?
Or maybe just dump static config data into a JSON file? append to the standard application.json file from Node.js? At least there should be one stablished convention