Re: looking at AT schema: (was) zope 3 schema's and the rest of us

On Fri, 2006-07-14 at 02:05 -0400, whit wrote:
> Roché Compaan wrote:
> > On Thu, 2006-07-13 at 14:30 -0400, whit wrote:
> >>> In essence what I am saying is, rather than trying to "adapt" AT to z3 I
> >>> would rather port what works well in AT to z3 and then drop AT. I would,
> >>> very simply:
> >>>
> >>> 1. Port missing fields
> >>> 2. Port missing widgets
> >>> 3. Rewrite content types 
> >>>
> >>> It's only 3 steps, it should work ;-)
> >>>
> >> add a fourth, and you don't even have to rewrite old AT code. not to 
> >> beat this drum again, but there is *no* reason that current Field and 
> >> Widget class constructor couldn't be simply mapped to registration 
> >> statements, and registerType couldn't just act a consumer of 
> >> registration info, much like browser views.
> > 
> > Rampa papam pam. Well if that's possible then I'll gladly shut up
> > now :-)
> > 
> 
> well, it is AT...so it probably won't be as easy as it could be, but 
> this may be one approach to piecemeal decomposition of the problem.
> 
> #class WikiField(ObjectField):
> #    """  my old field """
> 
> def WikiField(name, **kw):
>      """ my new field factory/registration function """
> 
> 
> consider what would be required to achieve parity in zcml (first, some at):
> 
> WikiField('text',
>             required=True,
>             searchable=True,
>             primary=True,
>             filters=('Wicked Filter',),
>             validators = ('isTidyHtmlWithCleanup',),
>             default_content_type = ATDOCUMENT_CONTENT_TYPE,
>             default_output_type = 'text/html',
>             allowable_content_types = ('text/structured',
>                                         'text/x-rst',
>                                         'text/html',
>                                         'text/plain',
>                                         'text/plain-pre',
>                                         'text/python-source',),
>             widget = atapi.RichWidget(
>                          description = "The body text of the document.",
>                          description_msgid = "help_body_text",
>                          label = "Body text",
>                          label_msgid = "label_body_text",
>                          rows = 25,
>                          i18n_domain = "plone"))
> 
> which does the same as:
> 
> <at:field
>     name='text'
>     provides='archetypes.field.IWickedfield'
>     required=True
>     searchable=True
>     primary=True
>     filters='archetypes.txtfilter.IWickedFilter'
>     validators ='archetypes.validators.IisTidyHtmlWithCleanup'
>     default_content_type = 'archetypes.content.interfaces.IDocument'
>     default_output_type = 'text/html'
>     allowable_content_types = 'text/structured,
>                                text/x-rst,
>                                text/html,
>                                text/plain,
>                                text/plain-pre,
>                                text/python-source'>
>    <at:widget
>       name='default'
>       provides='archetypes.widget.IRichWidget'
>       description = "The body text of the document.",
>       description_msgid = "help_body_text",
>       label = "Body text",
>       label_msgid = "label_body_text",
>       rows = 25,
>       i18n_domain = "plone" />
> 
> </at:field>
> 
> I'm modeling field as an extension of the adapter registration 
> directive(with the casual assumption we would register defaults for 
> interfaces). just the same, we could use the factory only syntax, but 
> obviously framework consumers shouldn't have to write an adapter every 
> time they want a field.
> 
> Then again, this is something a python function does better than zcml ;)
> 
> notice I've tried to logical map interfaces in places it made sense, and 
> that the widget is named.
> 
> Rather than have to rewrite wholesale every widget, simply cleaning up 
> the frontend mess so it could handle slightly different widget 
> implementations intelligently might allow us to evolve without much pain.
> 
> from Products.Archetypes.public import *
> from archetypes.fields.factories import StringField, TextField
> from archetypes.widgets.factories import RichWidget, StringWidget
> 
> obviously, there is a vector to avoid snafus.

Thanks for the above, it is very understandable (and clever) and does
make a lot of sense.


-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642