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/=wh
it
"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
_______________________________________________
Archetypes-devel mailing list
Archetypes-devel lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/archet
ypes-devel
|