On 1/13/06, Rocky Burt <[EMAIL PROTECTED]> 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 _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests