Re: generics
I converted our project to 1.4 as an experiment. It's quite large (257 source files). It was a bit tedious changing xxxModel to xxDefaultModel, etc, but it wasn't too bad. I haven't fixed all the warnings though. I think the design will benefit us and the conversion will be worth it. We use this pattern a lot: data provider + data panel + data view. Generifying the models these classes deal with reduces confusion, potential runtime errors and code size (the latter because you can get rid of casts and you can move some code to superclasses). Thanks to the Wicket team yet again! Julian -- View this message in context: http://www.nabble.com/generics-tp18083910p18493875.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
this is actually a perfect example where generifying Component broke down in 1.4m2. dataview does not use its model, it uses the dataprovider which it stores as a field. so right now you can just say new DataView and it will expect IDataProvider and you are free to attach any type of model to the dataview you want. in 1.4m2 if we reused the same type declaration for dataprovider and dataview then you would be forced to only use imodel for the dataview which is a completely arbitrary restriction. to fix the above we would have to allow two type declarations, one for model and one for dataprovider. so now you have to do new DataView which is very noisy not to mention you have to remember which one is for the model and which one is for the dataprovider. in m3 we do not have this problem... -igor On Wed, Jul 16, 2008 at 11:34 AM, JulianS <[EMAIL PROTECTED]> wrote: > > I converted our project to 1.4 as an experiment. It's quite large (257 source > files). It was a bit tedious changing xxxModel to xxDefaultModel, etc, but > it wasn't too bad. I haven't fixed all the warnings though. > > I think the design will benefit us and the conversion will be worth it. We > use this pattern a lot: data provider + data panel + data view. Generifying > the models these classes deal with reduces confusion, potential runtime > errors and code size (the latter because you can get rid of casts and you > can move some code to superclasses). > > Thanks to the Wicket team yet again! > Julian > -- > View this message in context: > http://www.nabble.com/generics-tp18083910p18493875.html > Sent from the Wicket - User mailing list archive at Nabble.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]
Re: generics
I ported all our projects to 1.4-m3 (from 1.4-m2). It was quite large - about 500 source files. Everything worked out nicely. I can say, that I am very happy with actual generics style. I think, that this is how generics should be applied in Wicket. Good work! Thanks to the Wicket team yet again! Stefan Simik -- View this message in context: http://www.nabble.com/generics-tp18083910p18498620.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics
Basically the list view depend from List interface due some calls to his
get(index) method. It means that the order of the components on the
collections, are meaninful to the component. If it is not your case (order,
item indexes doesn't matters), you can use an wrapper model in an list view,
like:
WrapperModel implements IModel
{
public WrapperModel (IModel wrappedModel)
{
this.wrappedModel = wrappedModel;
}
public Object getObject()
{
return new ArrayList(wrappedModel.getObject());
}
}
then you can create an list view like:
new ListView("id", new PropertyModel(bean, "listPropertyFromThatBean"))
On Mon, Jan 25, 2010 at 12:29 PM, Sam Barrow wrote:
> I've noticed in some places where generics wildcards may be useful that
> they are not used. For example, in IColumn.
> If I have a Type and a SubType that extends Type, I can't use
> IColumn in a DataTable. Is there any reason for this or
> was it just not implemented? Not the most necessary feature, but it
> couldn't hurt.
>
> Also is there a reason ListView and similar components require an
> IModel, and will not accept an IModel?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Pedro Henrique Oliveira dos Santos
Re: Generics
That's exactly what I do now (wrapped model). Just wondering if there was a
technical reason behind it.
Sent via BlackBerry from T-Mobile
-Original Message-
From: Pedro Santos
Date: Mon, 25 Jan 2010 13:03:16
To:
Subject: Re: Generics
Basically the list view depend from List interface due some calls to his
get(index) method. It means that the order of the components on the
collections, are meaninful to the component. If it is not your case (order,
item indexes doesn't matters), you can use an wrapper model in an list view,
like:
WrapperModel implements IModel
{
public WrapperModel (IModel wrappedModel)
{
this.wrappedModel = wrappedModel;
}
public Object getObject()
{
return new ArrayList(wrappedModel.getObject());
}
}
then you can create an list view like:
new ListView("id", new PropertyModel(bean, "listPropertyFromThatBean"))
On Mon, Jan 25, 2010 at 12:29 PM, Sam Barrow wrote:
> I've noticed in some places where generics wildcards may be useful that
> they are not used. For example, in IColumn.
> If I have a Type and a SubType that extends Type, I can't use
> IColumn in a DataTable. Is there any reason for this or
> was it just not implemented? Not the most necessary feature, but it
> couldn't hurt.
>
> Also is there a reason ListView and similar components require an
> IModel, and will not accept an IModel?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Pedro Henrique Oliveira dos Santos
Re: Generics
Just make sure that the items on the collection have an index (List
interface ensure it). It is important to the implementation of
ListItemModel.setObject for instance and turn possible the component
pagination.
On Mon, Jan 25, 2010 at 1:05 PM, wrote:
> That's exactly what I do now (wrapped model). Just wondering if there was a
> technical reason behind it.
>
> Sent via BlackBerry from T-Mobile
>
> -Original Message-
> From: Pedro Santos
> Date: Mon, 25 Jan 2010 13:03:16
> To:
> Subject: Re: Generics
>
> Basically the list view depend from List interface due some calls to his
> get(index) method. It means that the order of the components on the
> collections, are meaninful to the component. If it is not your case (order,
> item indexes doesn't matters), you can use an wrapper model in an list
> view,
> like:
>
> WrapperModel implements IModel
> {
> public WrapperModel (IModel wrappedModel)
> {
> this.wrappedModel = wrappedModel;
> }
> public Object getObject()
> {
> return new ArrayList(wrappedModel.getObject());
> }
>
> }
>
> then you can create an list view like:
> new ListView("id", new PropertyModel(bean, "listPropertyFromThatBean"))
>
> On Mon, Jan 25, 2010 at 12:29 PM, Sam Barrow wrote:
>
> > I've noticed in some places where generics wildcards may be useful that
> > they are not used. For example, in IColumn.
> > If I have a Type and a SubType that extends Type, I can't use
> > IColumn in a DataTable. Is there any reason for this or
> > was it just not implemented? Not the most necessary feature, but it
> > couldn't hurt.
> >
> > Also is there a reason ListView and similar components require an
> > IModel, and will not accept an IModel?
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
>
> --
> Pedro Henrique Oliveira dos Santos
>
>
--
Pedro Henrique Oliveira dos Santos
Wicket generics?
I have casting problem: dropDown = new DropDownChoice(, new ChoiceRenderer(...)); dropDown.getChoiceRenderer().getDisplayValue(dropDown.getModelObject()); <-- DOES NOT COMPILE Is this a wicket bug or bug in me? ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AutoCompleteTextField & Generics
Has anybody else had problems with AutoCompleteTextField and generics. It almost seems like I'm dealing with an eclipse bug. But basically if I call behavior.getChoices.add(xxx) it is always highlighted in red because, I am restricted by the model use "T" but the list wants "? extends T". D/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: generics
igor.vaynberg wrote:
>
> so now you have to do new
> DataView which is very noisy not to mention you have to
> remember which one is for the model and which one is for the
> dataprovider.
>
> -igor
>
>
I don't know if this is too late, and haven't played with DataViews for a
while but why couldn't you do something to this extent:
public abstract class DataViewBase extends AbstractPageableView
{
public DataViewBase(String id, IDataProvider dataProvider)
{
...snip...
}
...snip...
private static final class ModelIterator implements
Iterator>
{
...snip...
}
}
as DataView's children aren't actually supposed to use T - that's what the
DataView's model would use but chooses to ignore it (and we can't know if
some subclass would actually _want_ to use the model for something). Just
drop the T parameter and avoid the noise if required.
--
View this message in context:
http://www.nabble.com/generics-tp18083910p19065291.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Generics question
This is not really Wicket related, but I don't quite know where else to
ask this. The question is: why won't this compile?
// I define a model
IModel> subgenreModel = new
AbstractReadOnlyModel>() {
...
}
// Here I try to use the model
FieldSwitchPanel subgenrefield = *new
SubgenreFieldSwitchPanel("subgenre", subgenreModel);*
// This is the constructor for the class SubgenreFieldSwithcPanel
public SubgenreFieldSwitchPanel(String id, IModelDomainObject>> choices) {
...
}
// Subgenre extends DomainObject
public class Subgenre extends DomainObject{
...
}
The complaint is: The constructor SubgenreFieldSwitchPanel(String,
IModel>) is undefined.
Thanks,
Linda
Page / WebPage Generics
Maybes it's simple and I missed it, but why don't Page and WebPage implement generics? (Or maybe it's just coming in next milestone?) It would ensure that I don't pass an IModel to a page that needs an IModel for it's model. Also, from any anonymous subclass of the page where I'm doing MyPage.this.getModelObject(), I wouldn't need to cast. Thanks, Jeremy Thomerson
Wicket 1.4 Generics
I just migrated to 1.4-M1 and converted all my classes to use the new generics support. It cleaned up my code quite nicely - I got to remove a lot of casting and cured many unchecked/raw messages. It also make the code much more readable - especially in list views, etc. Excellent work, Wicket team. -Doug -- View this message in context: http://www.nabble.com/Wicket-1.4-Generics-tp17149922p17149922.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket generics
+1 for do it right, no matter if the api breaks or not
Am 07.06.2008 um 09:20 schrieb Igor Vaynberg:
so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void setmodel(imodel model) {...}
public imodel getmodel();
}
that is all good until you want to have a generified subclass eg a
listitem:
class listitem extends component {
public imodel getmodel() { return (imodel)super.getmodel(); }
<== works like a charm
public void setmodel(imodel model) {..} <== woops, compilation
error
Name clash: The method setModel(IModel) of type ListItem has the
same erasure as
setModel(IModel) of type MarkupContainer but does not override it
unfortunately the error makes sense and there is no way around it.
same goes for setmodelobject(). i think this makes this design variant
pretty useless. as long as we have the model coupled to component i
dont see a clean way of doing this :(
class listitem extends component {
public imodel getmodel(..);
public void setmodel(imodel model);
}
looks half baked and broken by design
i would almost reconsider 1.4 and its scope and opt to include a model
decoupling (however and if that is possible) refactor in it. otherwise
i fear we will break the whole generics model again in 1.5 and users
will have to relearn how to use them with wicket.
so as far as i can see, and this is only my opinion, our options are:
continue 1.4 as it is now with fully typed components
remove component type but make the api ugly ( i will let matej
explain )
attempt to fix 1.4 by decoupling model from component - 1.4 takes a
lot longer and is not a simple "drop-in/upgrade/whatever"
thoughts and ideas?
-igor
-
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]
Re: wicket generics
hi igor, that's a mess. :-( i would go for decoupling component/model for 1.4 - that makes a clean cut for the api towards generics. everything else is just half-baked. my 2c, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket generics
On Sat, Jun 7, 2008 at 8:20 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > thoughts and ideas? Is there much else apart from Generic's that's in 1.4 that would benefit from a release 'sooner' rather than 'later'? I know the intentions's not to have it much different, but not changing 1.3's overridden that, so arent't there were a few things, such as making org.apache.wicket.MarkupContainer#getMarkupType overridable allowing non-HTML pages, which might be worth considering? That's been my reason for using 1.4 so I know about that, but are there other things? /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket generics
I'm +1 for trying to decouple model from component, and if it takes
longer then so be it.
I'm pretty convinced that the problem is the 1-1 model-component
coupling and that generics only pointed out this problem.
Regards,
Sebastiaan
Igor Vaynberg wrote:
so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void setmodel(imodel model) {...}
public imodel getmodel();
}
that is all good until you want to have a generified subclass eg a listitem:
class listitem extends component {
public imodel getmodel() { return (imodel)super.getmodel(); }
<== works like a charm
public void setmodel(imodel model) {..} <== woops, compilation error
Name clash: The method setModel(IModel) of type ListItem has the
same erasure as
setModel(IModel) of type MarkupContainer but does not override it
unfortunately the error makes sense and there is no way around it.
same goes for setmodelobject(). i think this makes this design variant
pretty useless. as long as we have the model coupled to component i
dont see a clean way of doing this :(
class listitem extends component {
public imodel getmodel(..);
public void setmodel(imodel model);
}
looks half baked and broken by design
i would almost reconsider 1.4 and its scope and opt to include a model
decoupling (however and if that is possible) refactor in it. otherwise
i fear we will break the whole generics model again in 1.5 and users
will have to relearn how to use them with wicket.
so as far as i can see, and this is only my opinion, our options are:
continue 1.4 as it is now with fully typed components
remove component type but make the api ugly ( i will let matej explain )
attempt to fix 1.4 by decoupling model from component - 1.4 takes a
lot longer and is not a simple "drop-in/upgrade/whatever"
thoughts and ideas?
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: wicket generics
The decoupling doesn't have to be extremely painful. We could leave
support for the default slot in component, something like this:
class Component {
protected void setDefaultModel(IModel model);
protected IModel getDefaultModel();
}
class MyComponent extends Component {
public void setModel(IModel model); // note - no clashes, method
name is different
public IModel getModel();
}
This would solve some problems with decoupling model, such as that
setModel has to do some magic (wrapping, etc). Also given the way
default model slot is currently implemented this has not bigger memory
footprint than not having the slot at all.
-Matej
On Sat, Jun 7, 2008 at 12:17 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> I'm +1 for trying to decouple model from component, and if it takes longer
> then so be it.
>
> I'm pretty convinced that the problem is the 1-1 model-component coupling
> and that generics only pointed out this problem.
>
> Regards,
> Sebastiaan
>
> Igor Vaynberg wrote:
>>
>> so i tried to remove the generic type from component in
>> sandbox/ivaynberg/wicket-generics branch and ran into what i think is
>> a deal breaker for this design
>>
>> class component {
>> public void setmodel(imodel model) {...}
>> public imodel getmodel();
>> }
>>
>> that is all good until you want to have a generified subclass eg a
>> listitem:
>>
>> class listitem extends component {
>> public imodel getmodel() { return (imodel)super.getmodel(); }
>> <== works like a charm
>> public void setmodel(imodel model) {..} <== woops, compilation error
>>
>> Name clash: The method setModel(IModel) of type ListItem has the
>> same erasure as
>> setModel(IModel) of type MarkupContainer but does not override it
>>
>> unfortunately the error makes sense and there is no way around it.
>> same goes for setmodelobject(). i think this makes this design variant
>> pretty useless. as long as we have the model coupled to component i
>> dont see a clean way of doing this :(
>>
>> class listitem extends component {
>> public imodel getmodel(..);
>> public void setmodel(imodel model);
>> }
>>
>> looks half baked and broken by design
>>
>> i would almost reconsider 1.4 and its scope and opt to include a model
>> decoupling (however and if that is possible) refactor in it. otherwise
>> i fear we will break the whole generics model again in 1.5 and users
>> will have to relearn how to use them with wicket.
>>
>> so as far as i can see, and this is only my opinion, our options are:
>>
>> continue 1.4 as it is now with fully typed components
>> remove component type but make the api ugly ( i will let matej explain )
>> attempt to fix 1.4 by decoupling model from component - 1.4 takes a
>> lot longer and is not a simple "drop-in/upgrade/whatever"
>>
>> thoughts and ideas?
>>
>> -igor
>>
>> -
>> 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]
Re: wicket generics
Hi Igor and others,
Great that you tried that out in practice!
On Sat, 07 Jun 2008, Igor Vaynberg wrote:
> class component {
> public void setmodel(imodel model) {...}
> public imodel getmodel();
> }
I was earlier trying out this variant:
public class Component {
public Component setModel(final IModel model) { ... }
public IModel getModel() { ... }
public Object getModelObject() { ... }
public Component setModelObject(final T object) { ... }
}
and as far as I can tell, this does not inhibit the same
problem with generified subclasses. E.g. this works
public class ListItem extends WebMarkupContainer {
@SuppressWarnings({"unchecked"})
@Override
public IModel getModel()
{
return (IModel) super.getModel();
}
@Override
public ListItem setModel(IModel model)
{
return (ListItem) super.setModel(model);
}
@SuppressWarnings({"unchecked"})
@Override
public T getModelObject()
{
return (T) super.getModelObject();
}
@Override
public Component setModelObject(T object)
{
return super.setModelObject(object);
}
...
}
The unchecked cast warning when casting Object to T in
getModelObject() is a bummer, but then again I didn't
even think that getModelObject() would be overriden in
the generified subclasses (I don't consider needing to do
Foo foo = (Foo) getModelObject() a problem). The same
goes for getModel().
> i would almost reconsider 1.4 and its scope and opt to include a model
> decoupling (however and if that is possible) refactor in it. otherwise
> i fear we will break the whole generics model again in 1.5 and users
> will have to relearn how to use them with wicket.
Model decoupling would mean removing the default IModel of
Component, that was discussed this week, right?
It seems like a great idea [1] on the longer run, but as far as
I understand, the idea was to
- drop 1.3 support when 1.4 comes out
- offer 1.4 as a drop-in replacement (except for Java 5
requirement) for 1.3 users
- leave API breaks for 1.5
...and I don't see how the decoupling could happen without
a big API break.
So then it would effectively mean continuing Wicket 1.3 (and
Java 1.4) support for longer?
> so as far as i can see, and this is only my opinion, our options are:
>
> continue 1.4 as it is now with fully typed components
> remove component type but make the api ugly ( i will let matej explain )
Matej, please explain :)
> attempt to fix 1.4 by decoupling model from component - 1.4 takes a
> lot longer and is not a simple "drop-in/upgrade/whatever"
Yet another option would be to address this only in 1.5, and
drop Component and IModel generics from 1.4 altogether.
Best wishes,
Timo
[1] The Component class has a lot of responsibilities, so
removing any of them, such as the default model handling, is
a step to the right direction.
--
Timo Rantalaiho
Reaktor Innovations Oyhttp://www.ri.fi/ >
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket generics
i dont think listitem#setmodel is restricted in your example.to T in ListItem
>public ListItem setModel(IModel model)
the first hides the T of ListItem so you might as well have
said setModel(IModel model)
-igor
On Sat, Jun 7, 2008 at 4:48 AM, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
> Hi Igor and others,
>
> Great that you tried that out in practice!
>
> On Sat, 07 Jun 2008, Igor Vaynberg wrote:
>> class component {
>> public void setmodel(imodel model) {...}
>> public imodel getmodel();
>> }
>
> I was earlier trying out this variant:
>
> public class Component {
>public Component setModel(final IModel model) { ... }
>public IModel getModel() { ... }
>public Object getModelObject() { ... }
>public Component setModelObject(final T object) { ... }
> }
>
> and as far as I can tell, this does not inhibit the same
> problem with generified subclasses. E.g. this works
>
> public class ListItem extends WebMarkupContainer {
>@SuppressWarnings({"unchecked"})
>@Override
>public IModel getModel()
>{
>return (IModel) super.getModel();
>}
>
>@Override
>public ListItem setModel(IModel model)
>{
>return (ListItem) super.setModel(model);
>}
>
>@SuppressWarnings({"unchecked"})
>@Override
>public T getModelObject()
>{
>return (T) super.getModelObject();
>}
>
>@Override
>public Component setModelObject(T object)
>{
>return super.setModelObject(object);
>}
> ...
> }
>
> The unchecked cast warning when casting Object to T in
> getModelObject() is a bummer, but then again I didn't
> even think that getModelObject() would be overriden in
> the generified subclasses (I don't consider needing to do
> Foo foo = (Foo) getModelObject() a problem). The same
> goes for getModel().
>
>> i would almost reconsider 1.4 and its scope and opt to include a model
>> decoupling (however and if that is possible) refactor in it. otherwise
>> i fear we will break the whole generics model again in 1.5 and users
>> will have to relearn how to use them with wicket.
>
> Model decoupling would mean removing the default IModel of
> Component, that was discussed this week, right?
>
> It seems like a great idea [1] on the longer run, but as far as
> I understand, the idea was to
> - drop 1.3 support when 1.4 comes out
> - offer 1.4 as a drop-in replacement (except for Java 5
> requirement) for 1.3 users
> - leave API breaks for 1.5
>
> ...and I don't see how the decoupling could happen without
> a big API break.
>
> So then it would effectively mean continuing Wicket 1.3 (and
> Java 1.4) support for longer?
>
>> so as far as i can see, and this is only my opinion, our options are:
>>
>> continue 1.4 as it is now with fully typed components
>> remove component type but make the api ugly ( i will let matej explain )
>
> Matej, please explain :)
>
>> attempt to fix 1.4 by decoupling model from component - 1.4 takes a
>> lot longer and is not a simple "drop-in/upgrade/whatever"
>
> Yet another option would be to address this only in 1.5, and
> drop Component and IModel generics from 1.4 altogether.
>
> Best wishes,
> Timo
>
>
> [1] The Component class has a lot of responsibilities, so
> removing any of them, such as the default model handling, is
> a step to the right direction.
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oyhttp://www.ri.fi/ >
>
> -
> 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]
Re: wicket generics
On Sat, 07 Jun 2008, Igor Vaynberg wrote: > i dont think listitem#setmodel is restricted in your example.to T in > ListItem > > >public ListItem setModel(IModel model) > > the first hides the T of ListItem so you might as well have > said setModel(IModel model) Heh, you're right of course. There doesn't seem to be an easy way out, if you want to bind the type of the component with the type of its model only in a part of the Component inheritance hierarchy. I still find loosening the model type checks also in parametrised subclasses of Component a viable alternative for 1.4 (with less reuse of type variable names than what I'm guilty of :)). That is if we want to provide a fairly compatible alternative for migrating from 1.3. But on longer term, decoupling IModel from Component might be the best thing to have come out of this generics episode. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket generics
I may be the dumb kid on the block, but why do we need to "override" setModel and getModel( ) once it has already been done in Component class? ( meaning just have it in component class and then let all subclasses use the same methods?) Am i missing something? Rick On Sat, Jun 7, 2008 at 2:49 PM, Timo Rantalaiho <[EMAIL PROTECTED]> wrote: > On Sat, 07 Jun 2008, Igor Vaynberg wrote: > > i dont think listitem#setmodel is restricted in your example.to T in > ListItem > > > > >public ListItem setModel(IModel model) > > > > the first hides the T of ListItem so you might as well have > > said setModel(IModel model) > > Heh, you're right of course. > > There doesn't seem to be an easy way out, if you want to > bind the type of the component with the type of its model > only in a part of the Component inheritance hierarchy. > > I still find loosening the model type checks also in > parametrised subclasses of Component a viable alternative > for 1.4 (with less reuse of type variable names than what > I'm guilty of :)). That is if we want to provide a fairly > compatible alternative for migrating from 1.3. > > But on longer term, decoupling IModel from Component might > be the best thing to have come out of this generics episode. > > Best wishes, > Timo > > -- > Timo Rantalaiho > Reaktor Innovations Oyhttp://www.ri.fi/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: wicket generics
If the subclass wants type safety (returning T rather than Object), then they would override getModelObject(). This is allowed because of Java's covariant return types feature. However, there's no such thing as covariant parameter types, so overriding the setter won't work. On Tue, Jun 10, 2008 at 9:54 AM, Ricky <[EMAIL PROTECTED]> wrote: > I may be the dumb kid on the block, but why do we need to "override" > setModel and getModel( ) once it has already been done in Component class? ( > meaning just have it in component class and then let all subclasses use the > same methods?) > > Am i missing something? > > Rick > > On Sat, Jun 7, 2008 at 2:49 PM, Timo Rantalaiho <[EMAIL PROTECTED]> > wrote: > >> On Sat, 07 Jun 2008, Igor Vaynberg wrote: >> > i dont think listitem#setmodel is restricted in your example.to T in >> ListItem >> > >> > >public ListItem setModel(IModel model) >> > >> > the first hides the T of ListItem so you might as well have >> > said setModel(IModel model) >> >> Heh, you're right of course. >> >> There doesn't seem to be an easy way out, if you want to >> bind the type of the component with the type of its model >> only in a part of the Component inheritance hierarchy. >> >> I still find loosening the model type checks also in >> parametrised subclasses of Component a viable alternative >> for 1.4 (with less reuse of type variable names than what >> I'm guilty of :)). That is if we want to provide a fairly >> compatible alternative for migrating from 1.3. >> >> But on longer term, decoupling IModel from Component might >> be the best thing to have come out of this generics episode. >> >> Best wishes, >> Timo >> >> -- >> Timo Rantalaiho >> Reaktor Innovations Oyhttp://www.ri.fi/ > >> >> - >> 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]
Re: wicket generics
Hi, if the consequences are a cleaner api then I think to decouple the model is right. The migration for older code may be hard. But I think it will be worth it when the new code base is more robust. -- View this message in context: http://www.nabble.com/wicket-generics-tp17706107p17757524.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket generics
I don't know if i was clear enough, sorry about that.
I meant if you have something like :
public Component, ID extends Serializable>{
// getter here
public MODEL getModel() { }
// setter here
public void setModel(final MODEL model){ }
}
then, you don't have to do anything, basically all your components like for
example listItem would be :
public ListItem,ID extends Serializable> extends
Component{
// DONT need to override anything here!!!
}
Instead of capture i used an ID, because it makes more sense to have a model
generically typed to a serializable id.
Just some thoughts.
Rick
Re: wicket generics
which is exactly what we are trying to avoid - having generics in Component.
-Matej
On Tue, Jun 10, 2008 at 6:19 PM, Ricky <[EMAIL PROTECTED]> wrote:
> I don't know if i was clear enough, sorry about that.
>
> I meant if you have something like :
>
> public Component, ID extends Serializable>{
>
> // getter here
> public MODEL getModel() { }
>
> // setter here
> public void setModel(final MODEL model){ }
>
> }
>
> then, you don't have to do anything, basically all your components like for
> example listItem would be :
>
> public ListItem,ID extends Serializable> extends
> Component{
>
>
> // DONT need to override anything here!!!
>
> }
>
>
> Instead of capture i used an ID, because it makes more sense to have a model
> generically typed to a serializable id.
> Just some thoughts.
>
> Rick
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket generics
Hmmph, a weird fact to consider though is that when you are
"Non-generifying" the Component class, it doesn't make sense as to why one
would have XXComponent be generically typed to something, like a 'T' which
is also generic type for IModel, I mean the whole idea is to de-couple the
component class with the IModel in the first place; by keeping component
different from its children would "infer" from users standpoint at least
that children are somehow different.
I don't know just a thought.
Rick
On Tue, Jun 10, 2008 at 12:23 PM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> which is exactly what we are trying to avoid - having generics in
> Component.
>
> -Matej
>
> On Tue, Jun 10, 2008 at 6:19 PM, Ricky <[EMAIL PROTECTED]> wrote:
> > I don't know if i was clear enough, sorry about that.
> >
> > I meant if you have something like :
> >
> > public Component, ID extends Serializable>{
> >
> > // getter here
> > public MODEL getModel() { }
> >
> > // setter here
> > public void setModel(final MODEL model){ }
> >
> > }
> >
> > then, you don't have to do anything, basically all your components like
> for
> > example listItem would be :
> >
> > public ListItem,ID extends Serializable> extends
> > Component{
> >
> >
> > // DONT need to override anything here!!!
> >
> > }
> >
> >
> > Instead of capture i used an ID, because it makes more sense to have a
> model
> > generically typed to a serializable id.
> > Just some thoughts.
> >
> > Rick
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: SV: generics
I agree completely. - Brill On 15-Jul-08, at 3:28 AM, Wilhelmsen Tor Iver wrote: Brill Pappin [EMAIL PROTECTED] wrote: I'd say that WIcket *is a product*, and as such the consumers of that product have the final say. Not any more than you can e.g. go to Ford Motor Co. and demand they make this and that modification to the design of the Mustang, for instance. Like most consumers your way of "saying" is to choose whether to buy/ use the product or not, and it falls on the developer/manufacturer to fuind out why you do or do not buy/use it. (Walton's famous "the customer is always right" has a corollary: If someone is wrong they simply is not a customer. :) ) It's up to the "core committers" to do the best job they can to make sure their "consumers" are getting what they need... Not unless you want to start paying them to do so, becoming their "boss" in the process. As they have pointed out, Wicket is not their job but their "hobby" of sorts. However: Since it is an OSS product you can download the source and modify it as much as you like (like I did when I applied the portlet 2.0 patch to the 1.3 and 1.4 trees locally), even creating your own fork of it if you so desire. You see, the "consumers" are also the potential workers in the OSS world: if only a group of users want a feature it falls on them to implement it. just because it's an OS project that we don't have to buy, doesn't mean that the project doesn't depend on people using it. It does, but if it does not suit people's need they will look elsewhere. There is a ton of web application frameworks out there to choose from. If you like the separation of template and code in Wicket, try looking into e.g. Facelets, which is JSF without the cursed mess called JSP. - 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]
Re: AutoCompleteTextField & Generics
nope. No problem for me. Try pasting here the problematic code On Mon, Oct 12, 2009 at 10:50 AM, Douglas Ferguson wrote: > Has anybody else had problems with AutoCompleteTextField and generics. > > It almost seems like I'm dealing with an eclipse bug. > > But basically if I call > > behavior.getChoices.add(xxx) it is always highlighted in red because, > I am restricted by the model use "T" but the list wants "? extends T". > > D/ > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- http://mapsdev.blogspot.com/ Marcelo Takeshi Fukushima - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Generics in components
Hi, I am still very very new to Java and Wicket of course too, so excuse me if this is a dumb question. I swiched my project to Wicket 1.4-rc4 now and got all these wonderful warnings about the "Raw types" of the components in my sources. Are there any examples that highlight the handling of the generic component types? I have no clue what type parameter I have to give a form component for example (no clue for other components too). Should it be the class of my model or anything else? For validators I tried to set base types (Integer, ..) and this worked. But still I have no clue if this is the right thing to do. Confused ... :) Regards, Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
new DropDownChoice ? -igor On Fri, Jun 12, 2009 at 6:06 AM, Martin Makundi wrote: > I have casting problem: > > dropDown = new DropDownChoice(, new > ChoiceRenderer(...)); > > dropDown.getChoiceRenderer().getDisplayValue(dropDown.getModelObject()); > <-- DOES NOT COMPILE > > Is this a wicket bug or bug in me? > > ** > Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
> new DropDownChoice ? Maybe ... ** Martin > > On Fri, Jun 12, 2009 at 6:06 AM, Martin > Makundi wrote: >> I have casting problem: >> >> dropDown = new DropDownChoice(, new >> ChoiceRenderer(...)); >> >> dropDown.getChoiceRenderer().getDisplayValue(dropDown.getModelObject()); >> <-- DOES NOT COMPILE >> >> Is this a wicket bug or bug in me? >> >> ** >> Martin >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
Just because the constructor is declared that way (with the ?) doesn't mean you have to declare your variables that way. On Jun 12, 2009 4:43 PM, "Martin Makundi" < martin.maku...@koodaripalvelut.com> wrote: > new DropDownChoice ? Maybe ... ** Martin > > On Fri, Jun 12, 2009 at 6:06 AM, Martin > Makundi< martin.maku...@koodaripalvelut.com> wrote: >>...
Re: Wicket generics?
declaration is not the problem. from what i remember from generics (I might be wrong), you're not allowed to instantiate "generically". you have to tell the compiler exactly what type you want. at runtime it has no idea about generics. On Sat, Jun 13, 2009 at 12:41 AM, James Carman wrote: > Just because the constructor is declared that way (with the ?) doesn't mean > you have to declare your variables that way. > > On Jun 12, 2009 4:43 PM, "Martin Makundi" < > martin.maku...@koodaripalvelut.com> wrote: > > > new DropDownChoice ? > > Maybe ... > > ** > Martin > > > > On Fri, Jun 12, 2009 at 6:06 AM, Martin > Makundi< > martin.maku...@koodaripalvelut.com> wrote: >>... > -- Cristi Manole Nova Creator Software www.novacreator.com
Re: Wicket generics?
But, the compiler only knows what you're allowed to do by the type of the variable. You do not need to declare your variables with the wildcards. On Fri, Jun 12, 2009 at 6:31 PM, Cristi Manole wrote: > declaration is not the problem. from what i remember from generics (I might > be wrong), you're not allowed to instantiate "generically". you have to tell > the compiler exactly what type you want. at runtime it has no idea about > generics. > > On Sat, Jun 13, 2009 at 12:41 AM, James Carman > wrote: > >> Just because the constructor is declared that way (with the ?) doesn't mean >> you have to declare your variables that way. >> >> On Jun 12, 2009 4:43 PM, "Martin Makundi" < >> martin.maku...@koodaripalvelut.com> wrote: >> >> > new DropDownChoice ? >> >> Maybe ... >> >> ** >> Martin >> >> > > On Fri, Jun 12, 2009 at 6:06 AM, Martin > Makundi< >> martin.maku...@koodaripalvelut.com> wrote: >>... >> > > > > -- > Cristi Manole > > Nova Creator Software > www.novacreator.com > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
No. The compiler does not allow. If DropDownChoice is of type then the problem is that it assumes that getChoiceRenderer() is also of type . Now at runtime, because of the wildcard, I do not know what class I have, and I absolutely cannot use the renderer. The only workaround is to cast the renderer into (which it actually is!!) and that works, but the warning remains. Tricky ** Martin 2009/6/13 James Carman : > But, the compiler only knows what you're allowed to do by the type of > the variable. You do not need to declare your variables with the > wildcards. > > On Fri, Jun 12, 2009 at 6:31 PM, Cristi Manole wrote: >> declaration is not the problem. from what i remember from generics (I might >> be wrong), you're not allowed to instantiate "generically". you have to tell >> the compiler exactly what type you want. at runtime it has no idea about >> generics. >> >> On Sat, Jun 13, 2009 at 12:41 AM, James Carman >> wrote: >> >>> Just because the constructor is declared that way (with the ?) doesn't mean >>> you have to declare your variables that way. >>> >>> On Jun 12, 2009 4:43 PM, "Martin Makundi" < >>> martin.maku...@koodaripalvelut.com> wrote: >>> >>> > new DropDownChoice ? >>> >>> Maybe ... >>> >>> ** >>> Martin >>> >>> > > On Fri, Jun 12, 2009 at 6:06 AM, Martin > Makundi< >>> martin.maku...@koodaripalvelut.com> wrote: >>... >>> >> >> >> >> -- >> Cristi Manole >> >> Nova Creator Software >> www.novacreator.com >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
No casting is required. Try this:
BaseClass baseObject = null;
DropDownChoice dropDown = new DropDownChoice("id");
dropDown.getChoiceRenderer().getDisplayValue(null);
This will compile (it won't run because you'll get an NPE if the
display value method doesn't accept null). As I said, you don't have
to declare your local variable "dropDown" with type variable
wildcards.
On Sat, Jun 13, 2009 at 6:23 AM, Martin
Makundi wrote:
> No. The compiler does not allow. If DropDownChoice is of type extends BaseClass> then the problem is that it assumes that
> getChoiceRenderer() is also of type . Now at
> runtime, because of the wildcard, I do not know what class I have, and
> I absolutely cannot use the renderer. The only workaround is to cast
> the renderer into (which it actually is!!) and that works,
> but the warning remains.
>
> Tricky
>
> **
> Martin
>
> 2009/6/13 James Carman :
>> But, the compiler only knows what you're allowed to do by the type of
>> the variable. You do not need to declare your variables with the
>> wildcards.
>>
>> On Fri, Jun 12, 2009 at 6:31 PM, Cristi Manole wrote:
>>> declaration is not the problem. from what i remember from generics (I might
>>> be wrong), you're not allowed to instantiate "generically". you have to tell
>>> the compiler exactly what type you want. at runtime it has no idea about
>>> generics.
>>>
>>> On Sat, Jun 13, 2009 at 12:41 AM, James Carman
>>> wrote:
>>>
>>>> Just because the constructor is declared that way (with the ?) doesn't mean
>>>> you have to declare your variables that way.
>>>>
>>>> On Jun 12, 2009 4:43 PM, "Martin Makundi" <
>>>> martin.maku...@koodaripalvelut.com> wrote:
>>>>
>>>> > new DropDownChoice ?
>>>>
>>>> Maybe ...
>>>>
>>>> **
>>>> Martin
>>>>
>>>> > > On Fri, Jun 12, 2009 at 6:06 AM, Martin > Makundi<
>>>> martin.maku...@koodaripalvelut.com> wrote: >>...
>>>>
>>>
>>>
>>>
>>> --
>>> Cristi Manole
>>>
>>> Nova Creator Software
>>> www.novacreator.com
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
Hi!
Yes.. this is true but not ideally consistent. More consistent would be
DropDownChoice dropDown = new DropDownChoice("id");
in such a way that dropDown.getChoiceRenderer() would be automatically
of type .
One solution would be to change the signature of DropDownChoice (and
selectchoices ...):
public class DropDownChoice extends into
public class DropDownChoice extends in such a manner that
DropDownChoice dropDown = new DropDownChoice("id");
and
DropDownChoice.getChoiceRenderer() : S
That would work... both ways?
**
Martin
2009/6/13 James Carman :
> No casting is required. Try this:
>
> BaseClass baseObject = null;
> DropDownChoice dropDown = new DropDownChoice("id");
> dropDown.getChoiceRenderer().getDisplayValue(null);
>
> This will compile (it won't run because you'll get an NPE if the
> display value method doesn't accept null). As I said, you don't have
> to declare your local variable "dropDown" with type variable
> wildcards.
>
>
>
> On Sat, Jun 13, 2009 at 6:23 AM, Martin
> Makundi wrote:
>> No. The compiler does not allow. If DropDownChoice is of type > extends BaseClass> then the problem is that it assumes that
>> getChoiceRenderer() is also of type . Now at
>> runtime, because of the wildcard, I do not know what class I have, and
>> I absolutely cannot use the renderer. The only workaround is to cast
>> the renderer into (which it actually is!!) and that works,
>> but the warning remains.
>>
>> Tricky
>>
>> **
>> Martin
>>
>> 2009/6/13 James Carman :
>>> But, the compiler only knows what you're allowed to do by the type of
>>> the variable. You do not need to declare your variables with the
>>> wildcards.
>>>
>>> On Fri, Jun 12, 2009 at 6:31 PM, Cristi Manole
>>> wrote:
>>>> declaration is not the problem. from what i remember from generics (I might
>>>> be wrong), you're not allowed to instantiate "generically". you have to
>>>> tell
>>>> the compiler exactly what type you want. at runtime it has no idea about
>>>> generics.
>>>>
>>>> On Sat, Jun 13, 2009 at 12:41 AM, James Carman
>>>> wrote:
>>>>
>>>>> Just because the constructor is declared that way (with the ?) doesn't
>>>>> mean
>>>>> you have to declare your variables that way.
>>>>>
>>>>> On Jun 12, 2009 4:43 PM, "Martin Makundi" <
>>>>> martin.maku...@koodaripalvelut.com> wrote:
>>>>>
>>>>> > new DropDownChoice ?
>>>>>
>>>>> Maybe ...
>>>>>
>>>>> **
>>>>> Martin
>>>>>
>>>>> > > On Fri, Jun 12, 2009 at 6:06 AM, Martin > Makundi<
>>>>> martin.maku...@koodaripalvelut.com> wrote: >>...
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cristi Manole
>>>>
>>>> Nova Creator Software
>>>> www.novacreator.com
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
On Sat, Jun 13, 2009 at 8:13 AM, Martin
Makundi wrote:
> Hi!
>
> Yes.. this is true but not ideally consistent. More consistent would be
>
> DropDownChoice dropDown = new DropDownChoice extends BaseClass>("id");
You can't instantiate with a wildcard type. That's not allowed by the
Java language.
>
> in such a way that dropDown.getChoiceRenderer() would be automatically
> of type .
>
> One solution would be to change the signature of DropDownChoice (and
> selectchoices ...):
>
> public class DropDownChoice extends into
>
> public class DropDownChoice extends in such a manner that
>
> DropDownChoice dropDown = new DropDownChoice extends BaseClass=T>("id");
> and
>
> DropDownChoice.getChoiceRenderer() : S
>
> That would work... both ways?
I, for one, would be -1 to such a change (non-binding of course). Why
do you need the ChoiceRenderer to support a specific subtype of
BaseClass? If you have a ChoiceRenderer (which is what you
get if you declare your variable as I suggest), you can pass it any
type that extends BaseClass. You do not need to declare your
variables with the wildcard. What consistency are you looking for?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
>> DropDownChoice dropDown = new DropDownChoice> extends BaseClass>("id");
>
> You can't instantiate with a wildcard type. That's not allowed by the
> Java language.
Ah yes... I'm getting confused myself. So the real problem is that I
instantiate new DropDownChoice("id") but the method
getChoiceRenderer() returns IChoiceRenderer()
which is impractical.
Now that's the problem.
**
Martin
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
On Sat, Jun 13, 2009 at 9:25 AM, Martin
Makundi wrote:
>>> DropDownChoice dropDown = new DropDownChoice>> extends BaseClass>("id");
>>
>> You can't instantiate with a wildcard type. That's not allowed by the
>> Java language.
>
> Ah yes... I'm getting confused myself. So the real problem is that I
> instantiate new DropDownChoice("id") but the method
> getChoiceRenderer() returns IChoiceRenderer()
> which is impractical.
>
> Now that's the problem.
That's not what it returns (at least not in trunk or rc4)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket generics?
OK, my own fault:
DropDownChoice ps = new
DropDownChoice() so the variable type spoils it.
**
Martin
2009/6/13 James Carman :
> On Sat, Jun 13, 2009 at 9:25 AM, Martin
> Makundi wrote:
DropDownChoice dropDown = new DropDownChoice>>> extends BaseClass>("id");
>>>
>>> You can't instantiate with a wildcard type. That's not allowed by the
>>> Java language.
>>
>> Ah yes... I'm getting confused myself. So the real problem is that I
>> instantiate new DropDownChoice("id") but the method
>> getChoiceRenderer() returns IChoiceRenderer()
>> which is impractical.
>>
>> Now that's the problem.
>
> That's not what it returns (at least not in trunk or rc4)
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Generics and SortableDataProvider
Hi, Working on my first application using 1.4.x and generics and have a question regarding the use of SortableDataProvider. Within my extensions of this class I quite commonly obtain the id of an object within the iterator method and then load the object via a LoadableDetchableModel within the model method. My question is how to implement such an approach using the new generic classes. For example, the generic model method has the signature public IModel model(T object) but using the id based approach I would pass in a Long and return a model containing my domain model. The signature assumes the method parameter and model returned operate on the same type. Anyone tell me what I'm missing or if my approach is flawed? Thanks, Jonny This email message and any attached files are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message is prohibited. If you are not the intended recipient, please inform the sender by reply email and destroy all copies of the original message and your reply. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator.
PropertyColumn and generics
I'm writing a custom BooleanChoiceFilteredPropertyColumn extends ChoiceFilteredPropertyColumn (on 1.4-m3). When implementing @Override public void populateItem(final Item cellItem, final String componentId, final IModel model) I get a warning about Item and IModel needing to be parameterized. Makes sense. But if I parameterize it, I get: Name clash: The method populateItem(Item>, String, IModel) of type BooleanChoiceFilteredPropertyColumn has the same erasure as populateItem(Item, String, IModel) of type PropertyColumn but does not override itBooleanChoiceFilteredPropertyColumn.java So it turns out that even though Item and IModel have been generified (as well as PropertyColumn), the signature of populateItem in PropertyColumn is still: public void populateItem(Item item, String componentId, IModel model) Shouldn't that be: public void populateItem(Item> item, String componentId, IModel model) , the way it is in ICellPopulator? Am I smoking or misunderstanding generics? Luke -- View this message in context: http://www.nabble.com/PropertyColumn-and-generics-tp20335170p20335170.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
inmethod-grid generics?
Hi- Is there any interest in making inmethod grid generic? I have a half-way implementation that makes IDataSource -- it does not make IQueryResult generic though. Is there anywhere to attach patches for inmethod-grid? I don't see anything on: http://wicketstuff.org/jira/secure/Dashboard.jspa thanks! ryan
Re: Generics question
Hi Linda,
You are assuming that
IModel>
is a subtype of
IModel>
In java this is not the case (even if Subgenre extends DomainObject).
You'll need an explicit cast to make this work:
IModel> castedModel =
(IModel>) subgenreModel;
Regards,
Erik.
Linda van der Pal wrote:
This is not really Wicket related, but I don't quite know where else
to ask this. The question is: why won't this compile?
// I define a model
IModel> subgenreModel = new
AbstractReadOnlyModel>() {
...
}
// Here I try to use the model
FieldSwitchPanel subgenrefield = *new
SubgenreFieldSwitchPanel("subgenre", subgenreModel);*
// This is the constructor for the class SubgenreFieldSwithcPanel
public SubgenreFieldSwitchPanel(String id, IModelDomainObject>> choices) {
...
}
// Subgenre extends DomainObject
public class Subgenre extends DomainObject{
...
}
The complaint is: The constructor SubgenreFieldSwitchPanel(String,
IModel>) is undefined.
Thanks,
Linda
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics question
This looks exactly like the DropDownChoice issue that has been debated
recently. See the comments in JIRA:
https://issues.apache.org/jira/browse/WICKET-2137
The problem is that IModel> doesn't work
as we intuitively expect it to. It won't match IModel>
(nor IModel> for that matter).
As suggested by James, the correct generic type to achieve what you
want to do would be: IModel>
Olivier
2009/3/13 Linda van der Pal :
> This is not really Wicket related, but I don't quite know where else to ask
> this. The question is: why won't this compile?
>
> // I define a model
> IModel> subgenreModel = new
> AbstractReadOnlyModel>() {
> ...
> }
>
> // Here I try to use the model
> FieldSwitchPanel subgenrefield = *new SubgenreFieldSwitchPanel("subgenre",
> subgenreModel);*
>
>
> // This is the constructor for the class SubgenreFieldSwithcPanel
> public SubgenreFieldSwitchPanel(String id, IModel DomainObject>> choices) {
> ...
> }
>
>
> // Subgenre extends DomainObject
> public class Subgenre extends DomainObject{
> ...
> }
>
>
> The complaint is: The constructor SubgenreFieldSwitchPanel(String,
> IModel>) is undefined.
>
> Thanks,
> Linda
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics question
Thanks!
Erik van Oosten wrote:
Hi Linda,
You are assuming that
IModel>
is a subtype of
IModel>
In java this is not the case (even if Subgenre extends DomainObject).
You'll need an explicit cast to make this work:
IModel> castedModel =
(IModel>) subgenreModel;
Regards,
Erik.
Linda van der Pal wrote:
This is not really Wicket related, but I don't quite know where else
to ask this. The question is: why won't this compile?
// I define a model
IModel> subgenreModel = new
AbstractReadOnlyModel>() {
...
}
// Here I try to use the model
FieldSwitchPanel subgenrefield = *new
SubgenreFieldSwitchPanel("subgenre", subgenreModel);*
// This is the constructor for the class SubgenreFieldSwithcPanel
public SubgenreFieldSwitchPanel(String id, IModelDomainObject>> choices) {
...
}
// Subgenre extends DomainObject
public class Subgenre extends DomainObject{
...
}
The complaint is: The constructor SubgenreFieldSwitchPanel(String,
IModel>) is undefined.
Thanks,
Linda
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.278 / Virus Database: 270.11.13/1999 - Release Date: 03/13/09 05:59:00
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
DropDownChoice and generics
Hello,
the generics solution for the DropdownChoice is weird in my opinion.
I want to write like this:
List genders = getGenderList();
DropdownChoice new DropDownChoice("fieldId", new
PropertyModel(currentPerson, "gender"), genders);
But the compilation fails because of the mismatch between generics.
Actually how to solve such situations? Wicket's generic's are quite
weird in my opinion and I cannot understand them probably correctly...
I want to assign object(in my case Gender to Person) from the list via
PropertyModel to my object but cannot understand, how to do it. Did
not find even any examples from the manual.
Sigmar
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
inmethod-grid generics
Hi wicketers, I found inmethod-gric generics for wicket 1.5 on wicketstuff but can not find one for wicket 1.4.x. Is there any maven repo for 1.4.x? Thanks, Duy - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Page / WebPage Generics
Hi, Of course page will be generified, it's just a matter of time that Johan can invest in it :) -Matej On Tue, Apr 22, 2008 at 5:03 PM, Jeremy Thomerson <[EMAIL PROTECTED]> wrote: > Maybes it's simple and I missed it, but why don't Page and WebPage implement > generics? (Or maybe it's just coming in next milestone?) > > It would ensure that I don't pass an IModel to a page that needs an > IModel for it's model. Also, from any anonymous subclass of the page > where I'm doing MyPage.this.getModelObject(), I wouldn't need to cast. > > Thanks, > Jeremy Thomerson > -- Resizable and reorderable grid components. http://www.inmethod.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page / WebPage Generics
Thanks! I figured that must be it. On Tue, Apr 22, 2008 at 10:25 AM, Matej Knopp <[EMAIL PROTECTED]> wrote: > Hi, > > Of course page will be generified, it's just a matter of time that > Johan can invest in it :) > > -Matej > > On Tue, Apr 22, 2008 at 5:03 PM, Jeremy Thomerson > <[EMAIL PROTECTED]> wrote: > > Maybes it's simple and I missed it, but why don't Page and WebPage > implement > > generics? (Or maybe it's just coming in next milestone?) > > > > It would ensure that I don't pass an IModel to a page that needs > an > > IModel for it's model. Also, from any anonymous subclass of the > page > > where I'm doing MyPage.this.getModelObject(), I wouldn't need to cast. > > > > Thanks, > > Jeremy Thomerson > > > > > > -- > Resizable and reorderable grid components. > http://www.inmethod.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Page / WebPage Generics
done. On Tue, Apr 22, 2008 at 5:25 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > Hi, > > Of course page will be generified, it's just a matter of time that > Johan can invest in it :) > > -Matej > > On Tue, Apr 22, 2008 at 5:03 PM, Jeremy Thomerson > <[EMAIL PROTECTED]> wrote: > > Maybes it's simple and I missed it, but why don't Page and WebPage > implement > > generics? (Or maybe it's just coming in next milestone?) > > > > It would ensure that I don't pass an IModel to a page that needs > an > > IModel for it's model. Also, from any anonymous subclass of the > page > > where I'm doing MyPage.this.getModelObject(), I wouldn't need to cast. > > > > Thanks, > > Jeremy Thomerson > > > > > > -- > Resizable and reorderable grid components. > http://www.inmethod.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Page / WebPage Generics
Thank you! Thank you! On Tue, Apr 22, 2008 at 4:10 PM, Johan Compagner <[EMAIL PROTECTED]> wrote: > done. > > On Tue, Apr 22, 2008 at 5:25 PM, Matej Knopp <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > > Of course page will be generified, it's just a matter of time that > > Johan can invest in it :) > > > > -Matej > > > > On Tue, Apr 22, 2008 at 5:03 PM, Jeremy Thomerson > > <[EMAIL PROTECTED]> wrote: > > > Maybes it's simple and I missed it, but why don't Page and WebPage > > implement > > > generics? (Or maybe it's just coming in next milestone?) > > > > > > It would ensure that I don't pass an IModel to a page that needs > > an > > > IModel for it's model. Also, from any anonymous subclass of the > > page > > > where I'm doing MyPage.this.getModelObject(), I wouldn't need to > cast. > > > > > > Thanks, > > > Jeremy Thomerson > > > > > > > > > > > -- > > Resizable and reorderable grid components. > > http://www.inmethod.com > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
VOTE: Generics of IDataProvider
Hi,
I have a usecase where the current proposed generic Interface for IDataProvider
with upcoming v1.4 of Wicket would break the implementation concept working with
Wicket 1.3. The usecase needs different types for iterator + model. Example and
explanation are found below the vote:
VOTE:
[ ] IDataProvider
[ ] Iterator> , drop model
[ ] Leave as is.
Example:
new IDataProvider {
public Iterator iterator( int first, int count ) {
getForum().getTopics( first, count ); }
public int size() { getForum().getTopicsCount(); }
public IModel model( Integer id ) { return new TopicsDetachableModel(
id ); }
}
The current proposed IDataProvider would enforce model + iterator to be of
the same type, resulting in the above not working without hassle. I.e. either to
work without type safetey (always use Object to comply), or wrapping/querying
the type within iterator + model (which could cause time consuming lookups when
remote services are involved).
To get around this, there are 2 solutions:
- drop the 'model' method and have iterator return an Iterator>
That would fit this usecase since the Model could just be wrapped within
iterator and no extra lookups would be necessary. Implementation code of
iterator might get a bit uglier, though.
- add a second type as shown with example above
Would lead to "redundant" type definitions for many usecases where iterator +
model actually return the same type.
I'd really like to see support for generics with these cases as well.
Best regards, --- Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Wicket 1.4 and generics
I'm just now using 1.4. What type of thing is expected for T in WebPage ? It looks like what your model object is. But if your page doesn't use models (perhaps just it's children do), is the correct thing to do this? class MyPage extends WebPage I have lots of 'unchecked' and 'raw use' warnings now, so I'd like to know what the recommended approach is. Thanks, -Doug -- View this message in context: http://www.nabble.com/Wicket-1.4-and-generics-tp17115357p17115357.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.4 Generics
Doug Donohoe wrote: I just migrated to 1.4-M1 and converted all my classes to use the new generics support. It cleaned up my code quite nicely - I got to remove a lot of casting and cured many unchecked/raw messages. It also make the code much more readable - especially in list views, etc. Excellent work, Wicket team. -Doug has 1.4-m1 support spring ? i m about to start a wicket project, and if 1.4-m1 already supported spring i can give a shot. -andre- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.4 Generics
spring support has been there since 1.2, see wicket-spring and spring examples. -igor On Sun, May 11, 2008 at 8:10 PM, Andre Prasetya <[EMAIL PROTECTED]> wrote: > Doug Donohoe wrote: > > > I just migrated to 1.4-M1 and converted all my classes to use the new > > generics support. It cleaned up my code quite nicely - I got to remove a > > lot of casting and cured many unchecked/raw messages. > > > > It also make the code much more readable - especially in list views, etc. > > > > Excellent work, Wicket team. > > > > -Doug > > > > > has 1.4-m1 support spring ? i m about to start a wicket project, and if > 1.4-m1 already supported spring i can give a shot. > > -andre- > > > > - > 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]
Re: Wicket 1.4 Generics
usually there is a wicket-spring release for every wicket release, can I use wicket-spring 1.3.3 for 1.4-m1 or should i wait until there is a spesific release for 1.4-m1 ? -andre- Igor Vaynberg wrote: spring support has been there since 1.2, see wicket-spring and spring examples. -igor On Sun, May 11, 2008 at 8:10 PM, Andre Prasetya <[EMAIL PROTECTED]> wrote: Doug Donohoe wrote: I just migrated to 1.4-M1 and converted all my classes to use the new generics support. It cleaned up my code quite nicely - I got to remove a lot of casting and cured many unchecked/raw messages. It also make the code much more readable - especially in list views, etc. Excellent work, Wicket team. -Doug has 1.4-m1 support spring ? i m about to start a wicket project, and if 1.4-m1 already supported spring i can give a shot. -andre- - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.4 Generics
http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring/1.4-m1/ On Mon, May 12, 2008 at 8:02 AM, Andre Prasetya <[EMAIL PROTECTED]> wrote: > usually there is a wicket-spring release for every wicket release, can > I use wicket-spring 1.3.3 for 1.4-m1 or should i wait until there is a > spesific release for 1.4-m1 ? > > -andre- > > > > > Igor Vaynberg wrote: > > > spring support has been there since 1.2, see wicket-spring and spring > examples. > > > > -igor > > > > > > On Sun, May 11, 2008 at 8:10 PM, Andre Prasetya > > <[EMAIL PROTECTED]> wrote: > > > > > > > Doug Donohoe wrote: > > > > > > > > > > > > > I just migrated to 1.4-M1 and converted all my classes to use the new > > > > generics support. It cleaned up my code quite nicely - I got to > remove a > > > > lot of casting and cured many unchecked/raw messages. > > > > > > > > It also make the code much more readable - especially in list views, > etc. > > > > > > > > Excellent work, Wicket team. > > > > > > > > -Doug > > > > > > > > > > > > > > > > > > > has 1.4-m1 support spring ? i m about to start a wicket project, and if > > > 1.4-m1 already supported spring i can give a shot. > > > > > > -andre- > > > > > > > > > > > > - > > > 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] > > > > > > > > > > > - > 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]
Re: Wicket 1.4 Generics
merged On Mon, May 12, 2008 at 11:30 AM, Andre Prasetya <[EMAIL PROTECTED]> wrote: > thanks, how about the wicket-spring-annot ? > > http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring-annot/ > > is the 1.3.3 version compatible with the 1.4-m1 ? > > Frank Bille wrote: > > > http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring/1.4-m1/ > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Wicket 1.4 Generics
thanks, how about the wicket-spring-annot ? http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring-annot/ is the 1.3.3 version compatible with the 1.4-m1 ? Frank Bille wrote: http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring/1.4-m1/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.4 Generics
there is no need for a separate annots project since the entire codebase is now on java5, so annots was merged into wicket-spring -igor On Mon, May 12, 2008 at 2:30 AM, Andre Prasetya <[EMAIL PROTECTED]> wrote: > thanks, how about the wicket-spring-annot ? > > http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring-annot/ > > is the 1.3.3 version compatible with the 1.4-m1 ? > > > Frank Bille wrote: > > > http://repo1.maven.org/maven2/org/apache/wicket/wicket-spring/1.4-m1/ > > > > > > - > 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]
Re: Wicket 1.4 Generics
Thanks, I'm still new to Wicket, is there any examples in using 1.4 ? a best practices maybe ? -andre- Igor Vaynberg wrote: there is no need for a separate annots project since the entire codebase is now on java5, so annots was merged into wicket-spring -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.4 Generics
we have the wicket-examples project that demonstrates various components. you can browse live here http://wicketstuff.org/wicket13 wicket 1.4 is basically the same as wicket 1.3 but with generics support. -igor On Mon, May 12, 2008 at 9:53 PM, Andre Prasetya <[EMAIL PROTECTED]> wrote: > Thanks, I'm still new to Wicket, is there any examples in using 1.4 ? a best > practices maybe ? > > -andre- > > > Igor Vaynberg wrote: > > > there is no need for a separate annots project since the entire > > codebase is now on java5, so annots was merged into wicket-spring > > > > -igor > > > > > > - > 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]
Wicket 1.4 generics question
Hello there, I'm a Wicket Virgin (hm ;-) and have just started to look at Wicket 1.4. It seems something is wrong with the generics changes there. I have a page which itself has a model: a CompoundPropertyModel. Most basic Wicket components are generic: things like Label need a type parameter specifying the model (which by the way makes for very verbose coding). But the whole Page hierarchy gets defined hard as a MarkupContainer. This renders the setModel() calls on Page unusable because they in turn also expect IModel's, and not IModel. This makes it impossible to pass any Model into a Page-derived object without making use of a complex cast: setModel((IModel) (Object) new CompoundPropertyModel( bs)); This only works because of the utterly idiotic way that Generics are implemented in Java (type erasure; usability erasure would be a better name 8-(), and even there you need to watch out: Eclipse will silently remove the above cast and then generate a compilation error 8-( It looks like thinks like Page should also be generic (which looks like crap)... Or I'm doing something wrong, of course ;-) Frits -- DRM: Digital Restrictions Management -- learn about the dangers at http://www.defectivebydesign.org/what_is_drm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Generics for datatable columns
This is a stupid minor thing but I was wondering. If I have a datatable of SubClass objects, shouldn't a I be able to add an IColumn to the list of columns? Not very often used, but could be useful occasionally like for inheritance with domain entities. Couldn't hurt to implement this right (just add a generics wildcard)? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
inmethod grid generics patch
according to this post; http://tinyurl.com/qlghyf the inmethod grid it he wicketstuff modules was to get generics. I'm finding the missing generics a real pain in the behind but I also have a recent checkout of the 1.4-SNAPSHOT of wicketstuff, and it does not yet have generics. Does anyone know if this component has been abandoned or not? If I have to I'll go an add the generics myself, but if there is a copy out there that already has them I'd rather use that version. - Brill Pappin smime.p7s Description: S/MIME cryptographic signature
Re: Generics in components
On Mon, May 25, 2009 at 6:54 AM, Frank Tegtmeyer wrote: > Hi, > > I am still very very new to Java and Wicket of course too, > so excuse me if this is a dumb question. > > I swiched my project to Wicket 1.4-rc4 now and got all these > wonderful warnings about the "Raw types" of the components > in my sources. > Are there any examples that highlight the handling of > the generic component types? I have no clue what type parameter > I have to give a form component for example (no clue for other > components too). Should it be the class of my model or anything > else? For validators I tried to set base types (Integer, ..) > and this worked. But still I have no clue if this is the right > thing to do. > > Confused ... :) The type parameter on components is supposed to correspond to their model's type parameter. So, TextField would need an IModel. The Wicket test cases should have examples of this, if nothing else. Use the source, Luke. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Panel not using generics
hey, why does the panel is not using generics for type safety? regards -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics and SortableDataProvider
Hi John, I believe the consensus on this list is that you should change your approach: Why don't you just iterate over your domain objects in the first place? They will be loaded anyway to be displayed on your component. So your approach triggers 1+n selects instead of 1 select for all required objects at once. Sven jonny.w...@fiveprime.com wrote: Hi, Working on my first application using 1.4.x and generics and have a question regarding the use of SortableDataProvider. Within my extensions of this class I quite commonly obtain the id of an object within the iterator method and then load the object via a LoadableDetchableModel within the model method. My question is how to implement such an approach using the new generic classes. For example, the generic model method has the signature public IModel model(T object) but using the id based approach I would pass in a Long and return a model containing my domain model. The signature assumes the method parameter and model returned operate on the same type. Anyone tell me what I'm missing or if my approach is flawed? Thanks, Jonny This email message and any attached files are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message is prohibited. If you are not the intended recipient, please inform the sender by reply email and destroy all copies of the original message and your reply. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics and SortableDataProvider
Hi Sven, Thanks for your reply. Since I sent the original question I ended up doing what you suggested and now I'm wondering why I ever used the id projection approach. Habit I guess, formed with previous frameworks. Just to make sure I've got this right, as long as I use a DetachableModel as a return from model method, the domain objects aren't stored in the session even if they are returned from the iterator. Am I correct in this? Jonny svenmeier wrote: > > Hi John, > > I believe the consensus on this list is that you should change your > approach: > > Why don't you just iterate over your domain objects in the first place? > They will be loaded anyway to be displayed on your component. So your > approach triggers 1+n selects instead of 1 select for all required > objects at once. > > Sven > -- View this message in context: http://www.nabble.com/Generics-and-SortableDataProvider-tp25757590p25761751.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics and SortableDataProvider
Hi Jonny, yes, it works exactly like you described it. Sven jwray wrote: Hi Sven, Thanks for your reply. Since I sent the original question I ended up doing what you suggested and now I'm wondering why I ever used the id projection approach. Habit I guess, formed with previous frameworks. Just to make sure I've got this right, as long as I use a DetachableModel as a return from model method, the domain objects aren't stored in the session even if they are returned from the iterator. Am I correct in this? Jonny svenmeier wrote: Hi John, I believe the consensus on this list is that you should change your approach: Why don't you just iterate over your domain objects in the first place? They will be loaded anyway to be displayed on your component. So your approach triggers 1+n selects instead of 1 select for all required objects at once. Sven - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PropertyColumn and generics
And while we're on the subject, why is ChoiceFilteredPropertyColumn's constructor declared as public ChoiceFilteredPropertyColumn(IModel displayModel, String sortProperty, String propertyExpression, IModel> filterChoices) Why must filterChoices be a list of the parameterized type? What about the case where I might want a custom filter and pass in a List, for example? Luke Luke Ma wrote: > > I'm writing a custom BooleanChoiceFilteredPropertyColumn extends > ChoiceFilteredPropertyColumn (on 1.4-m3). When implementing > > @Override > public void populateItem(final Item cellItem, final String componentId, > final IModel model) > > I get a warning about Item and IModel needing to be parameterized. Makes > sense. But if I parameterize it, I get: > > Name clash: The method populateItem(Item>, String, > IModel) of type BooleanChoiceFilteredPropertyColumn has the same > erasure as populateItem(Item, String, IModel) of type PropertyColumn > but does not override it BooleanChoiceFilteredPropertyColumn.java > > So it turns out that even though Item and IModel have been generified (as > well as PropertyColumn), the signature of populateItem in PropertyColumn > is still: > > public void populateItem(Item item, String componentId, IModel model) > > Shouldn't that be: > > public void populateItem(Item> item, String > componentId, IModel model) > > , the way it is in ICellPopulator? Am I smoking or misunderstanding > generics? > > Luke > -- View this message in context: http://www.nabble.com/PropertyColumn-and-generics-tp20335170p20335387.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
a question regarding generics
Hi, We use at work Wicket 1.3.4 (going to 1.3.5) soon so we don't have any generic issue. I've created a Wicket project at home with 1.4_rc2 just to check it out (and do some testings). I've created a From and it asks for which is the model object type. I checked some discussions, especially http://www.nabble.com/generics-to18083910.html#a18083910 . But I bit confused. As I understand, if I have a bean that will be used in a CompoundPropertyModel, then I should put this as the T parameter, right? If I don't use a special model or a type in that model, what should I put? 'Object'? It's very easy for me to understand the generics for the IModel, but for the component, I'm still lost. I know it was discussed many time, but I would thank for any comment. Eyal Golan egola...@gmail.com Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74 P Save a tree. Please don't print this e-mail unless it's really necessary
Re: DropDownChoice and generics
> List genders = getGenderList();
> DropdownChoice new DropDownChoice("fieldId", new
> PropertyModel(currentPerson, "gender"), genders);
The class type parameter for the dropdown and models there should be Gender:
That the model delegates to a property in a Person object should not matter.
List genders = getGenderList();
DropdownChoice new DropDownChoice("fieldId", new
PropertyModel(currentPerson, "gender"), genders);
> I want to assign object(in my case Gender to Person
No, you want to set a Gender property in a Person object. But that the
PropertyModel uses a Person object is not something the dropdown really cares
about.
- Tor Iver
Re: DropDownChoice and generics
Hi,
IModel personModel = getPersonModel();
List genders = getGenderList();
DropDownChoice dropDownChoiceGender = new
DropDownChoice("genderFieldId", new PropertyModel(personModel,
"gender"), genderList);
Regards,
Bernard
On Thu, 2 Sep 2010 10:02:27 +0300, you wrote:
>Hello,
>the generics solution for the DropdownChoice is weird in my opinion.
>
>I want to write like this:
>
>List genders = getGenderList();
>DropdownChoice new DropDownChoice("fieldId", new
>PropertyModel(currentPerson, "gender"), genders);
>
>But the compilation fails because of the mismatch between generics.
>Actually how to solve such situations? Wicket's generic's are quite
>weird in my opinion and I cannot understand them probably correctly...
>
>I want to assign object(in my case Gender to Person) from the list via
>PropertyModel to my object but cannot understand, how to do it. Did
>not find even any examples from the manual.
>
>Sigmar
>
>-
>To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: inmethod-grid generics
Hi Duy, Generics were added only to the 1.5 branch of inmethod-grid. There is no plan to backport this to the 1.4 branch. Attila 2011/7/2 Duy Do > > Hi wicketers, > > I found inmethod-gric generics for wicket 1.5 on wicketstuff but can not > find one for wicket 1.4.x. Is there any maven repo for 1.4.x? > > Thanks, > Duy > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@wicket.**apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: inmethod-grid generics
Attila, thank you for your information. On 7/3/11 1:37 AM, Attila Király wrote: Hi Duy, Generics were added only to the 1.5 branch of inmethod-grid. There is no plan to backport this to the 1.4 branch. Attila 2011/7/2 Duy Do Hi wicketers, I found inmethod-gric generics for wicket 1.5 on wicketstuff but can not find one for wicket 1.4.x. Is there any maven repo for 1.4.x? Thanks, Duy --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
DataTable's FilterToolbar generics broken
I started migrating my code from wicket 1.4.19 to 6. Finally ! :) I found a FilterToolbar bug: Once you were able to create DataTable wrapped inside of FilterForm currently FilterToolbar requires you for those two types to be identical: public FilterToolbar(final DataTable table, final FilterForm form, final IFilterStateLocator stateLocator) It looks like commit 9b3f9ca1df064fe9c6fde64ccc37fecc504b09a6 introduced a bug long time ago and it carried on: - public FilterToolbar(final DataTable table, final FilterForm form, + public FilterToolbar(final DataTable table, final FilterForm form, FilterToolbar constructor should state: public FilterToolbar(final DataTable table, final FilterForm form, final IFilterStateLocator stateLocator) cheers. -- Leszek Gawron - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
SpringBean doesn't support Generics?
Spring 4 is able to wire/inject generic beans, as described here:
http://spring.io/blog/2013/12/03/spring-framework-4-0-and-java-generics .
However, I'm experiencing problems when using generic beans with Wicket's
SpringBean.
I basically have following situation, two concrete dao's that implement a
generic typed interface dao.:
class Product{}
class Car extends Product{}
class Phone extends Product{}
interface ProductDao {}
class CarProductDao implements ProductDao {}
class PhoneProductDao implements ProductDao {}
class ProductModel extends LoadableDetachableModel {
@SpringBean ProductDao productDao;
}
class ProductPage extends WebPage {
...
ProductModel model = new ProductModel(product);
...
}
This will result in the following error:
2015-jan-06;01:53:23.471 http-nio-8080-exec-6 WARN RequestCycleExtra -
Handling the following exception
java.lang.IllegalStateException: More than one bean of type [ProductDao]
found, you have to specify the name of the bean (@SpringBean(name="foo")) or
(@Named("foo") if using @javax.inject classes) in order to resolve this
conflict. Matched beans: carProductDao,phoneProductDao
at
org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getBeanNameOfClass(AnnotProxyFieldValueFactory.java:289)
~[AnnotProxyFieldValueFactory.class:6.18.0]
at
org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getBeanName(AnnotProxyFieldValueFactory.java:198)
~[AnnotProxyFieldValueFactory.class:6.18.0]
at
org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue(AnnotProxyFieldValueFactory.java:130)
~[AnnotProxyFieldValueFactory.class:6.18.0]
at org.apache.wicket.injection.Injector.inject(Injector.java:111)
~[Injector.class:6.18.0]
at
org.apache.wicket.spring.injection.annot.SpringComponentInjector.inject(SpringComponentInjector.java:124)
~[SpringComponentInjector.class:6.18.0]
at ProductModel.(ProductModel.java:20) ~[ProductModel.class:na]
at ProductPage$15.populateItem(ProductPage.java:742)
~[ProductPage$15.class:na]
Does Wicket's SpringBean support Spring-4's generics support?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/SpringBean-doesn-t-support-Generics-tp4668928.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: VOTE: Generics of IDataProvider
[ ] IDataProvider
[X] Iterator> , drop model
[ ] Leave as is.
Regards,
Sebastiaan
Jan Kriesten wrote:
Hi,
I have a usecase where the current proposed generic Interface for
IDataProvider with upcoming v1.4 of Wicket would break the
implementation concept working with Wicket 1.3. The usecase needs
different types for iterator + model. Example and explanation are found
below the vote:
VOTE:
[ ] IDataProvider
[ ] Iterator> , drop model
[ ] Leave as is.
Example:
new IDataProvider {
public Iterator iterator( int first, int count ) {
getForum().getTopics( first, count ); }
public int size() { getForum().getTopicsCount(); }
public IModel model( Integer id ) { return new
TopicsDetachableModel( id ); }
}
The current proposed IDataProvider would enforce model + iterator to
be of the same type, resulting in the above not working without hassle.
I.e. either to work without type safetey (always use Object to comply),
or wrapping/querying the type within iterator + model (which could cause
time consuming lookups when remote services are involved).
To get around this, there are 2 solutions:
- drop the 'model' method and have iterator return an Iterator>
That would fit this usecase since the Model could just be wrapped within
iterator and no extra lookups would be necessary. Implementation code of
iterator might get a bit uglier, though.
- add a second type as shown with example above
Would lead to "redundant" type definitions for many usecases where
iterator + model actually return the same type.
I'd really like to see support for generics with these cases as well.
Best regards, --- Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: VOTE: Generics of IDataProvider
[ ] IDataProvider
[X] Iterator> , drop model
[X] Leave as is.
I dont care much between those 2.
But i definitely dont like option 1, because your example gives me exact
the feeling why i dont want that
It gives the wrong idea to peoples mind. If they would do what you do,
Integer list of pks, and then in the model you get the Topics objects,
this would for most OR mapping tools be a real performance issue, and we get
the blame for that for being slow.
johan
On Thu, Apr 24, 2008 at 9:42 AM, Jan Kriesten <[EMAIL PROTECTED]>
wrote:
>
> Hi,
>
> I have a usecase where the current proposed generic Interface for
> IDataProvider with upcoming v1.4 of Wicket would break the implementation
> concept working with Wicket 1.3. The usecase needs different types for
> iterator + model. Example and explanation are found below the vote:
>
> VOTE:
>
>
>
>
> Example:
> new IDataProvider {
> public Iterator iterator( int first, int count ) {
> getForum().getTopics( first, count ); }
>
> public int size() { getForum().getTopicsCount(); }
>
> public IModel model( Integer id ) { return new
> TopicsDetachableModel( id ); }
> }
>
> The current proposed IDataProvider would enforce model + iterator to be
> of the same type, resulting in the above not working without hassle. I.e.
> either to work without type safetey (always use Object to comply), or
> wrapping/querying the type within iterator + model (which could cause time
> consuming lookups when remote services are involved).
>
> To get around this, there are 2 solutions:
>
> - drop the 'model' method and have iterator return an Iterator>
>
> That would fit this usecase since the Model could just be wrapped within
> iterator and no extra lookups would be necessary. Implementation code of
> iterator might get a bit uglier, though.
>
> - add a second type as shown with example above
>
> Would lead to "redundant" type definitions for many usecases where
> iterator + model actually return the same type.
>
>
> I'd really like to see support for generics with these cases as well.
>
> Best regards, --- Jan.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: VOTE: Generics of IDataProvider
[ ] IDataProvider [ X ] Iterator> , drop model [ ] Leave as is. Thijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Generics of IDataProvider
[ ] IDataProvider [X] Iterator> , drop model [X] Leave as is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Generics of IDataProvider
On 4/24/08, Jan Kriesten <[EMAIL PROTECTED]> wrote: > [ ] IDataProvider > [ ] Iterator> , drop model > [X] Leave as is. I don't see the additional benefit of removing the model method. It only breaks API for nothing much gained. Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Generics of IDataProvider
On Thu, Apr 24, 2008 at 3:42 AM, Jan Kriesten <[EMAIL PROTECTED]> wrote: > > Hi, > > I have a usecase where the current proposed generic Interface for > IDataProvider with upcoming v1.4 of Wicket would break the implementation > concept working with Wicket 1.3. The usecase needs different types for > iterator + model. Example and explanation are found below the vote: > > VOTE: > [ ] IDataProvider [X] Iterator> , drop model [X] Leave as is. I like the idea that the standard usecase is somewhat "enforced" by the interface. I agree that the integer -> object mapping usecase is not common and could lead to performance problems. However, I'm somewhat torn between the last two options. Having that model method there was somewhat confusing in the first place when I was learning about it, but that could just be because generics weren't there to begin with to make it a bit more clear. If we go with option #2, then we're basically putting the "modelizing" logic onto the user. But, if we stick with it the way that it is, we're taking care of "modelizing" each item in the iterator for them (by using their method of course). If 99% of the people are going to have to write a method (the iterator -> iterator> transforming method), then why not just do that stuff for them and allow them a bit to customize it (like the model method)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Generics of IDataProvider
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > [ ] IDataProvider > [ ] Iterator> , drop model > [X] Leave as is. - -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIEMpGAdpynRSGw3URAu9pAJ90tJ9KxN7Nppz5+FVfRVub5cg9bwCZAVnK ZtdjmI4yqNAonMvKYSJHqxY= =FedI -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Generics of IDataProvider
> VOTE: > > [ ] IDataProvider > [ ] Iterator> , drop model > [X] Leave as is. > > -Matej - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Generics of IDataProvider
I would have a better idea if I would have had the chance to actually play with it, but here is mine: [ ] IDataProvider [ x ] Iterator> , drop model [ ] Leave as is. Looks most elegant to me, and it is immediately clear what T is for. Also, I think that generics are bloody verbose anyway, so I'm not much in favor of shortening things up - and not support some of the use cases - for just this occasion. I rather have something that works for everyone. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: Generics of IDataProvider
[ ] IDataProvider [ x ] Iterator> , drop model [ ] Leave as is. Maarten On Fri, Apr 25, 2008 at 1:52 AM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > I would have a better idea if I would have had the chance to actually > play with it, but here is mine: > > [ ] IDataProvider > [ x ] Iterator> , drop model > [ ] Leave as is. > > Looks most elegant to me, and it is immediately clear what T is for. > Also, I think that generics are bloody verbose anyway, so I'm not much > in favor of shortening things up - and not support some of the use > cases - for just this occasion. I rather have something that works for > everyone. > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: VOTE: Generics of IDataProvider
[ ] IDataProvider
[x] Iterator> , drop model
[ ] Leave as is.
Leaving it as is just doesn't make sense as it doesn't support the use case
on hand.
Using IDataProvider is OK too. For those whose I == T, we can always
have a convenient base class:
abstract class ModelProvider implements IDataProvider {
IModel model(T object) {
return object;
}
}
Iterator> will make the interface simpler. For those who
need to wrap domain objects as models, we can provide a wrapper
iterator:
abstract class ModelWrapperIterator implements Iterator {
ModelWrapperIterator(Iterator source) {
...
}
abstract IModel map(T sourceElement);
}
-
--
Kent Tong
Wicket tutorials freely available at http://www.agileskills2.org/EWDW
Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA
--
View this message in context:
http://www.nabble.com/VOTE%3A-Generics-of-IDataProvider-tp16871723p16957615.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.4 and generics
I usually just use in such case. -Matej On Wed, May 7, 2008 at 11:40 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote: > > I'm just now using 1.4. What type of thing is expected for T in WebPage ? > > It looks like what your model object is. But if your page doesn't use > models (perhaps just it's children do), is the correct thing to do this? > > class MyPage extends WebPage > > I have lots of 'unchecked' and 'raw use' warnings now, so I'd like to know > what the recommended approach is. > > Thanks, > > -Doug > -- > View this message in context: > http://www.nabble.com/Wicket-1.4-and-generics-tp17115357p17115357.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Resizable and reorderable grid components. http://www.inmethod.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.4 and generics
You are correct, WebPage is for the model type of your page. This allows you to do MyObject getObject(), etc. I, too, am trying to deal with all of the generics warnings right now and figure out what my strategy will be for pages without a model. One suggestion that has been made on the list is for a page that does not use a model is to use Void, like this: class MyPage extends WebPage Jeremy Thomerson http://www.wickettraining.com On Wed, May 7, 2008 at 4:40 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote: > > I'm just now using 1.4. What type of thing is expected for T in > WebPage ? > > It looks like what your model object is. But if your page doesn't use > models (perhaps just it's children do), is the correct thing to do this? > > class MyPage extends WebPage > > I have lots of 'unchecked' and 'raw use' warnings now, so I'd like to know > what the recommended approach is. > > Thanks, > > -Doug > -- > View this message in context: > http://www.nabble.com/Wicket-1.4-and-generics-tp17115357p17115357.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Wicket 1.4 and generics
HTML gobbled my <Object> in that last message ... my proposed example was: class MyPage extends WebPage<Object> Doug Donohoe wrote: > > I'm just now using 1.4. What type of thing is expected for T in > WebPage ? > > It looks like what your model object is. But if your page doesn't use > models (perhaps just it's children do), is the correct thing to do this? > > class MyPage extends WebPage > > I have lots of 'unchecked' and 'raw use' warnings now, so I'd like to know > what the recommended approach is. > > Thanks, > > -Doug > -- View this message in context: http://www.nabble.com/Wicket-1.4-and-generics-tp17115357p17115478.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.4 generics question
page was not yet generified in m1, which is what i assume you are using. 1.4m2 will be out shortly where this has been corrected, and you can always use a snapshot. -igor On Sun, May 18, 2008 at 3:14 PM, Frits Jalvingh <[EMAIL PROTECTED]> wrote: > Hello there, > > I'm a Wicket Virgin (hm ;-) and have just started to look at Wicket 1.4. It > seems something is wrong with the generics changes there. I have a page which > itself has a model: a CompoundPropertyModel. Most basic Wicket > components are generic: things like Label need a type parameter specifying > the model (which by the way makes for very verbose coding). But the whole > Page hierarchy gets defined hard as a MarkupContainer. This renders > the setModel() calls on Page unusable because they in turn also expect > IModel's, and not IModel. This makes it impossible > to pass any Model into a Page-derived object without making use of a complex > cast: > > setModel((IModel) (Object) new CompoundPropertyModel( > bs)); > > This only works because of the utterly idiotic way that Generics are > implemented in Java (type erasure; usability erasure would be a better name > 8-(), and even there you need to watch out: Eclipse will silently remove the > above cast and then generate a compilation error 8-( > > It looks like thinks like Page should also be generic (which looks like > crap)... > > Or I'm doing something wrong, of course ;-) > > Frits > > -- > DRM: Digital Restrictions Management -- learn about the dangers at > http://www.defectivebydesign.org/what_is_drm > > - > 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]
Re: Wicket 1.4 generics question
But keep commenting - the idea of the milestones are to let people see the changes & feedback their thoughts on the generification & how it fits into the various use-cases beyond the one's we have... /Gwyn On Sun, May 18, 2008 at 11:32 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > page was not yet generified in m1, which is what i assume you are > using. 1.4m2 will be out shortly where this has been corrected, and > you can always use a snapshot. > > -igor > > > On Sun, May 18, 2008 at 3:14 PM, Frits Jalvingh <[EMAIL PROTECTED]> wrote: >> Hello there, >> >> I'm a Wicket Virgin (hm ;-) and have just started to look at Wicket 1.4. It >> seems something is wrong with the generics changes there. I have a page which >> itself has a model: a CompoundPropertyModel. Most basic Wicket >> components are generic: things like Label need a type parameter specifying >> the model (which by the way makes for very verbose coding). But the whole >> Page hierarchy gets defined hard as a MarkupContainer. This renders >> the setModel() calls on Page unusable because they in turn also expect >> IModel's, and not IModel. This makes it impossible >> to pass any Model into a Page-derived object without making use of a complex >> cast: >> >> setModel((IModel) (Object) new CompoundPropertyModel( >> bs)); >> >> This only works because of the utterly idiotic way that Generics are >> implemented in Java (type erasure; usability erasure would be a better name >> 8-(), and even there you need to watch out: Eclipse will silently remove the >> above cast and then generate a compilation error 8-( >> >> It looks like thinks like Page should also be generic (which looks like >> crap)... >> >> Or I'm doing something wrong, of course ;-) >> >> Frits >> >> -- >> DRM: Digital Restrictions Management -- learn about the dangers at >> http://www.defectivebydesign.org/what_is_drm >> >> - >> 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inmethod grid generics patch
Hi, it's not abandoned. There's a project created for it in wicketstuff jira that can be used to submit patches. -Matej On Fri, May 8, 2009 at 11:49 PM, Brill Pappin wrote: > according to this post; > > http://tinyurl.com/qlghyf > > the inmethod grid it he wicketstuff modules was to get generics. > > I'm finding the missing generics a real pain in the behind but I also have a > recent checkout of the 1.4-SNAPSHOT of wicketstuff, and it does not yet have > generics. > > Does anyone know if this component has been abandoned or not? > If I have to I'll go an add the generics myself, but if there is a copy out > there that already has them I'd rather use that version. > > - Brill Pappin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: inmethod grid generics patch
Found the patch, will assign it to jira issue. And possibly apply after review. -Matej On Fri, May 8, 2009 at 11:54 PM, Matej Knopp wrote: > Hi, > > it's not abandoned. There's a project created for it in wicketstuff > jira that can be used to submit patches. > > -Matej > > On Fri, May 8, 2009 at 11:49 PM, Brill Pappin wrote: >> according to this post; >> >> http://tinyurl.com/qlghyf >> >> the inmethod grid it he wicketstuff modules was to get generics. >> >> I'm finding the missing generics a real pain in the behind but I also have a >> recent checkout of the 1.4-SNAPSHOT of wicketstuff, and it does not yet have >> generics. >> >> Does anyone know if this component has been abandoned or not? >> If I have to I'll go an add the generics myself, but if there is a copy out >> there that already has them I'd rather use that version. >> >> - Brill Pappin > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: inmethod grid generics patch
That would be great! If you need an area to focus on, it's the generics that type things like getSelectedItems() etc. and some of the other common overrides. - Brill Pappin On 8-May-09, at 5:57 PM, Matej Knopp wrote: Found the patch, will assign it to jira issue. And possibly apply after review. -Matej On Fri, May 8, 2009 at 11:54 PM, Matej Knopp wrote: Hi, it's not abandoned. There's a project created for it in wicketstuff jira that can be used to submit patches. -Matej On Fri, May 8, 2009 at 11:49 PM, Brill Pappin wrote: according to this post; http://tinyurl.com/qlghyf the inmethod grid it he wicketstuff modules was to get generics. I'm finding the missing generics a real pain in the behind but I also have a recent checkout of the 1.4-SNAPSHOT of wicketstuff, and it does not yet have generics. Does anyone know if this component has been abandoned or not? If I have to I'll go an add the generics myself, but if there is a copy out there that already has them I'd rather use that version. - Brill Pappin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org smime.p7s Description: S/MIME cryptographic signature
Re: Panel not using generics
What's the meaning you want to attach to the "missing" generic parameter? Best, Ernesto On Wed, Sep 9, 2009 at 12:23 PM, Kurt Zitze wrote: > hey, > > why does the panel is not using generics for type safety? > > regards > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
