3D: Documentation Driven Development

I've been looking at how the 'py' project organizes themselve using 
documentation driven development.  Sort of goes like this:

1. write documentation for a feature
2. write tests for the documentation
3. write code to make the tests pass
4. refactor 1, 2, and 3 as need
5. rinse and repeat

how would people feel about creating a proprosals directory in the AT 
repository to start doing something like this.  I'll create it and stick 
this proposal in. we can edit it as we see fit, finished product being 
something we can literally write the implementation against?

-w


whit wrote:
> =================================
>   Proposal for Schema Refactoring
> =================================
> 
> step one: implement alternate schema retrieval adapters
> =======================================================
> 
> 0. attribute(done, needs refactoring)
> 0. module
> 0. annotation
> 0. utility
>     - global (similar to #2)
>     - local (similar to #3)
> 
> Once we have this we can start considering the problem of step 2
> 
> step two: determine effecient practices for schema usage
> ========================================================
> 
> Currently, the schema is store on every single object. Really,
> persistence should only be used when needed: ie, schema should only
> persist where people will configure them.
> 
> level	      	configured by
> ---------------------------
> module		developer
> utility(global)	developer/integrator
> utility(local)	integrator/manager
> annotation	user(owner)
> attribute 	user(owner)
> 
> I predict except for the hairy implementation stretches represented by
> VariableSchemaSupport and ATSENG, 99% of existing code will use the
> module level schema. This should mean faster access, make schema 
> migrations easy, and
> mitigate a bit of ZODB bloat.
> 
> step three: codify best practice for schema registration in zcml
> ================================================================
> 
> I would like to see a zcml directive that allows you to hook
> up a schema to an interface.  The python equivalent would use
> registerType to parse the class and read a class attribute that
> determines how the schema should be registered.
> 
> Special executable configuration(read modifying the ZODB) will be
> require for the local utility case.
> 
> Note: this is the first step in making the AT Content class just a
> configuration block.  I would eventually like to see AT content just
> be z3 content + a python option for declarative config.
> 
> Slowly, all behavior current on an AT object would move to adapters.
> This is another proposal ;)
> 
> 
> 
> 
> 


-- 

  | david "whit" morriss
  |
  | contact :: http://public.xdi.org/=whit

  "If you don't know where you are,
   you don't know anything at all"

   Dr. Edgar Spencer, Ph.D., 1995


  "I like to write code like
  other ppl like to tune their
  cars or 10kW hifi equipment..."

  Christian Heimes, 2004



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642