Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <33050.10.0.0.1.1117325642.squirrel@ags01.agsoftware.dnsalias.com>
In-Reply-To: <429867D8.7030406@apache.org>
References: 
    <57917.10.0.0.1.1117159841.squirrel@ags01.agsoftware.dnsalias.com>
    <429867D8.7030406@apache.org>
Date: Sat, 28 May 2005 19:14:02 -0500 (CDT)
Subject: Re: [RT] Cforms selection-lists
From: "Antonio Gallardo" <agallardo@agssa.net>
To: dev@cocoon.apache.org
User-Agent: SquirrelMail/1.4.4-1.FC3
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

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.

> - 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.

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.

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.

> You're right in saying that a pipeline querying a database cannot easily
> be cached. Now we have in the scratchpad (and this should IMO be
> promoted to core) a nice "cached:" protocol, which allows to cache any
> URI for a given period of time. So your DSL can use the
> "cached:cocoon://database-query?cocoon:cache-expires=1" to have your
> expensive pipeline called only once in a single second.

Hmm. I think is this not a good solution. There are some forms that can
take more than 1 second. And we see this often, there are not too much
special cases. IMHO, this is not also a solution to suggest 2 or X
seconds. Since we never will know how much time in fact we will need.
Customizing the time for every forms sounds like a not good idea.

> 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.

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

Best Regards,

Antonio Gallardo.