cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [RT] Cforms selection-lists
Date Sun, 29 May 2005 08:21:48 GMT
Antonio Gallardo wrote:

>On Sab, 28 de Mayo de 2005, 7:45, Sylvain Wallez dijo:
>  
>
>>Antonio Gallardo wrote:
>>
>>    
>>
>>>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. :-)
>>>      
>>>
>>Sorry for the late answer.
>>
>>Your use case is perfectly valid and must be taken into consideration.
>>However, just as Joerg I have some reservations on the implementation ;-)
>>
>>Caching the of the list data must not be triggered by the Field object,
>>for several reasons:
>>- the repeater containing the field may not be its direct parent, but
>>one of its ancestors if you have some enclosing group or union.
>>    
>>
>
>Opss. I forgot this! Hence, the current implementation is buggy and needs
>to be changed. I will revert the changes now. Sorry for the disturb.
>  
>

No problem. You have a need, you explain it and start implementing, and 
we discuss :-)

>>- each field in a repeater can programmatically be given a distinct
>>selection-list (e.g. with event handlers), in which case triggering the
>>test on the first repeater row will fail.
>>    
>>
>
>Yes. This is what I already saw. This address my second concern related to
>setting programatically a new SelectionList inside an event. Somehow, we
>need to cache this too, because inside a repeater there is a big chance we
>are using the same SelectionList over and over. Again, this is place for a
>performance improvement.
>  
>

My proposal also handles this case. If the DSL object manages the 
caching by itself, caching also happens if the same DSL object is set 
programmatically on various objects.

And this applies to more uses case than a repeater, but also to more 
complicated use cases such as recursive forms, e.g. a sitemap editor 
where the list of generators will be attached to all widgets 
representing a <map:generate>

>Given this new facts, I started to think if is posible to have a cache
>Collection of all involved DSL list (perhaps implemented as a handler, as
>suggested by Joerg). The handler will check first inside the cache
>Collection is the SelectionList was already generated.... Bah! Your
>solution suggested below is far better than this one. Dropping this
>idea...
>  
>

:-)

>>So this must be handled entirely either in the pipeline or in the
>>selection-list.
>>    
>>
>
>I don't like the pipeline idea. Better at the selection-list.
>
>But I see again teh selection-list needs to know more info, to create a
>smarter cache. We need to cache only if needed. If not, then we will
>slowdown the other selection-list that don't need an attribute after all.
>  
>

So let's add a "cache" attribute on <fd:selection-list> that, if true, 
will enable the caching.

>For example, If we have only a SelectionList in a form without a repeater
>or in a form with repeater but the SelectionList is placed outside the
>repeater, then there is totally not sense to cache the info. It is only a
>waste of time and memory.
>  
>

Yep.

>>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.
>>    
>>
>
>I think this is the best. And this is what I will be glad to see this
>working! :-)
>
>  
>
>>How does that sound?
>>    
>>
>
>This last suggestion, is really great! As you told, we need to find a way
>to generate a real unique attribute name to avoid conflict with whatever
>other attributes inside the request.
>  
>

What about "new java.rmi.server.UID().toString()"?

>How we are going to implement this? Can you do this?
>  
>

Better do it yourself if you need it quicly :-)

Don't hesitate to ask if you need advices however!

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message