|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
|
|
genericsdevelopment 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@... For additional commands, e-mail: users-help@... |
|
|
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/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@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsI 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@... > For additional commands, e-mail: users-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsI 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 <brill@...> 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@... >> For additional commands, e-mail: users-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > -- 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@... For additional commands, e-mail: users-help@... |
|
|
RE: genericsI'm getting the same thing.
-----Original Message----- From: Martin Funk [mailto:mafulafunk@...] Sent: Tuesday, June 24, 2008 10:42 AM To: users@... 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@... For additional commands, e-mail: users-help@... ______________ 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@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsshould 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 <mafulafunk@...> 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@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsIgor 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@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsIgor 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@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsUnfortunately 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 <martijn.dashorst@...> 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 <brill@...> 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@... >>> For additional commands, e-mail: users-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > > -- > 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@... For additional commands, e-mail: users-help@... |
|
|
Re: genericssince 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 <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@... For additional commands, e-mail: users-help@... |
|
|
RE: genericsI 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@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsOn Fri, Jun 27, 2008 at 8:08 AM, Igor Vaynberg <igor.vaynberg@...> 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@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsOn 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@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsi 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 <Timo.Rantalaiho@...> 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@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsHi,
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@... > For additional commands, e-mail: users-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsOn Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sven@...> 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@... >> For additional commands, e-mail: users-help@... >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsWhat 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 <igor.vaynberg@...> wrote: > On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sven@...> 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@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsI'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 <james@...> 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 <igor.vaynberg@...> wrote: >> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sven@...> 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@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > -- 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@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsunit tests are fixed...
-igor On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst <martijn.dashorst@...> 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 > <james@...> 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 <igor.vaynberg@...> wrote: >>> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sven@...> 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@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > > -- > 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@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: genericsi 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 <igor.vaynberg@...> wrote: > unit tests are fixed... > > -igor > > On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst > <martijn.dashorst@...> 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 > > <james@...> 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 <igor.vaynberg@...> > wrote: > >>> On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier <sven@...> 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@... > >>>>> For additional commands, e-mail: users-help@... > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: users-unsubscribe@... > >>>> For additional commands, e-mail: users-help@... > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: users-unsubscribe@... > >>> For additional commands, e-mail: users-help@... > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscribe@... > >> For additional commands, e-mail: users-help@... > >> > >> > > > > > > > > -- > > 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@... > > For additional commands, e-mail: users-help@... > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > |
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |