Hello from the St. Augustin sprint :)
Raphael Ritz wrote:
> > Hello again,
> >
> > this is just a service to those of you who do not follow the svn/plone
> > commits ;-)
> >
> > 2006-09-12 Raphael Ritz ([EMAIL PROTECTED])
> >
> > My test set-up: Python 2.4.3, Zope 2.10.0b2 release on Linux (FC5)
> >
> > First impression: excellent work Hanno
> >
> > Issues noticed so far:
> >
> > - there is a hard dependency on PIL in CMFPlone/utils.py
> > Do we really want that?
Making it a hard dependency wasn't intentional, but I would argue that
especially with the latest changes to use PIL to check uploaded member
portraits there is a good reason to make it a hard dependency now.
> > Furthermore, there are some deprecation warnings where I'm not sure
> > whether they could be avoided. For testing, what I did was to join
> > as a new user, log in, create a news item including an image,
> > submitting it for review and publishing it as site manager then.
> > This is what I noticed from watching the log:
> >
> > - 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.
To summarize: I just did not have the time to do it anf got Archetypes I
also lacked some knowledge ;)
> > - /extra2/sites/plip-reviews/148/Products/CMFCore/TypesTool.py:680:
> > DeprecationWarning: TypeInformation.listContentTypes(by_metatype=1)
> > is deprecated.
> >
> > Where does that come from? Should be easy to fix though as an
> > explicit specification of a content filter in a call to
> > content{Ids|Values|Items} or whatever might have caused that
> > should get rid of it.
This is an old deprecation warning that is at least present in Plone 2.5
as well if not in Plone 2.1. Somebody might just look into it and change
it, any volunteer?
> > - /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 !!!
> >
> > '<h2>Hier was \xc3\xbcber mich:</h2>\n ...
> >
> > text = unicode(structure)
> >
> > This was caused by entering a German text containing an Umlaut
> > into the body of a news item. Couldn't that be done just right?
> > (I know that that's potentially asking for much, i.e., to change
> > Plone/AT's policy with respect to encoding/unicode handling but
> > sooner or later we have to face it anyways.)
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.
The ideal solution is of course to change our complete software stack to
use Unicode internally, but the problems here are quite enourmnous.
After talking to Martijn Faassen who was responsible for the move of
Silva to use Unicode and has therefor quite some hands-on experience I
did agree with him that this move probably will take at least two to
three releases before we have changed all code to work in a pure Unicode
environment only. I think our strategy to the Unicode battle deserves
some extra thread and I'll post my current plan later today.
> > 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.
> > - 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 ;)
> > Somewhat off topic here:
> >
> > - there is actually one issue that worries me quite a bit at the
> > moment but I don't think it has anything particular to do with this
> > Plip. To see what I mean, install the plip bundle (or the current
> > Plone dev bundle), make a plone site, visit it in ZMI, go to
> > portal_skins, select a template like 'main_template',
> > 'prefs_install_products_form', 'table_view', or 'atct_topic_view'.
> > Note the error when trying to 'customize' one of these::
> >
> > Macro expansion failed
> > exceptions.KeyError: 'scripts'
> >
> > It does not happen for all templates but I'm sure more are
> > affected by this. I have not been able to debug this yet but
> > I assume at the moment that this is due to Zope 2 switching to
> > the Zope 3 TAL engine. Others please correct me if I'm wrong.
This sounds like a bad interaction of the CMF Page Templates with the
new Zope3 machinery. As there where already quite a few of these things
where Zope2 had some different semantics as Zope3 there are potentially
more issues. Another possibility is that CMFFormController has a problem
here as it subclasses from the CMF classes again. Could you verify if
this might be related to cpt vs. pt files?
> > 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 and issue
meaningful deprecation warnings to add-on product developers about the
removal of the manage* methods. The general deprecation warnings that
manage* methods in general are deprecated aren't helpful IMO.
Additionally we might begin to lobby for an extended deprecation period
for the manage* methods as we won't be able to migrate all our stack to
use events instead in time, especially if we want to have the option of
supporting Zope 2.11 (which hopefully support ZODB blobs) for Plone 3.0.
Hanno
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
