Item9772 < Tasks

NOTE: If you are a developer, please use a private wiki based on foswiki/trunk on a daily base ...or use trunk.foswiki.org to view this page for some minimal testing.
Use Item9693 for docu changes for 1.2 and 2.0.

You are here: Foswiki>Tasks Web>Item9772 (revision 3) (raw view)

As a consequence JQREQUIRE doesn't work either, as well as any %MACRO whose implementation creates the jquery module on perl level.

*Example*: %JQREQUIRE{"chili"}%
<verbatim class="tml">
<dirtyarea>
%JQREQUIRE{"shake"}%
%BUTTON{"Shake it, baby" icon="bomb" onclick="jQuery('#shakeit').shake(3, 10, 180)" id="shakeit"}%
%CLEAR%
</dirtyarea>
</verbatim>

This won't shake the button.

*Work around* this by moving all ADDTOZONE, or JQREQUIRE out of the dirty area:
<verbatim class="tml">
%JQREQUIRE{"shake"}%
<dirtyarea>
%BUTTON{"Shake it, baby" icon="bomb" onclick="jQuery('#shakeit').shake(3, 10, 180)" id="shakeit"}%
%CLEAR%
</dirtyarea>
</verbatim>

*Explanation*:

All of the page except the dirty area has already been rendered. This includes the =&lt;head>...&lt;/head>=
zone of the page. At the time the dirty area is computed again, this distant part of the page is already
static HTML. So a call to ADDTOZONE won't be able to alter this area anymore.

*Idea how to fix*:

Whenever there is a call to ADDTOZONE from inside a dirty area rendering the zones must be delayed til the 
request time as well. It can't be cached anymore as material added to the zone might change the ordering
of the content inside the zone significantly.

-- Main.MichaelDaum - 30 Sep 2010



Would it help if we eliminated the automatic =s/<\/head>//= regex, and force skin authors to have explicit RENDERZONEs wrapped in dirty areas?

%JQREQUIRE{"chili"}%<verbatim class="tml"><dirtyarea>%RENDERZONE{"head"}%%RENDERZONE{"script"}%</dirtyarea></verbatim</verbatim>

-- %USERSWEB%.PaulHarvey - 01 Oct 2010


I actually think forcing explicit =%RENDERZONE= is a good idea for other reasons. This solution removes magic, and avoids new magic to resolve the cache issue.

-- %USERSWEB%.PaulHarvey - 01 Oct 2010


This is not that simple. There are two sets of calls to ADDTOZONE: one at first hit, the other for all dirty areas. Both have to be combined into the zone rendered at request time.

Whatever we find to solve this, it should not add a default dirty area as this will degrade performance even in those cases where zones could be perfectly finished and cached.
We only need a solution if a page is flagged dirty in cache.

-- %USERSWEB%.MichaelDaum - 01 Oct 2010
%COMMENT%

ItemTemplate edit

Summary	adding to a zone from inside a dirtyarea doesn't work
ReportedBy	MichaelDaum
Codebase	trunk
SVN Range
AppliesTo	Engine
Component
Priority	Normal
CurrentState	New
WaitingFor
Checkins
TargetRelease	n/a
ReleasedIn	n/a

Topic revision: r3 - 01 Oct 2010, MichaelDaum

Tasks

Submit and Query

Create Task

Developer Tasks

Non Developer Tasks

Developer Tools

Tools

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement.