I tried to implement something like:
// java docs removed for clarity
public abstract class Change<FORMER extends IClusterable> implements
IClusterable {
private static final long serialVersionUID = 1L;
// former type
public FORMER former;
protected Change(final FORMER former)
{
setFormer(former);
}
public final FORMER getFormer()
{
return former;
}
public final void setFormer(FORMER former)
{
this.former = former;
}
public abstract void undo();
}
Then i changed a sample Change class code to something like: (renamed the
VisibilityChange to ComponentVisibility for more explicit name)
ComponentVisibilityChange implements Change<Component>
{
protected ComponentVisibilityChage(final Component component)
{
super(component);
}
public void undo()
{
do something (getFormer() );
}
}
This reduces a lot state maintainence on part on concrete change classes and
makes their names more explicitly apparent based on FORMER parameter type
given to Change, hence my boiler plate code is less in concrete change
classes. But then i saw classes like CurrentPageChange where current page
type is given as an int ... =( and not something like new
Model<Integer>(currentPage);
I thought IClusterable served as a namespace of sorts for everything
associated with wicket, especially for the change track bound entities type
... (something better than just an int) ... ?
some thoughts/questions thought i'd ask.
Thanks for your time.
Regards
Vyas, Anirudh
On Thu, Mar 26, 2009 at 9:13 PM, Ricky <ricky...@gmail.com> wrote:
> https://issues.apache.org/jira/browse/WICKET-2187
>
> done. thank you.
>
>
> On Thu, Mar 26, 2009 at 11:40 AM, Ricky <ricky...@gmail.com> wrote:
>
>> thanks, i'll create a JIRA issue and submit a patch tonight, appreciate
>> your time!
>>
>>
>> On Thu, Mar 26, 2009 at 8:31 AM, Johan Compagner <jcompag...@gmail.com>wrote:
>>
>>> if you have a patch for better toString() impl be my guest and attach it
>>> to
>>> jira
>>>
>>> Those Changes classes are internal to component, they are inner classes
>>> of
>>> Component so they dont have to specify that extra name..
>>> Its just verbose. Also those 2 are protected final but i think they could
>>> be
>>> private if you ask me.
>>> So they are just internal
>>>
>>> On Thu, Mar 26, 2009 at 02:49, Ricky <ricky...@gmail.com> wrote:
>>>
>>> > Hi,
>>> >
>>> > This concerns Wicket Version : 1.4-rc2
>>> >
>>> >
>>> > In componentModelChange class, we see the following :
>>> > @Override
>>> > public String toString()
>>> > {
>>> > return "ComponentModelChange[component: " + getPath() + "]";
>>> > }
>>> >
>>> > "ComponentModelChange[" piece of it, in toString( ) shouldn't that be
>>> > this.getClass().getSimpleName( ) + "[" or something in those lines, I
>>> see
>>> > that most of the component change classes are based on a format like
>>> that
>>> > ... am i missing something? If we see the Behaviour Change code that
>>> > follows
>>> > , we use more dynamic this.getClass() to spit out toString( ); If I may
>>> > ask,
>>> > is the Behavior change toString ( ) and OtherChange format different by
>>> > some
>>> > agreeable convention ? Also the toString( ) seems to be missing on
>>> > ComponentBorderChange class.
>>> >
>>> > One more small observation, our naming conventions on Change class are
>>> > inconsistent in many cases, for example, VisibilityChange and
>>> EnabledChange
>>> > .. for what? question comes to mind, and the answer is component ...
>>> that
>>> > to
>>> > me infers that either it should be:
>>> > 1.) Change<COMPONENT extends Component>
>>> > if above is not acceptable, then
>>> > 2.) name it like ComponentEnabledChange or something in those lines?
>>> >
>>> > Just some thoughts.
>>> > Sorry If questions have already been answered or are not appropriate,
>>> > thought i'd ask the programming elites of wicket ;)
>>> >
>>> > Regards
>>> > Vyas, Anirudh
>>> > || ॐ ||
>>> >
>>>
>>
>>
>>
>> --
>>
>> Regards
>> Vyas, Anirudh
>> || ॐ ||
>>
>
>
>
> --
>
> Regards
> Vyas, Anirudh
> || ॐ ||
>
--
Regards
Vyas, Anirudh
|| ॐ ||
