[Zope-CMF] Re: [Plone-developers] Re: Re: The components of Archetypes

[Alec Mitchell]

On 1/13/06, Rocky Burt <rocky at serverzen.com> wrote:
>
> Just going to add my 2 cents regarding non-specific-plone_schemas zope 3
> functionality.
>
> >  - Ability to make custom views easily
>
> Customizing views happens with overrides.zcml today.  No plone_schemas
> required.  This should work for widget customizations as well.
> Obviously as we've all discussed this needs a TTW customization component.

The TTW component shouldn't be hard if all we want is to lookup skin
templates via acquisition in the traditional manner, plone_schemas
could easily be extended with a custom view class/declaration that
handles this.  If we want a more general z3 way of doing TTW template
customization (which we should IMO), then it will take more time.

> >  - DC metadata
>
> I *hope* Five lets us use IAnnotatable today.  As it stands zope3
> provides a very nice DC metadata implementation built on top of
> IAnnotatable adapters/functionality which is quite nice.  Although I
> haven't confirmed if this works using z2+five yet.

We can use IAnnotatable in Five, it is used in a few places in listen.
 I have not tried using the DCMetadata implementation from Five, but I
don't forsee any issues with it.  I'm not sure if it will handle
setting the modified date automatically on emission of IModiified
events, but z3 would do so under normal circumstances IIRC.  It's
simple enough to write a handler which listens for these events on
'content' objects and updates the date.

> >  - Things like Modified date are kept up to date automatically
> Zope 3 events would help out here although I don't know if Five
> supported IModified events yet.  But perhaps alecm has another way of
> handling this with plone_schemas.
>
> >  - Validators on field level and on the whole object level
>
> FieldProperty and related zope3 schema functionality provides terrific
> per-field validation.  Per object validation really only means ensuring
> field level validation occurred, no?

I don't know about 'terrific' but it does do the validation of the
basic constraints set on the field, it may need to be extended to
support explicitly validating 'invariants' (multi-field/whole object
validation), though perhaps this should be done only after edit (with
an event equivalent to validate_integrity).

> >  - Rename-after-creation (title-to-id generation)
>
> The zope3 INameChooser adapter and related functionality should take
> care of this fine.  I don't know if plone_schema's hooks into this to
> use by default.  Although its probably a per-application decision to use
> in any event.

Plone Schemas provides a custom INameChooser that does this.

> >  - A way to create custom fields + widgets
>
> overrides.zcml in the short (and long term) from the filesystem.  But
> again hopefully there will be a TTW ability also in the long term.

You don't need overrides to create custom fields/widgets you just
create them and register them.  To use them in your schema you just
assign the new widget to the field in your configure.zcml content
declaration.  If you want to change a widget on an existing type then
you need overrides.zcml, but this is much nicer than having to change
code or monkey patch as we do with AT.  To change the field type on an
existing class you change the interface/schema.

> > Some of these I think I know the answer to, but I'm just curious how
> > far  along this approach is, and more importantly - where there are
> > gaps, how  you think they may be closed.
>
> Keeping in mind here that the intended actions should result in breaking
> up archetypes into separate products/components.  So a lot of this
> functionality which is considered standard archetypes functionality
> probably *shouldn't* be.  But gaining that functionality from other
> standard products is obviously desirable.  Thankfully zope3 provides a
> lot of the starting functionality (or at least a lot more than zope2 did).
>

The main gap right now is references, if we can make a real
componentized reference engine then this will go away.  The other
issue is storage which is not something we necessarily want to
replicate in the same manner.  Though storage abstraction is
important, this is something that z3 technologies should be capable of
doing much more nicely than z2.

Alec