generics

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 - 4 - 5 | Next >

generics

by igor.vaynberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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: generics

by Martin Funk-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


> 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: generics

by Brill Pappin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...


Re: generics

by Martijn Dashorst :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


RE: generics

by lzappaterrini :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'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: generics

by igor.vaynberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 <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: generics

by Martin Funk-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
For additional commands, e-mail: users-help@...


Re: generics

by Martin Funk-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
For additional commands, e-mail: users-help@...


Re: generics

by Martijn Dashorst :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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
<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: generics

by igor.vaynberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 <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: generics

by Stefan Lindner :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
For additional commands, e-mail: users-help@...


Re: generics

by Eelco Hillenius :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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: generics

by Timo Rantalaiho :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...


Re: generics

by igor.vaynberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 <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: generics

by svenmeier :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
> For additional commands, e-mail: users-help@...
>
>
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...


Re: generics

by igor.vaynberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...


Re: generics

by jwcarman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...


Re: generics

by Martijn Dashorst :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...


Re: generics

by igor.vaynberg :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...


Re: generics

by Johan Compagner :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 <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 >