Padrino 0.9.20 - now works with Sinatra 1.2
Today, we have released a new version of Padrino 0.9.20 which is fully compatible with Sinatra 1.1.0, 1.1.2 and 1.2a. There have also been a great deal of bug fixes in this release as well for many of the core functions provided by Padrino.
The major things that have been modified in this release are the easier management of middleware, fixing datamapper issues, adds erubis support, fixes to project generation, slim support, and namespaced application support in mounter. A more detailed list of changes is included below.
There are no breaking changes from the previous version. Other than Sinatra 1.1.X and 1.2 support, the following are the major changes in 0.9.20:
Middleware Management
You can now easily manage middleware in front of the Padrino application stack. To add middleware simply do:
Padrino.use(Some::Middleware)
You can also clear all middleware with:
Padrino.clear_middleware!
See this commit for more information about this.
New Rendering Components
Padrino now supports slim and erubis rendering engines out of the box. To use slim or erubis, just use the generators:
$ padrino g project example --renderer=slim # or erubis
This will generate the project to use those templates by default and properly include them in the Gemfile!
Namespaced Mounter Support
Padrino's project mounter now supports namespaced applications properly as follows:
module ::SomeNamespace
class AnApp < Padrino::Application; end
end
Padrino.mount("some_namespace/an_app").to("/")
See this commit for more details. Thanks mcmire!
There were also a lot of other bugfixes in this release as we try to become more and more stable towards a 1.0 release.
Next Step
We are already working towards a 0.9.21 release and will likely include more bugfixes, more components, etc. If you run into a problem please do let us know on Github Issues or better yet with a Pull Request .
You can also check out the full changelog as well.
Contribute
Padrino Moving Forward
Today on the Padrino google groups a user named ‘sol’ asked an interesting question about the roadmap for Padrino.
I think this is an important question to explore. Padrino has really come a long way since the idea started life as sinatra_more in October 2009 . The code base has filled out and most of the original functionality we intended to provide on top of Sinatra now exists in full. So in this post, I want to talk about where Padrino is going in broad strokes.
The reason we originally built Padrino is that Sinatra by nature was intentionally constrained to be very limited in scope. This was by design and the constraint is what allows Sinatra to be universally accessible and useful for a wide variety of projects.
Sinatra will never grow much outward in scope because the developers behind it rightfully feel that any additional scope added to Sinatra itself would be a disservice. Instead, Sinatra is a perfect foundation to be built onto by other projects that can add additional functionality and grow the size and scope of what is possible during development.
This is where Padrino fits into the ecosystem. As one of the original creators of ‘sinatra_more’ and ‘padrino’, I personally never intend for Padrino to abandon the Sinatra roots. It is important to me that Padrino simply build on the foundation provided by Sinatra. Part of this means keeping the scope of Padrino constrained as well. When we first started this project, we knew there were a set number of things that needed to be added to Sinatra in an organic and natural way. This set has always been roughly the same since the project creation:
1) Admin Panel Functionality (ala Django) 2) User Authentication and Permissions 3) View Helpers and Form Builders for templates 4) Generators for providing better default structure 5) Advanced routing, controller and alias functionality 6) Easy to use integrated mailer 7) Localization support baked-in 8) Caching (fragment, page, action) and adapters for cache storage
Beyond this there are some other niceties such as code reloading in development, better logging, et al. Really Padrino in it’s entirety does do quite a bit to extend Sinatra’s scope in almost every direction towards more powerful application development.
However, I feel we are not looking to expand the constrained scope this project has. In other words, those goals above are really the extent of what we want to bring to the table and all other major functionality can be tacked on as Padrino extensions rather than into core.
Obviously there is still a lot of work to do and Padrino will continue to grow. There are a few features left to finish (improved helpers, nested forms , ujs support ) which are mostly half finished. Also as always we need better tutorials, better documentation, support for more components, bug fixes, better test coverage, et al. This is the direction going forward.
Padrino is not looking be rails or YAWB (yet another web framework). Sinatra is already a tested and proven development option and we plan to continue our quest to make Sinatra development so flexible that it can be used for the smallest one line app or an advanced e-commerce consumer site without sacrificing what makes the development experience so pleasant.
As always, we are also open to hearing any feedback Padrino users might have. So please let us know in irc (#padrino) or in the Padrino google groups or through github (pull requests, tickets or otherwise). Also, if you want to help out Padrino in anyways please do let us know (or simply send me a message through github).