why not roll this into attributemodifier and have mode { replace,
append, prepand } where replace is how the modifier works now...

-igor

On Wed, Jun 8, 2011 at 12:07 AM, Martin Grigorov <[email protected]> wrote:
> Hi,
>
> I also had the same thoughts when I added the flag (as the patch
> suggested) but AttributeAppender is a class with just constructor
> overrides and one method override (#newValue()). If we introduce yet
> another class for prepend then there is no sense in "the one common
> parent" because they have nothing to share. Both of them will have the
> same number of constructors and this override of #newValue().
>
> I agree that now the name AttributeAppender is not the best but I
> cannot find a better one and even if we find it then we will have to
> rename this class which I think is used a lot
>
> On Wed, Jun 8, 2011 at 8:53 AM, Per Newgro <[email protected]> wrote:
>> Hi,
>>
>> i've traced changes in 1.5-RC4.2. Found the issue 3552 [
>> https://issues.apache.org/jira/browse/WICKET-3552 ]. If i'm not
>> completely in the wood the solution breaks the
>> SingleResponsibilityPrinciple by adding a flag to the constructor
>> which negates the class behavior.
>> Wouldn't it be more clear and reusable if we had another
>> AttributePrepender which acts like the AttributeAppender.
>> Both could extend the base-class AbstractAttributeRegister or
>> something. Then only the different part of the newValue method has
>> to be implemented by the concrete class.
>>
>> I only ask because if 1.5 is out it will be hard to exchange because
>> many apps will be upgraded and feature is maybe used :-).
>>
>> What do you think?
>> Cheers
>> Per
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to