[Framework-Team] Re: Our attititude to Archetypes

Rob Miller 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>  
>> wrote:
>>> 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  
>>> find
>>> 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  
>> into
>> views.
>
> 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  
componentizing.

>> AT also does a lot of other convenience stuff - registering  
>> searchable
>> 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.

-r




More information about the Framework-Team mailing list