On Sab, 28 de Mayo de 2005, 11:44, Joerg Heinicke dijo: >> Caching in the selection-list itself can be done on a per-request basis >> (thus ensuring the pipeline will be called only once per request), by >> storing the selection list in a request attribute. The DSL has to >> generate a unique attribute name (to avoid conflicts). When generating >> the SAX fragment, either the attribute is empty and the pipeline is >> called, caching on the fly, or the attribute exists and can be used >> immediately. The cached value is then automatically trashed at the end >> of the request processing. > > "Polluting" the request is always something to be avoided as far as > possible IMO. Would it not be possible to have just one buffering > SelectionListHandler per source and request (or form) with an internal > SAXBuffer?
A SelectionListsHandler per request is OK. We can store the cache elsewhere. That is OK to me. The handler must contains all the selection lists that needs to be cached. And I said "needs", because we don't want to cache all of them. We can detect wich of thems are good candidates to cached. Per form is not a good option, IMHO because I suppose the life of the form can have more than one request. Please correct me if I am wrong here. Here is some tipical sample where we need to cache a programatically changed selection list: We have an invoice form. In the detail repeater there can be 2 selection-lists: family of products and product. Said, the identity is conformed by both: the family and the product. Given this products: family product ====== ======= Food Rice Food Beans Food Bread Food ... Drink Water Drink Juice Drink ... ... ... The interface will set the product selection list once the user select a family. So we will use here a programatically selection-list. Perhaps we use for that: cocoon:/products.data?family=Food If the user choose to buy said: Rice, Beans, Bread Water and Juice then while we select the "Food" family we are triggering the pipeline for products of Food. We can see easily this pipeline must be cached since we will need it when the user select again the same family for Beans and Bread. (I hope this clearly explains the need of caching programatically changed selection-list). I know the sample is very easy and we can use Ids, etc. But this is not the point. Best Regards, Antonio Gallardo.
