Re: Re: What does Five and Z3 mean for Archetypes?

Sorry for chiming into this discussion so late in the game.

On Friday 18 November 2005 09:05 am, Sidnei da Silva wrote:
> On Fri, Nov 18, 2005 at 05:53:19PM +0100, Martijn Faassen wrote:
> | >AT paradigm   Z3 equiv
> | >---------     --------
> | >schemata      Interface inheritance / multiple schema
> |
> | So what does schemata do in Archetypes?
>
> It's a stupid name for separating widgets in 'groups' for
> presentation.

It's equivalent to creating multiple edit views for a single schema in zcml, 
assigning different fields to each of them, and chaining them together in a 
specific order (the order in which they are defined, as silly as it may be).

> | >storage       adapters for getting and setting
> |
> | Do annotations fit in somewhere? Zope 3 doesn't have a storage framework
> | yet, so I think Zope 3 has some work to do here. ZPatterns gurus speak
> | up.. :)
>
> One of the available storage components is a annotation storage.

AT's storage abstraction is nice in theory, but deeply flawed.  Because for 
z3 schemas, the schema is the most abstract definition of the type, it makes 
no sense to put storage implementation details at that level as it is in AT.  
Doing storage at the field level has nice benefits for a few usecases 
(storing specfic information about a user or customer object in LDAP for 
instance), but is problematic for doing things like storing objects an 
RDBMS, which is what most people seem to want it for (and they are often 
disappointed as a result).  The storage picture needs to be worked out on a 
level entirely apart from schemas and widgets, a baseclass that provides 
some decorator methods/classes for storing and retrieving field values in 
interesting ways would be essentially equivalent to the current AT storage 
implementation.

> | >a widget      3 views / 2 z3 schemas (search, edit, view)
> |
> | Views for fields (i.e. sub page views) are called "widgets" in Zope 3 as
> | well.
> |
> | An AT widget contains both a search, an edit and a display facility?
>
> Put it this way. A AT widget Page Template has usually 3 macros, view,
> edit and search. It could just as well be 3 different templates, or in
> Zope 3, 3 different interfaces. Say IDisplayWidget, IEditWidget,
> ISearchWidget.
>
> | Zope 3 right now has a pattern of separate edit and display widgets. I
> | don't know what the equivalent of 'search' would be -- what does this do
> | in AT?
>
> Search is underused, but usually it's exact the same as edit. It's for
> building a search form automatically for a given schema.

Yes, the search abstraction as it is implemented in AT though is almost 
entirely useless, because it requires an object of the type you want to 
search for in order to show the interface.  A z3 search form declaration 
could be nearly equivalent to an addform declaration, and the likelihood 
that specialized widgets are needed is probably low.  Though there's no 
reason a search view couldn't pull in an ISearchWidget if defined, in 
preference to IEditWidget.

...

> | >marshalling   a view? nothing currently
> |
> | What's marshalling exactly?
>
> Marshalling provides different 'marshalled' representations for the
> data of a object.
>
> For example, you can get a XMLMarshaller and spit out a xml
> representation for a object's data and a schema. Think of it as an
> adapter between (object, schema). It can also be used for the reverse
> operation, populating a object's fields from a file representation.
>
> So if you have some XML, you run it through a marshaller adapter and
> get your object populated.
>
> This feature is also very underused currently. I'm probably the
> (only?) one that uses it. We hope to change that with the 'Marshall'
> product, which lets you control which marshaller gets used through a
> UI. Sort of a local adapter registry.

Yes, marshalling is one of the great promises of AT, but it remains largely 
unfulfilled in practice.  In z3 it would likely be implemented as an adapter 
that processed some formatted data and applied it to your content object, 
and a view that displayed your content object in the desired format.
====
In another email On Friday 18 November 2005 08:38 am, Martijn Faassen wrote:
...
> Rob Miller wrote:
> > i suspect that the best thing to do here is to take a good look at what
> > we like about both the AT and the Z3 widget systems, merging those
> > together into something that is informed by both.
>
> Right. I would of course prefer if the Z3 widget system were improved as
> a result of that, but that leaves the AT people in the dry. I wonder
> whether it would be possible to allow Z3 widgets and AT widgets to
> coexist for a while to serve evolution...

In both cases there would seem to generally be very little python code in a 
widget, what logic there is can probably be shared between an AT and z3 
widget easily by having them share a common base class.  The html/js/ajax or 
whatever that is the heart of a nice widget whould probably be easily be 
shareable.  To this end, I will attempt to make sure future AT widgets that 
I make will also function as z3 widgets, and to retrofit my existing custom 
widgets to work with z3 schemas as I have the time.  AT widgets primary 
disadvantage is that they rely on AT's byzantine template/macro structure, 
and their primary advantage is that there is a very nice library of them in 
existence.  It would seem there are very few nice z3 widgets in the wild, 
but if we encourage developers to target their widget development to both 
frameworks, and offer some easy tips for doing so, we can probably grow that 
library significantly.

Alec


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