Re: What does Five and Z3 mean for Archetypes?

> > ... that looks like an AT schema to me. What's the difference?
> > 
> 
> at the level of fact orientation ie "I want to make a form", not much.
> 
> But the devil is in the details.  As a pattern, z3 schemas are an 
> interface that an object can be adapted to (resulting in a form). 
> Archetypes schema are a data structure composes of multiple different 
> object types that define all the getters and setters for data, configure 
> it's display, and even determine such things as metadata and relations.
> 
> Purist will point at at and say "impure MCV".  this is true, but the 
> convenience and power of resulting from an AT schema is a primary reason 
> for it's popularity.  A z3 schema just gives you a form, but have to go 
> flesh out much of the behavior elsewhere.

I see the argument, but can you be a bit more specific? What, practically, can a
simple Z3 schema not do (validation? default values?), and how would you get
that same functionality in a pure Z3 world?
 
> >>Looking at this from a z3 standpoint, widgets are views on field 
> >>objects.  It would be trivial and cool to write a widget that actually 
> >>rendered a multi input zope3 schema for a single field.  you get the idea.
> > 
> > 
> > What do you mean by multi-input zope3 schema?

Still wondering about this one...

> > Could we fix the incredible broken-ness of Fields/Widgets with Five views? 
>
> I think we could.  Part of the issue here is somewhat below the issue of 
> mixing model and view. I think it may be more of an issue of mixing 
> configuration and behavior. If we view the AT schema as a way to 
> configure the behavior on an otherwhise generic CMF type (ie folder or 
> content, nothing else), then we are no longer so married to the 
> decisions made there.

What do you mean? What decisions, made where? (obviously, we need to still
respect people's schemata)

> much of the pain is from the persistent duplication of site wide 
> configuration (ie the widget, storage, marshall and every property set 
> in a field or widget) on an object by object basis. 

Specifically, what type of configuration? Do you mean you want the ability to
say, all RichDocuments' bodyText fields should use AnnotationStorage, and if I
switch it in one place, it switches all new and current objects? (currently,
some of this stuff is stored on a per-instance basis, even though it's rarely
varied between instances).

> Using adapters and 
> views, we can abstract this configuration out of the object, leaving the 
> schema to be a generic bag of objects, devoid of any restricting logic 
> of how they should act.

Again, an example would be great. Why do you want this logic out (is it just to
avoid per-object settings?), and where would it be?

> I think the nicest part about component architecture is that this can 
> happen in stages.  One place to look is at how Five has gone about 
> changing Zope 2.

I call this "salvation" :)

> Following this model, we can do some structured monkeypatching of AT to 
> prototype where and how we want to decompose the structure, and as we 
> find things that work and are tried and true, move them into ATs core.
> 
> also, similar to Five and Z3, is that ben has done a bunch of 
> prototyping for AT2 with an events based core. and according to the 
> outcome of conversations between jim and ben, the events core will work 
> with z3 and five.

Meh? What state is this on? 

> Having clean developed code to integrate back into the thorny messy of 
> legacy often is easier than keeping clean in the briar patch.  this is 
> about the only good justification I can think of for rewriting from scratch.
> 
> the key is creating the right indirections to make backward 
> compatibility easy and optional, rather than an albatross that drives 
> ben away to write AT3.

Heh. Last I heard, he was writing filesystem drivers, as I said. ;-)

> z3 can be really quite alien to the zope/plone hacker at first (less so 
> if you have worked with other python frameworks).  Aside from annoying 
> failures with asymtomatic errors (ie why is the entire component 
> architecture not loading or why does my view not show up and not give 
> any error), it is deceptively easier.

Yes... I'm a little concerned here how much (if at all) we are raising the bar
for new developers to come in and contribute. Some of these concepts (includin
your examples, I'm afraid) are a bit hard to swallow without some real
tutorial-style documentation and a bit more experience.

> there are a few things missing that you might expect(transitive 
> adaptation ie PyProtocols, a simple way to return data without getting 
> an adapter), but all in all it's a breath of fresh air.

Mmmm... Yes :)

Martin



-------------------------------------------------------
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