This change kind of works (I had to change getPath() too), but then for
every component I use LazyModel this way (every textfield in my case), I
get three exceptions thrown, then ignored (2 at getObjectClass() and 1 at
getPath()).
I guess using exceptions to flow control isn't very efficient, too... :)
Could Generics.getClass(type) be changed to not throw
IllegalArgumentException when it can't resolve the class? Maybe return null
and let callers deal with it?
On Fri, Jun 14, 2013 at 2:52 AM, Sven Meier <s...@meiers.net> wrote:
> Hi Tetsuo,
>
> I stand corrected:
> For #getObjectClass() the model had to be bound to something revealing its
> type.
>
> We cannot hold a reference to the type because this could lead to all
> sorts of class loading problems (see Wicket's IClassResolver). Furthermore
> it would unnecessarily increase the size of LazyModel in most cases (if
> everything is properly typed).
>
> I improved LazyModel to behave like PropertyModel, i.e. return the result
> object's type as fallback or just return null if everything fails.
>
> Sven
>
>
> On 06/14/2013 02:24 AM, tetsuo wrote:
>
>> I made the changes to make it work, added a test case, and sent a pull
>> request on github.
>> Now it works when you create an unbound model from a class, and then bind
>> it to a plain model.
>>
>>
>> On Thu, Jun 13, 2013 at 6:39 PM, tetsuo <ronald.tet...@gmail.com> wrote:
>>
>> Well, you were the one who said that if I created the unbound model
>>> (from(A.class)) then I could bind it to a plain IModel, without the extra
>>> type information :)
>>>
>>> I just assumed that it would keep the 'A.class' information passed in the
>>> beginning and use it at runtime.
>>>
>>> It seems that the Evaluation holds the initial 'from' type, but it isn't
>>> passed down to LazyModel when it is created (it only receives target and
>>> stack), so it has to try to discover the type by itself, and fails.
>>>
>>> I'll try to do some experiments here...
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 13, 2013 at 6:21 PM, Sven Meier <s...@meiers.net> wrote:
>>>
>>> Well, here again LazyModel needs the type of the bound target at
>>>> runtime.
>>>> Without any runtime information about the model's object type, LazyModel
>>>> cannot derive the type of the evaluation result.
>>>>
>>>> Sven
>>>>
>>>>
>>>> On 06/13/2013 10:55 PM, tetsuo wrote:
>>>>
>>>> this test also passes here, but
>>>>>
>>>>> assertEquals(B.class, ((IObjectClassAwareModel<B>)
>>>>> model.bind(a)).getObjectClass(****));
>>>>>
>>>>> assertEquals(B.class, ((IObjectClassAwareModel<B>)
>>>>> model.bind(Model.of(a))).****getObjectClass());
>>>>>
>>>>>
>>>>>
>>>>> While the first assert passes, but the second one doesn't.
>>>>>
>>>>> The exception is thrown not when getting the object, but the object
>>>>> class
>>>>> (the AbstractTextComponent class calls this before rendering and while
>>>>> converting input).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jun 13, 2013 at 5:40 PM, Sven Meier <s...@meiers.net> wrote:
>>>>>
>>>>> Strange, works fine here:
>>>>>
>>>>>> @Test
>>>>>> public void bindToModelAndGet() {
>>>>>> LazyModel<B> model = model(from(A.class).getB());
>>>>>>
>>>>>> final A a = new A();
>>>>>> a.b = new B();
>>>>>>
>>>>>> assertEquals(a.b, model.bind(Model.of(a)).******
>>>>>> getObject());
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>> On 06/13/2013 10:23 PM, tetsuo wrote:
>>>>>>
>>>>>> Thanks for the response!
>>>>>>
>>>>>>> If I use an object instance, it works, but if I do as your third
>>>>>>> example
>>>>>>> (create a model from the class, then bind to a
>>>>>>> non-IObjectClassAwareModel-******model),
>>>>>>>
>>>>>>>
>>>>>>> it doesn't:
>>>>>>>
>>>>>>> public class TestPage extends WebPage {
>>>>>>>
>>>>>>> private String text;
>>>>>>>
>>>>>>> public TestPage(final PageParameters parameters) {
>>>>>>>
>>>>>>> super(parameters);
>>>>>>>
>>>>>>> add(new Form<Void>("form")
>>>>>>>
>>>>>>> .add(new TextField<String>("text",
>>>>>>> model(from(TestPage.class
>>>>>>> ).getText()).bind(Model.of(******this)))));
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> public String getText() { return text; }
>>>>>>>
>>>>>>> public void setText(String text) { this.text = text; }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> If I change 'Model.of(this)' to 'this' or an IObjectClassAwareModel
>>>>>>> implementation, it works:
>>>>>>>
>>>>>>>
>>>>>>> class TestPageModel extends AbstractReadOnlyModel<******
>>>>>>> TestPage>
>>>>>>>
>>>>>>> implements IObjectClassAwareModel<******TestPage> {
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> public TestPage getObject() { return TestPage.this; }
>>>>>>>
>>>>>>> public Class<TestPage> getObjectClass() { return
>>>>>>> TestPage.class;
>>>>>>> }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Is this a bug? I could create some wrapper models to make it work,
>>>>>>> but
>>>>>>> if
>>>>>>> this is a bug, I'd prefer to wait for a corrected version.
>>>>>>>
>>>>>>>
>>>>>>> Thanks again
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jun 13, 2013 at 4:52 PM, Sven Meier <s...@meiers.net> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> LazyModel needs to know the type of the model object to return an
>>>>>>>> appropriate proxy:
>>>>>>>>
>>>>>>>> model(from(a).getB()); // works
>>>>>>>> model(from(aModel).getB()); // aModel must be an
>>>>>>>> IObjectClassAwareModel
>>>>>>>> model(from(A.class).getB()).********bind(aModel); // works
>>>>>>>> even if
>>>>>>>>
>>>>>>>> aModel
>>>>>>>>
>>>>>>>>
>>>>>>>> does not reveal its object class
>>>>>>>>
>>>>>>>> Sven
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/13/2013 09:35 PM, tetsuo wrote:
>>>>>>>>
>>>>>>>> wait, wait, do you actually do something like
>>>>>>>>
>>>>>>>> new TextField<String>("name", new IModel<String>(){
>>>>>>>>> public String getObject() {
>>>>>>>>> return entity.getName();
>>>>>>>>> }
>>>>>>>>> public void setObject(String value) {
>>>>>>>>> entity.setName(value);
>>>>>>>>> }
>>>>>>>>> public void detach(){}
>>>>>>>>> });
>>>>>>>>>
>>>>>>>>> for every single field in your system, or you use LazyModel?
>>>>>>>>>
>>>>>>>>> Well, I've been trying to use LazyModel, but with it I have to pass
>>>>>>>>> the
>>>>>>>>> type of every field (the last arg of TextField's constructor)
>>>>>>>>> because
>>>>>>>>> if I
>>>>>>>>> don't, this exception is thrown:
>>>>>>>>>
>>>>>>>>> Caused by: java.lang.********IllegalArgumentException: T is not a
>>>>>>>>> class or
>>>>>>>>> parameterizedType
>>>>>>>>>
>>>>>>>>> at org.wicketstuff.lazymodel.********reflect.Generics.getClass(**
>>>>>>>>> Generics.java:78)
>>>>>>>>>
>>>>>>>>> at org.wicketstuff.lazymodel.********LazyModel.getObjectType(**
>>>>>>>>> LazyModel.java:139)
>>>>>>>>>
>>>>>>>>> at org.wicketstuff.lazymodel.********LazyModel.getObjectClass(**
>>>>>>>>> LazyModel.java:124)
>>>>>>>>>
>>>>>>>>> at org.apache.wicket.markup.html.********form.**
>>>>>>>>> AbstractTextComponent.****
>>>>>>>>> getModelType(
>>>>>>>>> AbstractTextComponent.java:********167)
>>>>>>>>>
>>>>>>>>> at org.apache.wicket.markup.html.********form.**
>>>>>>>>> AbstractTextComponent.****
>>>>>>>>> resolveType(
>>>>>>>>> AbstractTextComponent.java:********152)
>>>>>>>>>
>>>>>>>>> at org.apache.wicket.markup.html.********form.**
>>>>>>>>> AbstractTextComponent.****
>>>>>>>>> onBeforeRender(
>>>>>>>>> AbstractTextComponent.java:********142)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any thoughts?
>>>>>>>>>
>>>>>>>>> I guess I'll just go back to CompoundPropertyModel... (sigh)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (and no, I don't spend that much time debugging property models. I
>>>>>>>>> usually
>>>>>>>>> don't rename properties that often, and when I have to do some
>>>>>>>>> refactoring,
>>>>>>>>> usually the structure changes, and I have to revise all pages
>>>>>>>>> anyway...)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, May 31, 2013 at 10:49 AM, Martin Grigorov <
>>>>>>>>> mgrigo...@apache.org
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Fri, May 31, 2013 at 4:24 PM, tetsuo <
>>>>>>>>>>
>>>>>>>>> ronald.tet...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Black magic, or code generation? hard choice... :)
>>>>>>>>>
>>>>>>>>>> I think I'll try the black magic, let's see how it goes :)
>>>>>>>>>>
>>>>>>>>>>> I personally prefer writing the boilerplate of custom Model
>>>>>>>>>>> per
>>>>>>>>>>> field.
>>>>>>>>>>>
>>>>>>>>>>> It is a boring work but it gives me:
>>>>>>>>>>>
>>>>>>>>>> * type safety
>>>>>>>>>> * the fastest read/write access possible
>>>>>>>>>> * easier debugging
>>>>>>>>>>
>>>>>>>>>> (who knows - maybe I've spent less time to write such models than
>>>>>>>>>> you've
>>>>>>>>>> spent to debug your issues with property model after refactoring)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, May 30, 2013 at 8:16 PM, Igor Vaynberg <
>>>>>>>>>>
>>>>>>>>>> igor.vaynb...@gmail.com
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Thu, May 30, 2013 at 12:37 PM, tetsuo <
>>>>>>>>>>>> ronald.tet...@gmail.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> -1000!
>>>>>>>>>>>
>>>>>>>>>>> This will be horrible! Even with the current API, most generics
>>>>>>>>>>>> I
>>>>>>>>>>>>
>>>>>>>>>>>>> have
>>>>>>>>>>>>>
>>>>>>>>>>>>> to
>>>>>>>>>>>>
>>>>>>>>>>> declare in my code don't add anything to type safety. For
>>>>>>>>>>> example:
>>>>>>>>>>>
>>>>>>>>>>> while i am also not a fan of having component generified i do
>>>>>>>>>>>> believe
>>>>>>>>>>>> the example below is a bit contrived.
>>>>>>>>>>>>
>>>>>>>>>>>> first, i hope most people do not use PropertyModels because they
>>>>>>>>>>>> are
>>>>>>>>>>>> not compile-time-safe. there are plenty of project that
>>>>>>>>>>>> implement
>>>>>>>>>>>> compile-time-safe models, personally i prefer
>>>>>>>>>>>> https://github.com/42Lines/********metagen<https://github.com/42Lines/******metagen>
>>>>>>>>>>>> <https://github.com/**42Lines/****metagen<https://github.com/42Lines/****metagen>
>>>>>>>>>>>> >
>>>>>>>>>>>> <https://github.com/**42Lines/****metagen<https://github.com/**42Lines/**metagen>
>>>>>>>>>>>> <https://github.com/**42Lines/**metagen<https://github.com/42Lines/**metagen>
>>>>>>>>>>>> >
>>>>>>>>>>>> <https://github.com/**42Lines/****metagen<https://github.com/**42Lines/**metagen>
>>>>>>>>>>>> <https://github.com/****42Lines/metagen<https://github.com/**42Lines/metagen>
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>> <https://github.com/**42Lines/**metagen<https://github.com/**42Lines/metagen>
>>>>>>>>>>>> <https://github.com/**42Lines/metagen<https://github.com/42Lines/metagen>
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> using proxy-based solutions.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> further, i hope even less people use compound property models.
>>>>>>>>>>>> they
>>>>>>>>>>>> are even more unsafe then property models and make your code
>>>>>>>>>>>> even
>>>>>>>>>>>> more
>>>>>>>>>>>> fragile. i would hate to refactor code that uses CPMs.
>>>>>>>>>>>>
>>>>>>>>>>>> add(new Form<Person>("form", new
>>>>>>>>>>>> CompoundPropertyModel<Person>(
>>>>>>>>>>>> ****
>>>>>>>>>>>>
>>>>>>>>>>>> new
>>>>>>>>>>>>
>>>>>>>>>>>> PropertyModel<Person>(this, "person")))
>>>>>>>>>>>>> .add(new TextField<String>("name"))
>>>>>>>>>>>>> .add(new TextField<Integer>("age"))
>>>>>>>>>>>>> .add(new TextField<Double>("salary"))
>>>>>>>>>>>>> .add(new Button("save", new
>>>>>>>>>>>>>
>>>>>>>>>>>>> PropertyModel<Person>(this,"********person")){
>>>>>>>>>>>>>
>>>>>>>>>>>>> public void onSubmit() {
>>>>>>>>>>>>
>>>>>>>>>>>> repository.save((Person)********getForm().****
>>>>>>>>>>>>
>>>>>>>>>>>> getDefaultModelObject());
>>>>>>>>>>>>>
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>> });
>>>>>>>>>>>>
>>>>>>>>>>>> In my experience, this kind of code is fairly common in Wicket
>>>>>>>>>>>>> applications. Every form component must be declared with a
>>>>>>>>>>>>> type,
>>>>>>>>>>>>> but
>>>>>>>>>>>>>
>>>>>>>>>>>>> none
>>>>>>>>>>>>>
>>>>>>>>>>>>> has *any* kind of type safety gain.
>>>>>>>>>>>> but how often do you declare a form component without adding any
>>>>>>>>>>>> validators to it? the generic type of component also makes sure
>>>>>>>>>>>> you
>>>>>>>>>>>> add the correct validator. for example it wont let you add a
>>>>>>>>>>>> validator
>>>>>>>>>>>> that expects strings to a component that produces integers.
>>>>>>>>>>>>
>>>>>>>>>>>> also, not sure why you are replicating the model in Button.
>>>>>>>>>>>> first,
>>>>>>>>>>>> the
>>>>>>>>>>>> Button uses its model to fill its label; secondly, in real code
>>>>>>>>>>>> the
>>>>>>>>>>>> model would be in a final var or field that things like onsubmit
>>>>>>>>>>>> can
>>>>>>>>>>>> access easily.
>>>>>>>>>>>>
>>>>>>>>>>>> -igor
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - The property model uses reflection, so its type can't be
>>>>>>>>>>>> verified
>>>>>>>>>>>> by
>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>> compiler (this.person could be anything, not just a Person).
>>>>>>>>>>>
>>>>>>>>>>>> - Generics will guarantee that the form model will be of type
>>>>>>>>>>>>> Person,
>>>>>>>>>>>>>
>>>>>>>>>>>>> but
>>>>>>>>>>>>>
>>>>>>>>>>>>> since it's all declared inline, and the real model isn't
>>>>>>>>>>>> verifiable,
>>>>>>>>>>>> it
>>>>>>>>>>>>
>>>>>>>>>>>> just adds lots of verbosity without any real gain.
>>>>>>>>>>>>
>>>>>>>>>>> - Most form components use the implicit model, that also uses
>>>>>>>>>>>
>>>>>>>>>>>> reflection,
>>>>>>>>>>>>>
>>>>>>>>>>>>> and also can't verify the actual type of the underlying
>>>>>>>>>>>> property,
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>>> compilation time. Even in runtime, *the type information is
>>>>>>>>>>>> lost
>>>>>>>>>>>>
>>>>>>>>>>>>> due
>>>>>>>>>>>>>
>>>>>>>>>>>>> erasure
>>>>>>>>>>>>>
>>>>>>>>>>>>> *, so it can't use it to do any additional verification.
>>>>>>>>>>>>
>>>>>>>>>>>> *- Worse, you can even declare the "name" TextField as
>>>>>>>>>>>>> <Integer>
>>>>>>>>>>>>> or
>>>>>>>>>>>>> <Double> (while maintaining the 'text' attribute as String),
>>>>>>>>>>>>> and
>>>>>>>>>>>>>
>>>>>>>>>>>>> since
>>>>>>>>>>>>>
>>>>>>>>>>>>> there is no type information at runtime, it doesn't matter. It
>>>>>>>>>>>>
>>>>>>>>>>> won't
>>>>>>>>>>>
>>>>>>>>>>> even
>>>>>>>>>>>
>>>>>>>>>>>> throw an exception (it will just work normally).* In this case,
>>>>>>>>>>>> the
>>>>>>>>>>>> type
>>>>>>>>>>>> declaration is simply a lie.
>>>>>>>>>>>>
>>>>>>>>>>>> Just pain, no gain. In my code, I sometimes just add a
>>>>>>>>>>>>
>>>>>>>>>>>>> @SuppressWarnings(
>>>>>>>>>>>>>
>>>>>>>>>>>>> "rawtypes") to the class, and remove all useless generic type
>>>>>>>>>>>> declarations.
>>>>>>>>>>>>
>>>>>>>>>>>> If everything will be required to declare them, I will have
>>>>>>>>>>>> do
>>>>>>>>>>>> it
>>>>>>>>>>>>
>>>>>>>>>>>> more
>>>>>>>>>>>>>
>>>>>>>>>>>>> frequently.
>>>>>>>>>>>>
>>>>>>>>>>> That said, repeater components benefit greatly from generics.
>>>>>>>>>>> So
>>>>>>>>>>>
>>>>>>>>>>>> do
>>>>>>>>>>>>
>>>>>>>>>>>> custom
>>>>>>>>>>>>>
>>>>>>>>>>>>> models, validators, and converters. Or the rare cases that
>>>>>>>>>>>> we
>>>>>>>>>>>>
>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>
>>>>>>>>>>>>> declare the form component model. But forcing everything to be
>>>>>>>>>>>>
>>>>>>>>>>>> generic-typed will just make Wicket extremely verbose to use,
>>>>>>>>>>>>
>>>>>>>>>>>>> with
>>>>>>>>>>>>>
>>>>>>>>>>>>> very
>>>>>>>>>>>>>
>>>>>>>>>>>>> little benefit.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, May 30, 2013 at 4:00 AM, Martin Grigorov <
>>>>>>>>>>>>>
>>>>>>>>>>>>> mgrigo...@apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>> I just pushed some initial work for [1] and [2] in
>>>>>>>>>>>>>
>>>>>>>>>>>>>> branch generified-component-4930.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So far it doesn't look nice.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The added generics break somehow setMetaData/getMetaData
>>>>>>>>>>>>>> methods -
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>
>>>>>>>>>>>> see compilation errors in Component and Page classes. I think it
>>>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>> caused
>>>>>>>>>>>>> by the anonymous instance of MetaDataKey ( new
>>>>>>>>>>>>> MetaDataKey<T>(type)
>>>>>>>>>>>>> {}
>>>>>>>>>>>>>
>>>>>>>>>>>>> ).
>>>>>>>>>>>>>
>>>>>>>>>>>> Also the visit*** methods do not compile at the moment, but even
>>>>>>>>>>>> if
>>>>>>>>>>>>
>>>>>>>>>>>> we
>>>>>>>>>>>>>
>>>>>>>>>>>>> find
>>>>>>>>>>>>>
>>>>>>>>>>>> a way to fix their signature I think writing a visitor will
>>>>>>>>>>>> become
>>>>>>>>>>>>
>>>>>>>>>>>> quite
>>>>>>>>>>>>>
>>>>>>>>>>>>> cumbersome.
>>>>>>>>>>>>>
>>>>>>>>>>>> At the moment we have IVisitor
>>>>>>>>>>>>
>>>>>>>>>>>>> and org.apache.wicket.util.********iterator.****
>>>>>>>>>>>>>> AbstractHierarchyIterator
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>> same job. The Iterator API is supposed to be simpler to write
>>>>>>>>>>>> for
>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>> users. Maybe we can drop IVisitor ... ?!
>>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to ask for help with this task. It is supposed to be
>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>> biggest
>>>>>>>>>>>>> API break for Wicket 7.0. My current feeling is that the end
>>>>>>>>>>>>> result
>>>>>>>>>>>>> won't
>>>>>>>>>>>>> be very pleasant for the user-land code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For example the application code will have to do something
>>>>>>>>>>>>> like:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> WebMarkupContainer<Void> wmc = new
>>>>>>>>>>>>>> WebMarkupContainer<>("id")
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is not that much but we have to decide whether we want it.
>>>>>>>>>>>>>> But first let's try to fix the compilation problems.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1.
>>>>>>>>>>>>>> https://issues.apache.org/********jira/browse/WICKET-4930<https://issues.apache.org/******jira/browse/WICKET-4930>
>>>>>>>>>>>>>> <http**s://issues.apache.org/******jira/browse/WICKET-4930<https://issues.apache.org/****jira/browse/WICKET-4930>
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> <https:**//issues.apache.org/****jira/**browse/WICKET-4930<http://issues.apache.org/**jira/**browse/WICKET-4930>
>>>>>>>>>>>>>> <htt**ps://issues.apache.org/**jira/**browse/WICKET-4930<https://issues.apache.org/**jira/browse/WICKET-4930>
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> <https:**//issues.apache.org/****jira/**browse/WICKET-4930<http://issues.apache.org/**jira/**browse/WICKET-4930>
>>>>>>>>>>>>>> <htt**p://issues.apache.org/jira/****browse/WICKET-4930<http://issues.apache.org/jira/**browse/WICKET-4930>
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> <http**s://issues.apache.org/**jira/**browse/WICKET-4930<http://issues.apache.org/jira/**browse/WICKET-4930>
>>>>>>>>>>>>>> <http**s://issues.apache.org/jira/**browse/WICKET-4930<https://issues.apache.org/jira/browse/WICKET-4930>
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (Add
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> generics
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> o.a.w.Component)
>>>>>>>>>>>>>
>>>>>>>>>>>> 2.
>>>>>>>>>>>>
>>>>>>>>>>>> https://cwiki.apache.org/*******
>>>>>>>>>>>>>> *confluence/display/WICKET/**<https://cwiki.apache.org/******confluence/display/WICKET/**>
>>>>>>>>>>>>>> <**https://cwiki.apache.org/******
>>>>>>>>>>>>>> confluence/display/WICKET/**<https://cwiki.apache.org/****confluence/display/WICKET/**>
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> <h**ttps://cwiki.apache.org/****
>>>>>>>>>>>>>> **confluence/display/WICKET/**<http://cwiki.apache.org/****confluence/display/WICKET/**>
>>>>>>>>>>>>>> **<https://cwiki.apache.org/****confluence/display/WICKET/**<https://cwiki.apache.org/**confluence/display/WICKET/**>
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> Wicket+7.0+Roadmap#Wicket7.*****
>>>>>>>>>>>>>> ***0Roadmap-Genericsfororg.**
>>>>>>>>>>>>>>
>>>>>>>>>>>>> apache.wicket.Component<https:******//cwiki.apache.org/**
>>>>>>>>>>>>
>>>>>>>>>>> confluence/**
>>>>>>>>>>> <http://cwiki.apache.org/**confluence/**<http://cwiki.apache.org/confluence/**>
>>>>>>>>>> >
>>>>>>>>>> display/WICKET/Wicket+7.0+******Roadmap#Wicket7.0Roadmap-**
>>>>>>>>>> Genericsfororg.apache.wicket.******Component<https://cwiki.**
>>>>>>>>>> apache.org/confluence/display/****WICKET/Wicket+7.0+Roadmap#**<http://apache.org/confluence/display/**WICKET/Wicket+7.0+Roadmap#**>
>>>>>>>>>> Wicket7.0Roadmap-****Genericsfororg.apache.wicket.****Component<
>>>>>>>>>> https://cwiki.**apache.org/confluence/display/**
>>>>>>>>>> WICKET/Wicket+7.0+Roadmap#**Wicket7.0Roadmap-**
>>>>>>>>>> Genericsfororg.apache.wicket.**Component<https://cwiki.apache.org/confluence/display/WICKET/Wicket+7.0+Roadmap#Wicket7.0Roadmap-Genericsfororg.apache.wicket.Component>
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>
