tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Sommerville" <...@bulletproof.com.au>
Subject RE: [VOTE] Release 5.0.12
Date Fri, 06 Jun 2008 03:58:40 GMT
That issue is logged as
https://issues.apache.org/jira/browse/TAPESTRY-2369 along with a patch
(which steps around the problem by removing the requirement for zones to
be registered before links).

The underlying cause is that the all the init properties (linkZone,
zone,etc) are stored in a HashMap (inside JSONObject), so the order that
they are output is entirely unpredictable.

It can either be fixed by imposing an ordering on the init data or by
imposing a restriction on the functions that they be independent (which is
what my patch does for the linkZone case).


> -----Original Message-----
> From: Andreas Andreou [mailto:andreoua@gmail.com] 
> Sent: Friday, 6 June 2008 12:20 PM
> To: Tapestry development
> Subject: Re: [VOTE] Release 5.0.12
> Andreas Andreou: -1
> Just tried the code from tapestry4nonbelievers as well and it 
> seems to me
> that there's a regression with zones... To be more specific, here's
> the old js that got generated:
> Tapestry.initializeZones([{"div":"viewZone"}],
> [["view","viewZone"],["view_0","viewZone"],["view_1","viewZone
> and here's the new one:
> Tapestry.init({"linkZone":[["view","viewZone"],["view_0","view
> In the new one you'll notice that first the links and then the zone is
> registered... this however
> is problematic cause during registration of the links their zone must
> already be registered (so that
> it can be referenced - see the old initialization code)
> I'd be willing to change my vote if:
> - there's something terribly wrong with my findings
> - you guys consider this not to be a blocker

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message