cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: svn commit: r178778 - /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/ forms/datatype/DynamicSelectionList.java /cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/ forms/formmodel/Field.java /cocoon/branches/BRANCH_2_1_X/status.xml
Date Sat, 28 May 2005 06:31:11 GMT
On Vie, 27 de Mayo de 2005, 19:02, Joerg Heinicke dijo:
> Solution/suggestion:
>
> What for do we have source validities? Wouldn't help a
> SelecionListHandler storing the SAX events in a SAX buffer and
> resaxifying the events if source validity is still valid and wouldn't it
> fulfill all requirements?

I was trying to find a better solution. I can create a selection list
handler, but...

Here, I will try to explain why this is not so simple as you tried to
present above:

1. Given the nature of a Dynamic Selection List (DSL), we cannot blindly
store the SAX events and then only check if the source is valid. Because
even if we do that we will end up with a StaticSelectionList and this is
not what we try to archieve.

2. Checking if source validity is still valid, is not an option. How to
know if the source is valid? Sometimes, we are not dealing with simple
files where a date is enough to check. A cached pipeline does not helps
here much too. We can have the same source dealing with the same pipeline
fetching data from a database. How to know the data already changed in the
database? I think there is no way within cocoon nor cforms. Regenerating
the data from the pipeline is not a choice too. If we do that, then better
left the code untouched. And this is not a solution again, because the
DynamicSlectionList will continue with his slowness. And this is what we
are trying to fix. ;-)

3. Given the above point 2, them the DSL must be re-readed from the source
each time it is requested. And this is the way it is working now. But
inside the repeater it is time consuming. For this reason, what we are
doing now is re-reading on the first repeater row and then generating from
the cache. This is a lot times faster. Perhaps a hack. I am not sure.

4. I wanted to not touch at all the Field.java. It was my first intention.
But I miss to find in the DynamicSelectionList class a way to know if we
are generating inside a repeater. Because we need to know that in order to
activate the caching. If we are inside a repeater, then we need to check
if we are in the first row. This conditions must be meet before ceating
and storing the cache. If you know how inside the DynamicSelectionList we
can know is we are inside a repeater, please let me know. I will be glad
to remove the dependencies I added in the Field.java.

5. I must admit, the code to create the DynamicSlectionList cache is not
the best. Here, I can do a better solution. Here we need a signal to know
when to store the SAX events for later usage. This signal must be
triggered each time we are in the first row af a repeater.

6. About the copy paste, I know I can fix the copied pasted code from
DefaultSelectionListBuilder. Please note, I don't wanted to change the
DefaultSelectionListBuilder methods to "public". Because it add another
file to the changes. And perhaps makes the things worse. But is this is a
solution, I will switch the methods to public and use them in the
DynamicSelectionList code. I will prefer this, because we are building a
temporal StaticSelectionList as the cache. I am just reusing code.

WDYT?

Best Regards,

Antonio Gallardo.

Mime
View raw message