[Framework-Team] Re: Our attititude to Archetypes
ra at burningman.com
Tue Apr 11 21:20:25 UTC 2006
On Apr 11, 2006, at 12:33 PM, Alec Mitchell wrote:
> On 4/11/06, Martin Aspeli <optilude at gmx.net> wrote:
>> On Tue, 11 Apr 2006 19:07:03 +0100, Rob Miller <ra at burningman.com>
>>> for a while i was keen on the idea of replacing AT,
>>> componentizing it
>>> out until there wasn't any there there, eventually replacing the
>>> components with other pieces.
>>> i'm still not against that idea, but i've recently come back
>>> around to
>>> the possibility that AT might be salvageable. if it gets broken
>>> up into
>>> little bits, and the worst stuff is made better, then we may just
>>> ourselves with something that is not so bad to work with, w/o
>>> feeling so
>>> strong a need to have to make it die completely.
> I think much of the power of AT lies in how intertwined all its parts
> are, and while there's a great deal of value there, I think there's a
> high likelihood that componentizing it will become quite difficult as
> we move deeper into the AT core.
hmm. can you say more about this?
in any event, outside of any difficulties w.r.t. the AT 'core',
there's still a lot to be gained from breaking off pieces. the
reference engine, portal transforms and schema providing are the
three that i think are quite reasonable. once this is done, then the
"core" can be re-evaluated.
>> If you look at the thread I started on at-dev (and please respond
>> to it if
>> you have ideas) for re-using content types and making schemas more
>> flexible, my conclusion is similar.
>> Logic etc. should be made into adapters. View logic should be made
> I think efforts are better focused on making the non-core pieces of AT
> full-fledged reuasble components, than on trying to reimplement the
> core using component-y techniques.
this is in line w/ what i was recommending.
> Once we have these tools
> componentized (references, transforms), I think it's more likely that
> the sensible path will be to try and bring the remaining AT
> functionality over into z3-schema land.
this may be so; i have moments of thinking it will be, and moments of
thinking maybe AT will not look so unmanageable at that point, maybe
we'll refactor what's left instead of switching to straight z3
schemas. but my real point is that there's not much point in going
too deeply into this until we've actually done the first pass of
>> AT also does a lot of other convenience stuff - registering
>> fields, creating new indexes/metadata, that kind of stuff. Again,
>> I don't
>> see any major gains of separating that out until CMF itself relies on
>> adapters for these things.
> Right, none of these thing are terribly difficult problems to solve
> though. The bulk of AT, it seems to me, is schema stuff and
> class/method generation (which includes storage, etc.). Those are
> things that I personally would like to see us move away from.
i'm a strong +1 on moving away from ClassGen. i'm less sure about
the schema stuff. i definitely want the schemas to be moved out of
the type classes themselves, however... i think an AT object should
adapt itself to an ISchemaConsumer interface that receives the schema
from an ISchemaProvider object.
More information about the Framework-Team