cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
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 00:02:07 GMT
On 27.05.2005 16:05, antonio@apache.org wrote:
> Author: antonio
> Date: Fri May 27 07:05:02 2005
> New Revision: 178778
> 
> URL: http://svn.apache.org/viewcvs?rev=178778&view=rev
> Log:
> Cforms block: Improved dynamic selection list performance inside repeaters.

Sorry, but I absolutely don't like it for the following reasons:

1. You introduced a dependency on the class DynamicSelectionList into 
Field.java where before was only the interface SelectionList.

2. You introduced a dependency on the classes Repeater and RepeaterRow.

3. You mixed builder concerns with datatype concerns (copying code from 
DefaultSelectionListBuilder to DynamicSelectionList).

4. The implementation of DynamicSelectionList got much more complex, 
where I don't see a reason why? What's the difference between building a 
selection list in generateSaxFragment() and in prepareCache()? 90 lines 
of code just for caching?

Requirements:

1. It must be absolute transparent to Field.java (above issues 1 + 2).

2. No code duplication in sense of copy & paste (above issue 3).

3. Simple code! No code duplication in sense of having two parts of code 
doing the same (above issue 4).

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?

Joerg

Mime
View raw message