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

Hey,

Sidnei da Silva wrote:
[snip]
> | >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. :)
> 
> Thats great. I'm very interested in hearing what you have to say about
> it.

Well, I gave a summary just now. :) Are your usecases for marshalling 
broader than just export/import? Basically as soon as an 'export' to a 
potentially untrusted system happens, that should not have all the 
information in the system, you need to start worrying about which 
version of which objects you export.

[making widgets that work both in AT as well as in Z3]
> | 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.
> 
> It's actually not that hard, but the z3 widgets would have to 'adapt'
> the AT fields to the the interface for a z3 field.

If I understand you correctly, that would be the other way around; using 
AT widgets within Zope 3. That's not my preferred path -- it'd prefer 
extending the library of Zope 3 widgets directly, and allowing AT to use 
those. I understand that one of the problems with AT widgets is that 
they're rather complicated, and hopefully by this process we can 
"refine" them.

> | >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
> 
> Should be trivial. Archetypes doesn't expect much from a widget other
> than providing a macro and a method to extract it's own value from the
> request.

This is good. Of course Zope 3 doesn't have a macro per widget. :)

> | 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.
> 
> I'm +10 on this.

Good! I think the next step here would be for someone to try porting an 
interesting AT widget to Zope 3. From the problems this person will have 
we will learn what changes, if any, Zope 3 needs, and we can recommend a 
path to take for the next widget. I think I can contribute to this 
process, even though the AT side of things will have to come from 
someone else, so I cannot do it alone.

On another track we could try adjusting Archetypes so it can work with 
Zope 3 widgets. This needs an AT expert, and that isn't me.

Once we got the basics of both sides working, we can hopefully get 
otehrs on board by showing people the example code, spelling it all out, 
say this is the Future, and hopefully a bunch of widget rock stars will 
stand up and do all the actual porting..  Um, I invoke the power of the 
Plone Community! :)

The result should be that:

Zope 3 wins by getting new cool widgets and lots of AT knowledge.

AT wins by having a cleaned up widget story, being 1 step closer to Zope 
3 and thus more feature proof, and getting a wider audience developing 
widgets for it, including the Zope 3 developers.

I win as I can start using those widgets, through Five, in Silva. :)

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