cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject [RT] Cforms selection-lists
Date Fri, 27 May 2005 02:10:41 GMT

Yesterday, I posted a simple RT on how to improve cforms dynamic selection
list performance. After getting a huge responses and a lot interest from
the cocoon dev list. :-)

I am not sure if this was approved by a lazy consensus or simply people is
happy with the current performance. I prefer to interpret that as it was
approved by a lazy consensus. ;-)

Seriously, before continuing I must admit I feel like a newbie inside this
code. Yesterday, I was reviewing the current implementation of selections
lists. And I will try to describe what I saw there:

Current situation

In short, The world is black and white, there are no greys between.

Why? Because, we have only 2 choices:

1- Static selection list (SSL): generated only once over the all life
cycle of the servlet. Once it is generated it is served from the cache
forever. There is no chance to change it.

2- Dynamic selection list (DSL), this is generated every time we need it.
Over and over.

This polarized selections list are missing the real nature of forms. Or
perhaps we need only to improve the current implementation of them. I see
the need of 1 additional selections lists:

3-Semi-static selection list (SSSL): generated every time the user request
the form. Then it is served from the cache. This will allow us to change
on-line a static selection list without the need to restart the servlet. I
don't know if this should be called better semi-dynamic SL. Please

Also, in the previous mail, I tried to explain the current situation of
DSL inside a repeater:

IMHO, it should improved too. The question is:

Need it to be a user defined optional feature?


If the above is approved -> this mostly, why I am writing this mail. ;-)

In order to improve that I see 2 posibilities:

1. The selection list widget (SLW) should know more about the status of
his parent to know how to manage the current generation.  SLW need to

A. If his parent is a repeater or not. If yes, then need to know the
repeater-row index to. Useful for DSL.
B. Need to know if his parent is just initializating. Useful for SSSL. I
know, this is posible by the initialization of the form.

2. The repeater-row widget, the repeater widget know what to do and call
corresponding SLW methods to do the job. In this case the job is managed
from the parent and the parent call the required methods. I see in this
implementation an overhead, since the parent will need to know wich kind
of widget it needs to generate.

I am willing to implement this and I will be glad to hear opinions before
starting to implement this.

Also, need we a vote to do this?


Best Regards,

Antonio Gallardo.

View raw message