Re: Generics of Button#getForm
Done It will be better for 1.5.7/6.0.0-next On Mon, May 7, 2012 at 2:29 PM, Jonas barney...@gmail.com wrote: Hello all, as Sebastien mentioned earlier (http://apache-wicket.1842946.n4.nabble.com/Vote-Release-Apache-Wicket-1-5-6-build-2-td4593151.html#a4593497) the of Button#getForm returns the raw type Form in wicket 1.5.6. Could a committer please change the return type back to Form? so we don't have to suppress those annoying generics warnings? thanks. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics
Basically the list view depend from List interface due some calls to his
get(index) method. It means that the order of the components on the
collections, are meaninful to the component. If it is not your case (order,
item indexes doesn't matters), you can use an wrapper model in an list view,
like:
WrapperModel implements IModel
{
public WrapperModel (IModel wrappedModel)
{
this.wrappedModel = wrappedModel;
}
public Object getObject()
{
return new ArrayList(wrappedModel.getObject());
}
}
then you can create an list view like:
new ListView(id, new PropertyModel(bean, listPropertyFromThatBean))
On Mon, Jan 25, 2010 at 12:29 PM, Sam Barrow s...@sambarrow.com wrote:
I've noticed in some places where generics wildcards may be useful that
they are not used. For example, in IColumn.
If I have a Type and a SubType that extends Type, I can't use
IColumnType in a DataTableSubType. Is there any reason for this or
was it just not implemented? Not the most necessary feature, but it
couldn't hurt.
Also is there a reason ListView and similar components require an
IModelList, and will not accept an IModelCollection?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
Re: Generics
That's exactly what I do now (wrapped model). Just wondering if there was a
technical reason behind it.
Sent via BlackBerry from T-Mobile
-Original Message-
From: Pedro Santos pedros...@gmail.com
Date: Mon, 25 Jan 2010 13:03:16
To: users@wicket.apache.org
Subject: Re: Generics
Basically the list view depend from List interface due some calls to his
get(index) method. It means that the order of the components on the
collections, are meaninful to the component. If it is not your case (order,
item indexes doesn't matters), you can use an wrapper model in an list view,
like:
WrapperModel implements IModel
{
public WrapperModel (IModel wrappedModel)
{
this.wrappedModel = wrappedModel;
}
public Object getObject()
{
return new ArrayList(wrappedModel.getObject());
}
}
then you can create an list view like:
new ListView(id, new PropertyModel(bean, listPropertyFromThatBean))
On Mon, Jan 25, 2010 at 12:29 PM, Sam Barrow s...@sambarrow.com wrote:
I've noticed in some places where generics wildcards may be useful that
they are not used. For example, in IColumn.
If I have a Type and a SubType that extends Type, I can't use
IColumnType in a DataTableSubType. Is there any reason for this or
was it just not implemented? Not the most necessary feature, but it
couldn't hurt.
Also is there a reason ListView and similar components require an
IModelList, and will not accept an IModelCollection?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
Re: Generics
Just make sure that the items on the collection have an index (List
interface ensure it). It is important to the implementation of
ListItemModel.setObject for instance and turn possible the component
pagination.
On Mon, Jan 25, 2010 at 1:05 PM, s...@sambarrow.com wrote:
That's exactly what I do now (wrapped model). Just wondering if there was a
technical reason behind it.
Sent via BlackBerry from T-Mobile
-Original Message-
From: Pedro Santos pedros...@gmail.com
Date: Mon, 25 Jan 2010 13:03:16
To: users@wicket.apache.org
Subject: Re: Generics
Basically the list view depend from List interface due some calls to his
get(index) method. It means that the order of the components on the
collections, are meaninful to the component. If it is not your case (order,
item indexes doesn't matters), you can use an wrapper model in an list
view,
like:
WrapperModel implements IModel
{
public WrapperModel (IModel wrappedModel)
{
this.wrappedModel = wrappedModel;
}
public Object getObject()
{
return new ArrayList(wrappedModel.getObject());
}
}
then you can create an list view like:
new ListView(id, new PropertyModel(bean, listPropertyFromThatBean))
On Mon, Jan 25, 2010 at 12:29 PM, Sam Barrow s...@sambarrow.com wrote:
I've noticed in some places where generics wildcards may be useful that
they are not used. For example, in IColumn.
If I have a Type and a SubType that extends Type, I can't use
IColumnType in a DataTableSubType. Is there any reason for this or
was it just not implemented? Not the most necessary feature, but it
couldn't hurt.
Also is there a reason ListView and similar components require an
IModelList, and will not accept an IModelCollection?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
--
Pedro Henrique Oliveira dos Santos
Re: generics and models that take X as model object but return Y
/**
* Simplifies implementing wrapper models that adapt from model object
of one type to another
*
* @author igor.vaynberg
*
* @param N
*new type
* @param O
*old type
*/
public abstract class AdapterModelN, O implements IModelN
{
private static final long serialVersionUID = 1L;
/** delegate model */
private final IModelO delegate;
/**
* Constructor
*
* @param delegate
*model to be wrapped
*/
public AdapterModel(IModelO delegate)
{
this.delegate = delegate;
}
/** {...@inheritdoc} */
public N getObject()
{
return getObject(delegate);
}
/**
* Translates from codeIModel/code of type codeT/code to
object of type codeA/code
*
* @param delegate
* @return adapter value of codedelegate/code model
*/
protected abstract N getObject(IModelO delegate);
/** {...@inheritdoc} */
public void setObject(N object)
{
setObject(object, delegate);
}
/**
* Translates from object of type codeA/code to
codeIModel/code of type codeT/code
*
* @param object
*adapted object that needs to be unadopted
* @param delegate
*delegate model whose value should be set to
unadopted version of
*codeobject/code
*/
protected abstract void setObject(N object, IModelO delegate);
/** {...@inheritdoc} */
public void detach()
{
delegate.detach();
}
}
-igor
On Wed, Dec 30, 2009 at 5:23 AM, Sam Zilverberg samzilverb...@gmail.com wrote:
What's the best practice when using generics with models that take some
object but return another type of object?
examples:
When you have a collection and need to convert it to a list for listview
purposes.
When you have some object and you need a wrapping model that creates some
string representation of the object - usually involving more objects (so
you can't just use the toString or other getter of the object).
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics and SortableDataProvider
Hi Jonny, yes, it works exactly like you described it. Sven jwray wrote: Hi Sven, Thanks for your reply. Since I sent the original question I ended up doing what you suggested and now I'm wondering why I ever used the id projection approach. Habit I guess, formed with previous frameworks. Just to make sure I've got this right, as long as I use a DetachableModel as a return from model method, the domain objects aren't stored in the session even if they are returned from the iterator. Am I correct in this? Jonny svenmeier wrote: Hi John, I believe the consensus on this list is that you should change your approach: Why don't you just iterate over your domain objects in the first place? They will be loaded anyway to be displayed on your component. So your approach triggers 1+n selects instead of 1 select for all required objects at once. Sven - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics and SortableDataProvider
Hi John, I believe the consensus on this list is that you should change your approach: Why don't you just iterate over your domain objects in the first place? They will be loaded anyway to be displayed on your component. So your approach triggers 1+n selects instead of 1 select for all required objects at once. Sven jonny.w...@fiveprime.com wrote: Hi, Working on my first application using 1.4.x and generics and have a question regarding the use of SortableDataProvider. Within my extensions of this class I quite commonly obtain the id of an object within the iterator method and then load the object via a LoadableDetchableModel within the model method. My question is how to implement such an approach using the new generic classes. For example, the generic model method has the signature public IModelT model(T object) but using the id based approach I would pass in a Long and return a model containing my domain model. The signature assumes the method parameter and model returned operate on the same type. Anyone tell me what I'm missing or if my approach is flawed? Thanks, Jonny This email message and any attached files are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email message is prohibited. If you are not the intended recipient, please inform the sender by reply email and destroy all copies of the original message and your reply. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics and SortableDataProvider
Hi Sven, Thanks for your reply. Since I sent the original question I ended up doing what you suggested and now I'm wondering why I ever used the id projection approach. Habit I guess, formed with previous frameworks. Just to make sure I've got this right, as long as I use a DetachableModel as a return from model method, the domain objects aren't stored in the session even if they are returned from the iterator. Am I correct in this? Jonny svenmeier wrote: Hi John, I believe the consensus on this list is that you should change your approach: Why don't you just iterate over your domain objects in the first place? They will be loaded anyway to be displayed on your component. So your approach triggers 1+n selects instead of 1 select for all required objects at once. Sven -- View this message in context: http://www.nabble.com/Generics-and-SortableDataProvider-tp25757590p25761751.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics in components
On Mon, May 25, 2009 at 6:54 AM, Frank Tegtmeyer frank.tegtme...@online-systemhaus.com wrote: Hi, I am still very very new to Java and Wicket of course too, so excuse me if this is a dumb question. I swiched my project to Wicket 1.4-rc4 now and got all these wonderful warnings about the Raw types of the components in my sources. Are there any examples that highlight the handling of the generic component types? I have no clue what type parameter I have to give a form component for example (no clue for other components too). Should it be the class of my model or anything else? For validators I tried to set base types (Integer, ..) and this worked. But still I have no clue if this is the right thing to do. Confused ... :) The type parameter on components is supposed to correspond to their model's type parameter. So, TextFieldInteger would need an IModelInteger. The Wicket test cases should have examples of this, if nothing else. Use the source, Luke. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics question
Hi Linda,
You are assuming that
IModelListSubgenre
is a subtype of
IModelList? extends DomainObject
In java this is not the case (even if Subgenre extends DomainObject).
You'll need an explicit cast to make this work:
IModelList? extends DomainObject castedModel =
(IModelList? extends DomainObject) subgenreModel;
Regards,
Erik.
Linda van der Pal wrote:
This is not really Wicket related, but I don't quite know where else
to ask this. The question is: why won't this compile?
// I define a model
IModelListSubgenre subgenreModel = new
AbstractReadOnlyModelListSubgenre() {
...
}
// Here I try to use the model
FieldSwitchPanel subgenrefield = *new
SubgenreFieldSwitchPanel(subgenre, subgenreModel);*
// This is the constructor for the class SubgenreFieldSwithcPanel
public SubgenreFieldSwitchPanel(String id, IModelList? extends
DomainObject choices) {
...
}
// Subgenre extends DomainObject
public class Subgenre extends DomainObject{
...
}
The complaint is: The constructor SubgenreFieldSwitchPanel(String,
IModelListSubgenre) is undefined.
Thanks,
Linda
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics question
This looks exactly like the DropDownChoice issue that has been debated
recently. See the comments in JIRA:
https://issues.apache.org/jira/browse/WICKET-2137
The problem is that IModelList? extends DomainObject doesn't work
as we intuitively expect it to. It won't match IModelListSubgenre
(nor IModelListDomainObject for that matter).
As suggested by James, the correct generic type to achieve what you
want to do would be: IModel? extends List? extends DomainObject
Olivier
2009/3/13 Linda van der Pal lvd...@heritageagenturen.nl:
This is not really Wicket related, but I don't quite know where else to ask
this. The question is: why won't this compile?
// I define a model
IModelListSubgenre subgenreModel = new
AbstractReadOnlyModelListSubgenre() {
...
}
// Here I try to use the model
FieldSwitchPanel subgenrefield = *new SubgenreFieldSwitchPanel(subgenre,
subgenreModel);*
// This is the constructor for the class SubgenreFieldSwithcPanel
public SubgenreFieldSwitchPanel(String id, IModelList? extends
DomainObject choices) {
...
}
// Subgenre extends DomainObject
public class Subgenre extends DomainObject{
...
}
The complaint is: The constructor SubgenreFieldSwitchPanel(String,
IModelListSubgenre) is undefined.
Thanks,
Linda
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics question
Thanks!
Erik van Oosten wrote:
Hi Linda,
You are assuming that
IModelListSubgenre
is a subtype of
IModelList? extends DomainObject
In java this is not the case (even if Subgenre extends DomainObject).
You'll need an explicit cast to make this work:
IModelList? extends DomainObject castedModel =
(IModelList? extends DomainObject) subgenreModel;
Regards,
Erik.
Linda van der Pal wrote:
This is not really Wicket related, but I don't quite know where else
to ask this. The question is: why won't this compile?
// I define a model
IModelListSubgenre subgenreModel = new
AbstractReadOnlyModelListSubgenre() {
...
}
// Here I try to use the model
FieldSwitchPanel subgenrefield = *new
SubgenreFieldSwitchPanel(subgenre, subgenreModel);*
// This is the constructor for the class SubgenreFieldSwithcPanel
public SubgenreFieldSwitchPanel(String id, IModelList? extends
DomainObject choices) {
...
}
// Subgenre extends DomainObject
public class Subgenre extends DomainObject{
...
}
The complaint is: The constructor SubgenreFieldSwitchPanel(String,
IModelListSubgenre) is undefined.
Thanks,
Linda
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.278 / Virus Database: 270.11.13/1999 - Release Date: 03/13/09 05:59:00
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics changes in 1.4-rc1
Please make issues for this in jira On 11/20/08, aditsu [EMAIL PROTECTED] wrote: Hi, I've been using m3 for a while and just tried switching to rc1. I found several problems: - LabelTree.getNodeTextModel requires IModel and returns IModel. I was overriding it and returning a ModelString, but I can't do that anymore. Why not just return IModel? ? - RatingPanel now requires an IModelInteger for the rating, but I was using IModelDouble. How can I show rated 3.6 from 7 votes now? Can it use IModel? extends Number instead? - BaseTree requires IModelTreeModel; I was using a Model with a DefaultTreeModel object, but I can't do that anymore (TreeModel is not necessarily Serializable). Why not just require IModel? extends TreeModel ? Adrian -- View this message in context: http://www.nabble.com/Generics-changes-in-1.4-rc1-tp20599173p20599173.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generics changes in 1.4-rc1
Johan Compagner wrote: Please make issues for this in jira Since you said issues, I created 3 issues: WICKET-1947, WICKET-1948, WICKET-1949 Adrian -- View this message in context: http://www.nabble.com/Generics-changes-in-1.4-rc1-tp20599173p20615568.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
igor.vaynberg wrote:
so now you have to do new
DataViewVoid,Foo which is very noisy not to mention you have to
remember which one is for the model and which one is for the
dataprovider.
-igor
I don't know if this is too late, and haven't played with DataViews for a
while but why couldn't you do something to this extent:
public abstract class DataViewBaseT extends AbstractPageableViewT
{
public K DataViewBase(String id, IDataProviderK dataProvider)
{
...snip...
}
...snip...
private static final class ModelIteratorK implements
IteratorIModelK
{
...snip...
}
}
as DataView's children aren't actually supposed to use T - that's what the
DataView's model would use but chooses to ignore it (and we can't know if
some subclass would actually _want_ to use the model for something). Just
drop the T parameter and avoid the noise if required.
--
View this message in context:
http://www.nabble.com/generics-tp18083910p19065291.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
That discussion will not happen any time soon, first java 7 must be released.. Then i guess 2+ or 3+ years will pass before java 7 is widely used. So i guess we can plan that discussion around 2011.. On 7/16/08, Ricky [EMAIL PROTECTED] wrote: orginally said by Martijn: We don't say that, but without the core committers, you won't have a framework. Treat us gently and you'll get a lot done. :D Ok, Please, can we generify components? :D I have already stated my opinion, but i think we should not really be bothered about generic notation, because anyways we will have some changes coming up in Java 7 and with closures (which will be useful to wicket imho), wicket HAS to change and use the new feature-set. At that point i know that there will again be a debate whether we want to go with newer feature set (especially closures etc) or not. Its just a matter of getting used to and once you do, you will know how elegant generification really is. Regards Vyas, Anirudh || ॐ || On Tue, Jul 15, 2008 at 4:00 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: You're right that 'slave' is too strong a word. I apologize. Wilhelmsen Tor Iver reconstructed my intent much better. Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I converted our project to 1.4 as an experiment. It's quite large (257 source files). It was a bit tedious changing xxxModel to xxDefaultModel, etc, but it wasn't too bad. I haven't fixed all the warnings though. I think the design will benefit us and the conversion will be worth it. We use this pattern a lot: data provider + data panel + data view. Generifying the models these classes deal with reduces confusion, potential runtime errors and code size (the latter because you can get rid of casts and you can move some code to superclasses). Thanks to the Wicket team yet again! Julian -- View this message in context: http://www.nabble.com/generics-tp18083910p18493875.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
this is actually a perfect example where generifying Component broke down in 1.4m2. dataview does not use its model, it uses the dataprovider which it stores as a field. so right now you can just say new DataViewFoo and it will expect IDataProviderFoo and you are free to attach any type of model to the dataview you want. in 1.4m2 if we reused the same type declaration for dataprovider and dataview then you would be forced to only use imodelfoo for the dataview which is a completely arbitrary restriction. to fix the above we would have to allow two type declarations, one for model and one for dataprovider. so now you have to do new DataViewVoid,Foo which is very noisy not to mention you have to remember which one is for the model and which one is for the dataprovider. in m3 we do not have this problem... -igor On Wed, Jul 16, 2008 at 11:34 AM, JulianS [EMAIL PROTECTED] wrote: I converted our project to 1.4 as an experiment. It's quite large (257 source files). It was a bit tedious changing xxxModel to xxDefaultModel, etc, but it wasn't too bad. I haven't fixed all the warnings though. I think the design will benefit us and the conversion will be worth it. We use this pattern a lot: data provider + data panel + data view. Generifying the models these classes deal with reduces confusion, potential runtime errors and code size (the latter because you can get rid of casts and you can move some code to superclasses). Thanks to the Wicket team yet again! Julian -- View this message in context: http://www.nabble.com/generics-tp18083910p18493875.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I ported all our projects to 1.4-m3 (from 1.4-m2). It was quite large - about 500 source files. Everything worked out nicely. I can say, that I am very happy with actual generics style. I think, that this is how generics should be applied in Wicket. Good work! Thanks to the Wicket team yet again! Stefan Simik -- View this message in context: http://www.nabble.com/generics-tp18083910p18498620.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Mon, Jul 14, 2008 at 10:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: personally i am still in favor of going with the m2 way of doing things where Component is generic, but from the looks of the discussion i think i may be in the minority here. Looking at the people who reacted, that seems to be the case. But the reason why we ask people their opinion is of course to get an idea on what involved users think, so I hope the discussion is somewhat representative. really?? I think if you do an exact count also of the real vote you be surprised i think it is more 50/50... maybe 60/40 So far, to me m3 looks like a good trade off that has the support of the whole team and a decent amount of users. I'm afraid we can't make everyone perfectly happy :-) thats true
Re: generics
You're right that 'slave' is too strong a word. I apologize. Wilhelmsen Tor Iver reconstructed my intent much better. Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
orginally said by Martijn: We don't say that, but without the core committers, you won't have a framework. Treat us gently and you'll get a lot done. :D Ok, Please, can we generify components? :D I have already stated my opinion, but i think we should not really be bothered about generic notation, because anyways we will have some changes coming up in Java 7 and with closures (which will be useful to wicket imho), wicket HAS to change and use the new feature-set. At that point i know that there will again be a debate whether we want to go with newer feature set (especially closures etc) or not. Its just a matter of getting used to and once you do, you will know how elegant generification really is. Regards Vyas, Anirudh || ॐ || On Tue, Jul 15, 2008 at 4:00 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: You're right that 'slave' is too strong a word. I apologize. Wilhelmsen Tor Iver reconstructed my intent much better. Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I think you are *not* in the minority, but a lot of the dissenters
piped in last minute in a big flood so to some it might look that way.
However, It may actually be valuable the way they are doing it now, so
I'm reserving judgement until I can sit down and port my latest
project to it... and check out how well it works.
The moment I have to do a cast, I'll consider it a sign that it needs
more work.
- Brill Pappin
On 14-Jul-08, at 10:17 AM, Craig McIlwee wrote:
personally i am still in favor of going with the m2 way of doing
things where
Component is generic, but from the looks of the discussion i think i
may be
in the minority here. this kinda surprises me though because as i
read the
original generic discussion it sounded like most people supported
ComponentT.
igor.vaynberg wrote:
basically we feel this is a much cleaner way then what is 1.4m2. this
is a call for confirmation/discussion from our user base.
1) i'm not sure i agree with this. i don't feel that just adding
Void to
components that don't need their models makes things messy. i'd
much rather
have the option to use generics whenever i need than to create extra
classes
such as the 'GenericPanel', etc that have been mentioned. in fact i
think
its alot messier to create more classes and to start changing method
names
(getDefaultModel, etc) and then adding getModel to the classes that
do use
generics.
2) the wicket web site now suggests the following code for generic
components:
@SuppressWarnings(unchecked)
public final T getModelObject()
{
return (T)getDefaultModelObject();
}
... but isn't the purpose of adding generic support to wicket to
prevent the
need for unchecked casts? if we now have to place unchecked casts
into our
code then we lose out on the strong type checking that generics are
supposed
to provide. its not hard to imagine a case where one part of
someone's code
calls setDefaultModelObject with the wrong type, and then later
another part
of the code calls getModelObject and hits a class cast exception.
3) the Component class has several methods that return 'this' to
allow for
method chaining. the problem here is that the generic components
don't
override these methods with covariant returns, so if i do something
like
formComponent
.setVersioned(false).moreMethodCalls().chainedTogether() then
those chained methods can't use models because we've upcast our
component to
something that doesn't have generic support. i guess the solution
would be
to put these calls on separate lines, but it seems like a bit of a
hassle
(i'm probably just being picky tho)
- craig
--
View this message in context:
http://www.nabble.com/generics-tp18083910p18444866.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Mon, Jul 14, 2008 at 5:03 PM, Brill Pappin [EMAIL PROTECTED] wrote:
I think you are *not* in the minority, but a lot of the dissenters piped in
last minute in a big flood so to some it might look that way.
I think this is a baseless statement: both sides have been very vocal.
In any case this will not be a majority vote unless there is a 1-99%
split, but even then: the core committers have the final say and it is
their responsibility to move the project forward in the way they deem
to be in the best interest of the framework. This doesn't say the
wicket committers don't value your input, nor won't take it into
account (lots of double negatives). In other words: we *do* value your
input and feedback, and will take it into account, but the ultimate
responsibility lies with the core committers.
However, It may actually be valuable the way they are doing it now, so I'm
reserving judgement until I can sit down and port my latest project to it...
and check out how well it works.
This is what we ask, so thanks and please provide feedback!
The moment I have to do a cast, I'll consider it a sign that it needs more
work.
This is what we propose: when you come across a point where generics
should be added, give us a note. We will take it into consideration,
just as we do with removing final in our code base.
Martijn
On 14-Jul-08, at 10:17 AM, Craig McIlwee wrote:
personally i am still in favor of going with the m2 way of doing things
where
Component is generic, but from the looks of the discussion i think i may
be
in the minority here. this kinda surprises me though because as i read
the
original generic discussion it sounded like most people supported
ComponentT.
igor.vaynberg wrote:
basically we feel this is a much cleaner way then what is 1.4m2. this
is a call for confirmation/discussion from our user base.
1) i'm not sure i agree with this. i don't feel that just adding Void
to
components that don't need their models makes things messy. i'd much
rather
have the option to use generics whenever i need than to create extra
classes
such as the 'GenericPanel', etc that have been mentioned. in fact i think
its alot messier to create more classes and to start changing method names
(getDefaultModel, etc) and then adding getModel to the classes that do use
generics.
2) the wicket web site now suggests the following code for generic
components:
@SuppressWarnings(unchecked)
public final T getModelObject()
{
return (T)getDefaultModelObject();
}
... but isn't the purpose of adding generic support to wicket to prevent
the
need for unchecked casts? if we now have to place unchecked casts into
our
code then we lose out on the strong type checking that generics are
supposed
to provide. its not hard to imagine a case where one part of someone's
code
calls setDefaultModelObject with the wrong type, and then later another
part
of the code calls getModelObject and hits a class cast exception.
3) the Component class has several methods that return 'this' to allow for
method chaining. the problem here is that the generic components don't
override these methods with covariant returns, so if i do something like
formComponent.setVersioned(false).moreMethodCalls().chainedTogether()
then
those chained methods can't use models because we've upcast our component
to
something that doesn't have generic support. i guess the solution would
be
to put these calls on separate lines, but it seems like a bit of a hassle
(i'm probably just being picky tho)
- craig
--
View this message in context:
http://www.nabble.com/generics-tp18083910p18444866.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On 14-Jul-08, at 11:24 AM, Martijn Dashorst wrote: On Mon, Jul 14, 2008 at 5:03 PM, Brill Pappin [EMAIL PROTECTED] wrote: I think you are *not* in the minority, but a lot of the dissenters piped in last minute in a big flood so to some it might look that way. I think this is a baseless statement: both sides have been very vocal. In any case this will not be a majority vote unless there is a 1-99% split, but even then: the core committers have the final say and it is their responsibility to move the project forward in the way they deem to be in the best interest of the framework. This doesn't say the wicket committers don't value your input, nor won't take it into account (lots of double negatives). In other words: we *do* value your input and feedback, and will take it into account, but the ultimate responsibility lies with the core committers. I'd say that WIcket *is a product*, and as such the consumers of that product have the final say. It's up to the core committers to do the best job they can to make sure their consumers are getting what they need... just because it's an OS project that we don't have to buy, doesn't mean that the project doesn't depend on people using it. That said, I think that you guys have done some good work and have produced a good product with or without the generics. - Brill Pappin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Craig McIlwee wrote:
2) the wicket web site now suggests the following code for generic
components:
@SuppressWarnings(unchecked)
public final T getModelObject()
{
return (T)getDefaultModelObject();
}
I am just starting to use the new form and it struck me as a little strange
that getModel() and its friends are not a part of any interface or abstract
class.
--
View this message in context:
http://www.nabble.com/generics-tp18083910p18446636.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Mon, Jul 14, 2008 at 5:36 PM, Brill Pappin [EMAIL PROTECTED] wrote: I'd say that WIcket *is a product*, and as such the consumers of that product have the final say. We build this in our spare time, and are customers ourselves. Wicket is not a product, it is an open source community. The definition of community is in the strictest sense defined as the core committers. They have to do the job, and won't do it when they don't see any benefit, or don't enjoy working on the project. It's up to the core committers to do the best job they can to make sure their consumers are getting what they need... We are not your slaves. The Apache license explicitly states so: 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. just because it's an OS project that we don't have to buy, doesn't mean that the project doesn't depend on people using it. We don't say that, but without the core committers, you won't have a framework. Treat us gently and you'll get a lot done. :D Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I'm not going to get into an argument on the definition of a product or how the rules of supply and demand apply to Wicket. Those that actually care about this thread can make up their own minds. However I do object to being misrepresented. No where did I call you folks slaves, and don't believe that to be true in the least... I didn't even allude to the concept. I've been in your shoes as well and understand exactly why you do it... from various angles. - Brill Pappin On 14-Jul-08, at 11:47 AM, Martijn Dashorst wrote: On Mon, Jul 14, 2008 at 5:36 PM, Brill Pappin [EMAIL PROTECTED] wrote: I'd say that WIcket *is a product*, and as such the consumers of that product have the final say. We build this in our spare time, and are customers ourselves. Wicket is not a product, it is an open source community. The definition of community is in the strictest sense defined as the core committers. They have to do the job, and won't do it when they don't see any benefit, or don't enjoy working on the project. It's up to the core committers to do the best job they can to make sure their consumers are getting what they need... We are not your slaves. The Apache license explicitly states so: 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. just because it's an OS project that we don't have to buy, doesn't mean that the project doesn't depend on people using it. We don't say that, but without the core committers, you won't have a framework. Treat us gently and you'll get a lot done. :D Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
personally i am still in favor of going with the m2 way of doing things where Component is generic, but from the looks of the discussion i think i may be in the minority here. Looking at the people who reacted, that seems to be the case. But the reason why we ask people their opinion is of course to get an idea on what involved users think, so I hope the discussion is somewhat representative. this kinda surprises me though because as i read the original generic discussion it sounded like most people supported ComponentT. Well, the original discussion was more about whether to generify Component in the first place. Because we got so many mixed reactions, we looked for the third way, which is what m3 basically is. So far, to me m3 looks like a good trade off that has the support of the whole team and a decent amount of users. I'm afraid we can't make everyone perfectly happy :-) Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I'd say that WIcket *is a product*, and as such the consumers of that product have the final say. I think closer to reality - the consumer's final say - is that when people don't like the product anymore, they'll switch to alternatives or - unique to open source software - create their own branches. Obviously, we value the input of involved users highly, which is exactly why we start up these discussions! :-) That said, I think that you guys have done some good work and have produced a good product with or without the generics. Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Don't have time to update to 1.4 yet, so I haven't been following this
thread much, but I did see this go by:
2) the wicket web site now suggests the following code for generic
components:
@SuppressWarnings(unchecked)
public final T getModelObject()
{
return (T)getDefaultModelObject();
}
Normally, it shouldn't be necessary to have to use casting with
generics. In fact, the idea is that if no casting is used (along with a
few other constraints that I don't remember off hand), then the code is
guaranteed to be type safe.
In other words... something seems not quite right with the code above
because of the cast.
Sorry if I'm bringing up something already discussed. Like I said, I
haven't really been following this thread.
Cheers,
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Tue, 15 Jul 2008, David Leangen wrote: Normally, it shouldn't be necessary to have to use casting with generics. In fact, the idea is that if no casting is used (along with a few other constraints that I don't remember off hand), then the code is guaranteed to be type safe. In other words... something seems not quite right with the code above because of the cast. Sorry if I'm bringing up something already discussed. Like I said, I haven't really been following this thread. Heh, it sure has :) You can easily check out the previous discussions from Nabble http://www.google.fi/search?q=wicket+nabble+genericsie=utf-8oe=utf-8aq=trls=com.ubuntu:en-US:unofficialclient=firefox-a To put it short, we're looking for an option where Component could live without the class level type parameter but IModel would have it. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Timo Rantalaiho wrote: On Mon, 07 Jul 2008, Matthijs Wensveen wrote: The thing is that when using Ajax you have to specifically add PersonViewer to the AjaxRequestTarget when 'some other component' modifies the Person object. The problem is that 'some other component' might not even know about or have access to PersonViewer (maybe it's a 3rd-party component). OnModelChanged does not work in this case, because there is no call to setModelObject, just to some setter of the Person object. Yep, in our current project we use the WICKET-1312 broadcaster approach to solve this. This means that the logic of which component needs to be repainted when something happens is in the UI components. (The domain logic itself we try to put in the domain objects.) So in our model, the other component modifying the Person object would broadcast a PersonModifiedEvent to all PersonModificationReceiver components, who could then act accordingly (typically add themselves to the Ajax request target). There's not a lot of automagical intelligence there, but we have found this way clear and effective. All relationships are static on component class level and navigable in the IDE. The proliferation of events and receivers must be watched out for though. I knew about WICKET-1312, but hadn't thought of broadcasting domain object typed events, just things like onClick and such which gives too little information. Thanks for the eyeopener! While Ajax does very nice things to the GUI, it kinda messes up the model-driven (as in wicket model) approach to gui development. That is why I was thinking about some aspect-oriented solution to let components know about model updates, even when they keep a reference to the same object. That's true. It's a pity that for now, Java AOP solutions are still a bit invasive (AFAIK, if you know of some really neat and transparent implementation without -javaagents or special compilers or some such nuisance, I'd be glad to hear :)). We tried sharing models and making them more intelligent and models sending events to registered listeners and whatnot dead chickens before arriving at the current broadcast/receiver approach. When the components are physically far away from each other, sharing the model or handling registration and deregistration can get hairy. And to avoid memory leaks, removing the listeners when components are being replaced (e.g. repeater children recreated) should be taken care of carefully in a traditional event-listener mechanism. Maybe listeners could be registered using weak references so that the objects are still garbage collected even when the listener is still alive. However, more experimentation is definitely needed on this, and I'd be very interested on hearing any experiences and ideas! It seems that ajax will be around for some more years, whether we like it or not, so best to make the best out of it :) Best wishes, Timo Matthijs -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I always find using PropertyChangeSupport and ProperyChangeListener is a
lot of work and kinda pollutes your code. But it is a solution. Maybe a
combination of ProperyChangeListener and AOP could be made to reduce the
required boilerplate code.
Matthijs
Johan Compagner wrote:
thats just a listener interface for example PropertyChangeListener (but you
can make it more specific interface)
Just make a base model that has add/removePropertyChangeListener and let
your components listen to that
johan
On Mon, Jul 7, 2008 at 8:28 AM, Matthijs Wensveen [EMAIL PROTECTED]
wrote:
Timo Rantalaiho wrote:
On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
How do you cope with deeply nested model properties? For example:
public class PersonViewer extends ComponentPerson {
..
}
some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in
beer)
I have no idea of Johan's project, but normally you just edit an object in
one place at a time, and PersonViewer would be a read-only component with a
model that always pulls the freshest version of the person it is displaying
from the database.
Best wishes,
Timo
The thing is that when using Ajax you have to specifically add PersonViewer
to the AjaxRequestTarget when 'some other component' modifies the Person
object. The problem is that 'some other component' might not even know about
or have access to PersonViewer (maybe it's a 3rd-party component).
OnModelChanged does not work in this case, because there is no call to
setModelObject, just to some setter of the Person object.
While Ajax does very nice things to the GUI, it kinda messes up the
model-driven (as in wicket model) approach to gui development. That is why I
was thinking about some aspect-oriented solution to let components know
about model updates, even when they keep a reference to the same object.
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
See this article http://weblogs.java.net/blog/rbair/archive/2006/05/the_unknown_jav.html for a clean solution to this problem. Essentially, you can grab a class JavaBean from the SwingX project and extend it. Of course if you're already extending another class it doesn't really help you out... On Tue, Jul 8, 2008 at 5:58 AM, Matthijs Wensveen [EMAIL PROTECTED] wrote: I always find using PropertyChangeSupport and ProperyChangeListener is a lot of work and kinda pollutes your code. But it is a solution. Maybe a combination of ProperyChangeListener and AOP could be made to reduce the required boilerplate code. Matthijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Haven't yet tried it myself, but this project seems like a big help when you have to support ProperyChangeListener etc : https://bean-properties.dev.java.net/10things.html Maarten On Tue, Jul 8, 2008 at 2:03 PM, David N. Arnold [EMAIL PROTECTED] wrote: See this article http://weblogs.java.net/blog/rbair/archive/2006/05/the_unknown_jav.html for a clean solution to this problem. Essentially, you can grab a class JavaBean from the SwingX project and extend it. Of course if you're already extending another class it doesn't really help you out... On Tue, Jul 8, 2008 at 5:58 AM, Matthijs Wensveen [EMAIL PROTECTED] wrote: I always find using PropertyChangeSupport and ProperyChangeListener is a lot of work and kinda pollutes your code. But it is a solution. Maybe a combination of ProperyChangeListener and AOP could be made to reduce the required boilerplate code. Matthijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Mon, 07 Jul 2008, Matthijs Wensveen wrote: The thing is that when using Ajax you have to specifically add PersonViewer to the AjaxRequestTarget when 'some other component' modifies the Person object. The problem is that 'some other component' might not even know about or have access to PersonViewer (maybe it's a 3rd-party component). OnModelChanged does not work in this case, because there is no call to setModelObject, just to some setter of the Person object. Yep, in our current project we use the WICKET-1312 broadcaster approach to solve this. This means that the logic of which component needs to be repainted when something happens is in the UI components. (The domain logic itself we try to put in the domain objects.) So in our model, the other component modifying the Person object would broadcast a PersonModifiedEvent to all PersonModificationReceiver components, who could then act accordingly (typically add themselves to the Ajax request target). There's not a lot of automagical intelligence there, but we have found this way clear and effective. All relationships are static on component class level and navigable in the IDE. The proliferation of events and receivers must be watched out for though. While Ajax does very nice things to the GUI, it kinda messes up the model-driven (as in wicket model) approach to gui development. That is why I was thinking about some aspect-oriented solution to let components know about model updates, even when they keep a reference to the same object. That's true. It's a pity that for now, Java AOP solutions are still a bit invasive (AFAIK, if you know of some really neat and transparent implementation without -javaagents or special compilers or some such nuisance, I'd be glad to hear :)). We tried sharing models and making them more intelligent and models sending events to registered listeners and whatnot dead chickens before arriving at the current broadcast/receiver approach. When the components are physically far away from each other, sharing the model or handling registration and deregistration can get hairy. And to avoid memory leaks, removing the listeners when components are being replaced (e.g. repeater children recreated) should be taken care of carefully in a traditional event-listener mechanism. However, more experimentation is definitely needed on this, and I'd be very interested on hearing any experiences and ideas! It seems that ajax will be around for some more years, whether we like it or not, so best to make the best out of it :) Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Timo Rantalaiho wrote:
On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
How do you cope with deeply nested model properties? For example:
public class PersonViewer extends ComponentPerson {
..
}
some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in beer)
I have no idea of Johan's project, but normally you just
edit an object in one place at a time, and PersonViewer
would be a read-only component with a model that always
pulls the freshest version of the person it is displaying
from the database.
Best wishes,
Timo
The thing is that when using Ajax you have to specifically add
PersonViewer to the AjaxRequestTarget when 'some other component'
modifies the Person object. The problem is that 'some other component'
might not even know about or have access to PersonViewer (maybe it's a
3rd-party component). OnModelChanged does not work in this case, because
there is no call to setModelObject, just to some setter of the Person
object.
While Ajax does very nice things to the GUI, it kinda messes up the
model-driven (as in wicket model) approach to gui development. That is
why I was thinking about some aspect-oriented solution to let components
know about model updates, even when they keep a reference to the same
object.
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
thats just a listener interface for example PropertyChangeListener (but you
can make it more specific interface)
Just make a base model that has add/removePropertyChangeListener and let
your components listen to that
johan
On Mon, Jul 7, 2008 at 8:28 AM, Matthijs Wensveen [EMAIL PROTECTED]
wrote:
Timo Rantalaiho wrote:
On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
How do you cope with deeply nested model properties? For example:
public class PersonViewer extends ComponentPerson {
..
}
some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in
beer)
I have no idea of Johan's project, but normally you just edit an object in
one place at a time, and PersonViewer would be a read-only component with a
model that always pulls the freshest version of the person it is displaying
from the database.
Best wishes,
Timo
The thing is that when using Ajax you have to specifically add PersonViewer
to the AjaxRequestTarget when 'some other component' modifies the Person
object. The problem is that 'some other component' might not even know about
or have access to PersonViewer (maybe it's a 3rd-party component).
OnModelChanged does not work in this case, because there is no call to
setModelObject, just to some setter of the Person object.
While Ajax does very nice things to the GUI, it kinda messes up the
model-driven (as in wicket model) approach to gui development. That is why I
was thinking about some aspect-oriented solution to let components know
about model updates, even when they keep a reference to the same object.
Matthijs
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
How do you cope with deeply nested model properties? For example:
public class PersonViewer extends ComponentPerson {
..
}
some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in beer)
I have no idea of Johan's project, but normally you just
edit an object in one place at a time, and PersonViewer
would be a read-only component with a model that always
pulls the freshest version of the person it is displaying
from the database.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Thu, 03 Jul 2008, Matej Knopp wrote: I'm gonna be -1 on removing model utility methods and default model slot from component until you suggest a clean and transparent way to support - compound (inherited) models - component assigned models - automatic detachment Fair enough, let's see what we can come up with :) I was thinking that most of that stuff could be achieved by moving more logic to the model classes. Some things such as the add(new Label(name)); for CompoundPropertyModel-component children could be tricky to get working though. Anyway, I agree that now our focus must be on getting 1.4 out of the door -- the reason this came up was just that I was thinking out loud whether the plans for 1.5 have implications on what to add in 1.4. Automatic detachment for all IModel fields of a component would be great (and the easiest to do of those I suppose). From component where? ComponentUtil? Component has a very strong and complicated contract. There are lot of methods in component, but there are reasons for it. There are parts like rendering though that might need to be cleaned up. Definitely not to a utility class with static methods :) Maybe some of the responsibilities can be moved to different other classes, such as ComponentTag and MarkupStream. But let's see that when working on 1.5. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Matej Knopp wrote: On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp [EMAIL PROTECTED] wrote: And there is some functionality in there that Wicket might be better without. For example, onModelChanged / Changing things become tricky when you share the same model between different instances. And when using setModelObject() with an object that is equal to the current model object, but a different instance (such as a Hibernate-persisted object bound to the correct session), you have to either do getModel().setObject() or change the model comparator. setModelObject isn't the best idea IMHO. Models should support some kind of state change notifications, we might want to improve that for 1.5, though it probably wouldn't be very easy to do. Well, we can hardly detect change of propertypromodels unless we pull and compare the value every time... Better state change notifications would be a huge improvement IMO because that way components could add themselves to AjaxRequestTarget when needed. Currently all Ajax functionality requires Ajaxified components to know about each other and when they should be displayed. Some kind of even mechanism as described in https://issues.apache.org/jira/browse/WICKET-1312 would definitely help, but a model-driven approach would be even better. I was thinking to support this using annotations and aspects and the likes, but I haven't had the time to create a proof of concept. Matthijs PS. Thread subject has become little different than thread content :) -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
There are many state things in a component. Wicket itself has only a few like model/visibile/enable. But a developer could add many many more. In our project this is easily handled by our components. Every component knows when it is changed, what ever it is and then a visitor adds them to ajax. We have a fixed set of components so its not a big problem. On 7/4/08, Matthijs Wensveen [EMAIL PROTECTED] wrote: Matej Knopp wrote: On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp [EMAIL PROTECTED] wrote: And there is some functionality in there that Wicket might be better without. For example, onModelChanged / Changing things become tricky when you share the same model between different instances. And when using setModelObject() with an object that is equal to the current model object, but a different instance (such as a Hibernate-persisted object bound to the correct session), you have to either do getModel().setObject() or change the model comparator. setModelObject isn't the best idea IMHO. Models should support some kind of state change notifications, we might want to improve that for 1.5, though it probably wouldn't be very easy to do. Well, we can hardly detect change of propertypromodels unless we pull and compare the value every time... Better state change notifications would be a huge improvement IMO because that way components could add themselves to AjaxRequestTarget when needed. Currently all Ajax functionality requires Ajaxified components to know about each other and when they should be displayed. Some kind of even mechanism as described in https://issues.apache.org/jira/browse/WICKET-1312 would definitely help, but a model-driven approach would be even better. I was thinking to support this using annotations and aspects and the likes, but I haven't had the time to create a proof of concept. Matthijs PS. Thread subject has become little different than thread content :) -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
How do you cope with deeply nested model properties? For example:
public class PersonViewer extends ComponentPerson {
..
}
some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in beer)
Matthijs
Johan Compagner wrote:
There are many state things in a component. Wicket itself has only a
few like model/visibile/enable. But a developer could add many many
more.
In our project this is easily handled by our components. Every
component knows when it is changed, what ever it is and then a visitor
adds them to ajax. We have a fixed set of components so its not a big
problem.
On 7/4/08, Matthijs Wensveen [EMAIL PROTECTED] wrote:
Matej Knopp wrote:
On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp [EMAIL PROTECTED] wrote:
And there is some functionality in there that Wicket might
be better without. For example, onModelChanged / Changing
things become tricky when you share the same model between
different instances. And when using setModelObject() with an
object that is equal to the current model object, but a
different instance (such as a Hibernate-persisted object
bound to the correct session), you have to either do
getModel().setObject() or change the model comparator.
setModelObject isn't the best idea IMHO. Models should support some
kind of state change notifications, we might want to improve that for
1.5, though it probably wouldn't be very easy to do.
Well, we can hardly detect change of propertypromodels unless we pull
and compare the value every time...
Better state change notifications would be a huge improvement IMO
because that way components could add themselves to AjaxRequestTarget
when needed. Currently all Ajax functionality requires Ajaxified
components to know about each other and when they should be displayed.
Some kind of even mechanism as described in
https://issues.apache.org/jira/browse/WICKET-1312 would definitely help,
but a model-driven approach would be even better.
I was thinking to support this using annotations and aspects and the
likes, but I haven't had the time to create a proof of concept.
Matthijs
PS. Thread subject has become little different than thread content :)
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 423
F +31 20 4223500
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Okay, long story short.
I'm gonna be -1 on removing model utility methods and default model
slot from component until you suggest a clean and transparent way to
support
- compound (inherited) models
- component assigned models
- automatic detachment
Just because you don't use these features it doesn't mean there are
not users who do.
There is convenience, removing bloat and just crippling the API. And
there's difference between these.
Don't take me wrong, I don't mind removing the *default* methods from
components, but not in a way that is going to sacrifice any of the
mentioned functionality.
On Thu, Jul 3, 2008 at 5:32 AM, Timo Rantalaiho [EMAIL PROTECTED] wrote:
On Wed, 02 Jul 2008, Matej Knopp wrote:
I still don't see what's wrong with GenericPanel. It's certainly much
easier to type than ModelContainingPanel.
Nothing wrong with that either, it's just very generic :)
There are a lot of ways of making use of generics in a
component besides just adding the type parameter bound to
the type parameter of the model of the component.
I mean, if you have
public FooPanel extends GenericPanelFoo {
public FooPanel(String id, IModelFoo model, IModelListBar bars) {
...
}
...
}
it's not so much more generic than
public FooPanel extends Panel {
public FooPanel(String id, IModelFoo model, IModelListBar bars) {
...
}
...
}
I strongly disagree. There are good reasons for Wicket to bind model
and component together and I think what we have in 1.4 right now is a
balanced compromise.
I'd be glad to hear more on this! For now, I imagine that a
lot of stuff that the Component IModel dependency exists for
could be done in other ways.
Sure, mind sharing how?
And there is some functionality in there that Wicket might
be better without. For example, onModelChanged / Changing
things become tricky when you share the same model between
different instances. And when using setModelObject() with an
object that is equal to the current model object, but a
different instance (such as a Hibernate-persisted object
bound to the correct session), you have to either do
getModel().setObject() or change the model comparator.
Again, I'm just exploring, and perhaps overlooking
something.
Also if we don't provide the convenience classes
people will bound to write their own (because it's the only reasonable
way to migrate project that already uses generics).
That's true, I just thought it would be no big deal and only
affect the earliest 1.4 adopters (or those still converting
from 2.0 if there are any left) (sorry :)). I had in mind
that if we then remove those convenience classes in 1.5,
they would have to move to the user codebases anyway, but
maybe 1.4 - 1.5 will not be such a common migration path
because of API breaks.
I don't buy this. Our components have a lot of methods, but most of
them are not part of public API. I plan to prefix those methods with a
common prefix for 1.5 so they don't confuse regular users. But I
really don't see how removing four methods (*defaultModel) improves
our api.
It would be better (altough harder) to move responsibilities
away from Component to other classes, which could be then
marked as not being a part of the public API. When you do
the rename I'll be happy to do a spike of moving some of the
renamed stuff away from Component altogether :)
From component where? ComponentUtil? Component has a very strong and
complicated contract. There are lot of methods in component, but there
are reasons for it. There are parts like rendering though that might
need to be cleaned up.
Models have always been conceptually bound to component. Right now the
problem of our API is not that we have a model slot in component. It
is that we have exactly one model slot. This doesn't work well for all
components, since some don't need model at all and some need more than
one.
Yeah, if we cannot get rid of the default model handling
(which I still hope to be possible), at least a more
flexible abstraction (IModelsContainer?) might be good.
esier. Now thinking about it, the name should really suggest that
there is one model per component. Maybe PanelWithModel could be the
name after all :)
PanelWithExactlyOneModelInTheDefaultSlotAndHoldingAnObjectOfTheSameTypeAsTheTypeParameterOfThisComponent
:)
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Ligther? Does it meen with no Compund and ComponentAssignedModel? Wouldn't that feel more like crippled? The default model slot doesn't take any runtime space when you don't use it, property would. And removing four methods from component will hardly make it much lighter. -Matej On Thu, Jul 3, 2008 at 7:13 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: What I mean is that post-1.4 it would be good to remove the defaultModel* stuff and other IModel dependencies from Component, and maybe try to move towards a more case-by-case model handling in generified (actually typed-after-their-default-model-type) components as well. I'm very much in favor of that. If it were up to me, I would actually try to cut away from component (and other pivotal classes for that matter) as much as possible. I'd love Wicket to feel lighter and more pointed with 1.5 rather than heavy with convenience like it is now. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
And there is some functionality in there that Wicket might be better without. For example, onModelChanged / Changing things become tricky when you share the same model between different instances. And when using setModelObject() with an object that is equal to the current model object, but a different instance (such as a Hibernate-persisted object bound to the correct session), you have to either do getModel().setObject() or change the model comparator. setModelObject isn't the best idea IMHO. Models should support some kind of state change notifications, we might want to improve that for 1.5, though it probably wouldn't be very easy to do. -Matej - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp [EMAIL PROTECTED] wrote: And there is some functionality in there that Wicket might be better without. For example, onModelChanged / Changing things become tricky when you share the same model between different instances. And when using setModelObject() with an object that is equal to the current model object, but a different instance (such as a Hibernate-persisted object bound to the correct session), you have to either do getModel().setObject() or change the model comparator. setModelObject isn't the best idea IMHO. Models should support some kind of state change notifications, we might want to improve that for 1.5, though it probably wouldn't be very easy to do. Well, we can hardly detect change of propertypromodels unless we pull and compare the value every time... -Matej - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp [EMAIL PROTECTED] wrote: Ligther? Does it meen with no Compund and ComponentAssignedModel? Wouldn't that feel more like crippled? The default model slot doesn't take any runtime space when you don't use it, property would. And removing four methods from component will hardly make it much lighter. Big +1 on that :) I wasn't just thinking about models though. *I* would like us to go through the API when we start on 1.5 and remove anything that isn't necessary. Remove all the the deprecations and convenience methods that have (easy) alternatives. All the while keeping an easy upgrade path in mind of course. Of course, things like compound property models are pretty cool, and we should keep supporting the types of models we are supporting now. But maybe we can find a way to add this kind of support to components without needing it to be built in. Or maybe not and in the end our conclusion will be to stick with 1.4's model. But lets try to be creative before we give up on that :-) Creative is ok for me. Destructive isn't :) We're getting a bit ahead of ourselves now though, unless we already want to start coding on 1.5. It is probably a better idea to finalize 1.4 first, and decide on what to generify by default based on the likeliness it will help users for this version. Yeah, agree on this as well. -Matej Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Matej: drink some coffee, you're +1-ing yourself now :) Martijn On Thu, Jul 3, 2008 at 10:08 AM, Matej Knopp [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp [EMAIL PROTECTED] wrote: Ligther? Does it meen with no Compund and ComponentAssignedModel? Wouldn't that feel more like crippled? The default model slot doesn't take any runtime space when you don't use it, property would. And removing four methods from component will hardly make it much lighter. Big +1 on that :) -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Rofl :) I've slept like 4 hours. I wanted to +1 Eelco of course. Or maybe that just my Ego and my subconciousness messing with me. On Thu, Jul 3, 2008 at 10:22 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: Matej: drink some coffee, you're +1-ing yourself now :) Martijn On Thu, Jul 3, 2008 at 10:08 AM, Matej Knopp [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp [EMAIL PROTECTED] wrote: Ligther? Does it meen with no Compund and ComponentAssignedModel? Wouldn't that feel more like crippled? The default model slot doesn't take any runtime space when you don't use it, property would. And removing four methods from component will hardly make it much lighter. Big +1 on that :) -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp [EMAIL PROTECTED] wrote: Ligther? Does it meen with no Compund and ComponentAssignedModel? Wouldn't that feel more like crippled? The default model slot doesn't take any runtime space when you don't use it, property would. And removing four methods from component will hardly make it much lighter. I wasn't just thinking about models though. *I* would like us to go through the API when we start on 1.5 and remove anything that isn't necessary. Remove all the the deprecations and convenience methods that have (easy) alternatives. All the while keeping an easy upgrade path in mind of course. Okay. Big +1 here of course., -Matej - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp [EMAIL PROTECTED] wrote: Ligther? Does it meen with no Compund and ComponentAssignedModel? Wouldn't that feel more like crippled? The default model slot doesn't take any runtime space when you don't use it, property would. And removing four methods from component will hardly make it much lighter. Big +1 on that :) That's a +1 on your own reply... cheater! ;-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Thu, Jul 3, 2008 at 9:46 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp [EMAIL PROTECTED] wrote: Ligther? Does it meen with no Compund and ComponentAssignedModel? Wouldn't that feel more like crippled? The default model slot doesn't take any runtime space when you don't use it, property would. And removing four methods from component will hardly make it much lighter. Big +1 on that :) That's a +1 on your own reply... cheater! ;-) Like Martijn said ugh I need to learn to read the rest of the thread before replying first! Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
if we ungenerify Link, should we also ungenerify Form? seems like the exact same kind of usecase. -igor On Tue, Jul 1, 2008 at 10:25 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: This is not a big deal though, either way is fine by me. I prefer link to be not generified, but either way is fine by me as well. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Tue, Jul 1, 2008 at 11:09 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: if we ungenerify Link, should we also ungenerify Form? seems like the exact same kind of usecase. Imho, generic forms make more sense, as you'd typically work on fields (with formcomponents) of one object (the model object of the form), and then do something with it if updating the fields succeeds (like saving the changes). It is true that you often use some model value(s) in the link onClick method, but personally I never do that through the model value, but rather like how Timo described it. Anyway, not a big deal really. If you feel Link is better generified, I'm cool with it. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Tue, Jul 1, 2008 at 11:09 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
if we ungenerify Link, should we also ungenerify Form? seems like the
exact same kind of usecase.
Imho, generic forms make more sense, as you'd typically work on fields
(with formcomponents) of one object (the model object of the form)
thats my point. you work on fields of one object, true, but it does
not necessarily have to be the form's modelobject unless you use a
compound property model. eg
FormVoid form = new FormVoid(form)
{
protected void onSubmit() { value = dosomethingwith(symbol); }
};
add(form);
form.add(new TextFieldString(symbol, new
PropertyModelString(this, symbol)));
where [value] and [symbol] are clearly fields on the container that
parents the form. inside onsubmit i can just as easily access the
object directly without it being the model object of the form. now if
we factor out the form into a static inner or a top level class, just
like the link discussion, it becomes valuable to have the model.
Anyway, not a big deal really. If you feel Link is better generified,
I'm cool with it.
i agree that its no big deal, i am just trying to figure out some sort
of guidelines for when we do include the type and when we dont. if we
say that we only include the type when the component uses its model
then neither Link nor Form qualify. in fact neither will ListItem.
only things like ListView and FormComponents will qualify.
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
thats my point. you work on fields of one object, true, but it does
not necessarily have to be the form's modelobject unless you use a
compound property model. eg
FormVoid form = new FormVoid(form)
{
protected void onSubmit() { value = dosomethingwith(symbol); }
};
add(form);
form.add(new TextFieldString(symbol, new
PropertyModelString(this, symbol)));
where [value] and [symbol] are clearly fields on the container that
parents the form. inside onsubmit i can just as easily access the
object directly without it being the model object of the form. now if
we factor out the form into a static inner or a top level class, just
like the link discussion, it becomes valuable to have the model.
Yeah, you're right actually. I realize now that I rarely use Form's
model directly. And I actually do the special stuff in the buttons
anyway.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I still dont see a complete decoupling or do you mean only getDefaultXxxx()? So all the getModel() (Link/FormComponent) are still there? For link we could have Link (without model) and ModelLink (generified and with get/setModel) that would be fine with me. On 7/2/08, Timo Rantalaiho [EMAIL PROTECTED] wrote: On Tue, 01 Jul 2008, Matej Knopp wrote: There is one thing that helped me quite a lot when migration the project I'm working out. I've created GenericPanel, GenericWebMarkupContainer and GenericFragment classes. In most cases the only change was renaming PanelMyClass to GenericPanelMyClass. Maybe the names could be TypedPanel / ModelContainingPanel or something like that? Or maybe start with the original component name so that they would pop up more easily in the IDE, for example PanelWithType / PanelWithModel? I was wondering, even though those classes were farily simple, we might want to include them in Wicket anyway, for the sake of consistency and convenience. I thought about this and I think that it might be better to not include them after all. In 1.5 it would be great to separate IModel and Component more thoroughly, getting rid of the defaultModel* accessors. Then it would make less sense to have the convenience classes with those model and modelObject accessors. In cases where two components share the same model, it would make sense to make the IModel field in each component final. Then setModel() does not make sense any more; all it could do would be throw an exception or be a confusing no-op. Likewise, sometimes you never do setModelObject() or getModelObject() from outside the class. Leaner APIs and less methods per objects are good things. Hence it's better to add methods as you need them, instead of providing a lot of convenience stuff that is only used a part of the time. Surely each Component subclass has anyway a lot of methods, and MarkupContainers even more, but you have got to start somewhere :) This is not a big deal though, either way is fine by me. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Hi, i agree that its no big deal, i am just trying to figure out some sort of guidelines for when we do include the type and when we dont. if we say that we only include the type when the component uses its model then neither Link nor Form qualify. in fact neither will ListItem. only things like ListView and FormComponents will qualify. I'd actually prefer untyped Link and Form, since I also don't use Models on them directly most of the time. But other's may have a different style and always use Models... Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
thats completely up how you use it I can think of a lot that dont use models on FormComponents but only on Forms If you use CompoundModel then you never will touch or give a FormComponent a model. and all your stuff is done on the Model of the Form. (in the onSubmit for example) So this can never be generalized like this will never be used this way The only way for this is to have a complete separate stack of ModelComponents/GenericComponents See for example Link, Igor says i use model a lot. Eelco says he never uses it.. (but he uses it on button if i read correctly which is the same thing as a link) johan On Wed, Jul 2, 2008 at 9:15 AM, Jan Kriesten [EMAIL PROTECTED] wrote: Hi, i agree that its no big deal, i am just trying to figure out some sort of guidelines for when we do include the type and when we dont. if we say that we only include the type when the component uses its model then neither Link nor Form qualify. in fact neither will ListItem. only things like ListView and FormComponents will qualify. I'd actually prefer untyped Link and Form, since I also don't use Models on them directly most of the time. But other's may have a different style and always use Models... Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
igor.vaynberg wrote: On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: thats my point. you work on fields of one object, true, but it does not necessarily have to be the form's modelobject unless you use a compound property model. The usage of a CompoundPropertyModel as a Form-model saved us quite some typing and it's IMO a very common use case. In fact, this it propbably the most relevant use case for a CPM anyway. So, I'm in favor of having a Form with Model (or at least a variation like a ModelFormT ...) ... roland -- View this message in context: http://www.nabble.com/generics-tp18083910p18231920.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Wed, Jul 2, 2008 at 4:28 AM, Timo Rantalaiho [EMAIL PROTECTED] wrote: On Tue, 01 Jul 2008, Matej Knopp wrote: There is one thing that helped me quite a lot when migration the project I'm working out. I've created GenericPanel, GenericWebMarkupContainer and GenericFragment classes. In most cases the only change was renaming PanelMyClass to GenericPanelMyClass. Maybe the names could be TypedPanel / ModelContainingPanel or something like that? I still don't see what's wrong with GenericPanel. It's certainly much easier to type than ModelContainingPanel. Or maybe start with the original component name so that they would pop up more easily in the IDE, for example PanelWithType / PanelWithModel? I was wondering, even though those classes were farily simple, we might want to include them in Wicket anyway, for the sake of consistency and convenience. I thought about this and I think that it might be better to not include them after all. In 1.5 it would be great to separate IModel and Component more thoroughly, getting rid of the defaultModel* accessors. Then it would make less sense to have the convenience classes with those model and modelObject accessors. I strongly disagree. There are good reasons for Wicket to bind model and component together and I think what we have in 1.4 right now is a balanced compromise. Also if we don't provide the convenience classes people will bound to write their own (because it's the only reasonable way to migrate project that already uses generics). In cases where two components share the same model, it would make sense to make the IModel field in each component final. Then setModel() does not make sense any more; all it could do would be throw an exception or be a confusing no-op. Likewise, sometimes you never do setModelObject() or getModelObject() from outside the class. You don't have to use those methods, there are for convenience only. Leaner APIs and less methods per objects are good things. Hence it's better to add methods as you need them, instead of providing a lot of convenience stuff that is only used a part of the time. Surely each Component subclass has anyway a lot of methods, and MarkupContainers even more, but you have got to start somewhere :) I don't buy this. Our components have a lot of methods, but most of them are not part of public API. I plan to prefix those methods with a common prefix for 1.5 so they don't confuse regular users. But I really don't see how removing four methods (*defaultModel) improves our api. We will always need some kind of utility methods for manipulating models in component. Models have always been conceptually bound to component. Right now the problem of our API is not that we have a model slot in component. It is that we have exactly one model slot. This doesn't work well for all components, since some don't need model at all and some need more than one. Unfortunately the component - model contract is quite complicated as we have compound models, componentassignedmodels, etc so a simple property for model doesn't really cut it. We still need some kind of model manipuation methods. Something like current setDefaultModel,... but more flexible. And when we do have it, having GenericPanel,Fragment,... might make the migration for users lot esier. Now thinking about it, the name should really suggest that there is one model per component. Maybe PanelWithModel could be the name after all :) -Matej This is not a big deal though, either way is fine by me. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
In my current project I have:
10 Forms that use a CompoundPropertymodel and
5 Forms that have no model.
IMHO both Form forms :) should be easy to work with.
Regards,
Erik.
Eelco Hillenius wrote:
thats my point. you work on fields of one object, true, but it does
not necessarily have to be the form's modelobject unless you use a
compound property model. eg
FormVoid form = new FormVoid(form)
{
protected void onSubmit() { value = dosomethingwith(symbol); }
};
add(form);
form.add(new TextFieldString(symbol, new
PropertyModelString(this, symbol)));
where [value] and [symbol] are clearly fields on the container that
parents the form. inside onsubmit i can just as easily access the
object directly without it being the model object of the form. now if
we factor out the form into a static inner or a top level class, just
like the link discussion, it becomes valuable to have the model.
Yeah, you're right actually. I realize now that I rarely use Form's
model directly. And I actually do the special stuff in the buttons
anyway.
Eelco
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
In my current project we try to do everything by BookmarkablePageLinks. Count: - 1 Link with an abstractreadonlymodel - 14 Links without model - 13 bookmarkablepagelinks without model - 2 ajaxfallbacklinks without model in addition we have 4 many used subclasses of bookmarkablepagelink that do not have a model. Maybe not representative, but with 1 link with a model out of 30+ lead me to think that Link without generics is just fine. For Forms I would like to keep generics. Regards, Erik. Igor Vaynberg wrote: the question here is: do most people use the model in the Link or not? when you use compound property model in conjunction with form components you never call getmodel/object() on those either. what now? not generify form components? i dont think a strict criteria will work. some components fall into a gray area which needs to be discussed and generified on case by case basis. when i was generifying wicket my primary usecase is to use Link with a model so i went that way. start a discussion/vote and see where that goes in a different thread. i will be happy to go with what the majority thinks in this particular case. -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
the 13 bookmarkable link are not really model things anyway :) But this discussions just tells us that many people uses things many different ways. And that is just a problem to say what is the good way So i think i am still +1 for a Link and a Generic/ModelLink johan On Wed, Jul 2, 2008 at 3:37 PM, Erik van Oosten [EMAIL PROTECTED] wrote: In my current project we try to do everything by BookmarkablePageLinks. Count: - 1 Link with an abstractreadonlymodel - 14 Links without model - 13 bookmarkablepagelinks without model - 2 ajaxfallbacklinks without model in addition we have 4 many used subclasses of bookmarkablepagelink that do not have a model. Maybe not representative, but with 1 link with a model out of 30+ lead me to think that Link without generics is just fine. For Forms I would like to keep generics. Regards, Erik. Igor Vaynberg wrote: the question here is: do most people use the model in the Link or not? when you use compound property model in conjunction with form components you never call getmodel/object() on those either. what now? not generify form components? i dont think a strict criteria will work. some components fall into a gray area which needs to be discussed and generified on case by case basis. when i was generifying wicket my primary usecase is to use Link with a model so i went that way. start a discussion/vote and see where that goes in a different thread. i will be happy to go with what the majority thinks in this particular case. -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Just because you're using a CompoundPropertyModel on your Forms doesn't mean you need it generified. Sven Roland Huss schrieb: igor.vaynberg wrote: On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: thats my point. you work on fields of one object, true, but it does not necessarily have to be the form's modelobject unless you use a compound property model. The usage of a CompoundPropertyModel as a Form-model saved us quite some typing and it's IMO a very common use case. In fact, this it propbably the most relevant use case for a CPM anyway. So, I'm in favor of having a Form with Model (or at least a variation like a ModelFormT ...) ... roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
But at the end, I want my model object back to do some business with it, so I could either store the CPM myself for later reference (but why would I want to do this ?) or retrieve it from the Form's model (typesafe, if possible). That's why a generified Form would be nice. ... roland svenmeier wrote: Just because you're using a CompoundPropertyModel on your Forms doesn't mean you need it generified. Sven Roland Huss schrieb: igor.vaynberg wrote: On Tue, Jul 1, 2008 at 11:28 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: thats my point. you work on fields of one object, true, but it does not necessarily have to be the form's modelobject unless you use a compound property model. The usage of a CompoundPropertyModel as a Form-model saved us quite some typing and it's IMO a very common use case. In fact, this it propbably the most relevant use case for a CPM anyway. So, I'm in favor of having a Form with Model (or at least a variation like a ModelFormT ...) ... roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/generics-tp18083910p18245100.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Another thought: Why do we have a setter for the model actually? I never call setDefaultModel() (formerly setModel()) in my code. In wicket-examples it seems that most calls to setDefaultModel() are done from inside the constructor (where it is sometimes needed because you cannot call instance methods before the super constructor call). Shouldn't we declare this method (final) protected? Custom components could just handle generified models in the constructor, the non-final getDefaultModel() could be overriden with the preferred return type (as already suggested). And we could get rid of the 'default' in all this method names which frankly don't look too good to me. Sven Johan Compagner schrieb: thats completely up how you use it I can think of a lot that dont use models on FormComponents but only on Forms If you use CompoundModel then you never will touch or give a FormComponent a model. and all your stuff is done on the Model of the Form. (in the onSubmit for example) So this can never be generalized like this will never be used this way The only way for this is to have a complete separate stack of ModelComponents/GenericComponents See for example Link, Igor says i use model a lot. Eelco says he never uses it.. (but he uses it on button if i read correctly which is the same thing as a link) johan On Wed, Jul 2, 2008 at 9:15 AM, Jan Kriesten [EMAIL PROTECTED] wrote: Hi, i agree that its no big deal, i am just trying to figure out some sort of guidelines for when we do include the type and when we dont. if we say that we only include the type when the component uses its model then neither Link nor Form qualify. in fact neither will ListItem. only things like ListView and FormComponents will qualify. I'd actually prefer untyped Link and Form, since I also don't use Models on them directly most of the time. But other's may have a different style and always use Models... Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Wed, Jul 2, 2008 at 12:53 PM, Sven Meier [EMAIL PROTECTED] wrote: Another thought: Why do we have a setter for the model actually? Consider the case (that I sometimes have) where you want to set the model in the component's constructor, but it needs a bit of preparation first in such a way that you can't do it in the super or this call. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Wed, 02 Jul 2008, Matej Knopp wrote:
I still don't see what's wrong with GenericPanel. It's certainly much
easier to type than ModelContainingPanel.
Nothing wrong with that either, it's just very generic :)
There are a lot of ways of making use of generics in a
component besides just adding the type parameter bound to
the type parameter of the model of the component.
I mean, if you have
public FooPanel extends GenericPanelFoo {
public FooPanel(String id, IModelFoo model, IModelListBar bars) {
...
}
...
}
it's not so much more generic than
public FooPanel extends Panel {
public FooPanel(String id, IModelFoo model, IModelListBar bars) {
...
}
...
}
I strongly disagree. There are good reasons for Wicket to bind model
and component together and I think what we have in 1.4 right now is a
balanced compromise.
I'd be glad to hear more on this! For now, I imagine that a
lot of stuff that the Component IModel dependency exists for
could be done in other ways.
And there is some functionality in there that Wicket might
be better without. For example, onModelChanged / Changing
things become tricky when you share the same model between
different instances. And when using setModelObject() with an
object that is equal to the current model object, but a
different instance (such as a Hibernate-persisted object
bound to the correct session), you have to either do
getModel().setObject() or change the model comparator.
Again, I'm just exploring, and perhaps overlooking
something.
Also if we don't provide the convenience classes
people will bound to write their own (because it's the only reasonable
way to migrate project that already uses generics).
That's true, I just thought it would be no big deal and only
affect the earliest 1.4 adopters (or those still converting
from 2.0 if there are any left) (sorry :)). I had in mind
that if we then remove those convenience classes in 1.5,
they would have to move to the user codebases anyway, but
maybe 1.4 - 1.5 will not be such a common migration path
because of API breaks.
I don't buy this. Our components have a lot of methods, but most of
them are not part of public API. I plan to prefix those methods with a
common prefix for 1.5 so they don't confuse regular users. But I
really don't see how removing four methods (*defaultModel) improves
our api.
It would be better (altough harder) to move responsibilities
away from Component to other classes, which could be then
marked as not being a part of the public API. When you do
the rename I'll be happy to do a spike of moving some of the
renamed stuff away from Component altogether :)
Models have always been conceptually bound to component. Right now the
problem of our API is not that we have a model slot in component. It
is that we have exactly one model slot. This doesn't work well for all
components, since some don't need model at all and some need more than
one.
Yeah, if we cannot get rid of the default model handling
(which I still hope to be possible), at least a more
flexible abstraction (IModelsContainer?) might be good.
esier. Now thinking about it, the name should really suggest that
there is one model per component. Maybe PanelWithModel could be the
name after all :)
PanelWithExactlyOneModelInTheDefaultSlotAndHoldingAnObjectOfTheSameTypeAsTheTypeParameterOfThisComponent
:)
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Wed, 02 Jul 2008, Johan Compagner wrote: I still dont see a complete decoupling or do you mean only getDefaultXxxx()? What I mean is that post-1.4 it would be good to remove the defaultModel* stuff and other IModel dependencies from Component, and maybe try to move towards a more case-by-case model handling in generified (actually typed-after-their-default-model-type) components as well. So all the getModel() (Link/FormComponent) are still there? I wouldn't mind trying to see if we could remove the magic currently done in get/setModel* in those too, and if model becomes a normal field in those (instead of an element stored in Component.data), open it to subclasses by making it protected and leave implementing a part of those methods to the users. Often it's better for the design to avoid using getters and setters. Some of the magic might work in the models themselves, for example making the component aware models... aware of the relevant components :) This might turn out not to be practical, and either way having the get/setModel* by default in the generified components is fine by me -- just thinking about different options, and whether they have relevance on what will go to 1.4. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
What I mean is that post-1.4 it would be good to remove the defaultModel* stuff and other IModel dependencies from Component, and maybe try to move towards a more case-by-case model handling in generified (actually typed-after-their-default-model-type) components as well. I'm very much in favor of that. If it were up to me, I would actually try to cut away from component (and other pivotal classes for that matter) as much as possible. I'd love Wicket to feel lighter and more pointed with 1.5 rather than heavy with convenience like it is now. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I second Matej here... maybe instead of GenericPanelT, GenericFragmentT,
etc. you could name it something more explicit. Some examples:
SingleModelPanelT
ModelBoundPanelT
It took me the better part of one day to convert a partially genericized
project (we started out with 1.3 then switched to 1.4 mid-stream). The
project had 100k++ LOC. The resulting code is much easier to read.
Another thing that you can consider adding to the core... a utilities class
'Models' to wrap models so you don't have those pesky all over the place:
public MyPanel(String id, IModelInteger model)
{
super (id, Models.compound (model)); // wrap model in a
CompoundPropertyModel
}
Matej Knopp-2 wrote:
There is one thing that helped me quite a lot when migration the
project I'm working out. I've created GenericPanel,
GenericWebMarkupContainer and GenericFragment classes. In most cases
the only change was renaming PanelMyClass to GenericPanelMyClass.
I was wondering, even though those classes were farily simple, we
might want to include them in Wicket anyway, for the sake of
consistency and convenience.
-Matej
On Mon, Jun 30, 2008 at 12:28 PM, Johan Compagner [EMAIL PROTECTED]
wrote:
i looked through the code and it is fine by me.
Lets test this then in a Build and see what people think of this.
On Mon, Jun 30, 2008 at 8:54 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
unit tests are fixed...
-igor
On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED]
wrote:
On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier [EMAIL PROTECTED]
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 IModelT 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
IModelT 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best:
Re: generics
I too like this compromise alot Although I don't see a good use case for generifying Link ? Am I missing something? On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho [EMAIL PROTECTED] 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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
onPopulateItem(ItemUser item) {
add(new LinkUser(delete, item.getModel()) {
protected void onClick() { service.delete(getModelObject()); }
});
}
-igor
On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen [EMAIL PROTECTED] wrote:
I too like this compromise alot
Although I don't see a good use case for generifying Link ?
Am I missing something?
On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho [EMAIL PROTECTED]
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 OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
add (new LinkPerson(edit, person) {
public void onClick () {
setResponsePage (new EditPersonPage (getModel()));
}
});
This code makes a lot more sense if it is inside a repeater...
Rodolfo Hansen-2 wrote:
I too like this compromise alot
Although I don't see a good use case for generifying Link ?
Am I missing something?
On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho [EMAIL PROTECTED]
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 OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/generics-tp18083910p18222901.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Isn't this a same thing:
onPopulateItem(final ItemUser item) {
add(new Link(delete) {
protected void onClick() { service.delete(item.getModelObject()); }
});
}
Joni
On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
onPopulateItem(ItemUser item) {
add(new LinkUser(delete, item.getModel()) {
protected void onClick() { service.delete(getModelObject()); }
});
}
-igor
On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen [EMAIL PROTECTED] wrote:
I too like this compromise alot
Although I don't see a good use case for generifying Link ?
Am I missing something?
On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho [EMAIL PROTECTED]
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 OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
Wouldn't it be better to leave the generic part to this reusable link
then? Why 'pollute' all links with a generic parameter?
Back to your definition:
(1) only components that use their model have a generic type
(components you are likely to call getmodel/getmodelobject on as a
user).
What now? Components that use their model *or* you're likely to call getmodel
on? Seems to me as two different things:
Link doesn't fit in the first category nor is it always used with a model.
Sven
Igor Vaynberg schrieb:
if your link is anonymous, yes. if you have reusable links in their
own class, then no.
-igor
On Tue, Jul 1, 2008 at 12:24 PM, Joni Freeman [EMAIL PROTECTED] wrote:
Isn't this a same thing:
onPopulateItem(final ItemUser item) {
add(new Link(delete) {
protected void onClick() { service.delete(item.getModelObject()); }
});
}
Joni
On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
onPopulateItem(ItemUser item) {
add(new LinkUser(delete, item.getModel()) {
protected void onClick() { service.delete(getModelObject()); }
});
}
-igor
On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen [EMAIL PROTECTED] wrote:
I too like this compromise alot
Although I don't see a good use case for generifying Link ?
Am I missing something?
On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho [EMAIL PROTECTED]
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 OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
the question here is: do most people use the model in the Link or not?
when you use compound property model in conjunction with form
components you never call getmodel/object() on those either. what now?
not generify form components? i dont think a strict criteria will
work.
some components fall into a gray area which needs to be discussed and
generified on case by case basis. when i was generifying wicket my
primary usecase is to use Link with a model so i went that way. start
a discussion/vote and see where that goes in a different thread. i
will be happy to go with what the majority thinks in this particular
case.
-igor
On Tue, Jul 1, 2008 at 2:34 PM, Sven Meier [EMAIL PROTECTED] wrote:
Wouldn't it be better to leave the generic part to this reusable link then?
Why 'pollute' all links with a generic parameter?
Back to your definition:
(1) only components that use their model have a generic type
(components you are likely to call getmodel/getmodelobject on as a
user).
What now? Components that use their model *or* you're likely to call
getmodel on? Seems to me as two different things:
Link doesn't fit in the first category nor is it always used with a model.
Sven
Igor Vaynberg schrieb:
if your link is anonymous, yes. if you have reusable links in their
own class, then no.
-igor
On Tue, Jul 1, 2008 at 12:24 PM, Joni Freeman [EMAIL PROTECTED] wrote:
Isn't this a same thing:
onPopulateItem(final ItemUser item) {
add(new Link(delete) {
protected void onClick() { service.delete(item.getModelObject()); }
});
}
Joni
On Tue, 2008-07-01 at 11:56 -0700, Igor Vaynberg wrote:
onPopulateItem(ItemUser item) {
add(new LinkUser(delete, item.getModel()) {
protected void onClick() { service.delete(getModelObject()); }
});
}
-igor
On Tue, Jul 1, 2008 at 11:51 AM, Rodolfo Hansen [EMAIL PROTECTED]
wrote:
I too like this compromise alot
Although I don't see a good use case for generifying Link ?
Am I missing something?
On Fri, Jun 27, 2008 at 2:49 PM, Timo Rantalaiho
[EMAIL PROTECTED]
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 OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Tue, 01 Jul 2008, Matej Knopp wrote: There is one thing that helped me quite a lot when migration the project I'm working out. I've created GenericPanel, GenericWebMarkupContainer and GenericFragment classes. In most cases the only change was renaming PanelMyClass to GenericPanelMyClass. Maybe the names could be TypedPanel / ModelContainingPanel or something like that? Or maybe start with the original component name so that they would pop up more easily in the IDE, for example PanelWithType / PanelWithModel? I was wondering, even though those classes were farily simple, we might want to include them in Wicket anyway, for the sake of consistency and convenience. I thought about this and I think that it might be better to not include them after all. In 1.5 it would be great to separate IModel and Component more thoroughly, getting rid of the defaultModel* accessors. Then it would make less sense to have the convenience classes with those model and modelObject accessors. In cases where two components share the same model, it would make sense to make the IModel field in each component final. Then setModel() does not make sense any more; all it could do would be throw an exception or be a confusing no-op. Likewise, sometimes you never do setModelObject() or getModelObject() from outside the class. Leaner APIs and less methods per objects are good things. Hence it's better to add methods as you need them, instead of providing a lot of convenience stuff that is only used a part of the time. Surely each Component subclass has anyway a lot of methods, and MarkupContainers even more, but you have got to start somewhere :) This is not a big deal though, either way is fine by me. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
There is one thing that helped me quite a lot when migration the project I'm working out. I've created GenericPanel, GenericWebMarkupContainer and GenericFragment classes. In most cases the only change was renaming PanelMyClass to GenericPanelMyClass. I was wondering, even though those classes were farily simple, we might want to include them in Wicket anyway, for the sake of consistency and convenience. -Matej On Mon, Jun 30, 2008 at 12:28 PM, Johan Compagner [EMAIL PROTECTED] wrote: i looked through the code and it is fine by me. Lets test this then in a Build and see what people think of this. On Mon, Jun 30, 2008 at 8:54 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: unit tests are fixed... -igor On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier [EMAIL PROTECTED] 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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier [EMAIL PROTECTED] 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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
unit tests are fixed... -igor On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier [EMAIL PROTECTED] 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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
i 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 [EMAIL PROTECTED] wrote: unit tests are fixed... -igor On Sun, Jun 29, 2008 at 11:16 PM, Martijn Dashorst [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier [EMAIL PROTECTED] 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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
On Sun, Jun 29, 2008 at 12:48 PM, Sven Meier [EMAIL PROTECTED] 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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
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 [EMAIL PROTECTED] 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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: generics
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
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 OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 TT 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 TT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
I 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 [EMAIL PROTECTED] 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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: generics
I'm getting the same thing. -Original Message- From: Martin Funk [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 10:42 AM To: users@wicket.apache.org Subject: Re: generics basically we feel this is a much cleaner way then what is 1.4m2. this is a call for confirmation/discussion from our user base. do try to port a small project or a part of a larger project you are working on to the [1] branch to see how the new api feels. if we do like this more the new branch will be merged into what will be 1.4m3. [1] https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/generics am I the only one running into this: mvn clean install [...] [INFO] [INFO] Building Wicket [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/fnk64/tmp/generics/wicket/target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Compiling 748 source files to /home/fnk64/tmp/generics/wicket/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/fnk64/tmp/generics/wicket/src/main/java/org/apache/wicket/markup/h tml/list/ListItem.java:[90,42] type parameters of TT 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 TT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
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 [EMAIL PROTECTED] 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 TT 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 TT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: generics
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 IModelT 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 IModelT 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
