cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: svn commit: r178778 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/ forms/datatype/ /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/ forms/formmodel/ /cocoon/branches/BRANCH_2_1_X/status.xml
Date Sat, 28 May 2005 15:51:02 GMT
On 28.05.2005 03:20, Antonio Gallardo wrote:

> Hi Joerg:
> I am glad to see you active on the list again. As I told you in GT2004, I
> like your radar over my work. :-)

Hi Antonio,

yeah, I'm back again at least for a few days (starting last weekend, 
ending tomorrow). I hope to get my internet access in the next days for 
being permantly online again.

> I only got one reply, I didn't knew if the community was in favor of the
> change (I assumed a lazy approval).

I have not been reading your RT, I'm somewhat behind my mails (mid of 
february for dev and beginning of march for users list). I only saw your 
commit mail (there I'm up-to-date ;-) ).

> This code was done mostly as a proof
> of concept. To see if this really will improve the performance.
> After all, I think there is a good news: The proof was successful. While
> Using 3 combos inside a repeater I can see the code runs 2 to 3 times
> faster than before. When the repeater grows, there is almost no
> performance penality now.
> Now, I am also thinking to improve now other pieces, for example, there is
> another big time penality inside selection-lists. Again when we are inside
> a repeaters. When we change the value of a selection-list using something
> like that:
> <fd:on-value-changed>
>   <fd:javascript>
>     myWidget.setSelectionList("cocoon:/" + value);
>   </fd:javascript>
> </fd:on-value-changed>
> Here again, the current behavior is to reread the data. And I noted in
> some cases is posible the same combo will be there over and over so a
> cache improvement will save a lot of time again. But this is another
> story. First, I will try to fix the current one.

I understood your goals. Maybe the selection list can be configured to 
be buffered for the request. The SelectionListHandler is then not 
instantiated for each generateSAXFragment()-call, but only once, stores 
the events in SAXBuffer and replays them for all selection lists of that 
type for one request.

Now I'm going to read your initial RT and Sylvain's answer :-)


View raw message