Hi: 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 comment. Also, in the previous mail, I tried to explain the current situation of DSL inside a repeater: http://marc.theaimsgroup.com/?t=111706780900003&r=1&w=2 IMHO, it should improved too. The question is: Need it to be a user defined optional feature? Architecture ============ 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 know: 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? WDYT? Best Regards, Antonio Gallardo.
