Re: What does Five and Z3 mean for Archetypes?

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

ok...let me try to chart this...

AT paradigm   Z3 equiv
---------     --------
schemata      Interface inheritance / multiple schema

storage       adapters for getting and setting

a widget      3 views / 2 z3 schemas (search, edit, view)

a field       z3 content object or an attr on a z3 content object

a reffield    nothing currently

marshalling   a view? nothing currently

AT schema     nothing in at gives a cohesive representation of
               an entire "type". if if any of you saw ben wisdol talk
               you may remember the importance of this for dealing with
               webservices and other strongly typed systems.



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

just a  zope3 schema with more than one element? as a view for a field 
object.

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

ok...poorly stated.  My point is that what people want is the views and 
behavior, but they don't want to be stuck with those decisions forever.

By make the schema a form of configuration rather than a place of 
programming logic, we let people adapt these decisions.


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

exactly!  storage is a choice that may change at any time and usually 
you will want that to happen across at some point in the hierarchy of 
class / portal_type / object instance, or perhaps depending on an 
objects location or other metadata.

By defining an interface that applies to the desired situation, storage 
can be registered as desired and happily decoupled from the default 
configuration.

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

persistence is always getting to say you are sorry.

most of what we do as zope programmer is configuration.  This involves 
TTW, and scripting interactions with zope so we don't have to do TTW. 
Why? because the zodb is a foul temptress and it was easy and fast.  now 
we pay for it every plone migration.

I can see alot of case where policy and config should be applied or 
edited at levels between global and object.  And TTW tools are good.

It's just a matter of where the configuration is defined and stored.

Configuration is most optimal as flat text on the filesystem (Why? 
because flat text is read by everything and available everywhere).

A well defined domain language is a migrators dream, because you can 
generate the new without having to decompose all the turds of the old.


>>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. ;-)
> 

to quote zoolander, we've been waiting for ben to bust out magnum for a 
long time.

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

well, we all have to stick our head in eventually.  off the top of my 
head, the following CMF Products employ z3 tech (correct me if I'm wrong 
and please add to the list):

SubPlone, Flon, Fate, zmori, FatSyn, Quills, LinguisticReference, 
Archetypes, ATContentype, Plone goldegg-bundle, Plone i18n-bundle, 
plone_schemas and CMF2.0.

-w




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click