public
Rubygem
Description: Merb Core: All you need. None you don't.
Homepage: http://www.merbivore.com
Clone URL: git://github.com/wycats/merb-core.git
Search Repo:
ivey (author)
Fri Feb 29 08:57:47 -0800 2008
commit  0b7f94a35d25057b7cccd593cea3abaae3efa72a
tree    e95572c74de4199533828dc3509fa7e6f0ef1c8a
parent  ff6e1a92e276b04529e7cea4ceb97c5ced4246aa
name age message
folder .gitignore Thu Feb 14 09:16:02 -0800 2008 ignore DS_Store files [tdreyno]
folder CHANGELOG Sun Feb 17 06:55:18 -0800 2008 fix date for 0.9.0 [ivey]
folder CONFIG Sat Jan 12 13:30:36 -0800 2008 Parts of Merb::Controller ported over [wycats]
folder LICENSE Sun Jan 13 17:50:05 -0800 2008 Updated rack adapters, added Merb::Config and m... [ezmobius]
folder README Thu Feb 14 08:28:57 -0800 2008 better docs for sample apps [ivey]
folder Rakefile Fri Feb 29 08:57:47 -0800 2008 get autotest working for merb-core [ivey]
folder TODO Sun Jan 13 17:50:05 -0800 2008 Updated rack adapters, added Merb::Config and m... [ezmobius]
folder autotest/ Fri Feb 29 08:57:47 -0800 2008 get autotest working for merb-core [ivey]
folder bin/ Fri Feb 29 08:57:47 -0800 2008 get autotest working for merb-core [ivey]
folder docs/ Fri Feb 01 11:31:17 -0800 2008 Repairing a little of the damage by Hater. [Hampton Catlin]
folder lib/ Fri Feb 29 08:57:47 -0800 2008 get autotest working for merb-core [ivey]
folder simple_benches/ Mon Feb 18 19:19:26 -0800 2008 Fixes for capture/concat [wycats]
folder spec/ Thu Feb 28 12:25:20 -0800 2008 Merge branch 'tiny_typo_fix' of git://github.co... [wycats]
folder 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