You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Igor Vaynberg <ig...@gmail.com> on 2008/06/24 07:12:31 UTC
generics
development of the 1.4 branch has been quiet lately, this is because
the core team has been busy working on an alternative way of
generifiing the framework. an early result of that effort can be found
here [1]. The key difference in [1] is that we have decoupled the
component from the type of the model.
here is the list of major differences:
(1) only components that use their model have a generic type
(components you are likely to call getmodel/getmodelobject on as a
user). so far these are link,form,formcomponent
subclasses,listview,listitem,(other repeaters will follow soon). this
allows for typesafety where it makes sense, and eliminates a ton of
noise from code. we will generify others upon request if a good
usecase is provided and we think it is widely applicable.
(2) non-generified components do not have IModel<T> get/setModel and T
get/setModelObject, instead they have IModel<?>get/setDefaultModel and
Object get/setDefaultModelObject. this clearly expresses that the
default component model is not tied to the type of component. this is
a bit of a pain from the code migration point of view, but we think is
worth the effort. generifyed components are free to implement the old
IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
see ListItem for an example.
basically we feel this is a much cleaner way then what is 1.4m2. this
is a call for confirmation/discussion from our user base. do try to
port a small project or a part of a larger project you are working on
to the [1] branch to see how the new api feels. if we do like this
more the new branch will be merged into what will be 1.4m3.
[1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
-igor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: generics
Posted by "Zappaterrini, Larry" <La...@fnis.com>.
I'm getting the same thing.
-----Original Message-----
From: Martin Funk [mailto:mafulafunk@googlemail.com]
Sent: Tuesday, June 24, 2008 10:42 AM
To: users@wicket.apache.org
Subject: Re: generics
> basically we feel this is a much cleaner way then what is 1.4m2. this
> is a call for confirmation/discussion from our user base. do try to
> port a small project or a part of a larger project you are working on
> to the [1] branch to see how the new api feels. if we do like this
> more the new branch will be merged into what will be 1.4m3.
>
> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>
>
am I the only one running into this:
mvn clean install
[...]
[INFO]
------------------------------------------------------------------------
[INFO] Building Wicket
[INFO] task-segment: [clean, install]
[INFO]
------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory /home/fnk64/tmp/generics/wicket/target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 748 source files to
/home/fnk64/tmp/generics/wicket/target/classes
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
/home/fnk64/tmp/generics/wicket/src/main/java/org/apache/wicket/markup/h
tml/list/ListItem.java:[90,42]
type parameters of <T>T cannot be determined; no unique maximal instance
exists for type variable T with upper bounds T,java.lang.Object
/home/fnk64/tmp/generics/wicket/src/main/java/org/apache/wicket/markup/h
tml/list/ListItem.java:[90,42]
type parameters of <T>T cannot be determined; no unique maximal instance
exists for type variable T with upper bounds T,java.lang.Object
[...]
though eclipse compiler doesn't complain
I'm running: javac -version
javac 1.5.0_15
uname -a
Linux fnk64-desktop 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC
2008 i686 GNU/Linux
on a current Kubuntu 8/04
mf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
______________
The information contained in this message is proprietary and/or confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition,
please be aware that any message addressed to our domain is subject to archiving and review by
persons other than the intended recipient. Thank you.
_____________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Martin Funk <ma...@googlemail.com>.
Igor Vaynberg wrote:
> should compile now, there maybe be some failing tests, but mvn clean
> install -Dmaven.test.skip=true works for sure
>
thnx, it compiles now
mf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Martin Funk <ma...@googlemail.com>.
Igor Vaynberg wrote:
> should compile now, there maybe be some failing tests, but mvn clean
> install -Dmaven.test.skip=true works for sure
>
thnx, it compiles now
mf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
should compile now, there maybe be some failing tests, but mvn clean
install -Dmaven.test.skip=true works for sure
-igor
On Tue, Jun 24, 2008 at 7:41 AM, Martin Funk <ma...@googlemail.com> wrote:
>
>> basically we feel this is a much cleaner way then what is 1.4m2. this
>> is a call for confirmation/discussion from our user base. do try to
>> port a small project or a part of a larger project you are working on
>> to the [1] branch to see how the new api feels. if we do like this
>> more the new branch will be merged into what will be 1.4m3.
>>
>> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>>
>>
>
> am I the only one running into this:
>
> mvn clean install
> [...]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Wicket
> [INFO] task-segment: [clean, install]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] [clean:clean]
> [INFO] Deleting directory /home/fnk64/tmp/generics/wicket/target
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Compiling 748 source files to
> /home/fnk64/tmp/generics/wicket/target/classes
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Compilation failure
> /home/fnk64/tmp/generics/wicket/src/main/java/org/apache/wicket/markup/html/list/ListItem.java:[90,42]
> type parameters of <T>T cannot be determined; no unique maximal instance
> exists for type variable T with upper bounds T,java.lang.Object
>
>
>
> /home/fnk64/tmp/generics/wicket/src/main/java/org/apache/wicket/markup/html/list/ListItem.java:[90,42]
> type parameters of <T>T cannot be determined; no unique maximal instance
> exists for type variable T with upper bounds T,java.lang.Object
> [...]
>
> though eclipse compiler doesn't complain
>
> I'm running: javac -version
> javac 1.5.0_15
>
> uname -a
> Linux fnk64-desktop 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 2008
> i686 GNU/Linux
>
> on a current Kubuntu 8/04
>
> mf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Martin Funk <ma...@googlemail.com>.
> basically we feel this is a much cleaner way then what is 1.4m2. this
> is a call for confirmation/discussion from our user base. do try to
> port a small project or a part of a larger project you are working on
> to the [1] branch to see how the new api feels. if we do like this
> more the new branch will be merged into what will be 1.4m3.
>
> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>
>
am I the only one running into this:
mvn clean install
[...]
[INFO]
------------------------------------------------------------------------
[INFO] Building Wicket
[INFO] task-segment: [clean, install]
[INFO]
------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory /home/fnk64/tmp/generics/wicket/target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 748 source files to
/home/fnk64/tmp/generics/wicket/target/classes
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
/home/fnk64/tmp/generics/wicket/src/main/java/org/apache/wicket/markup/html/list/ListItem.java:[90,42]
type parameters of <T>T cannot be determined; no unique maximal instance
exists for type variable T with upper bounds T,java.lang.Object
/home/fnk64/tmp/generics/wicket/src/main/java/org/apache/wicket/markup/html/list/ListItem.java:[90,42]
type parameters of <T>T cannot be determined; no unique maximal instance
exists for type variable T with upper bounds T,java.lang.Object
[...]
though eclipse compiler doesn't complain
I'm running: javac -version
javac 1.5.0_15
uname -a
Linux fnk64-desktop 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC
2008 i686 GNU/Linux
on a current Kubuntu 8/04
mf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Lauri Piispanen <la...@conmio.com>.
igor.vaynberg wrote:
>
> so now you have to do new
> DataView<Void,Foo> 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<T> extends AbstractPageableView<T>
{
public <K> DataViewBase(String id, IDataProvider<K> dataProvider)
{
...snip...
}
...snip...
private static final class ModelIterator<K> implements Iterator<IModel<K>>
{
...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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
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<Foo> and it will expect IDataProvider<Foo> 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<foo> 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<Void,Foo> 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 <js...@yahoo.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by JulianS <js...@yahoo.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Stefan Simik <st...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Martijn Dashorst <ma...@gmail.com>.
Unfortunately I get a build error (not the aforementioned compile
error, something different) so I'm not able to build tonight.
martijn
On Tue, Jun 24, 2008 at 5:23 PM, Martijn Dashorst
<ma...@gmail.com> wrote:
> I can try to do so later this evening (after I've done my duties for
> Wicket in Action)
>
> Martijn
>
> On Tue, Jun 24, 2008 at 5:21 PM, Brill Pappin <br...@pappin.ca> wrote:
>> I personally don't mind changes that cause me migration pain if they
>> actually make it better. I'm looking forward to trying it out.
>> Would it be possible to deploy the snapshots some place so I don't have to
>> go through the build pain?
>>
>> - Brill Pappin
>>
>> On 24-Jun-08, at 1:12 AM, Igor Vaynberg wrote:
>>
>>> development of the 1.4 branch has been quiet lately, this is because
>>> the core team has been busy working on an alternative way of
>>> generifiing the framework. an early result of that effort can be found
>>> here [1]. The key difference in [1] is that we have decoupled the
>>> component from the type of the model.
>>>
>>> here is the list of major differences:
>>>
>>> (1) only components that use their model have a generic type
>>> (components you are likely to call getmodel/getmodelobject on as a
>>> user). so far these are link,form,formcomponent
>>> subclasses,listview,listitem,(other repeaters will follow soon). this
>>> allows for typesafety where it makes sense, and eliminates a ton of
>>> noise from code. we will generify others upon request if a good
>>> usecase is provided and we think it is widely applicable.
>>>
>>> (2) non-generified components do not have IModel<T> get/setModel and T
>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
>>> Object get/setDefaultModelObject. this clearly expresses that the
>>> default component model is not tied to the type of component. this is
>>> a bit of a pain from the code migration point of view, but we think is
>>> worth the effort. generifyed components are free to implement the old
>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>>> see ListItem for an example.
>>>
>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>>> is a call for confirmation/discussion from our user base. do try to
>>> port a small project or a part of a larger project you are working on
>>> to the [1] branch to see how the new api feels. if we do like this
>>> more the new branch will be merged into what will be 1.4m3.
>>>
>>> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>>>
>>> -igor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Martijn Dashorst <ma...@gmail.com>.
I can try to do so later this evening (after I've done my duties for
Wicket in Action)
Martijn
On Tue, Jun 24, 2008 at 5:21 PM, Brill Pappin <br...@pappin.ca> wrote:
> I personally don't mind changes that cause me migration pain if they
> actually make it better. I'm looking forward to trying it out.
> Would it be possible to deploy the snapshots some place so I don't have to
> go through the build pain?
>
> - Brill Pappin
>
> On 24-Jun-08, at 1:12 AM, Igor Vaynberg wrote:
>
>> development of the 1.4 branch has been quiet lately, this is because
>> the core team has been busy working on an alternative way of
>> generifiing the framework. an early result of that effort can be found
>> here [1]. The key difference in [1] is that we have decoupled the
>> component from the type of the model.
>>
>> here is the list of major differences:
>>
>> (1) only components that use their model have a generic type
>> (components you are likely to call getmodel/getmodelobject on as a
>> user). so far these are link,form,formcomponent
>> subclasses,listview,listitem,(other repeaters will follow soon). this
>> allows for typesafety where it makes sense, and eliminates a ton of
>> noise from code. we will generify others upon request if a good
>> usecase is provided and we think it is widely applicable.
>>
>> (2) non-generified components do not have IModel<T> get/setModel and T
>> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
>> Object get/setDefaultModelObject. this clearly expresses that the
>> default component model is not tied to the type of component. this is
>> a bit of a pain from the code migration point of view, but we think is
>> worth the effort. generifyed components are free to implement the old
>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>> see ListItem for an example.
>>
>> basically we feel this is a much cleaner way then what is 1.4m2. this
>> is a call for confirmation/discussion from our user base. do try to
>> port a small project or a part of a larger project you are working on
>> to the [1] branch to see how the new api feels. if we do like this
>> more the new branch will be merged into what will be 1.4m3.
>>
>> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>>
>> -igor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Brill Pappin <br...@pappin.ca>.
I personally don't mind changes that cause me migration pain if they
actually make it better. I'm looking forward to trying it out.
Would it be possible to deploy the snapshots some place so I don't
have to go through the build pain?
- Brill Pappin
On 24-Jun-08, at 1:12 AM, Igor Vaynberg wrote:
> development of the 1.4 branch has been quiet lately, this is because
> the core team has been busy working on an alternative way of
> generifiing the framework. an early result of that effort can be found
> here [1]. The key difference in [1] is that we have decoupled the
> component from the type of the model.
>
> here is the list of major differences:
>
> (1) only components that use their model have a generic type
> (components you are likely to call getmodel/getmodelobject on as a
> user). so far these are link,form,formcomponent
> subclasses,listview,listitem,(other repeaters will follow soon). this
> allows for typesafety where it makes sense, and eliminates a ton of
> noise from code. we will generify others upon request if a good
> usecase is provided and we think it is widely applicable.
>
> (2) non-generified components do not have IModel<T> get/setModel and T
> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
> Object get/setDefaultModelObject. this clearly expresses that the
> default component model is not tied to the type of component. this is
> a bit of a pain from the code migration point of view, but we think is
> worth the effort. generifyed components are free to implement the old
> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
> see ListItem for an example.
>
> basically we feel this is a much cleaner way then what is 1.4m2. this
> is a call for confirmation/discussion from our user base. do try to
> port a small project or a part of a larger project you are working on
> to the [1] branch to see how the new api feels. if we do like this
> more the new branch will be merged into what will be 1.4m3.
>
> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>
> -igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Johan Compagner <jc...@gmail.com>.
On Mon, Jul 14, 2008 at 10:44 PM, Eelco Hillenius <ee...@gmail.com>
wrote:
> > personally i am still in favor of going with the m2 way of doing things
> where
> > Component is generic, but from the looks of the discussion i think i may
> be
> > in the minority here.
>
> Looking at the people who reacted, that seems to be the case. But the
> reason why we ask people their opinion is of course to get an idea on
> what involved users think, so I hope the discussion is somewhat
> representative.
really??
I think if you do an exact count also of the real vote you be surprised
i think it is more 50/50... maybe 60/40
> So far, to me m3 looks like a good trade off that has the support of
> the whole team and a decent amount of users. I'm afraid we can't make
> everyone perfectly happy :-)
>
thats true
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
> personally i am still in favor of going with the m2 way of doing things where
> Component is generic, but from the looks of the discussion i think i may be
> in the minority here.
Looking at the people who reacted, that seems to be the case. But the
reason why we ask people their opinion is of course to get an idea on
what involved users think, so I hope the discussion is somewhat
representative.
> this kinda surprises me though because as i read the
> original generic discussion it sounded like most people supported
> Component<T>.
Well, the original discussion was more about whether to generify
Component in the first place. Because we got so many mixed reactions,
we looked for the third way, which is what m3 basically is.
So far, to me m3 looks like a good trade off that has the support of
the whole team and a decent amount of users. I'm afraid we can't make
everyone perfectly happy :-)
Cheers,
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Tue, 15 Jul 2008, David Leangen wrote:
> Normally, it shouldn't be necessary to have to use casting with
> generics. In fact, the idea is that if no casting is used (along with a
> few other constraints that I don't remember off hand), then the code is
> guaranteed to be type safe.
>
> In other words... something seems not quite right with the code above
> because of the cast.
>
>
> Sorry if I'm bringing up something already discussed. Like I said, I
> haven't really been following this thread.
Heh, it sure has :) You can easily check out the previous
discussions from Nabble
http://www.google.fi/search?q=wicket+nabble+generics&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
To put it short, we're looking for an option where Component
could live without the class level type parameter but IModel
would have it.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by David Leangen <wi...@leangen.net>.
Don't have time to update to 1.4 yet, so I haven't been following this
thread much, but I did see this go by:
> > 2) the wicket web site now suggests the following code for generic
> > components:
> >
> > @SuppressWarnings("unchecked")
> > public final T getModelObject()
> > {
> > return (T)getDefaultModelObject();
> > }
Normally, it shouldn't be necessary to have to use casting with
generics. In fact, the idea is that if no casting is used (along with a
few other constraints that I don't remember off hand), then the code is
guaranteed to be type safe.
In other words... something seems not quite right with the code above
because of the cast.
Sorry if I'm bringing up something already discussed. Like I said, I
haven't really been following this thread.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by John Patterson <jd...@gmail.com>.
Craig McIlwee wrote:
>
> 2) the wicket web site now suggests the following code for generic
> components:
>
> @SuppressWarnings("unchecked")
> public final T getModelObject()
> {
> return (T)getDefaultModelObject();
> }
>
I am just starting to use the new form and it struck me as a little strange
that getModel() and its friends are not a part of any interface or abstract
class.
--
View this message in context: http://www.nabble.com/generics-tp18083910p18446636.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
> I'd say that WIcket *is a product*, and as such the consumers of that product have the final say.
I think closer to reality - the consumer's final say - is that when
people don't like the product anymore, they'll switch to alternatives
or - unique to open source software - create their own branches.
Obviously, we value the input of involved users highly, which is
exactly why we start up these discussions! :-)
> That said, I think that you guys have done some good work and have produced
> a good product with or without the generics.
Cheers,
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Johan Compagner <jc...@gmail.com>.
That discussion will not happen any time soon, first java 7 must be
released.. Then i guess 2+ or 3+ years will pass before java 7 is
widely used.
So i guess we can plan that discussion around 2011..
On 7/16/08, Ricky <ri...@gmail.com> wrote:
> orginally said by Martijn:
> We don't say that, but without the core committers, you won't have a
> framework. Treat us gently and you'll get a lot done. :D
>
> Ok, Please, can we generify components? :D
>
> I have already stated my opinion, but i think we should not really be
> bothered about generic notation, because anyways we will have some changes
> coming up in Java 7 and with closures (which will be useful to wicket imho),
> wicket HAS to change and use the new feature-set. At that point i know that
> there will again be a debate whether we want to go with newer feature set
> (especially closures etc) or not. Its just a matter of getting used to and
> once you do, you will know how "elegant" generification really is.
>
> Regards
> Vyas, Anirudh
> || ॐ ||
>
> On Tue, Jul 15, 2008 at 4:00 AM, Martijn Dashorst <
> martijn.dashorst@gmail.com> wrote:
>
>> You're right that 'slave' is too strong a word. I apologize.
>> Wilhelmsen Tor Iver reconstructed my intent much better.
>>
>> Martijn
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: generics
Posted by Ricky <ri...@gmail.com>.
orginally said by Martijn:
We don't say that, but without the core committers, you won't have a
framework. Treat us gently and you'll get a lot done. :D
Ok, Please, can we generify components? :D
I have already stated my opinion, but i think we should not really be
bothered about generic notation, because anyways we will have some changes
coming up in Java 7 and with closures (which will be useful to wicket imho),
wicket HAS to change and use the new feature-set. At that point i know that
there will again be a debate whether we want to go with newer feature set
(especially closures etc) or not. Its just a matter of getting used to and
once you do, you will know how "elegant" generification really is.
Regards
Vyas, Anirudh
|| ॐ ||
On Tue, Jul 15, 2008 at 4:00 AM, Martijn Dashorst <
martijn.dashorst@gmail.com> wrote:
> You're right that 'slave' is too strong a word. I apologize.
> Wilhelmsen Tor Iver reconstructed my intent much better.
>
> Martijn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: generics
Posted by Martijn Dashorst <ma...@gmail.com>.
You're right that 'slave' is too strong a word. I apologize.
Wilhelmsen Tor Iver reconstructed my intent much better.
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Brill Pappin <br...@pappin.ca>.
I'm not going to get into an argument on the definition of a product
or how the rules of supply and demand apply to Wicket. Those that
actually care about this thread can make up their own minds.
However I do object to being misrepresented. No where did I call you
folks "slaves", and don't believe that to be true in the least... I
didn't even allude to the concept.
I've been in your shoes as well and understand exactly why you do
it... from various angles.
- Brill Pappin
On 14-Jul-08, at 11:47 AM, Martijn Dashorst wrote:
> On Mon, Jul 14, 2008 at 5:36 PM, Brill Pappin <br...@pappin.ca> wrote:
>> I'd say that WIcket *is a product*, and as such the consumers of that
>> product have the final say.
>
> We build this in our spare time, and are customers ourselves. Wicket
> is not a product, it is an open source community. The definition of
> community is in the strictest sense defined as the core committers.
> They have to do the job, and won't do it when they don't see any
> benefit, or don't enjoy working on the project.
>
>> It's up to the "core committers" to do the best
>> job they can to make sure their "consumers" are getting what they
>> need...
>
> We are not your slaves. The Apache license explicitly states so:
>
> 7. Disclaimer of Warranty. Unless required by applicable law or agreed
> to in writing, Licensor provides the Work (and each Contributor
> provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR
> CONDITIONS OF ANY KIND, either express or implied, including, without
> limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT,
> MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely
> responsible for determining the appropriateness of using or
> redistributing the Work and assume any risks associated with Your
> exercise of permissions under this License.
>
>> 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.
>
> We don't say that, but without the core committers, you won't have a
> framework. Treat us gently and you'll get a lot done. :D
>
> Martijn
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Martijn Dashorst <ma...@gmail.com>.
On Mon, Jul 14, 2008 at 5:36 PM, Brill Pappin <br...@pappin.ca> wrote:
> I'd say that WIcket *is a product*, and as such the consumers of that
> product have the final say.
We build this in our spare time, and are customers ourselves. Wicket
is not a product, it is an open source community. The definition of
community is in the strictest sense defined as the core committers.
They have to do the job, and won't do it when they don't see any
benefit, or don't enjoy working on the project.
> It's up to the "core committers" to do the best
> job they can to make sure their "consumers" are getting what they need...
We are not your slaves. The Apache license explicitly states so:
7. Disclaimer of Warranty. Unless required by applicable law or agreed
to in writing, Licensor provides the Work (and each Contributor
provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR
CONDITIONS OF ANY KIND, either express or implied, including, without
limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT,
MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely
responsible for determining the appropriateness of using or
redistributing the Work and assume any risks associated with Your
exercise of permissions under this License.
> 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.
We don't say that, but without the core committers, you won't have a
framework. Treat us gently and you'll get a lot done. :D
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SV: generics
Posted by Brill Pappin <br...@pappin.ca>.
I agree completely.
- Brill
On 15-Jul-08, at 3:28 AM, Wilhelmsen Tor Iver wrote:
> Brill Pappin [brill@pappin.ca] 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
SV: generics
Posted by Wilhelmsen Tor Iver <To...@arrive.no>.
Brill Pappin [brill@pappin.ca] 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Brill Pappin <br...@pappin.ca>.
On 14-Jul-08, at 11:24 AM, Martijn Dashorst wrote:
> On Mon, Jul 14, 2008 at 5:03 PM, Brill Pappin <br...@pappin.ca> wrote:
>> I think you are *not* in the minority, but a lot of the dissenters
>> piped in
>> last minute in a big flood so to some it might look that way.
>
> I think this is a baseless statement: both sides have been very vocal.
> In any case this will not be a majority vote unless there is a 1-99%
> split, but even then: the core committers have the final say and it is
> their responsibility to move the project forward in the way they deem
> to be in the best interest of the framework. This doesn't say the
> wicket committers don't value your input, nor won't take it into
> account (lots of double negatives). In other words: we *do* value your
> input and feedback, and will take it into account, but the ultimate
> responsibility lies with the core committers.
I'd say that WIcket *is a product*, and as such the consumers of that
product have the final say. It's up to the "core committers" to do the
best job they can to make sure their "consumers" are getting what they
need... 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.
That said, I think that you guys have done some good work and have
produced a good product with or without the generics.
- Brill Pappin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Martijn Dashorst <ma...@gmail.com>.
On Mon, Jul 14, 2008 at 5:03 PM, Brill Pappin <br...@pappin.ca> wrote:
> I think you are *not* in the minority, but a lot of the dissenters piped in
> last minute in a big flood so to some it might look that way.
I think this is a baseless statement: both sides have been very vocal.
In any case this will not be a majority vote unless there is a 1-99%
split, but even then: the core committers have the final say and it is
their responsibility to move the project forward in the way they deem
to be in the best interest of the framework. This doesn't say the
wicket committers don't value your input, nor won't take it into
account (lots of double negatives). In other words: we *do* value your
input and feedback, and will take it into account, but the ultimate
responsibility lies with the core committers.
> However, It may actually be valuable the way they are doing it now, so I'm
> reserving judgement until I can sit down and port my latest project to it...
> and check out how well it works.
This is what we ask, so thanks and please provide feedback!
> The moment I have to do a cast, I'll consider it a sign that it needs more
> work.
This is what we propose: when you come across a point where generics
should be added, give us a note. We will take it into consideration,
just as we do with removing "final" in our code base.
Martijn
> On 14-Jul-08, at 10:17 AM, Craig McIlwee wrote:
>
>>
>> personally i am still in favor of going with the m2 way of doing things
>> where
>> Component is generic, but from the looks of the discussion i think i may
>> be
>> in the minority here. this kinda surprises me though because as i read
>> the
>> original generic discussion it sounded like most people supported
>> Component<T>.
>>
>>
>> igor.vaynberg wrote:
>>>
>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>>> is a call for confirmation/discussion from our user base.
>>>
>>
>> 1) i'm not sure i agree with this. i don't feel that just adding <Void>
>> to
>> components that don't need their models makes things messy. i'd much
>> rather
>> have the option to use generics whenever i need than to create extra
>> classes
>> such as the 'GenericPanel', etc that have been mentioned. in fact i think
>> its alot messier to create more classes and to start changing method names
>> (getDefaultModel, etc) and then adding getModel to the classes that do use
>> generics.
>>
>> 2) the wicket web site now suggests the following code for generic
>> components:
>>
>> @SuppressWarnings("unchecked")
>> public final T getModelObject()
>> {
>> return (T)getDefaultModelObject();
>> }
>>
>> ... but isn't the purpose of adding generic support to wicket to prevent
>> the
>> need for unchecked casts? if we now have to place unchecked casts into
>> our
>> code then we lose out on the strong type checking that generics are
>> supposed
>> to provide. its not hard to imagine a case where one part of someone's
>> code
>> calls setDefaultModelObject with the wrong type, and then later another
>> part
>> of the code calls getModelObject and hits a class cast exception.
>>
>> 3) the Component class has several methods that return 'this' to allow for
>> method chaining. the problem here is that the generic components don't
>> override these methods with covariant returns, so if i do something like
>> formComponent.setVersioned(false).moreMethodCalls().chainedTogether()
>> then
>> those chained methods can't use models because we've upcast our component
>> to
>> something that doesn't have generic support. i guess the solution would
>> be
>> to put these calls on separate lines, but it seems like a bit of a hassle
>> (i'm probably just being picky tho)
>>
>> - craig
>> --
>> View this message in context:
>> http://www.nabble.com/generics-tp18083910p18444866.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Brill Pappin <br...@pappin.ca>.
I think you are *not* in the minority, but a lot of the dissenters
piped in last minute in a big flood so to some it might look that way.
However, It may actually be valuable the way they are doing it now, so
I'm reserving judgement until I can sit down and port my latest
project to it... and check out how well it works.
The moment I have to do a cast, I'll consider it a sign that it needs
more work.
- Brill Pappin
On 14-Jul-08, at 10:17 AM, Craig McIlwee wrote:
>
> personally i am still in favor of going with the m2 way of doing
> things where
> Component is generic, but from the looks of the discussion i think i
> may be
> in the minority here. this kinda surprises me though because as i
> read the
> original generic discussion it sounded like most people supported
> Component<T>.
>
>
> igor.vaynberg wrote:
>>
>> basically we feel this is a much cleaner way then what is 1.4m2. this
>> is a call for confirmation/discussion from our user base.
>>
>
> 1) i'm not sure i agree with this. i don't feel that just adding
> <Void> to
> components that don't need their models makes things messy. i'd
> much rather
> have the option to use generics whenever i need than to create extra
> classes
> such as the 'GenericPanel', etc that have been mentioned. in fact i
> think
> its alot messier to create more classes and to start changing method
> names
> (getDefaultModel, etc) and then adding getModel to the classes that
> do use
> generics.
>
> 2) the wicket web site now suggests the following code for generic
> components:
>
> @SuppressWarnings("unchecked")
> public final T getModelObject()
> {
> return (T)getDefaultModelObject();
> }
>
> ... but isn't the purpose of adding generic support to wicket to
> prevent the
> need for unchecked casts? if we now have to place unchecked casts
> into our
> code then we lose out on the strong type checking that generics are
> supposed
> to provide. its not hard to imagine a case where one part of
> someone's code
> calls setDefaultModelObject with the wrong type, and then later
> another part
> of the code calls getModelObject and hits a class cast exception.
>
> 3) the Component class has several methods that return 'this' to
> allow for
> method chaining. the problem here is that the generic components
> don't
> override these methods with covariant returns, so if i do something
> like
> formComponent
> .setVersioned(false).moreMethodCalls().chainedTogether() then
> those chained methods can't use models because we've upcast our
> component to
> something that doesn't have generic support. i guess the solution
> would be
> to put these calls on separate lines, but it seems like a bit of a
> hassle
> (i'm probably just being picky tho)
>
> - craig
> --
> View this message in context: http://www.nabble.com/generics-tp18083910p18444866.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Craig McIlwee <cr...@vt.edu>.
personally i am still in favor of going with the m2 way of doing things where
Component is generic, but from the looks of the discussion i think i may be
in the minority here. this kinda surprises me though because as i read the
original generic discussion it sounded like most people supported
Component<T>.
igor.vaynberg wrote:
>
> basically we feel this is a much cleaner way then what is 1.4m2. this
> is a call for confirmation/discussion from our user base.
>
1) i'm not sure i agree with this. i don't feel that just adding <Void> to
components that don't need their models makes things messy. i'd much rather
have the option to use generics whenever i need than to create extra classes
such as the 'GenericPanel', etc that have been mentioned. in fact i think
its alot messier to create more classes and to start changing method names
(getDefaultModel, etc) and then adding getModel to the classes that do use
generics.
2) the wicket web site now suggests the following code for generic
components:
@SuppressWarnings("unchecked")
public final T getModelObject()
{
return (T)getDefaultModelObject();
}
... but isn't the purpose of adding generic support to wicket to prevent the
need for unchecked casts? if we now have to place unchecked casts into our
code then we lose out on the strong type checking that generics are supposed
to provide. its not hard to imagine a case where one part of someone's code
calls setDefaultModelObject with the wrong type, and then later another part
of the code calls getModelObject and hits a class cast exception.
3) the Component class has several methods that return 'this' to allow for
method chaining. the problem here is that the generic components don't
override these methods with covariant returns, so if i do something like
formComponent.setVersioned(false).moreMethodCalls().chainedTogether() then
those chained methods can't use models because we've upcast our component to
something that doesn't have generic support. i guess the solution would be
to put these calls on separate lines, but it seems like a bit of a hassle
(i'm probably just being picky tho)
- craig
--
View this message in context: http://www.nabble.com/generics-tp18083910p18444866.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Patrick Angeles <pa...@inertiabev.com>.
I second Matej here... maybe instead of GenericPanel<T>, GenericFragment<T>,
etc. you could name it something more explicit. Some examples:
SingleModelPanel<T>
ModelBoundPanel<T>
It took me the better part of one day to convert a partially genericized
project (we started out with 1.3 then switched to 1.4 mid-stream). The
project had 100k++ LOC. The resulting code is much easier to read.
Another thing that you can consider adding to the core... a utilities class
'Models' to wrap models so you don't have those pesky <> all over the place:
public MyPanel(String id, IModel<Integer> model)
{
super (id, Models.compound (model)); // wrap model in a
CompoundPropertyModel
}
Matej Knopp-2 wrote:
>
> There is one thing that helped me quite a lot when migration the
> project I'm working out. I've created GenericPanel,
> GenericWebMarkupContainer and GenericFragment classes. In most cases
> the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.
>
> I was wondering, even though those classes were farily simple, we
> might want to include them in Wicket anyway, for the sake of
> consistency and convenience.
>
> -Matej
>
> On Mon, Jun 30, 2008 at 12:28 PM, Johan Compagner <jc...@gmail.com>
> wrote:
>> i looked through the code and it is fine by me.
>> Lets test this then in a Build and see what people think of this.
>>
>>
>> On Mon, Jun 30, 2008 at 8:54 AM, Igor Vaynberg <ig...@gmail.com>
>> wrote:
>>
>>> unit tests are fixed...
>>>
>>> -igor
>>>
>>> On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst
>>> <ma...@gmail.com> wrote:
>>> > I'm guessing somewhere this week or so. We need to flush out the unit
>>> > test failures and get some preliminary feedback. Also we need to have
>>> > time available to actually build the release.
>>> >
>>> > My time is limited because we're in the final stages before publishing
>>> > and I have to read our book twice or so.
>>> >
>>> > Martijn
>>> >
>>> > On Mon, Jun 30, 2008 at 2:36 AM, James Carman
>>> > <ja...@carmanconsulting.com> wrote:
>>> >> What sort of time frame are we looking at for a release with this new
>>> >> generics paradigm?
>>> >>
>>> >> On Sun, Jun 29, 2008 at 3:54 PM, Igor Vaynberg
>>> <ig...@gmail.com>
>>> wrote:
>>> >>> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sv...@meiers.net>
>>> wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>> I've just converted two projects to the new generics setup and
>>> everything
>>> >>>> worked out nicely.
>>> >>>> I think this is how generics should be applied to Wicket.
>>> >>>>
>>> >>>> Igor, thanks for your hard work on this.
>>> >>>
>>> >>> wasnt just me :)
>>> >>>
>>> >>> -igor
>>> >>>
>>> >>>>
>>> >>>> Sven
>>> >>>>
>>> >>>> Igor Vaynberg schrieb:
>>> >>>>>
>>> >>>>> development of the 1.4 branch has been quiet lately, this is
>>> because
>>> >>>>> the core team has been busy working on an alternative way of
>>> >>>>> generifiing the framework. an early result of that effort can be
>>> found
>>> >>>>> here [1]. The key difference in [1] is that we have decoupled the
>>> >>>>> component from the type of the model.
>>> >>>>>
>>> >>>>> here is the list of major differences:
>>> >>>>>
>>> >>>>> (1) only components that use their model have a generic type
>>> >>>>> (components you are likely to call getmodel/getmodelobject on as a
>>> >>>>> user). so far these are link,form,formcomponent
>>> >>>>> subclasses,listview,listitem,(other repeaters will follow soon).
>>> this
>>> >>>>> allows for typesafety where it makes sense, and eliminates a ton
>>> of
>>> >>>>> noise from code. we will generify others upon request if a good
>>> >>>>> usecase is provided and we think it is widely applicable.
>>> >>>>>
>>> >>>>> (2) non-generified components do not have IModel<T> get/setModel
>>> and
>>> T
>>> >>>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel
>>> and
>>> >>>>> Object get/setDefaultModelObject. this clearly expresses that the
>>> >>>>> default component model is not tied to the type of component. this
>>> is
>>> >>>>> a bit of a pain from the code migration point of view, but we
>>> think
>>> is
>>> >>>>> worth the effort. generifyed components are free to implement the
>>> old
>>> >>>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast
>>> inside.
>>> >>>>> see ListItem for an example.
>>> >>>>>
>>> >>>>> basically we feel this is a much cleaner way then what is 1.4m2.
>>> this
>>> >>>>> is a call for confirmation/discussion from our user base. do try
>>> to
>>> >>>>> port a small project or a part of a larger project you are working
>>> on
>>> >>>>> to the [1] branch to see how the new api feels. if we do like this
>>> >>>>> more the new branch will be merged into what will be 1.4m3.
>>> >>>>>
>>> >>>>> [1]
>>> https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>>> >>>>>
>>> >>>>> -igor
>>> >>>>>
>>> >>>>>
>>> ---------------------------------------------------------------------
>>> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> ---------------------------------------------------------------------
>>> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> >>>> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>>
>>> >>>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>>> > Apache Wicket 1.3.4 is released
>>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/generics-tp18083910p18222779.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Erik van Oosten <e....@grons.nl>.
In my current project I have:
10 Forms that use a CompoundPropertymodel and
5 Forms that have no model.
IMHO both Form forms :) should be easy to work with.
Regards,
Erik.
Eelco Hillenius wrote:
>> thats my point. you work on fields of one object, true, but it does
>> not necessarily have to be the form's modelobject unless you use a
>> compound property model. eg
>>
>> Form<Void> form = new Form<Void>("form")
>> {
>> protected void onSubmit() { value = dosomethingwith(symbol); }
>> };
>> add(form);
>>
>> form.add(new TextField<String>("symbol", new
>> PropertyModel<String>(this, "symbol")));
>>
>> where [value] and [symbol] are clearly fields on the container that
>> parents the form. inside onsubmit i can just as easily access the
>> object directly without it being the model object of the form. now if
>> we factor out the form into a static inner or a top level class, just
>> like the link discussion, it becomes valuable to have the model.
>>
>
> Yeah, you're right actually. I realize now that I rarely use Form's
> model directly. And I actually do the special stuff in the buttons
> anyway.
>
> Eelco
>
>
>
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
> thats my point. you work on fields of one object, true, but it does
> not necessarily have to be the form's modelobject unless you use a
> compound property model. eg
>
> Form<Void> form = new Form<Void>("form")
> {
> protected void onSubmit() { value = dosomethingwith(symbol); }
> };
> add(form);
>
> form.add(new TextField<String>("symbol", new
> PropertyModel<String>(this, "symbol")));
>
> where [value] and [symbol] are clearly fields on the container that
> parents the form. inside onsubmit i can just as easily access the
> object directly without it being the model object of the form. now if
> we factor out the form into a static inner or a top level class, just
> like the link discussion, it becomes valuable to have the model.
Yeah, you're right actually. I realize now that I rarely use Form's
model directly. And I actually do the special stuff in the buttons
anyway.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
On Wed, Jul 2, 2008 at 12:53 PM, Sven Meier <sv...@meiers.net> wrote:
> Another thought:
> Why do we have a setter for the model actually?
Consider the case (that I sometimes have) where you want to set the
model in the component's constructor, but it needs a bit of
preparation first in such a way that you can't do it in the super or
this call.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Sven Meier <sv...@meiers.net>.
Another thought:
Why do we have a setter for the model actually?
I never call setDefaultModel() (formerly setModel()) in my code. In
wicket-examples it seems that most calls to setDefaultModel() are done
from inside the constructor (where it is sometimes needed because you
cannot call instance methods before the super constructor call).
Shouldn't we declare this method (final) protected?
Custom components could just handle generified models in the
constructor, the non-final getDefaultModel() could be overriden with the
preferred return type (as already suggested).
And we could get rid of the 'default' in all this method names which
frankly don't look too good to me.
Sven
Johan Compagner schrieb:
> thats completely up how you use it
> I can think of a lot that dont use models on FormComponents but only on
> Forms
> If you use CompoundModel then you never will touch or give a FormComponent a
> model.
> and all your stuff is done on the Model of the Form. (in the onSubmit for
> example)
>
> So this can never be generalized like this will never be used this way
> The only way for this is to have a complete separate stack of
> "ModelComponents/GenericComponents"
>
> See for example Link, Igor says i use model a lot. Eelco says he never uses
> it.. (but he uses it on button if i read correctly which is the same thing
> as a link)
>
> johan
>
>
> On Wed, Jul 2, 2008 at 9:15 AM, Jan Kriesten <ja...@renitence.de>
> wrote:
>
>
>> Hi,
>>
>> i agree that its no big deal, i am just trying to figure out some sort
>>
>>> of guidelines for when we do include the type and when we dont. if we
>>> say that we only include the type when the component uses its model
>>> then neither Link nor Form qualify. in fact neither will ListItem.
>>> only things like ListView and FormComponents will qualify.
>>>
>>>
>> I'd actually prefer untyped Link and Form, since I also don't use Models on
>> them directly most of the time. But other's may have a different style and
>> always use Models...
>>
>> Best regards, --- Jan.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Johan Compagner <jc...@gmail.com>.
thats completely up how you use it
I can think of a lot that dont use models on FormComponents but only on
Forms
If you use CompoundModel then you never will touch or give a FormComponent a
model.
and all your stuff is done on the Model of the Form. (in the onSubmit for
example)
So this can never be generalized like this will never be used this way
The only way for this is to have a complete separate stack of
"ModelComponents/GenericComponents"
See for example Link, Igor says i use model a lot. Eelco says he never uses
it.. (but he uses it on button if i read correctly which is the same thing
as a link)
johan
On Wed, Jul 2, 2008 at 9:15 AM, Jan Kriesten <ja...@renitence.de>
wrote:
>
> Hi,
>
> i agree that its no big deal, i am just trying to figure out some sort
>> of guidelines for when we do include the type and when we dont. if we
>> say that we only include the type when the component uses its model
>> then neither Link nor Form qualify. in fact neither will ListItem.
>> only things like ListView and FormComponents will qualify.
>>
>
> I'd actually prefer untyped Link and Form, since I also don't use Models on
> them directly most of the time. But other's may have a different style and
> always use Models...
>
> Best regards, --- Jan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: generics
Posted by Jan Kriesten <ja...@renitence.de>.
Hi,
> i agree that its no big deal, i am just trying to figure out some sort
> of guidelines for when we do include the type and when we dont. if we
> say that we only include the type when the component uses its model
> then neither Link nor Form qualify. in fact neither will ListItem.
> only things like ListView and FormComponents will qualify.
I'd actually prefer untyped Link and Form, since I also don't use Models on them
directly most of the time. But other's may have a different style and always use
Models...
Best regards, --- Jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Roland Huss <na...@tichny.org>.
But at the end, I want my model object back to do some business with it, so I
could either store the CPM myself for later reference (but why would I want
to do this ?) or retrieve it from the Form's model (typesafe, if possible).
That's why a generified Form would be nice.
... roland
svenmeier wrote:
>
> Just because you're using a CompoundPropertyModel on your Forms doesn't
> mean you need it generified.
>
> Sven
>
> Roland Huss schrieb:
>>
>> igor.vaynberg wrote:
>>
>>> On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius
>>> <ee...@gmail.com> wrote:
>>> thats my point. you work on fields of one object, true, but it does
>>> not necessarily have to be the form's modelobject unless you use a
>>> compound property model.
>>>
>>>
>>
>> The usage of a CompoundPropertyModel as a Form-model saved us quite some
>> typing and it's IMO
>> a very common use case. In fact, this it propbably the most relevant use
>> case for a CPM anyway.
>> So, I'm in favor of having a Form with Model (or at least a variation
>> like a
>> ModelForm<T> ...)
>>
>> ... roland
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/generics-tp18083910p18245100.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Sven Meier <sv...@meiers.net>.
Just because you're using a CompoundPropertyModel on your Forms doesn't
mean you need it generified.
Sven
Roland Huss schrieb:
>
> igor.vaynberg wrote:
>
>> On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius
>> <ee...@gmail.com> wrote:
>> thats my point. you work on fields of one object, true, but it does
>> not necessarily have to be the form's modelobject unless you use a
>> compound property model.
>>
>>
>
> The usage of a CompoundPropertyModel as a Form-model saved us quite some
> typing and it's IMO
> a very common use case. In fact, this it propbably the most relevant use
> case for a CPM anyway.
> So, I'm in favor of having a Form with Model (or at least a variation like a
> ModelForm<T> ...)
>
> ... roland
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Roland Huss <na...@tichny.org>.
igor.vaynberg wrote:
>
> On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius
> <ee...@gmail.com> wrote:
> thats my point. you work on fields of one object, true, but it does
> not necessarily have to be the form's modelobject unless you use a
> compound property model.
>
The usage of a CompoundPropertyModel as a Form-model saved us quite some
typing and it's IMO
a very common use case. In fact, this it propbably the most relevant use
case for a CPM anyway.
So, I'm in favor of having a Form with Model (or at least a variation like a
ModelForm<T> ...)
... roland
--
View this message in context: http://www.nabble.com/generics-tp18083910p18231920.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius
<ee...@gmail.com> wrote:
> On Tue, Jul 1, 2008 at 11:09 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> if we ungenerify Link, should we also ungenerify Form? seems like the
>> exact same kind of usecase.
>
> Imho, generic forms make more sense, as you'd typically work on fields
> (with formcomponents) of one object (the model object of the form)
thats my point. you work on fields of one object, true, but it does
not necessarily have to be the form's modelobject unless you use a
compound property model. eg
Form<Void> form = new Form<Void>("form")
{
protected void onSubmit() { value = dosomethingwith(symbol); }
};
add(form);
form.add(new TextField<String>("symbol", new
PropertyModel<String>(this, "symbol")));
where [value] and [symbol] are clearly fields on the container that
parents the form. inside onsubmit i can just as easily access the
object directly without it being the model object of the form. now if
we factor out the form into a static inner or a top level class, just
like the link discussion, it becomes valuable to have the model.
> Anyway, not a big deal really. If you feel Link is better generified,
> I'm cool with it.
i agree that its no big deal, i am just trying to figure out some sort
of guidelines for when we do include the type and when we dont. if we
say that we only include the type when the component uses its model
then neither Link nor Form qualify. in fact neither will ListItem.
only things like ListView and FormComponents will qualify.
-igor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
On Tue, Jul 1, 2008 at 11:09 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> if we ungenerify Link, should we also ungenerify Form? seems like the
> exact same kind of usecase.
Imho, generic forms make more sense, as you'd typically work on fields
(with formcomponents) of one object (the model object of the form),
and then do something with it if updating the fields succeeds (like
saving the changes). It is true that you often use some model value(s)
in the link onClick method, but personally I never do that through the
model value, but rather like how Timo described it.
Anyway, not a big deal really. If you feel Link is better generified,
I'm cool with it.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
if we ungenerify Link, should we also ungenerify Form? seems like the
exact same kind of usecase.
-igor
On Tue, Jul 1, 2008 at 10:25 PM, Eelco Hillenius
<ee...@gmail.com> wrote:
>> This is not a big deal though, either way is fine by me.
>
> I prefer link to be not generified, but either way is fine by me as well.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
> This is not a big deal though, either way is fine by me.
I prefer link to be not generified, but either way is fine by me as well.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
On Thu, Jul 3, 2008 at 9:46 AM, Eelco Hillenius
<ee...@gmail.com> wrote:
>>> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <ma...@gmail.com> wrote:
>>>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>>>> Wouldn't that feel more like crippled?
>>>> The default model slot doesn't take any runtime space when you don't
>>>> use it, property would. And removing four methods from component will
>>>> hardly make it much lighter.
>>>
>> Big +1 on that :)
>
> That's a +1 on your own reply... cheater! ;-)
Like Martijn said.... ugh I need to learn to read the rest of the
thread before replying first!
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matej Knopp <ma...@gmail.com>.
On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius
<ee...@gmail.com> wrote:
> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <ma...@gmail.com> wrote:
>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>> Wouldn't that feel more like crippled?
>> The default model slot doesn't take any runtime space when you don't
>> use it, property would. And removing four methods from component will
>> hardly make it much lighter.
>
> I wasn't just thinking about models though. *I* would like us to go
> through the API when we start on 1.5 and remove anything that isn't
> necessary. Remove all the the deprecations and convenience methods
> that have (easy) alternatives. All the while keeping an easy upgrade
> path in mind of course.
Okay. Big +1 here of course.,
-Matej
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
>> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <ma...@gmail.com> wrote:
>>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>>> Wouldn't that feel more like crippled?
>>> The default model slot doesn't take any runtime space when you don't
>>> use it, property would. And removing four methods from component will
>>> hardly make it much lighter.
>>
> Big +1 on that :)
That's a +1 on your own reply... cheater! ;-)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matej Knopp <ma...@gmail.com>.
Rofl :) I've slept like 4 hours. I wanted to +1 Eelco of course. Or
maybe that just my Ego and my subconciousness messing with me.
On Thu, Jul 3, 2008 at 10:22 AM, Martijn Dashorst
<ma...@gmail.com> wrote:
> Matej: drink some coffee, you're +1-ing yourself now :)
>
> Martijn
>
> On Thu, Jul 3, 2008 at 10:08 AM, Matej Knopp <ma...@gmail.com> wrote:
>> On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius
>> <ee...@gmail.com> wrote:
>>> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <ma...@gmail.com> wrote:
>>>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>>>> Wouldn't that feel more like crippled?
>>>> The default model slot doesn't take any runtime space when you don't
>>>> use it, property would. And removing four methods from component will
>>>> hardly make it much lighter.
>>>
>> Big +1 on that :)
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Martijn Dashorst <ma...@gmail.com>.
Matej: drink some coffee, you're +1-ing yourself now :)
Martijn
On Thu, Jul 3, 2008 at 10:08 AM, Matej Knopp <ma...@gmail.com> wrote:
> On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius
> <ee...@gmail.com> wrote:
>> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <ma...@gmail.com> wrote:
>>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>>> Wouldn't that feel more like crippled?
>>> The default model slot doesn't take any runtime space when you don't
>>> use it, property would. And removing four methods from component will
>>> hardly make it much lighter.
>>
> Big +1 on that :)
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matej Knopp <ma...@gmail.com>.
On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius
<ee...@gmail.com> wrote:
> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <ma...@gmail.com> wrote:
>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>> Wouldn't that feel more like crippled?
>> The default model slot doesn't take any runtime space when you don't
>> use it, property would. And removing four methods from component will
>> hardly make it much lighter.
>
Big +1 on that :)
> I wasn't just thinking about models though. *I* would like us to go
> through the API when we start on 1.5 and remove anything that isn't
> necessary. Remove all the the deprecations and convenience methods
> that have (easy) alternatives. All the while keeping an easy upgrade
> path in mind of course.
>
> Of course, things like compound property models are pretty cool, and
> we should keep supporting the types of models we are supporting now.
> But maybe we can find a way to add this kind of support to components
> without needing it to be built in. Or maybe not and in the end our
> conclusion will be to stick with 1.4's model. But lets try to be
> creative before we give up on that :-)
Creative is ok for me. Destructive isn't :)
>
> We're getting a bit ahead of ourselves now though, unless we already
> want to start coding on 1.5. It is probably a better idea to finalize
> 1.4 first, and decide on what to generify by default based on the
> likeliness it will help users for this version.
Yeah, agree on this as well.
-Matej
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <ma...@gmail.com> wrote:
> Ligther? Does it meen with no Compund and ComponentAssignedModel?
> Wouldn't that feel more like crippled?
> The default model slot doesn't take any runtime space when you don't
> use it, property would. And removing four methods from component will
> hardly make it much lighter.
I wasn't just thinking about models though. *I* would like us to go
through the API when we start on 1.5 and remove anything that isn't
necessary. Remove all the the deprecations and convenience methods
that have (easy) alternatives. All the while keeping an easy upgrade
path in mind of course.
Of course, things like compound property models are pretty cool, and
we should keep supporting the types of models we are supporting now.
But maybe we can find a way to add this kind of support to components
without needing it to be built in. Or maybe not and in the end our
conclusion will be to stick with 1.4's model. But lets try to be
creative before we give up on that :-)
We're getting a bit ahead of ourselves now though, unless we already
want to start coding on 1.5. It is probably a better idea to finalize
1.4 first, and decide on what to generify by default based on the
likeliness it will help users for this version.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matej Knopp <ma...@gmail.com>.
Ligther? Does it meen with no Compund and ComponentAssignedModel?
Wouldn't that feel more like crippled?
The default model slot doesn't take any runtime space when you don't
use it, property would. And removing four methods from component will
hardly make it much lighter.
-Matej
On Thu, Jul 3, 2008 at 7:13 AM, Eelco Hillenius
<ee...@gmail.com> wrote:
>> What I mean is that post-1.4 it would be good to remove the
>> defaultModel* stuff and other IModel dependencies from
>> Component, and maybe try to move towards a more case-by-case
>> model handling in generified (actually
>> typed-after-their-default-model-type) components as well.
>
> I'm very much in favor of that. If it were up to me, I would actually
> try to cut away from component (and other pivotal classes for that
> matter) as much as possible. I'd love Wicket to feel lighter and more
> pointed with 1.5 rather than heavy with convenience like it is now.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
> What I mean is that post-1.4 it would be good to remove the
> defaultModel* stuff and other IModel dependencies from
> Component, and maybe try to move towards a more case-by-case
> model handling in generified (actually
> typed-after-their-default-model-type) components as well.
I'm very much in favor of that. If it were up to me, I would actually
try to cut away from component (and other pivotal classes for that
matter) as much as possible. I'd love Wicket to feel lighter and more
pointed with 1.5 rather than heavy with convenience like it is now.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Wed, 02 Jul 2008, Johan Compagner wrote:
> I still dont see a complete decoupling or do you mean only getDefaultXxxx()?
What I mean is that post-1.4 it would be good to remove the
defaultModel* stuff and other IModel dependencies from
Component, and maybe try to move towards a more case-by-case
model handling in generified (actually
typed-after-their-default-model-type) components as well.
> So all the getModel() (Link/FormComponent) are still there?
I wouldn't mind trying to see if we could remove the magic
currently done in get/setModel* in those too, and if model
becomes a normal field in those (instead of an element
stored in Component.data), open it to subclasses by making
it protected and leave implementing a part of those methods
to the users. Often it's better for the design to avoid
using getters and setters.
Some of the magic might work in the models themselves, for
example making the component aware models... aware of the
relevant components :)
This might turn out not to be practical, and either way
having the get/setModel* by default in the generified
components is fine by me -- just thinking about different
options, and whether they have relevance on what will go to
1.4.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Johan Compagner <jc...@gmail.com>.
I still dont see a complete decoupling or do you mean only getDefaultXxxx()?
So all the getModel() (Link/FormComponent) are still there?
For link we could have Link (without model) and ModelLink (generified
and with get/setModel) that would be fine with me.
On 7/2/08, Timo Rantalaiho <Ti...@ri.fi> wrote:
> On Tue, 01 Jul 2008, Matej Knopp wrote:
>> There is one thing that helped me quite a lot when migration the
>> project I'm working out. I've created GenericPanel,
>> GenericWebMarkupContainer and GenericFragment classes. In most cases
>> the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.
>
> Maybe the names could be TypedPanel / ModelContainingPanel
> or something like that?
>
> Or maybe start with the original component name so that they
> would pop up more easily in the IDE, for example
> PanelWithType / PanelWithModel?
>
>> I was wondering, even though those classes were farily simple, we
>> might want to include them in Wicket anyway, for the sake of
>> consistency and convenience.
>
> I thought about this and I think that it might be better to
> not include them after all. In 1.5 it would be great to
> separate IModel and Component more thoroughly, getting rid
> of the defaultModel* accessors. Then it would make less
> sense to have the convenience classes with those model and
> modelObject accessors.
>
> In cases where two components share the same model, it would
> make sense to make the IModel field in each component final.
> Then setModel() does not make sense any more; all it could
> do would be throw an exception or be a confusing no-op.
> Likewise, sometimes you never do setModelObject() or
> getModelObject() from outside the class.
>
> Leaner APIs and less methods per objects are good things.
> Hence it's better to add methods as you need them, instead
> of providing a lot of convenience stuff that is only used a
> part of the time. Surely each Component subclass has anyway
> a lot of methods, and MarkupContainers even more, but you
> have got to start somewhere :)
>
> This is not a big deal though, either way is fine by me.
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Thu, 03 Jul 2008, Matej Knopp wrote:
> I'm gonna be -1 on removing model utility methods and default model
> slot from component until you suggest a clean and transparent way to
> support
> - compound (inherited) models
> - component assigned models
> - automatic detachment
Fair enough, let's see what we can come up with :)
I was thinking that most of that stuff could be achieved by
moving more logic to the model classes. Some things such as
the add(new Label("name")); for
CompoundPropertyModel-component children could be tricky to
get working though.
Anyway, I agree that now our focus must be on getting 1.4
out of the door -- the reason this came up was just that I
was thinking out loud whether the plans for 1.5 have
implications on what to add in 1.4.
Automatic detachment for all IModel fields of a component
would be great (and the easiest to do of those I suppose).
> From component where? ComponentUtil? Component has a very strong and
> complicated contract. There are lot of methods in component, but there
> are reasons for it. There are parts like rendering though that might
> need to be cleaned up.
Definitely not to a utility class with static methods :)
Maybe some of the responsibilities can be moved to different
other classes, such as ComponentTag and MarkupStream. But
let's see that when working on 1.5.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Maarten Bosteels <mb...@gmail.com>.
Haven't yet tried it myself, but this project seems like a big help when you
have to support ProperyChangeListener etc :
https://bean-properties.dev.java.net/10things.html
Maarten
On Tue, Jul 8, 2008 at 2:03 PM, David N. Arnold <da...@gmail.com>
wrote:
> See this article
>
> http://weblogs.java.net/blog/rbair/archive/2006/05/the_unknown_jav.html
>
> for a clean solution to this problem. Essentially, you can grab a
> class "JavaBean" from the SwingX project and extend it.
>
> Of course if you're already extending another class it doesn't really
> help you out...
>
>
> On Tue, Jul 8, 2008 at 5:58 AM, Matthijs Wensveen <m....@func.nl>
> wrote:
> > I always find using PropertyChangeSupport and ProperyChangeListener is a
> lot
> > of work and kinda pollutes your code. But it is a solution. Maybe a
> > combination of ProperyChangeListener and AOP could be made to reduce the
> > required boilerplate code.
> >
> > Matthijs
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: generics
Posted by "David N. Arnold" <da...@gmail.com>.
See this article
http://weblogs.java.net/blog/rbair/archive/2006/05/the_unknown_jav.html
for a clean solution to this problem. Essentially, you can grab a
class "JavaBean" from the SwingX project and extend it.
Of course if you're already extending another class it doesn't really
help you out...
On Tue, Jul 8, 2008 at 5:58 AM, Matthijs Wensveen <m....@func.nl> wrote:
> I always find using PropertyChangeSupport and ProperyChangeListener is a lot
> of work and kinda pollutes your code. But it is a solution. Maybe a
> combination of ProperyChangeListener and AOP could be made to reduce the
> required boilerplate code.
>
> Matthijs
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matthijs Wensveen <m....@func.nl>.
I always find using PropertyChangeSupport and ProperyChangeListener is a
lot of work and kinda pollutes your code. But it is a solution. Maybe a
combination of ProperyChangeListener and AOP could be made to reduce the
required boilerplate code.
Matthijs
Johan Compagner wrote:
> thats just a listener interface for example PropertyChangeListener (but you
> can make it more specific interface)
> Just make a base model that has add/removePropertyChangeListener and let
> your components listen to that
>
> johan
>
>
> On Mon, Jul 7, 2008 at 8:28 AM, Matthijs Wensveen <m....@func.nl>
> wrote:
>
>
>> Timo Rantalaiho wrote:
>>
>>
>>> On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
>>>
>>>
>>>
>>>> How do you cope with deeply nested model properties? For example:
>>>>
>>>> public class PersonViewer extends Component<Person> {
>>>> ..
>>>> }
>>>>
>>>> some other component does:
>>>> person.getOrders().get(0).setAmount(0); // first order for free (as in
>>>> beer)
>>>>
>>>>
>>>>
>>> I have no idea of Johan's project, but normally you just edit an object in
>>> one place at a time, and PersonViewer would be a read-only component with a
>>> model that always pulls the freshest version of the person it is displaying
>>> from the database.
>>>
>>> Best wishes,
>>> Timo
>>>
>>>
>>>
>>>
>> The thing is that when using Ajax you have to specifically add PersonViewer
>> to the AjaxRequestTarget when 'some other component' modifies the Person
>> object. The problem is that 'some other component' might not even know about
>> or have access to PersonViewer (maybe it's a 3rd-party component).
>> OnModelChanged does not work in this case, because there is no call to
>> setModelObject, just to some setter of the Person object.
>>
>> While Ajax does very nice things to the GUI, it kinda messes up the
>> model-driven (as in wicket model) approach to gui development. That is why I
>> was thinking about some aspect-oriented solution to let components know
>> about model updates, even when they keep a reference to the same object.
>>
>> Matthijs
>>
>> --
>> Matthijs Wensveen
>> Func. Internet Integration
>> W http://www.func.nl
>> T +31 20 4230000
>> F +31 20 4223500
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Johan Compagner <jc...@gmail.com>.
thats just a listener interface for example PropertyChangeListener (but you
can make it more specific interface)
Just make a base model that has add/removePropertyChangeListener and let
your components listen to that
johan
On Mon, Jul 7, 2008 at 8:28 AM, Matthijs Wensveen <m....@func.nl>
wrote:
> Timo Rantalaiho wrote:
>
>> On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
>>
>>
>>> How do you cope with deeply nested model properties? For example:
>>>
>>> public class PersonViewer extends Component<Person> {
>>> ..
>>> }
>>>
>>> some other component does:
>>> person.getOrders().get(0).setAmount(0); // first order for free (as in
>>> beer)
>>>
>>>
>>
>> I have no idea of Johan's project, but normally you just edit an object in
>> one place at a time, and PersonViewer would be a read-only component with a
>> model that always pulls the freshest version of the person it is displaying
>> from the database.
>>
>> Best wishes,
>> Timo
>>
>>
>>
> The thing is that when using Ajax you have to specifically add PersonViewer
> to the AjaxRequestTarget when 'some other component' modifies the Person
> object. The problem is that 'some other component' might not even know about
> or have access to PersonViewer (maybe it's a 3rd-party component).
> OnModelChanged does not work in this case, because there is no call to
> setModelObject, just to some setter of the Person object.
>
> While Ajax does very nice things to the GUI, it kinda messes up the
> model-driven (as in wicket model) approach to gui development. That is why I
> was thinking about some aspect-oriented solution to let components know
> about model updates, even when they keep a reference to the same object.
>
> Matthijs
>
> --
> Matthijs Wensveen
> Func. Internet Integration
> W http://www.func.nl
> T +31 20 4230000
> F +31 20 4223500
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: generics
Posted by Matthijs Wensveen <m....@func.nl>.
Timo Rantalaiho wrote:
> On Mon, 07 Jul 2008, Matthijs Wensveen wrote:
>
>> The thing is that when using Ajax you have to specifically add
>> PersonViewer to the AjaxRequestTarget when 'some other component'
>> modifies the Person object. The problem is that 'some other component'
>> might not even know about or have access to PersonViewer (maybe it's a
>> 3rd-party component). OnModelChanged does not work in this case, because
>> there is no call to setModelObject, just to some setter of the Person
>> object.
>>
>
> Yep, in our current project we use the WICKET-1312
> "broadcaster" approach to solve this. This means that the
> logic of which component needs to be repainted when
> something happens is in the UI components. (The domain logic
> itself we try to put in the domain objects.)
>
> So in our model, the other component modifying the Person
> object would broadcast a PersonModifiedEvent to all
> PersonModificationReceiver components, who could then act
> accordingly (typically add themselves to the Ajax request
> target). There's not a lot of automagical intelligence
> there, but we have found this way clear and effective. All
> relationships are "static" on component class level and
> navigable in the IDE. The proliferation of events and
> receivers must be watched out for though.
>
I knew about WICKET-1312, but hadn't thought of broadcasting domain
object typed events, just things like onClick and such which gives too
little information. Thanks for the eyeopener!
>
>> While Ajax does very nice things to the GUI, it kinda messes up the
>> model-driven (as in wicket model) approach to gui development. That is
>> why I was thinking about some aspect-oriented solution to let components
>> know about model updates, even when they keep a reference to the same
>> object.
>>
>
> That's true. It's a pity that for now, Java AOP solutions
> are still a bit invasive (AFAIK, if you know of some really
> neat and transparent implementation without -javaagents or
> special compilers or some such nuisance, I'd be glad to hear
> :)).
>
> We tried sharing models and making them more intelligent and
> models sending events to registered listeners and whatnot
> dead chickens before arriving at the current
> broadcast/receiver approach. When the components are
> "physically" far away from each other, sharing the model or
> handling registration and deregistration can get hairy. And
> to avoid memory leaks, removing the listeners when
> components are being replaced (e.g. repeater children
> recreated) should be taken care of carefully in a
> traditional event-listener mechanism.
>
Maybe listeners could be registered using weak references so that the
objects are still garbage collected even when the listener is still alive.
> However, more experimentation is definitely needed on this,
> and I'd be very interested on hearing any experiences and
> ideas! It seems that ajax will be around for some more
> years, whether we like it or not, so best to make the best
> out of it :)
>
> Best wishes, Timo
>
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Mon, 07 Jul 2008, Matthijs Wensveen wrote:
> The thing is that when using Ajax you have to specifically add
> PersonViewer to the AjaxRequestTarget when 'some other component'
> modifies the Person object. The problem is that 'some other component'
> might not even know about or have access to PersonViewer (maybe it's a
> 3rd-party component). OnModelChanged does not work in this case, because
> there is no call to setModelObject, just to some setter of the Person
> object.
Yep, in our current project we use the WICKET-1312
"broadcaster" approach to solve this. This means that the
logic of which component needs to be repainted when
something happens is in the UI components. (The domain logic
itself we try to put in the domain objects.)
So in our model, the other component modifying the Person
object would broadcast a PersonModifiedEvent to all
PersonModificationReceiver components, who could then act
accordingly (typically add themselves to the Ajax request
target). There's not a lot of automagical intelligence
there, but we have found this way clear and effective. All
relationships are "static" on component class level and
navigable in the IDE. The proliferation of events and
receivers must be watched out for though.
> While Ajax does very nice things to the GUI, it kinda messes up the
> model-driven (as in wicket model) approach to gui development. That is
> why I was thinking about some aspect-oriented solution to let components
> know about model updates, even when they keep a reference to the same
> object.
That's true. It's a pity that for now, Java AOP solutions
are still a bit invasive (AFAIK, if you know of some really
neat and transparent implementation without -javaagents or
special compilers or some such nuisance, I'd be glad to hear
:)).
We tried sharing models and making them more intelligent and
models sending events to registered listeners and whatnot
dead chickens before arriving at the current
broadcast/receiver approach. When the components are
"physically" far away from each other, sharing the model or
handling registration and deregistration can get hairy. And
to avoid memory leaks, removing the listeners when
components are being replaced (e.g. repeater children
recreated) should be taken care of carefully in a
traditional event-listener mechanism.
However, more experimentation is definitely needed on this,
and I'd be very interested on hearing any experiences and
ideas! It seems that ajax will be around for some more
years, whether we like it or not, so best to make the best
out of it :)
Best wishes, Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matthijs Wensveen <m....@func.nl>.
Timo Rantalaiho wrote:
> On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
>
>> How do you cope with deeply nested model properties? For example:
>>
>> public class PersonViewer extends Component<Person> {
>> ..
>> }
>>
>> some other component does:
>> person.getOrders().get(0).setAmount(0); // first order for free (as in beer)
>>
>
> I have no idea of Johan's project, but normally you just
> edit an object in one place at a time, and PersonViewer
> would be a read-only component with a model that always
> pulls the freshest version of the person it is displaying
> from the database.
>
> Best wishes,
> Timo
>
>
The thing is that when using Ajax you have to specifically add
PersonViewer to the AjaxRequestTarget when 'some other component'
modifies the Person object. The problem is that 'some other component'
might not even know about or have access to PersonViewer (maybe it's a
3rd-party component). OnModelChanged does not work in this case, because
there is no call to setModelObject, just to some setter of the Person
object.
While Ajax does very nice things to the GUI, it kinda messes up the
model-driven (as in wicket model) approach to gui development. That is
why I was thinking about some aspect-oriented solution to let components
know about model updates, even when they keep a reference to the same
object.
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
> How do you cope with deeply nested model properties? For example:
>
> public class PersonViewer extends Component<Person> {
> ..
> }
>
> some other component does:
> person.getOrders().get(0).setAmount(0); // first order for free (as in beer)
I have no idea of Johan's project, but normally you just
edit an object in one place at a time, and PersonViewer
would be a read-only component with a model that always
pulls the freshest version of the person it is displaying
from the database.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matej Knopp <ma...@gmail.com>.
Okay, long story short.
I'm gonna be -1 on removing model utility methods and default model
slot from component until you suggest a clean and transparent way to
support
- compound (inherited) models
- component assigned models
- automatic detachment
Just because you don't use these features it doesn't mean there are
not users who do.
There is convenience, removing bloat and just crippling the API. And
there's difference between these.
Don't take me wrong, I don't mind removing the *default* methods from
components, but not in a way that is going to sacrifice any of the
mentioned functionality.
On Thu, Jul 3, 2008 at 5:32 AM, Timo Rantalaiho <Ti...@ri.fi> wrote:
> On Wed, 02 Jul 2008, Matej Knopp wrote:
>> I still don't see what's wrong with GenericPanel. It's certainly much
>> easier to type than ModelContainingPanel.
>
> Nothing wrong with that either, it's just very generic :)
>
> There are a lot of ways of making use of generics in a
> component besides just adding the type parameter bound to
> the type parameter of the model of the component.
>
> I mean, if you have
>
> public FooPanel extends GenericPanel<Foo> {
> public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
> ...
> }
> ...
> }
>
> it's not so much more generic than
>
> public FooPanel extends Panel {
> public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
> ...
> }
> ...
> }
>
>> I strongly disagree. There are good reasons for Wicket to bind model
>> and component together and I think what we have in 1.4 right now is a
>> balanced compromise.
>
> I'd be glad to hear more on this! For now, I imagine that a
> lot of stuff that the Component IModel dependency exists for
> could be done in other ways.
Sure, mind sharing how?
>
> And there is some functionality in there that Wicket might
> be better without. For example, onModelChanged / Changing
> things become tricky when you share the same model between
> different instances. And when using setModelObject() with an
> object that is equal to the current model object, but a
> different instance (such as a Hibernate-persisted object
> bound to the correct session), you have to either do
> getModel().setObject() or change the model comparator.
>
> Again, I'm just exploring, and perhaps overlooking
> something.
>
>> Also if we don't provide the convenience classes
>> people will bound to write their own (because it's the only reasonable
>> way to migrate project that already uses generics).
>
> That's true, I just thought it would be no big deal and only
> affect the earliest 1.4 adopters (or those still converting
> from 2.0 if there are any left) (sorry :)). I had in mind
> that if we then remove those convenience classes in 1.5,
> they would have to move to the user codebases anyway, but
> maybe 1.4 -> 1.5 will not be such a common migration path
> because of API breaks.
>
>> I don't buy this. Our components have a lot of methods, but most of
>> them are not part of public API. I plan to prefix those methods with a
>> common prefix for 1.5 so they don't confuse regular users. But I
>> really don't see how removing four methods (*defaultModel) improves
>> our api.
>
> It would be better (altough harder) to move responsibilities
> away from Component to other classes, which could be then
> marked as not being a part of the public API. When you do
> the rename I'll be happy to do a spike of moving some of the
> renamed stuff away from Component altogether :)
>From component where? ComponentUtil? Component has a very strong and
complicated contract. There are lot of methods in component, but there
are reasons for it. There are parts like rendering though that might
need to be cleaned up.
>
>> Models have always been conceptually bound to component. Right now the
>> problem of our API is not that we have a model slot in component. It
>> is that we have exactly one model slot. This doesn't work well for all
>> components, since some don't need model at all and some need more than
>> one.
>
> Yeah, if we cannot get rid of the default model handling
> (which I still hope to be possible), at least a more
> flexible abstraction (IModelsContainer?) might be good.
>
>> esier. Now thinking about it, the name should really suggest that
>> there is one model per component. Maybe PanelWithModel could be the
>> name after all :)
>
> PanelWithExactlyOneModelInTheDefaultSlotAndHoldingAnObjectOfTheSameTypeAsTheTypeParameterOfThisComponent :)
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matthijs Wensveen <m....@func.nl>.
How do you cope with deeply nested model properties? For example:
public class PersonViewer extends Component<Person> {
..
}
some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in beer)
Matthijs
Johan Compagner wrote:
> There are many state things in a component. Wicket itself has only a
> few like model/visibile/enable. But a developer could add many many
> more.
>
> In our project this is easily handled by our components. Every
> component knows when it is changed, what ever it is and then a visitor
> adds them to ajax. We have a fixed set of components so its not a big
> problem.
>
> On 7/4/08, Matthijs Wensveen <m....@func.nl> wrote:
>
>> Matej Knopp wrote:
>>
>>> On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <ma...@gmail.com> wrote:
>>>
>>>
>>>>> And there is some functionality in there that Wicket might
>>>>> be better without. For example, onModelChanged / Changing
>>>>> things become tricky when you share the same model between
>>>>> different instances. And when using setModelObject() with an
>>>>> object that is equal to the current model object, but a
>>>>> different instance (such as a Hibernate-persisted object
>>>>> bound to the correct session), you have to either do
>>>>> getModel().setObject() or change the model comparator.
>>>>>
>>>>>
>>>>>
>>>> setModelObject isn't the best idea IMHO. Models should support some
>>>> kind of state change notifications, we might want to improve that for
>>>> 1.5, though it probably wouldn't be very easy to do.
>>>>
>>>>
>>> Well, we can hardly detect change of propertypromodels unless we pull
>>> and compare the value every time...
>>>
>>>
>> Better state change notifications would be a huge improvement IMO
>> because that way components could add themselves to AjaxRequestTarget
>> when needed. Currently all Ajax functionality requires Ajaxified
>> components to know about each other and when they should be displayed.
>> Some kind of even mechanism as described in
>> https://issues.apache.org/jira/browse/WICKET-1312 would definitely help,
>> but a model-driven approach would be even better.
>>
>> I was thinking to support this using annotations and aspects and the
>> likes, but I haven't had the time to create a proof of concept.
>>
>> Matthijs
>>
>> PS. Thread subject has become little different than thread content :)
>>
>> --
>> Matthijs Wensveen
>> Func. Internet Integration
>> W http://www.func.nl
>> T +31 20 4230000
>> F +31 20 4223500
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Johan Compagner <jc...@gmail.com>.
There are many state things in a component. Wicket itself has only a
few like model/visibile/enable. But a developer could add many many
more.
In our project this is easily handled by our components. Every
component knows when it is changed, what ever it is and then a visitor
adds them to ajax. We have a fixed set of components so its not a big
problem.
On 7/4/08, Matthijs Wensveen <m....@func.nl> wrote:
> Matej Knopp wrote:
>> On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <ma...@gmail.com> wrote:
>>
>>>> And there is some functionality in there that Wicket might
>>>> be better without. For example, onModelChanged / Changing
>>>> things become tricky when you share the same model between
>>>> different instances. And when using setModelObject() with an
>>>> object that is equal to the current model object, but a
>>>> different instance (such as a Hibernate-persisted object
>>>> bound to the correct session), you have to either do
>>>> getModel().setObject() or change the model comparator.
>>>>
>>>>
>>> setModelObject isn't the best idea IMHO. Models should support some
>>> kind of state change notifications, we might want to improve that for
>>> 1.5, though it probably wouldn't be very easy to do.
>>>
>> Well, we can hardly detect change of propertypromodels unless we pull
>> and compare the value every time...
>>
>
> Better state change notifications would be a huge improvement IMO
> because that way components could add themselves to AjaxRequestTarget
> when needed. Currently all Ajax functionality requires Ajaxified
> components to know about each other and when they should be displayed.
> Some kind of even mechanism as described in
> https://issues.apache.org/jira/browse/WICKET-1312 would definitely help,
> but a model-driven approach would be even better.
>
> I was thinking to support this using annotations and aspects and the
> likes, but I haven't had the time to create a proof of concept.
>
> Matthijs
>
> PS. Thread subject has become little different than thread content :)
>
> --
> Matthijs Wensveen
> Func. Internet Integration
> W http://www.func.nl
> T +31 20 4230000
> F +31 20 4223500
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matthijs Wensveen <m....@func.nl>.
Matej Knopp wrote:
> On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <ma...@gmail.com> wrote:
>
>>> And there is some functionality in there that Wicket might
>>> be better without. For example, onModelChanged / Changing
>>> things become tricky when you share the same model between
>>> different instances. And when using setModelObject() with an
>>> object that is equal to the current model object, but a
>>> different instance (such as a Hibernate-persisted object
>>> bound to the correct session), you have to either do
>>> getModel().setObject() or change the model comparator.
>>>
>>>
>> setModelObject isn't the best idea IMHO. Models should support some
>> kind of state change notifications, we might want to improve that for
>> 1.5, though it probably wouldn't be very easy to do.
>>
> Well, we can hardly detect change of propertypromodels unless we pull
> and compare the value every time...
>
Better state change notifications would be a huge improvement IMO
because that way components could add themselves to AjaxRequestTarget
when needed. Currently all Ajax functionality requires Ajaxified
components to know about each other and when they should be displayed.
Some kind of even mechanism as described in
https://issues.apache.org/jira/browse/WICKET-1312 would definitely help,
but a model-driven approach would be even better.
I was thinking to support this using annotations and aspects and the
likes, but I haven't had the time to create a proof of concept.
Matthijs
PS. Thread subject has become little different than thread content :)
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matej Knopp <ma...@gmail.com>.
On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <ma...@gmail.com> wrote:
>>
>> And there is some functionality in there that Wicket might
>> be better without. For example, onModelChanged / Changing
>> things become tricky when you share the same model between
>> different instances. And when using setModelObject() with an
>> object that is equal to the current model object, but a
>> different instance (such as a Hibernate-persisted object
>> bound to the correct session), you have to either do
>> getModel().setObject() or change the model comparator.
>>
>
> setModelObject isn't the best idea IMHO. Models should support some
> kind of state change notifications, we might want to improve that for
> 1.5, though it probably wouldn't be very easy to do.
Well, we can hardly detect change of propertypromodels unless we pull
and compare the value every time...
>
> -Matej
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matej Knopp <ma...@gmail.com>.
>
> And there is some functionality in there that Wicket might
> be better without. For example, onModelChanged / Changing
> things become tricky when you share the same model between
> different instances. And when using setModelObject() with an
> object that is equal to the current model object, but a
> different instance (such as a Hibernate-persisted object
> bound to the correct session), you have to either do
> getModel().setObject() or change the model comparator.
>
setModelObject isn't the best idea IMHO. Models should support some
kind of state change notifications, we might want to improve that for
1.5, though it probably wouldn't be very easy to do.
-Matej
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Wed, 02 Jul 2008, Matej Knopp wrote:
> I still don't see what's wrong with GenericPanel. It's certainly much
> easier to type than ModelContainingPanel.
Nothing wrong with that either, it's just very generic :)
There are a lot of ways of making use of generics in a
component besides just adding the type parameter bound to
the type parameter of the model of the component.
I mean, if you have
public FooPanel extends GenericPanel<Foo> {
public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
...
}
...
}
it's not so much more generic than
public FooPanel extends Panel {
public FooPanel(String id, IModel<Foo> model, IModel<List<Bar>> bars) {
...
}
...
}
> I strongly disagree. There are good reasons for Wicket to bind model
> and component together and I think what we have in 1.4 right now is a
> balanced compromise.
I'd be glad to hear more on this! For now, I imagine that a
lot of stuff that the Component IModel dependency exists for
could be done in other ways.
And there is some functionality in there that Wicket might
be better without. For example, onModelChanged / Changing
things become tricky when you share the same model between
different instances. And when using setModelObject() with an
object that is equal to the current model object, but a
different instance (such as a Hibernate-persisted object
bound to the correct session), you have to either do
getModel().setObject() or change the model comparator.
Again, I'm just exploring, and perhaps overlooking
something.
> Also if we don't provide the convenience classes
> people will bound to write their own (because it's the only reasonable
> way to migrate project that already uses generics).
That's true, I just thought it would be no big deal and only
affect the earliest 1.4 adopters (or those still converting
from 2.0 if there are any left) (sorry :)). I had in mind
that if we then remove those convenience classes in 1.5,
they would have to move to the user codebases anyway, but
maybe 1.4 -> 1.5 will not be such a common migration path
because of API breaks.
> I don't buy this. Our components have a lot of methods, but most of
> them are not part of public API. I plan to prefix those methods with a
> common prefix for 1.5 so they don't confuse regular users. But I
> really don't see how removing four methods (*defaultModel) improves
> our api.
It would be better (altough harder) to move responsibilities
away from Component to other classes, which could be then
marked as not being a part of the public API. When you do
the rename I'll be happy to do a spike of moving some of the
renamed stuff away from Component altogether :)
> Models have always been conceptually bound to component. Right now the
> problem of our API is not that we have a model slot in component. It
> is that we have exactly one model slot. This doesn't work well for all
> components, since some don't need model at all and some need more than
> one.
Yeah, if we cannot get rid of the default model handling
(which I still hope to be possible), at least a more
flexible abstraction (IModelsContainer?) might be good.
> esier. Now thinking about it, the name should really suggest that
> there is one model per component. Maybe PanelWithModel could be the
> name after all :)
PanelWithExactlyOneModelInTheDefaultSlotAndHoldingAnObjectOfTheSameTypeAsTheTypeParameterOfThisComponent :)
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matej Knopp <ma...@gmail.com>.
On Wed, Jul 2, 2008 at 4:28 AM, Timo Rantalaiho <Ti...@ri.fi> wrote:
> On Tue, 01 Jul 2008, Matej Knopp wrote:
>> There is one thing that helped me quite a lot when migration the
>> project I'm working out. I've created GenericPanel,
>> GenericWebMarkupContainer and GenericFragment classes. In most cases
>> the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.
>
> Maybe the names could be TypedPanel / ModelContainingPanel
> or something like that?
I still don't see what's wrong with GenericPanel. It's certainly much
easier to type than ModelContainingPanel.
>
> Or maybe start with the original component name so that they
> would pop up more easily in the IDE, for example
> PanelWithType / PanelWithModel?
>
>> I was wondering, even though those classes were farily simple, we
>> might want to include them in Wicket anyway, for the sake of
>> consistency and convenience.
>
> I thought about this and I think that it might be better to
> not include them after all. In 1.5 it would be great to
> separate IModel and Component more thoroughly, getting rid
> of the defaultModel* accessors. Then it would make less
> sense to have the convenience classes with those model and
> modelObject accessors.
I strongly disagree. There are good reasons for Wicket to bind model
and component together and I think what we have in 1.4 right now is a
balanced compromise. Also if we don't provide the convenience classes
people will bound to write their own (because it's the only reasonable
way to migrate project that already uses generics).
>
> In cases where two components share the same model, it would
> make sense to make the IModel field in each component final.
> Then setModel() does not make sense any more; all it could
> do would be throw an exception or be a confusing no-op.
> Likewise, sometimes you never do setModelObject() or
> getModelObject() from outside the class.
You don't have to use those methods, there are for convenience only.
>
> Leaner APIs and less methods per objects are good things.
> Hence it's better to add methods as you need them, instead
> of providing a lot of convenience stuff that is only used a
> part of the time. Surely each Component subclass has anyway
> a lot of methods, and MarkupContainers even more, but you
> have got to start somewhere :)
I don't buy this. Our components have a lot of methods, but most of
them are not part of public API. I plan to prefix those methods with a
common prefix for 1.5 so they don't confuse regular users. But I
really don't see how removing four methods (*defaultModel) improves
our api.
We will always need some kind of utility methods for manipulating
models in component.
Models have always been conceptually bound to component. Right now the
problem of our API is not that we have a model slot in component. It
is that we have exactly one model slot. This doesn't work well for all
components, since some don't need model at all and some need more than
one.
Unfortunately the component <-> model contract is quite complicated as
we have compound models, componentassignedmodels, etc so a simple
property for model doesn't really cut it. We still need some kind of
model manipuation methods. Something like current setDefaultModel,...
but more flexible. And when we do have it, having
GenericPanel,Fragment,... might make the migration for users lot
esier. Now thinking about it, the name should really suggest that
there is one model per component. Maybe PanelWithModel could be the
name after all :)
-Matej
>
> This is not a big deal though, either way is fine by me.
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Tue, 01 Jul 2008, Matej Knopp wrote:
> There is one thing that helped me quite a lot when migration the
> project I'm working out. I've created GenericPanel,
> GenericWebMarkupContainer and GenericFragment classes. In most cases
> the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.
Maybe the names could be TypedPanel / ModelContainingPanel
or something like that?
Or maybe start with the original component name so that they
would pop up more easily in the IDE, for example
PanelWithType / PanelWithModel?
> I was wondering, even though those classes were farily simple, we
> might want to include them in Wicket anyway, for the sake of
> consistency and convenience.
I thought about this and I think that it might be better to
not include them after all. In 1.5 it would be great to
separate IModel and Component more thoroughly, getting rid
of the defaultModel* accessors. Then it would make less
sense to have the convenience classes with those model and
modelObject accessors.
In cases where two components share the same model, it would
make sense to make the IModel field in each component final.
Then setModel() does not make sense any more; all it could
do would be throw an exception or be a confusing no-op.
Likewise, sometimes you never do setModelObject() or
getModelObject() from outside the class.
Leaner APIs and less methods per objects are good things.
Hence it's better to add methods as you need them, instead
of providing a lot of convenience stuff that is only used a
part of the time. Surely each Component subclass has anyway
a lot of methods, and MarkupContainers even more, but you
have got to start somewhere :)
This is not a big deal though, either way is fine by me.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Matej Knopp <ma...@gmail.com>.
There is one thing that helped me quite a lot when migration the
project I'm working out. I've created GenericPanel,
GenericWebMarkupContainer and GenericFragment classes. In most cases
the only change was renaming Panel<MyClass> to GenericPanel<MyClass>.
I was wondering, even though those classes were farily simple, we
might want to include them in Wicket anyway, for the sake of
consistency and convenience.
-Matej
On Mon, Jun 30, 2008 at 12:28 PM, Johan Compagner <jc...@gmail.com> wrote:
> i looked through the code and it is fine by me.
> Lets test this then in a Build and see what people think of this.
>
>
> On Mon, Jun 30, 2008 at 8:54 AM, Igor Vaynberg <ig...@gmail.com>
> wrote:
>
>> unit tests are fixed...
>>
>> -igor
>>
>> On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst
>> <ma...@gmail.com> wrote:
>> > I'm guessing somewhere this week or so. We need to flush out the unit
>> > test failures and get some preliminary feedback. Also we need to have
>> > time available to actually build the release.
>> >
>> > My time is limited because we're in the final stages before publishing
>> > and I have to read our book twice or so.
>> >
>> > Martijn
>> >
>> > On Mon, Jun 30, 2008 at 2:36 AM, James Carman
>> > <ja...@carmanconsulting.com> wrote:
>> >> What sort of time frame are we looking at for a release with this new
>> >> generics paradigm?
>> >>
>> >> On Sun, Jun 29, 2008 at 3:54 PM, Igor Vaynberg <ig...@gmail.com>
>> wrote:
>> >>> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sv...@meiers.net> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> I've just converted two projects to the new generics setup and
>> everything
>> >>>> worked out nicely.
>> >>>> I think this is how generics should be applied to Wicket.
>> >>>>
>> >>>> Igor, thanks for your hard work on this.
>> >>>
>> >>> wasnt just me :)
>> >>>
>> >>> -igor
>> >>>
>> >>>>
>> >>>> Sven
>> >>>>
>> >>>> Igor Vaynberg schrieb:
>> >>>>>
>> >>>>> development of the 1.4 branch has been quiet lately, this is because
>> >>>>> the core team has been busy working on an alternative way of
>> >>>>> generifiing the framework. an early result of that effort can be
>> found
>> >>>>> here [1]. The key difference in [1] is that we have decoupled the
>> >>>>> component from the type of the model.
>> >>>>>
>> >>>>> here is the list of major differences:
>> >>>>>
>> >>>>> (1) only components that use their model have a generic type
>> >>>>> (components you are likely to call getmodel/getmodelobject on as a
>> >>>>> user). so far these are link,form,formcomponent
>> >>>>> subclasses,listview,listitem,(other repeaters will follow soon). this
>> >>>>> allows for typesafety where it makes sense, and eliminates a ton of
>> >>>>> noise from code. we will generify others upon request if a good
>> >>>>> usecase is provided and we think it is widely applicable.
>> >>>>>
>> >>>>> (2) non-generified components do not have IModel<T> get/setModel and
>> T
>> >>>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel
>> and
>> >>>>> Object get/setDefaultModelObject. this clearly expresses that the
>> >>>>> default component model is not tied to the type of component. this is
>> >>>>> a bit of a pain from the code migration point of view, but we think
>> is
>> >>>>> worth the effort. generifyed components are free to implement the old
>> >>>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>> >>>>> see ListItem for an example.
>> >>>>>
>> >>>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>> >>>>> is a call for confirmation/discussion from our user base. do try to
>> >>>>> port a small project or a part of a larger project you are working on
>> >>>>> to the [1] branch to see how the new api feels. if we do like this
>> >>>>> more the new branch will be merged into what will be 1.4m3.
>> >>>>>
>> >>>>> [1]
>> https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>> >>>>>
>> >>>>> -igor
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Become a Wicket expert, learn from the best: http://wicketinaction.com
>> > Apache Wicket 1.3.4 is released
>> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Johan Compagner <jc...@gmail.com>.
i looked through the code and it is fine by me.
Lets test this then in a Build and see what people think of this.
On Mon, Jun 30, 2008 at 8:54 AM, Igor Vaynberg <ig...@gmail.com>
wrote:
> unit tests are fixed...
>
> -igor
>
> On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst
> <ma...@gmail.com> wrote:
> > I'm guessing somewhere this week or so. We need to flush out the unit
> > test failures and get some preliminary feedback. Also we need to have
> > time available to actually build the release.
> >
> > My time is limited because we're in the final stages before publishing
> > and I have to read our book twice or so.
> >
> > Martijn
> >
> > On Mon, Jun 30, 2008 at 2:36 AM, James Carman
> > <ja...@carmanconsulting.com> wrote:
> >> What sort of time frame are we looking at for a release with this new
> >> generics paradigm?
> >>
> >> On Sun, Jun 29, 2008 at 3:54 PM, Igor Vaynberg <ig...@gmail.com>
> wrote:
> >>> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sv...@meiers.net> wrote:
> >>>> Hi,
> >>>>
> >>>> I've just converted two projects to the new generics setup and
> everything
> >>>> worked out nicely.
> >>>> I think this is how generics should be applied to Wicket.
> >>>>
> >>>> Igor, thanks for your hard work on this.
> >>>
> >>> wasnt just me :)
> >>>
> >>> -igor
> >>>
> >>>>
> >>>> Sven
> >>>>
> >>>> Igor Vaynberg schrieb:
> >>>>>
> >>>>> development of the 1.4 branch has been quiet lately, this is because
> >>>>> the core team has been busy working on an alternative way of
> >>>>> generifiing the framework. an early result of that effort can be
> found
> >>>>> here [1]. The key difference in [1] is that we have decoupled the
> >>>>> component from the type of the model.
> >>>>>
> >>>>> here is the list of major differences:
> >>>>>
> >>>>> (1) only components that use their model have a generic type
> >>>>> (components you are likely to call getmodel/getmodelobject on as a
> >>>>> user). so far these are link,form,formcomponent
> >>>>> subclasses,listview,listitem,(other repeaters will follow soon). this
> >>>>> allows for typesafety where it makes sense, and eliminates a ton of
> >>>>> noise from code. we will generify others upon request if a good
> >>>>> usecase is provided and we think it is widely applicable.
> >>>>>
> >>>>> (2) non-generified components do not have IModel<T> get/setModel and
> T
> >>>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel
> and
> >>>>> Object get/setDefaultModelObject. this clearly expresses that the
> >>>>> default component model is not tied to the type of component. this is
> >>>>> a bit of a pain from the code migration point of view, but we think
> is
> >>>>> worth the effort. generifyed components are free to implement the old
> >>>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
> >>>>> see ListItem for an example.
> >>>>>
> >>>>> basically we feel this is a much cleaner way then what is 1.4m2. this
> >>>>> is a call for confirmation/discussion from our user base. do try to
> >>>>> port a small project or a part of a larger project you are working on
> >>>>> to the [1] branch to see how the new api feels. if we do like this
> >>>>> more the new branch will be merged into what will be 1.4m3.
> >>>>>
> >>>>> [1]
> https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
> >>>>>
> >>>>> -igor
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > Apache Wicket 1.3.4 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
unit tests are fixed...
-igor
On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst
<ma...@gmail.com> wrote:
> I'm guessing somewhere this week or so. We need to flush out the unit
> test failures and get some preliminary feedback. Also we need to have
> time available to actually build the release.
>
> My time is limited because we're in the final stages before publishing
> and I have to read our book twice or so.
>
> Martijn
>
> On Mon, Jun 30, 2008 at 2:36 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> What sort of time frame are we looking at for a release with this new
>> generics paradigm?
>>
>> On Sun, Jun 29, 2008 at 3:54 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sv...@meiers.net> wrote:
>>>> Hi,
>>>>
>>>> I've just converted two projects to the new generics setup and everything
>>>> worked out nicely.
>>>> I think this is how generics should be applied to Wicket.
>>>>
>>>> Igor, thanks for your hard work on this.
>>>
>>> wasnt just me :)
>>>
>>> -igor
>>>
>>>>
>>>> Sven
>>>>
>>>> Igor Vaynberg schrieb:
>>>>>
>>>>> development of the 1.4 branch has been quiet lately, this is because
>>>>> the core team has been busy working on an alternative way of
>>>>> generifiing the framework. an early result of that effort can be found
>>>>> here [1]. The key difference in [1] is that we have decoupled the
>>>>> component from the type of the model.
>>>>>
>>>>> here is the list of major differences:
>>>>>
>>>>> (1) only components that use their model have a generic type
>>>>> (components you are likely to call getmodel/getmodelobject on as a
>>>>> user). so far these are link,form,formcomponent
>>>>> subclasses,listview,listitem,(other repeaters will follow soon). this
>>>>> allows for typesafety where it makes sense, and eliminates a ton of
>>>>> noise from code. we will generify others upon request if a good
>>>>> usecase is provided and we think it is widely applicable.
>>>>>
>>>>> (2) non-generified components do not have IModel<T> get/setModel and T
>>>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
>>>>> Object get/setDefaultModelObject. this clearly expresses that the
>>>>> default component model is not tied to the type of component. this is
>>>>> a bit of a pain from the code migration point of view, but we think is
>>>>> worth the effort. generifyed components are free to implement the old
>>>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>>>>> see ListItem for an example.
>>>>>
>>>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>>>>> is a call for confirmation/discussion from our user base. do try to
>>>>> port a small project or a part of a larger project you are working on
>>>>> to the [1] branch to see how the new api feels. if we do like this
>>>>> more the new branch will be merged into what will be 1.4m3.
>>>>>
>>>>> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>>>>>
>>>>> -igor
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Martijn Dashorst <ma...@gmail.com>.
I'm guessing somewhere this week or so. We need to flush out the unit
test failures and get some preliminary feedback. Also we need to have
time available to actually build the release.
My time is limited because we're in the final stages before publishing
and I have to read our book twice or so.
Martijn
On Mon, Jun 30, 2008 at 2:36 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> What sort of time frame are we looking at for a release with this new
> generics paradigm?
>
> On Sun, Jun 29, 2008 at 3:54 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sv...@meiers.net> wrote:
>>> Hi,
>>>
>>> I've just converted two projects to the new generics setup and everything
>>> worked out nicely.
>>> I think this is how generics should be applied to Wicket.
>>>
>>> Igor, thanks for your hard work on this.
>>
>> wasnt just me :)
>>
>> -igor
>>
>>>
>>> Sven
>>>
>>> Igor Vaynberg schrieb:
>>>>
>>>> development of the 1.4 branch has been quiet lately, this is because
>>>> the core team has been busy working on an alternative way of
>>>> generifiing the framework. an early result of that effort can be found
>>>> here [1]. The key difference in [1] is that we have decoupled the
>>>> component from the type of the model.
>>>>
>>>> here is the list of major differences:
>>>>
>>>> (1) only components that use their model have a generic type
>>>> (components you are likely to call getmodel/getmodelobject on as a
>>>> user). so far these are link,form,formcomponent
>>>> subclasses,listview,listitem,(other repeaters will follow soon). this
>>>> allows for typesafety where it makes sense, and eliminates a ton of
>>>> noise from code. we will generify others upon request if a good
>>>> usecase is provided and we think it is widely applicable.
>>>>
>>>> (2) non-generified components do not have IModel<T> get/setModel and T
>>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
>>>> Object get/setDefaultModelObject. this clearly expresses that the
>>>> default component model is not tied to the type of component. this is
>>>> a bit of a pain from the code migration point of view, but we think is
>>>> worth the effort. generifyed components are free to implement the old
>>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>>>> see ListItem for an example.
>>>>
>>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>>>> is a call for confirmation/discussion from our user base. do try to
>>>> port a small project or a part of a larger project you are working on
>>>> to the [1] branch to see how the new api feels. if we do like this
>>>> more the new branch will be merged into what will be 1.4m3.
>>>>
>>>> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>>>>
>>>> -igor
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by James Carman <ja...@carmanconsulting.com>.
What sort of time frame are we looking at for a release with this new
generics paradigm?
On Sun, Jun 29, 2008 at 3:54 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sv...@meiers.net> wrote:
>> Hi,
>>
>> I've just converted two projects to the new generics setup and everything
>> worked out nicely.
>> I think this is how generics should be applied to Wicket.
>>
>> Igor, thanks for your hard work on this.
>
> wasnt just me :)
>
> -igor
>
>>
>> Sven
>>
>> Igor Vaynberg schrieb:
>>>
>>> development of the 1.4 branch has been quiet lately, this is because
>>> the core team has been busy working on an alternative way of
>>> generifiing the framework. an early result of that effort can be found
>>> here [1]. The key difference in [1] is that we have decoupled the
>>> component from the type of the model.
>>>
>>> here is the list of major differences:
>>>
>>> (1) only components that use their model have a generic type
>>> (components you are likely to call getmodel/getmodelobject on as a
>>> user). so far these are link,form,formcomponent
>>> subclasses,listview,listitem,(other repeaters will follow soon). this
>>> allows for typesafety where it makes sense, and eliminates a ton of
>>> noise from code. we will generify others upon request if a good
>>> usecase is provided and we think it is widely applicable.
>>>
>>> (2) non-generified components do not have IModel<T> get/setModel and T
>>> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
>>> Object get/setDefaultModelObject. this clearly expresses that the
>>> default component model is not tied to the type of component. this is
>>> a bit of a pain from the code migration point of view, but we think is
>>> worth the effort. generifyed components are free to implement the old
>>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>>> see ListItem for an example.
>>>
>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>>> is a call for confirmation/discussion from our user base. do try to
>>> port a small project or a part of a larger project you are working on
>>> to the [1] branch to see how the new api feels. if we do like this
>>> more the new branch will be merged into what will be 1.4m3.
>>>
>>> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>>>
>>> -igor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sv...@meiers.net> wrote:
> Hi,
>
> I've just converted two projects to the new generics setup and everything
> worked out nicely.
> I think this is how generics should be applied to Wicket.
>
> Igor, thanks for your hard work on this.
wasnt just me :)
-igor
>
> Sven
>
> Igor Vaynberg schrieb:
>>
>> development of the 1.4 branch has been quiet lately, this is because
>> the core team has been busy working on an alternative way of
>> generifiing the framework. an early result of that effort can be found
>> here [1]. The key difference in [1] is that we have decoupled the
>> component from the type of the model.
>>
>> here is the list of major differences:
>>
>> (1) only components that use their model have a generic type
>> (components you are likely to call getmodel/getmodelobject on as a
>> user). so far these are link,form,formcomponent
>> subclasses,listview,listitem,(other repeaters will follow soon). this
>> allows for typesafety where it makes sense, and eliminates a ton of
>> noise from code. we will generify others upon request if a good
>> usecase is provided and we think it is widely applicable.
>>
>> (2) non-generified components do not have IModel<T> get/setModel and T
>> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
>> Object get/setDefaultModelObject. this clearly expresses that the
>> default component model is not tied to the type of component. this is
>> a bit of a pain from the code migration point of view, but we think is
>> worth the effort. generifyed components are free to implement the old
>> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
>> see ListItem for an example.
>>
>> basically we feel this is a much cleaner way then what is 1.4m2. this
>> is a call for confirmation/discussion from our user base. do try to
>> port a small project or a part of a larger project you are working on
>> to the [1] branch to see how the new api feels. if we do like this
>> more the new branch will be merged into what will be 1.4m3.
>>
>> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>>
>> -igor
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Sven Meier <sv...@meiers.net>.
Hi,
I've just converted two projects to the new generics setup and
everything worked out nicely.
I think this is how generics should be applied to Wicket.
Igor, thanks for your hard work on this.
Sven
Igor Vaynberg schrieb:
> development of the 1.4 branch has been quiet lately, this is because
> the core team has been busy working on an alternative way of
> generifiing the framework. an early result of that effort can be found
> here [1]. The key difference in [1] is that we have decoupled the
> component from the type of the model.
>
> here is the list of major differences:
>
> (1) only components that use their model have a generic type
> (components you are likely to call getmodel/getmodelobject on as a
> user). so far these are link,form,formcomponent
> subclasses,listview,listitem,(other repeaters will follow soon). this
> allows for typesafety where it makes sense, and eliminates a ton of
> noise from code. we will generify others upon request if a good
> usecase is provided and we think it is widely applicable.
>
> (2) non-generified components do not have IModel<T> get/setModel and T
> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
> Object get/setDefaultModelObject. this clearly expresses that the
> default component model is not tied to the type of component. this is
> a bit of a pain from the code migration point of view, but we think is
> worth the effort. generifyed components are free to implement the old
> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
> see ListItem for an example.
>
> basically we feel this is a much cleaner way then what is 1.4m2. this
> is a call for confirmation/discussion from our user base. do try to
> port a small project or a part of a larger project you are working on
> to the [1] branch to see how the new api feels. if we do like this
> more the new branch will be merged into what will be 1.4m3.
>
> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>
> -igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: generics
Posted by Stefan Lindner <li...@visionet.de>.
I still prefer the M2 way of generics but if this can become the common
sense about Generics for the 1.4 release apply this change. The sooner
the better.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
> To be a little dramatic: A 100k line project where 50% of forms are
> generified and the other are using casts doesn't seem very nice.
But if you would find the need to cast the model object of a component
(form), that's the time to use the generic version. So you'd only use
the non-generic versions when you don't do anything interesting with
the model (or don't use it at all).
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Rodolfo Hansen <rh...@kindleit.net>.
IMHO too many ways to do the same thing makes a project very hard to
maintain.
Development generally becomes more expensive and error prone, as you forget
the initial mindset you where in when you started, or have the same
components used one way in here, and another way there.
One has to be wary of a framework that is too orthogonal. At least in my
opinion...
I like how you guys have treated the whole generics issue, precisely in the
sense that there wont be the choice of having the same component either
generified or ungenerified..
To be a little dramatic: A 100k line project where 50% of forms are
generified and the other are using casts doesn't seem very nice.
On Wed, Jul 2, 2008 at 9:43 AM, Johan Compagner <jc...@gmail.com>
wrote:
> the 13 bookmarkable link are not really model things anyway :)
>
> But this discussions just tells us that many people uses things many
> different ways.
> And that is just a problem to say what is the good way
> So i think i am still +1 for a Link and a Generic/ModelLink
>
> johan
>
>
> On Wed, Jul 2, 2008 at 3:37 PM, Erik van Oosten <e....@grons.nl>
> wrote:
>
> > In my current project we try to do everything by BookmarkablePageLinks.
> >
> > Count:
> > - 1 Link with an abstractreadonlymodel
> > - 14 Links without model
> > - 13 bookmarkablepagelinks without model
> > - 2 ajaxfallbacklinks without model
> >
> > in addition we have 4 many used subclasses of bookmarkablepagelink that
> do
> > not have a model.
> >
> > Maybe not representative, but with 1 link with a model out of 30+ lead me
> > to think that Link without generics is just fine. For Forms I would like
> to
> > keep generics.
> >
> > Regards,
> > Erik.
> >
> >
> > Igor Vaynberg wrote:
> >
> >> the question here is: do most people use the model in the Link or not?
> >>
> >> when you use compound property model in conjunction with form
> >> components you never call getmodel/object() on those either. what now?
> >> not generify form components? i dont think a strict criteria will
> >> work.
> >>
> >> some components fall into a gray area which needs to be discussed and
> >> generified on case by case basis. when i was generifying wicket my
> >> primary usecase is to use Link with a model so i went that way. start
> >> a discussion/vote and see where that goes in a different thread. i
> >> will be happy to go with what the majority thinks in this particular
> >> case.
> >>
> >> -igor
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: generics
Posted by Johan Compagner <jc...@gmail.com>.
the 13 bookmarkable link are not really model things anyway :)
But this discussions just tells us that many people uses things many
different ways.
And that is just a problem to say what is the good way
So i think i am still +1 for a Link and a Generic/ModelLink
johan
On Wed, Jul 2, 2008 at 3:37 PM, Erik van Oosten <e....@grons.nl>
wrote:
> In my current project we try to do everything by BookmarkablePageLinks.
>
> Count:
> - 1 Link with an abstractreadonlymodel
> - 14 Links without model
> - 13 bookmarkablepagelinks without model
> - 2 ajaxfallbacklinks without model
>
> in addition we have 4 many used subclasses of bookmarkablepagelink that do
> not have a model.
>
> Maybe not representative, but with 1 link with a model out of 30+ lead me
> to think that Link without generics is just fine. For Forms I would like to
> keep generics.
>
> Regards,
> Erik.
>
>
> Igor Vaynberg wrote:
>
>> the question here is: do most people use the model in the Link or not?
>>
>> when you use compound property model in conjunction with form
>> components you never call getmodel/object() on those either. what now?
>> not generify form components? i dont think a strict criteria will
>> work.
>>
>> some components fall into a gray area which needs to be discussed and
>> generified on case by case basis. when i was generifying wicket my
>> primary usecase is to use Link with a model so i went that way. start
>> a discussion/vote and see where that goes in a different thread. i
>> will be happy to go with what the majority thinks in this particular
>> case.
>>
>> -igor
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: generics
Posted by Erik van Oosten <e....@grons.nl>.
In my current project we try to do everything by BookmarkablePageLinks.
Count:
- 1 Link with an abstractreadonlymodel
- 14 Links without model
- 13 bookmarkablepagelinks without model
- 2 ajaxfallbacklinks without model
in addition we have 4 many used subclasses of bookmarkablepagelink that
do not have a model.
Maybe not representative, but with 1 link with a model out of 30+ lead
me to think that Link without generics is just fine. For Forms I would
like to keep generics.
Regards,
Erik.
Igor Vaynberg wrote:
> the question here is: do most people use the model in the Link or not?
>
> when you use compound property model in conjunction with form
> components you never call getmodel/object() on those either. what now?
> not generify form components? i dont think a strict criteria will
> work.
>
> some components fall into a gray area which needs to be discussed and
> generified on case by case basis. when i was generifying wicket my
> primary usecase is to use Link with a model so i went that way. start
> a discussion/vote and see where that goes in a different thread. i
> will be happy to go with what the majority thinks in this particular
> case.
>
> -igor
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
the question here is: do most people use the model in the Link or not?
when you use compound property model in conjunction with form
components you never call getmodel/object() on those either. what now?
not generify form components? i dont think a strict criteria will
work.
some components fall into a gray area which needs to be discussed and
generified on case by case basis. when i was generifying wicket my
primary usecase is to use Link with a model so i went that way. start
a discussion/vote and see where that goes in a different thread. i
will be happy to go with what the majority thinks in this particular
case.
-igor
On Tue, Jul 1, 2008 at 2:34 PM, Sven Meier <sv...@meiers.net> wrote:
> Wouldn't it be better to leave the generic part to this reusable link then?
> Why 'pollute' all links with a generic parameter?
>
> Back to your definition:
>
>>> (1) only components that use their model have a generic type
>>> (components you are likely to call getmodel/getmodelobject on as a
>>> user).
>
> What now? Components that use their model *or* you're likely to call
> getmodel on? Seems to me as two different things:
> Link doesn't fit in the first category nor is it always used with a model.
>
> Sven
>
> Igor Vaynberg schrieb:
>>
>> if your link is anonymous, yes. if you have reusable links in their
>> own class, then no.
>>
>> -igor
>>
>> On Tue, Jul 1, 2008 at 12:24 PM, Joni Freeman <jo...@ri.fi> wrote:
>>
>>>
>>> Isn't this a same thing:
>>>
>>> onPopulateItem(final Item<User> item) {
>>> add(new Link("delete") {
>>> protected void onClick() { service.delete(item.getModelObject()); }
>>> });
>>> }
>>>
>>> Joni
>>>
>>> On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
>>>
>>>>
>>>> onPopulateItem(Item<User> item) {
>>>> add(new Link<User>("delete", item.getModel()) {
>>>> protected void onClick() { service.delete(getModelObject()); }
>>>> });
>>>> }
>>>>
>>>> -igor
>>>>
>>>> On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rh...@kindleit.net>
>>>> wrote:
>>>>
>>>>>
>>>>> I too like this compromise alot
>>>>>
>>>>> Although I don't see a good use case for generifying Link ?
>>>>> Am I missing something?
>>>>>
>>>>>
>>>>> On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho
>>>>> <Ti...@ri.fi>
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>>>>>>
>>>>>>>
>>>>>>> since no one complained, should we apply this change over the
>>>>>>> weekend?
>>>>>>> and soon thereafter release m3?
>>>>>>>
>>>>>>
>>>>>> I prefer this over M2. Even though:
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> user). so far these are link,form,formcomponent
>>>>>>>>
>>>>>>
>>>>>> Link might be better without the type parameter. It's no big
>>>>>> deal though.
>>>>>>
>>>>>> And yes, it would be good if for example Johan and Gerolf
>>>>>> who have invested a lot of effort on the generification
>>>>>> could have a closer look and tell what they think before
>>>>>> proceeding.
>>>>>>
>>>>>> Best wishes,
>>>>>> Timo
>>>>>>
>>>>>> --
>>>>>> Timo Rantalaiho
>>>>>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Sven Meier <sv...@meiers.net>.
Wouldn't it be better to leave the generic part to this reusable link
then? Why 'pollute' all links with a generic parameter?
Back to your definition:
>> (1) only components that use their model have a generic type
>> (components you are likely to call getmodel/getmodelobject on as a
>> user).
What now? Components that use their model *or* you're likely to call getmodel on? Seems to me as two different things:
Link doesn't fit in the first category nor is it always used with a model.
Sven
Igor Vaynberg schrieb:
> if your link is anonymous, yes. if you have reusable links in their
> own class, then no.
>
> -igor
>
> On Tue, Jul 1, 2008 at 12:24 PM, Joni Freeman <jo...@ri.fi> wrote:
>
>> Isn't this a same thing:
>>
>> onPopulateItem(final Item<User> item) {
>> add(new Link("delete") {
>> protected void onClick() { service.delete(item.getModelObject()); }
>> });
>> }
>>
>> Joni
>>
>> On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
>>
>>> onPopulateItem(Item<User> item) {
>>> add(new Link<User>("delete", item.getModel()) {
>>> protected void onClick() { service.delete(getModelObject()); }
>>> });
>>> }
>>>
>>> -igor
>>>
>>> On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rh...@kindleit.net> wrote:
>>>
>>>> I too like this compromise alot
>>>>
>>>> Although I don't see a good use case for generifying Link ?
>>>> Am I missing something?
>>>>
>>>>
>>>> On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Ti...@ri.fi>
>>>> wrote:
>>>>
>>>>
>>>>> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>>>>>
>>>>>> since no one complained, should we apply this change over the weekend?
>>>>>> and soon thereafter release m3?
>>>>>>
>>>>> I prefer this over M2. Even though:
>>>>>
>>>>>
>>>>>>> user). so far these are link,form,formcomponent
>>>>>>>
>>>>> Link might be better without the type parameter. It's no big
>>>>> deal though.
>>>>>
>>>>> And yes, it would be good if for example Johan and Gerolf
>>>>> who have invested a lot of effort on the generification
>>>>> could have a closer look and tell what they think before
>>>>> proceeding.
>>>>>
>>>>> Best wishes,
>>>>> Timo
>>>>>
>>>>> --
>>>>> Timo Rantalaiho
>>>>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
if your link is anonymous, yes. if you have reusable links in their
own class, then no.
-igor
On Tue, Jul 1, 2008 at 12:24 PM, Joni Freeman <jo...@ri.fi> wrote:
> Isn't this a same thing:
>
> onPopulateItem(final Item<User> item) {
> add(new Link("delete") {
> protected void onClick() { service.delete(item.getModelObject()); }
> });
> }
>
> Joni
>
> On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
>> onPopulateItem(Item<User> item) {
>> add(new Link<User>("delete", item.getModel()) {
>> protected void onClick() { service.delete(getModelObject()); }
>> });
>> }
>>
>> -igor
>>
>> On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rh...@kindleit.net> wrote:
>> > I too like this compromise alot
>> >
>> > Although I don't see a good use case for generifying Link ?
>> > Am I missing something?
>> >
>> >
>> > On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Ti...@ri.fi>
>> > wrote:
>> >
>> >> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>> >> > since no one complained, should we apply this change over the weekend?
>> >> > and soon thereafter release m3?
>> >>
>> >> I prefer this over M2. Even though:
>> >>
>> >> > > user). so far these are link,form,formcomponent
>> >>
>> >> Link might be better without the type parameter. It's no big
>> >> deal though.
>> >>
>> >> And yes, it would be good if for example Johan and Gerolf
>> >> who have invested a lot of effort on the generification
>> >> could have a closer look and tell what they think before
>> >> proceeding.
>> >>
>> >> Best wishes,
>> >> Timo
>> >>
>> >> --
>> >> Timo Rantalaiho
>> >> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Joni Freeman <jo...@ri.fi>.
Isn't this a same thing:
onPopulateItem(final Item<User> item) {
add(new Link("delete") {
protected void onClick() { service.delete(item.getModelObject()); }
});
}
Joni
On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
> onPopulateItem(Item<User> item) {
> add(new Link<User>("delete", item.getModel()) {
> protected void onClick() { service.delete(getModelObject()); }
> });
> }
>
> -igor
>
> On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rh...@kindleit.net> wrote:
> > I too like this compromise alot
> >
> > Although I don't see a good use case for generifying Link ?
> > Am I missing something?
> >
> >
> > On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Ti...@ri.fi>
> > wrote:
> >
> >> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
> >> > since no one complained, should we apply this change over the weekend?
> >> > and soon thereafter release m3?
> >>
> >> I prefer this over M2. Even though:
> >>
> >> > > user). so far these are link,form,formcomponent
> >>
> >> Link might be better without the type parameter. It's no big
> >> deal though.
> >>
> >> And yes, it would be good if for example Johan and Gerolf
> >> who have invested a lot of effort on the generification
> >> could have a closer look and tell what they think before
> >> proceeding.
> >>
> >> Best wishes,
> >> Timo
> >>
> >> --
> >> Timo Rantalaiho
> >> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
onPopulateItem(Item<User> item) {
add(new Link<User>("delete", item.getModel()) {
protected void onClick() { service.delete(getModelObject()); }
});
}
-igor
On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen <rh...@kindleit.net> wrote:
> I too like this compromise alot
>
> Although I don't see a good use case for generifying Link ?
> Am I missing something?
>
>
> On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Ti...@ri.fi>
> wrote:
>
>> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>> > since no one complained, should we apply this change over the weekend?
>> > and soon thereafter release m3?
>>
>> I prefer this over M2. Even though:
>>
>> > > user). so far these are link,form,formcomponent
>>
>> Link might be better without the type parameter. It's no big
>> deal though.
>>
>> And yes, it would be good if for example Johan and Gerolf
>> who have invested a lot of effort on the generification
>> could have a closer look and tell what they think before
>> proceeding.
>>
>> Best wishes,
>> Timo
>>
>> --
>> Timo Rantalaiho
>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Patrick Angeles <pa...@inertiabev.com>.
add (new Link<Person>("edit", person) {
public void onClick () {
setResponsePage (new EditPersonPage (getModel()));
}
});
This code makes a lot more sense if it is inside a repeater...
Rodolfo Hansen-2 wrote:
>
> I too like this compromise alot
>
> Although I don't see a good use case for generifying Link ?
> Am I missing something?
>
>
> On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Ti...@ri.fi>
> wrote:
>
>> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>> > since no one complained, should we apply this change over the weekend?
>> > and soon thereafter release m3?
>>
>> I prefer this over M2. Even though:
>>
>> > > user). so far these are link,form,formcomponent
>>
>> Link might be better without the type parameter. It's no big
>> deal though.
>>
>> And yes, it would be good if for example Johan and Gerolf
>> who have invested a lot of effort on the generification
>> could have a closer look and tell what they think before
>> proceeding.
>>
>> Best wishes,
>> Timo
>>
>> --
>> Timo Rantalaiho
>> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/generics-tp18083910p18222901.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Rodolfo Hansen <rh...@kindleit.net>.
I too like this compromise alot
Although I don't see a good use case for generifying Link ?
Am I missing something?
On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho <Ti...@ri.fi>
wrote:
> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
> > since no one complained, should we apply this change over the weekend?
> > and soon thereafter release m3?
>
> I prefer this over M2. Even though:
>
> > > user). so far these are link,form,formcomponent
>
> Link might be better without the type parameter. It's no big
> deal though.
>
> And yes, it would be good if for example Johan and Gerolf
> who have invested a lot of effort on the generification
> could have a closer look and tell what they think before
> proceeding.
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
i have just checked in the refactored generics into trunk.
there are some unit test failures that need to be looked at, i wont
have time until tomorrow evening though; if someone can look into the
tests in the meanwhile that would be great.
-igor
On Fri, Jun 27, 2008 at 11:49 AM, Timo Rantalaiho <Ti...@ri.fi> wrote:
> On Fri, 27 Jun 2008, Igor Vaynberg wrote:
>> since no one complained, should we apply this change over the weekend?
>> and soon thereafter release m3?
>
> I prefer this over M2. Even though:
>
>> > user). so far these are link,form,formcomponent
>
> Link might be better without the type parameter. It's no big
> deal though.
>
> And yes, it would be good if for example Johan and Gerolf
> who have invested a lot of effort on the generification
> could have a closer look and tell what they think before
> proceeding.
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Fri, 27 Jun 2008, Igor Vaynberg wrote:
> since no one complained, should we apply this change over the weekend?
> and soon thereafter release m3?
I prefer this over M2. Even though:
> > user). so far these are link,form,formcomponent
Link might be better without the type parameter. It's no big
deal though.
And yes, it would be good if for example Johan and Gerolf
who have invested a lot of effort on the generification
could have a closer look and tell what they think before
proceeding.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Eelco Hillenius <ee...@gmail.com>.
On Fri, Jun 27, 2008 at 8:08 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> since no one complained, should we apply this change over the weekend?
> and soon thereafter release m3?
I'm in favor of the new branch, so yes. But it would be great to see a
few more opinions.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: generics
Posted by Igor Vaynberg <ig...@gmail.com>.
since no one complained, should we apply this change over the weekend?
and soon thereafter release m3?
-igor
On Mon, Jun 23, 2008 at 10:12 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> development of the 1.4 branch has been quiet lately, this is because
> the core team has been busy working on an alternative way of
> generifiing the framework. an early result of that effort can be found
> here [1]. The key difference in [1] is that we have decoupled the
> component from the type of the model.
>
> here is the list of major differences:
>
> (1) only components that use their model have a generic type
> (components you are likely to call getmodel/getmodelobject on as a
> user). so far these are link,form,formcomponent
> subclasses,listview,listitem,(other repeaters will follow soon). this
> allows for typesafety where it makes sense, and eliminates a ton of
> noise from code. we will generify others upon request if a good
> usecase is provided and we think it is widely applicable.
>
> (2) non-generified components do not have IModel<T> get/setModel and T
> get/setModelObject, instead they have IModel<?>get/setDefaultModel and
> Object get/setDefaultModelObject. this clearly expresses that the
> default component model is not tied to the type of component. this is
> a bit of a pain from the code migration point of view, but we think is
> worth the effort. generifyed components are free to implement the old
> IModel<T> get/setModel, etc, but have to keep the unsafe cast inside.
> see ListItem for an example.
>
> basically we feel this is a much cleaner way then what is 1.4m2. this
> is a call for confirmation/discussion from our user base. do try to
> port a small project or a part of a larger project you are working on
> to the [1] branch to see how the new api feels. if we do like this
> more the new branch will be merged into what will be 1.4m3.
>
> [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics
>
> -igor
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org