a goaloc entity needs to be able to encapsulate roughly what a merb slice does:  the model, view, and controller parts of an application.

it needs:

model:
associations
dbfields
validations
model_lifecycle_callbacks:  before_save, after_validate, etc..

controller:
list of actions to support
filters
destinations for the non-GET actions (delete, create, update ) (pretty much only 2 reasonable options for each)

view:
form, large and small individual representations, collection representation, optionally a layout

tests:
unit
functional
a coverage metric (how hard do you want this covered?)


An app has a collection of such entities, and also 
routes
plugins
gems
configuration


how does this play with javascript?  maybe better than rails.
how does this do continuation-based apps?

I should be able to indicate to the app that it will always have an instance of a given class, accessible by a given method_name

so, eg., when you install restful_auth, it can tell the app that there is a user available under current_user

actually, current_user makes sense in an app-from the point of view of any given controller, there will always be exactly one current user, so that should be visible in the framework and available to anyone.  

also, need to cope with roles, probably.  

I should make a migration_order accessor, so people can define the order in which migrations happen.  This would also, coincidentally, allow me to get rid of the Kernel.sleep(1) hack.

It might be interesting, as a process note, to develop goaloc in two parts:  a front end which is mostly about poking objects and modifying their state (at which ruby excels) and another part that is all about code generation (at which ruby is OK and lisp is unbeatable).  The interface between the two might be reasonably easy to express in thrift.  

Need a name for the thing that you generate when you do 

route :posts

a goal?  an entity?  goal is cuter.


plan for the rewrite:
BDD the goal object
  fields
  associations
  validations
  lifecycle callbacks
  class/instance meths
  requires/acts_as_* calls

BDD the code generator
  migration
  model
  controller
  views
    index
    show
    form
    partials


Questions:  
do I need to define classes?  Might it suffice to define instances, and perhaps bind appropriately-named constants to them?
how do I define a blog such that it only has the create method on comments routed, and not the others?
how hard is it to serve it directly?  (need to add rack handler)
do I need to add the ability to do continuation-based apps?
how soon should I make this able to serve itself?

It'd be nice to rename something and have that rename propagate to all the places it might be needed.