[Framework-Team] Minutes: 8 August 2009

Alec Mitchell apm13 at columbia.edu
Wed Aug 5 21:27:27 UTC 2009


I concur that the globalize stuff is a serious hack and should be
removed at some point.  However, I don't think 4.0 is the right time
to remove it considering the huge impact it will have on 3rd-party
products.  If removing it doesn't result in a significant performance
improvement (and apparently it does not), then I'd suggest we continue
to live with it until the "break-everything" 5.0 release.  We didn't
have a PLIP for this and it would be a major disruption for 3rd party
developers and integrators.

Perhaps we could find some clever way to deprecate access to the
globalized attributes (e.g. make them all lazy lookups and issue a
warning on first access)?

Alec

On Wed, Aug 5, 2009 at 2:15 PM, Hanno Schlichting<hanno at hannosch.eu> wrote:
> On Wed, Aug 5, 2009 at 10:00 PM, Erik Rose<psucorp at grinchcentral.com> wrote:
>>  * All the globalization in templates is gone now, and Plone's
>>   templates have been updated to not use it. This originated in the
>>   5.x branch as a speed optimization, but does it deliver? It's
>>   going to break a lot of products. MatthewWilkes will talk to
>>   Hanno about this and see if it really did help performance. The
>>   FWT is concerned about breaking every product if it turns our
>>   we're just replacing one very slow thing with many less-slow
>>   things.
>
> This change is not only and maybe not even primarily a speed optimization.
>
> When running performance tests against current Plone 4 for typical
> full-fledged pages like a document view, edit screens or folder
> contents views, there is hardly any performance difference between
> Plone 4.0 and 3.3. Thus there doesn't seem to be an immediate
> performance gain for those kind of pages, but neither is there any
> increased cost.
>
> One thing where you should be able to measure a significant difference
> is on classic portlets. These used to set up all the globalize stuff
> again for the separate expression context of the classic template,
> making them quite a bit slower. Executing the globalize hack twice or
> even many times was certainly quite a bit of a difference.
>
> The reasons why I'm very much in favor of removing the globalize hack
> are different ones:
>
> Obviously the way it is done is an utter hack. Walking up stack frames
> to inject things into a higher global scope is very evil.
>
> Second the "globalized" names are today a random set of shortcuts,
> which have little to do with the typical need inside templates. They
> started out a point where access to a set of tools was essentially the
> whole Plone API, but this isn't the case anymore.
>
> Now they just make it harder to understand template code as there is
> no way to find the actual code path from for example the "syntool"
> name inside a template to the actual implementation. They obscure
> templates for little to no benefit, as most often the real call is a
> one-liner itself and context/portal_syndication gives a much better
> searchable term.
>
> Another point is that they make templates rely on execution order of
> the whole macros system. They only work when called after the
> globalize hack has been executed but not in isolation. This also leads
> to problems when trying to move templates into more reusable packages
> as it becomes very hard to see the actual dependencies of the
> template. What looks like locally defined shortcuts turn out to be "oh
> and btw. I need those other ten packages"-type dependencies. It would
> have been much harder to understand and disentangle dependencies
> between packages on trunk, if those hacked in names still would have
> been in place. If we want to make things optional to get people a more
> speedy and less memory hungry Plone, having a central place that binds
> them all doesn't work.
>
> And last removing these calls from a centralized place makes both
> profiling of what actually contributes to the slowness of Plone much
> easier and allows for easier deprecation of some of the so far
> globalized names. For example many of the actual performance
> improvements on trunk result from changes to the way actions are
> looked up. To make these work, all of the "actions, keyed_actions,
> user_actions, workflow_actions, folder_actions, global_actions" names
> of todays globalize thing need to be deprecated and replaced. Instead
> of always having these defined everywhere, they need to be turned into
> a pattern where only the viewlet / macro that actually shows the
> particular action category also calls and evaluates those actions. For
> example hiding the personal bar in the UI today doesn't make a
> difference since all the actions in that category are still evaluated
> and their conditions checked. Even though nobody will ever show any of
> them.
>
> Maybe I forgot other reasons why this particular hack is considered one ;-)
>
> Hanno
>
> _______________________________________________
> Framework-Team mailing list
> Framework-Team at lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>




More information about the Framework-Team mailing list