Re: What does Five and Z3 mean for Archetypes?

> Those who've used AT in anger know that AT has some issues that need to
> resolved. Of course, 80% of what most people do with Plone development (made-up
> statistic) 

I think I can count on one hand the number of people I know who use AT 
outside of Plone.

at least is connected to AT, since AT is the only sane(ish) way of
> making content types for Plone, and Plone is so content-centric. That means AT
> needs to live on, but it also needs to evolve.

ben has proposed an at remedial sprint between now and the snow sprint 
for the purpose of getting at off the short bus.

> From the top of my head, there are some quick-win things we can do:
> 
>  - Use events to make the content initition sequence sane. That means avoiding 5
> reindexObject() calls, for example, when only 1 is necessary. It also means a
> lot of hacks for things like "call this code when content is created" or "call
> this code when content is first saved" can be done in a nicer way.

+1

If rob miller had not been so heroic to pick up the mantle of getting 
plone ready for CMF2.0, this might be done already.  He can extroplate 
more on his plan, but the general idea is that CatalogMultiplex should 
go down to CMF and all indexing is triggered by event.


>  - Fix the reference engine. I imagine the component way of writing would make a
> new reference engine easier to write and easier to maintain. The current one is
> very slow, and no-one is able to maintain it.

and, there is use for this all over the rest of the zope/py world. 
Having this play nicely as a source or consumer of rdf would be immensly 
valuable (especially since rdflib is subsuming zemantic).

part of the advantage of CA is that we can rewrite parts of it while 
fixing it, and provide breakpoint for the insertion of other improvements.

>  - Fix the widgets system. Widgets are hard to create, hard to maintain, hard to
> fix for those who know UI (Alex tried once, he got a headache). The whole
> base_view/base_edit chain of templates takes so much complexity, like
> conditionally calling macros discovered at run-time, you really don't want to go
> there. This in turn makes base_view or base_edit very much an all-or-nothing
> approach to usin the schema to create forms/views, which is unfortunate. I'm
> hoping something like zope.formlib (not that I know anything about it) could
> help here.

+1

I'm not sure formlib is going to help limi's head, but again, z3 will 
make what is supposed be pluggable truly extensible.

part of the at problem is that there are at least 10 users who work the 
living crap out of every feature that 90% of us only deal with when it 
breaks.  We have a huge heaping pile of indirection that hardly get used 
and each one of those layers represents either a running project or a 
joint someone smoked.

>  - Simplify the storage mechanism. I wrote an SQL storage once. That was
> incredibly painful. I reckon events would help here, as we would be able to do
> things like "get object only once out of storage and cache" or "only persist
> object when all fields have been written durin save sequence". Using adapters
> for the abstraction between storage and accessor would also help a lot.

+1, though there is alot of argument about where this layer goes. some 
of us sit in the wings and root for the return of zpatterns.

> There are other things as well, of course, but those are the four that I think
> are possible to fix by evolution/mini-revolution (we may have to break some
> hacks people have used to get around current limitations, and we may make
> existing add-on fields/widgets require some patching up, for instance). 

the nice thing about AT is that the api is somewhat contained and 
regular (an advantage of being a code generator).

Hypothetically, Schema can be imported from anywhere, and parse its 
contents in any way that fufills the necessary contracts. similarily, 
metaclasses could turn at class MyAT into an adapter for IMyAT. 
suddenly you have new style code, without changing any of the old except 
the import statements.


> There are other things, too, such as getting rid of ClassGen and moving to
> get(fieldName) and set(fieldName, value) as the standard way of getting/setting
> objects in the schema, and Ben was talking about routing messages around the
> framework to further loosen coupling, but those things will probably take longer
> to decide on and understand the impact of. With proper componentisation of the
> internal architecture, however, it ought to be possible for those pieces to live
> on even if other parts of the framework evolve.
> 
indeed.

-w



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php