On 9/12/06, Raphael Ritz <[EMAIL PROTECTED]> wrote:
Hanno Schlichting schrieb: > Hello from the St. Augustin sprint :) > > cheers from Berlin to all of you ;-) (I wish I could be there ...) > [..] >> - Is it really necessary for AT/ATCT to still use the deprecated >> "manage_*" hooks instead of proper event subscribers? >> If the plan really is to also support Zope 2.11 with Plone 3.0 >> this will cause trouble. >> > This is related to the biggest TODO item that I wasn't able to solve. > While I tried to convert at least all cataloging infrastructure in > Archetypes (and ATCT) to use events, I failed miserably on it and didn't > have any time to look into this again. The current state is IMO not > acceptable as it uses an ugly trick to not catalog items multiple times, > which is to check if an object is already cataloged before indexing it > and if it is still in the catalog before unindexing it. You can see > behavior in the reindexing tests in Archetypes, where quite a few new > indexing calls happen. > > so who do we ask to take a look? Ben, Kapil, Sidnei, ...
I think we need to accept that for the time being at least we will need to move back to an implementation that catalogs multiple times per transaction in the wordt case. Hopefully over the course of the release we can do our best to minimize that, and possibly implement a listener that uses end of transaction hooks to help.
[..] >> - /extra2/Zope-2.10.0-b2/lib/python/zope/tal/talinterpreter.py:754: >> DeprecationWarning:*** *** Insertion of non-unicode non-ascii text >> in TAL is deprecated and will be broken in Plone 4.0 !!! >> [..] >> > You might have noticed that I put quite some ugly patches into Plone > trunk to deal with our mixed encoding situation. These patch into the > guts of the Zope3 tal machinery, as it was the only way to get non-ascii > characters working again right now. > > OK, better working with a warning than not working at all
Yeah, this is a very thorny issue, though I'd say the warning message should be a bit more adamant and say that we require uncode everywhere. Otherwise we are inviting a mix of unicode and ascii, which, while guaranteed to work, is far from ideal IMO. It's just a matter of wording though ...
>> What would be really nice to have for our add-on developers: >> >> - a hands-on, fool-proof guide on how to update 3rd-party products >> for Plone 3.0. In particular this should contain (pointers to) >> instructions on supporting and using GenericSetup and the new >> style action handling. I'm sure Hanno has gained much experience >> on this by doing it for Plone/AT/ATCT so he should be in an >> excellent position to sum that up ;-) >> > I'm sure I can write something up here, especially the common pitfalls I > encountered. Luckily it's not too many changes but writing a product > that works with both old-style and new-style actions is probably not an > easy task or not possible at all. > Not sure it makes much sense to require both. Old-style actions have been deprecated since CMF 1.5 I think.
Certainly not, most product developers and integrators should never have to know about or worry about this change. Generally the only time one deals with the action API is when installing a product. GS fortunately makes knowledge of the underlying APIs unnecessary, so generally only the framework bits should have to worry about this. For people customizing bts of the framework that deal with actions, the changes needed should be pretty self-evident IMO.
>> - An just in passing: is there really no sane way to fix >> 'installTypes' from Archetypes.Extensions.utils? >> This will break **a lot** of 3rd-party products! >> > I'm sure there is a way, I just didn't have time to fix it. Help is > welcome as always ;) > OK, I might take a look at this one myself. I just find it somewhat funny that Plone 2.5 - which was advertized as a "framework release" - didn't require much from add-on authors to deal with while 3.0 - advertized as a "UI release" - looks like it it's causing quite a change ...
Indeed, this will be a huge step for both Framework and UI, which is why it's 3.0(!) after all. It's important that we not get ambitious beyond the manpower we have. Nonetheless this CMF 2.x change is very critical as far as I'm concerned, though so far only Hanno has had the inclination to work on it ....
> >> Summary for now: I think it is no question that this PLIP has to be >> accepted as otherwise we would not catch up with our underlying >> framework (the CMF). I consider it ready for merge as soon as there >> is enough confidence in a 2.1 release of the CMF itself (at least an >> alpha out). The only open question I see is whether we really want to >> make PIL a hard dependency. >> > Actually I think unless we have fixed the Archetypes event story at > least to an somewhat acceptable state, this PLIP should not be merged. > We need to begin to switch to an event infrastructure now but that's the whole point: we need at least to begin with this switch *now*. Meaning the longer we wait, then harder it will become.
I think you are both right. :-) We need this PLIP, which means we need to fix the event stuff in AT ASAP. Alec _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
