public
Fork of wycats/merb-core
Description: Merb Core: All you need. None you don't.
Homepage: http://www.merbivore.com
Clone URL: git://github.com/auser/merb-core.git
ivey (author)
Thu Feb 14 08:28:19 -0800 2008
commit  ecf2c43de74354a441b9fe4030f4969354a87c3f
tree    6caf7cc9f468d71d1e4c8923c3a6a282a6cd0a4e
parent  47d4122d73eaf6186f1f7077f2a4a171287d7634
name age message
file .gitignore Thu Jan 31 17:06:29 -0800 2008 rake rcov works now with the individual spec ru... [Yehuda Katz]
file CONFIG Sat Jan 12 13:30:36 -0800 2008 Parts of Merb::Controller ported over [wycats]
file LICENSE Sun Jan 13 17:50:05 -0800 2008 Updated rack adapters, added Merb::Config and m... [ezmobius]
file README Thu Feb 14 08:28:57 -0800 2008 better docs for sample apps [ivey]
file Rakefile Tue Feb 12 20:20:24 -0800 2008 Allow for running specs with different Ruby imp... [dudleyf]
file TODO Sun Jan 13 17:50:05 -0800 2008 Updated rack adapters, added Merb::Config and m... [ezmobius]
directory autotest/ Fri Feb 01 11:32:29 -0800 2008 A few more tweaks [Hampton Catlin]
directory bin/ Mon Jan 28 22:12:40 -0800 2008 Now that 0.5.x is end-of-lifed, merb-core insta... [ivey]
directory docs/ Fri Feb 01 11:31:17 -0800 2008 Repairing a little of the damage by Hater. [Hampton Catlin]
directory lib/ Thu Feb 14 01:04:08 -0800 2008 use REQUEST_PATH when matching routes so webric... [ezmobius]
directory simple_benches/ Tue Feb 05 13:41:08 -0800 2008 Adds new paths and makes render work in dev mode. [Yehuda Katz]
directory spec/ Thu Feb 14 00:22:44 -0800 2008 Fix problem with static files, use Proc === body [ezmobius]
directory tools/ Fri Feb 01 11:31:17 -0800 2008 Repairing a little of the damage by Hater. [Hampton Catlin]
README
merb-core is a new branch of Merb (also referred to as merb-next or the 0.9 series) which aims to provide a stable, 
stripped down API for a future Merb 1.0 release.

This branch is based off the 0.5 release series but with significant rewrites.

Goals of this release:

  * Stabilize the @public interface methods to provide for a more consistent application development experience.
  * Remove features until nothing except a central application API is left
  * Improve comments on methods using a standard documentation methodology as described in DOCUMENTATION_STANDARDS
  * Separate the tests into two sections... "private" and "public"
    * Public methods are methods tagged with @public that will be part of the standard, stable Merb API
    * Private methods are implementation methods that might 
  * Implement a new render API
  * Build more extensions to regain selected features when needed
  
To familiarize yourself with how a merb-core application might look,
use merb-gen (from merb-more) to generate a few apps:
$ merb-gen myapp                   # a "normal" merb app
$ merb-gen myapp --flat            # a flattened app
$ merb-gen myapp --very-flat       # a single-file app