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
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
Thanks for your reply. I think I can (at least partially) understand
your position and think there aren't any new arguments here I can
mention. So the discussions seems to be at an end here.
Maybe it is a matter of taste... If I find any time, I will create a
patch...
Regards,
Johannes
On
On Wed, 2009-03-04 at 09:14 -0800, Igor Vaynberg wrote:
components that deal with collections in wicket always reuse the same
instance of collection is one was provided where it makes sense.
Yes, and therefore a setter is not necessary.
setobject is still called on the model, but is called
On Sat, Mar 7, 2009 at 10:15 AM, Johannes Schneider
maili...@cedarsoft.com wrote:
setobject is still called on the model, but is called with the same
instance of collection. this is necessary so that if you have a model
that translates a collection of one type to a collection of another
i think misuse is a pretty bold word considering you are talking to
people who designed and built imodel, dont you think? :)
Well, I think you are right. Sorry for that.
I just mean, that it has a bad smell here...
if we do what you suggest then we would end up with:
interface imodel {
you are right, the components that just read a collection do just
that, read it. they simply ignore the setter method in imodel. no big
deal, just because you are given an interface doesnt mean you have to
use all the methods in it. thus abstractreadonlymodel.
however, a lot of components
Hi,
the concept of IModel seems to be very obvious. It is simply some kind
of reference and offers a getter and a setter.
When used with ordinary object, everything works fine. An IModel that
contains a String can easily be mapped to a TextField.
The text field calls getObject to show the
Does AbstractReadOnlyModel accomplish what you're talking about?
Scott
On Wed, Mar 4, 2009 at 4:50 AM, Johannes Schneider
maili...@cedarsoft.com wrote:
Hi,
the concept of IModel seems to be very obvious. It is simply some kind
of reference and offers a getter and a setter.
When used with
components that deal with collections in wicket always reuse the same
instance of collection is one was provided where it makes sense.
setobject is still called on the model, but is called with the same
instance of collection. this is necessary so that if you have a model
that translates a
On Wed, 25 Feb 2009, Timo Rantalaiho wrote:
I'd say that ListView is wrong here.
I created a new Jira issue on fixing that
https://issues.apache.org/jira/browse/WICKET-2126
and will do if there are no objections or better ideas.
Well, Igor objected very convincingly :)
So now there
? extends
Foo
That just seems odd.
Welcome to Java generics...
Thanks. It's working now.
private class AllUsersModel extends LoadableDetachableModelList?
extends
User{
protected ListUser load() {
return userService.findAllUsers
On Tue, 24 Feb 2009, Matthew Hanlon wrote:
I've always handled the typing problem with DropDownChoice and my list
models by just ignoring it and not applying type parameters to the
DropDownChoice. This is because if I use the same IModelList? extends
Foo for a ListView, then I get an error in
, but no
luck. I'm sure I'm missing an E or a T or a? somewhere but I at a
lost
as to what the exact problem is. I've been a consumer of generics
forever,
but actually being on the creation side is a bit new to me.
--
View this message in context:
http://www.nabble.com/LDM-with-Generics
your model supertype from ListFoo to List? extends Foo
That just seems odd.
Welcome to Java generics...
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3
? extends
Foo
That just seems odd.
Welcome to Java generics...
Thanks. It's working now.
private class AllUsersModel extends LoadableDetachableModelList?
extends
User{
protected ListUser load() {
return userService.findAllUsers
();
}
}
I'm trying to use this as the Choices model in a DropDownChoice, but no
luck. I'm sure I'm missing an E or a T or a? somewhere but I at a lost
as to what the exact problem is. I've been a consumer of generics forever,
but actually being on the creation side is a bit new to me
in a DropDownChoice, but no
luck. I'm sure I'm missing an E or a T or a? somewhere but I at a
lost
as to what the exact problem is. I've been a consumer of generics forever,
but actually being on the creation side is a bit new to me.
--
View this message in context:
http://www.nabble.com/LDM
On Sun, 22 Feb 2009, Jeremy Thomerson wrote:
I've been meaning to ask on the dev list why that is. Being forced to
declare the ? extends User for a model like yours seems to add complexity,
and force a local variable. I haven't looked at it that much, but I know
that every time I've had to
Hi-
Is there any interest in making inmethod grid generic?
I have a half-way implementation that makes IDataSourceT -- it does
not make IQueryResult generic though.
Is there anywhere to attach patches for inmethod-grid? I don't see
anything on:
://www.nabble.com/ListView-vs-DropDownChoice-with-Generics-tp20684801p20684801.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
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
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
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
When trying to use the DefaultDataTable in combination i'm running into what I
think is a bug in the generification of ChoiceFilteredPropertyColumn,
DefaultDataTable is parameterized with type T and the constructor expects
IColumnT for it's column types. if I try to parameterize
please open a jira issue.
-igor
On Mon, Nov 17, 2008 at 4:44 AM, Dylan Schell [EMAIL PROTECTED] wrote:
When trying to use the DefaultDataTable in combination i'm running into what
I think is a bug in the generification of ChoiceFilteredPropertyColumn,
DefaultDataTable is parameterized with
Who has a real live example of this function:
http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/jsr166y/forkjoin/ParallelArrayWithMapping.html#withMapping(jsr166y.forkjoin.Ops.BinaryOp,%20jsr166y.forkjoin.ParallelArrayWithMapping)
Its one of the most beautiful generic methods i have ever seen!
should i?
On Fri, Nov 14, 2008 at 6:09 PM, Igor Vaynberg [EMAIL PROTECTED]wrote:
youve never coded WTL?
-igor
On Fri, Nov 14, 2008 at 8:17 AM, Johan Compagner [EMAIL PROTECTED]
wrote:
Who has a real live example of this function:
it had way cooloer functions as far as generic arguments went :)
-igor
On Fri, Nov 14, 2008 at 9:11 AM, Johan Compagner [EMAIL PROTECTED] wrote:
should i?
On Fri, Nov 14, 2008 at 6:09 PM, Igor Vaynberg [EMAIL PROTECTED]wrote:
youve never coded WTL?
-igor
On Fri, Nov 14, 2008 at 8:17 AM,
The code is not so cool as the compiler error messages! :-)
Adriano
Igor Vaynberg escreveu:
youve never coded WTL?
-igor
On Fri, Nov 14, 2008 at 8:17 AM, Johan Compagner [EMAIL PROTECTED] wrote:
Who has a real live example of this function:
that be:
public void populateItem(ItemICellPopulatorT item, String
componentId,
IModelT model)
, the way it is in ICellPopulator? Am I smoking or misunderstanding
generics?
Luke
--
View this message in context:
http://www.nabble.com/PropertyColumn-and-generics-tp20335170p20335170.html
Sent from
I'm probably too late coming into the discussion but from reviewing past
threads it appears the only reason for 1.4-m3 over m2 and removing
generics from Component is because some things like Page and Label don't
make sense with generics?
If that is really the only reason (and there may
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
feel about your choice above?
[X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p18965543.html
Sent from the Wicket
-on-generics-with-Wicket-tp17589984p18800407.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
generics, there are many other features in java
5 could be used to enhance wicket. and I feel the most helpful new
facilities of wicket could be some powerful widgets, layouts, menus that one
can use java api to produce (it could use any JS toolkits). Although it was
contended that wicket is server
] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
Wicket Rocks!
Thanks!
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p18661192.html
Sent from the Wicket - User mailing
about your choice above?
[X ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
The reason for my decision is that if a concept will be applied to a
framework, then it should be applied thoroughly; in this case generics to
all container-like types.
But what
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
--
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
--
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
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
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,
Brill Pappin [EMAIL PROTECTED] wrote:
I'd say that WIcket *is a product*, and as such the consumers
of that product have the final say.
Not any more than you can e.g. go to Ford Motor Co. and demand they make
this and that modification to the design of the Mustang, for instance.
Like most
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]
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
I agree completely.
- Brill
On 15-Jul-08, at 3:28 AM, Wilhelmsen Tor Iver wrote:
Brill Pappin [EMAIL PROTECTED] wrote:
I'd say that WIcket *is a product*, and as such the consumers
of that product have the final say.
Not any more than you can e.g. go to Ford Motor Co. and demand they
. 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
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
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
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
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
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
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
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
)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
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
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
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
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...
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
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
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
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]
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
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
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
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.
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
:)
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
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,
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
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
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
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
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
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
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
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
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
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
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
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); }
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
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
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
:
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]
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
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
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
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
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
]
--
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
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
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
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
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
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
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
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
101 - 200 of 635 matches
Mail list logo
