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

Alec Mitchell wrote:
> 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).

Hm, interesting, for complicated layouting purposes, or to make wizards?

The use cases of complicated layout could be fulfilled by other means as 
well.

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

Right, though it would be nice to be able to define the storage for a 
type outside the type in Zope 3.

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

Right, something along these lines could work and that's approximately 
the area I'd try to fit this functionality.

[snip]
>>| 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.

Note for the readers: a searchform declaration in ZCML could be created; 
this is the 'traditional Zope 3 way'. The zope.formlib method would 
simply to create a particular form (in Python code) for an interface 
that's specific for search purposes. It would need some facilities to be 
able to pull in an ISearchWidget still though, so that would mean a 
slight extension to zope.formlib.

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

Right. There are of course all kinds of tricky issues with this in 
practice, like interaction with workflow, versioning, whether you want 
to use the marshalled state for other purposes than just export (in the 
case where you want to use it for something else, you may need security 
restrictions on what exactly gets marshalled), and so on. We've done a 
lot of thinking about this kind of issue in the context of Silva. :)

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

Cool!

Hm, making widgets that work for both sounds like a challenge to me. The 
alternative route would be to try to keep AT as it is intact, but allow 
it to search Zope 3-style widgets and work with them too. Not sure 
whether that's any easier a route to follow, but it would keep the new 
widget clean of code necessary to work with Archetypes in particular.

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

Yes, that would be nice. If we could do a combination of:

a) make Archetypes work with Zope 3 widgets

b) port over Archetypes widgets to Zope 3 style

then that would hopefully eventually benefit both Archetypes and Zope 3 
equally. I don't know how hard a) is though, and I don't know whether 
Zope 3 is still missing facilities to accomplish b)... I also imagine 
that right now many widgets in Archetypes rely on various facilities 
that are not there or are called differently in Zope 3.

Regards,

Martijn


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