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:/mySelectionList.data?id=" + 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 :-)
Joerg
