Also, 1.3's default session store
serializes on each request, but does not reuse that serialized
instance until the back button is used (or if you're doing session
replication and come in through another node I guess).
It keeps the 'current' page in memory, and reuses that when it can.
Eelco
generics.
It depends on how you phrase things. It is a fact that currently
models and components are tightly bound because of 'getModelObject'.
The main issue is that with 1.3 you can simply omit the model, whereas
with generified components the choice to not use a model is explicit
(whether you use
I implemented this by hooking in to serialization, just checking
each object
in ObjectOutputStream.replaceObject and
ObjectInputStream.resolveObject.
Also had to use my own PageMapEntries to get a suitable hook. Might
work as
an idea for your implementation perhaps?
That's a cool idea for
Well... I haven't actually hooked into the SessionStore but instead have
implemented a special PageMapEntry that stores a serialized page with my
special serialization (hooked in by overridden getPageMapEntry(...) in my
BasePage). The special serialization takes place when the page is put into
model - it is there totally
out of convinience. i think what is flawed here is that we tied the
two types via generics.
It depends on how you phrase things. It is a fact that currently
models and components are tightly bound because of 'getModelObject'.
The main issue is that with 1.3 you can
you have an example for this or some pointer to
someone who has ?
--
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-tp17589984p17656527.html
Sent from the Wicket - User mailing list archive at Nabble.com
in the regular way nowadays.
I use plenty of panels (the app I work on hardly uses separate pages)
that nest other panels in them (typically detail views or dialogs)
that reuse models of the parent. But indeed YMMV.
Personally, I think the whole generics business exposes that the
one-one relation between
, or that anything is flawed. the
component provides a slot for a default model - it is there totally
out of convinience. i think what is flawed here is that we tied the
two types via generics.
It depends on how you phrase things. It is a fact that currently
models and components are tightly bound
.
Personally, I think the whole generics business exposes that the
one-one relation between components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor, but as generics aren't as 'optional' it is all very in
your face suddenly.
I think
on the internet...)
johan
On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila [EMAIL PROTECTED]
wrote:
generics for formcomponents do not make sense, most of the time they
can figure out the type by inspecting their model. further, generics
did not get rid of the need to specify the type
generics for formcomponents do not make sense, most of the time they
can figure out the type by inspecting their model. further, generics
did not get rid of the need to specify the type as a constructor
argument: new TextFieldInteger(num, Integer.class)
Agreed.
+1 for NOT generifying
models as parameter to the constructor of my custom components.
Those parameters are always named according to the expected type they
contain (e.g. fooModel if i expect an object of type Foo in there).
Therefore, generics could jump in quite easily and I am looking forward to
use them
Johan Compagner wrote:
On Mon, Jun 2, 2008 at 9:33 PM, Martin Funk [EMAIL PROTECTED]
wrote:
Hi Sebastiann,
just for clarifying my understanding of the vocabulary:
A_HomePage extends WebPage
and
B_HomePage extends WebPageVoid
are both non-generified java classes.
No the last one is
://www.agileskills2.org/EWDW
Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA
--
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-tp17589984p17618364.html
Sent from the Wicket - User mailing
. Getting used to generics took
about 1 1/2 days, but was well worth the effort. Consider this a
two-thumbs-up success story for generics.
Thanks to the people on this list who answered my questions. I hope to
add more lessons learned to my wiki page this week
(http://wiki.donohoedigital.com/wiki
: users, please give us your opinion: what is your take on
generics with Wicket
If only... if only
we had this construct:
class ComponentT default Void
{
}
then all our problems with verbosity would be gone..
TextField tf = new TextField(id) // just default Void
Also only declare it once
Hi,
We haven't worked with 1.4 enough to form an opinion, but we'll
definitely upgrade to it for the next project.
On 6/3/08, Johan Compagner [EMAIL PROTECTED] wrote:
If only... if only
we had this construct:
class ComponentT default Void
If only we had type inference :-)
Is this any
If only we had type inference :-)
Is this any nicer in scala?
in scala you wouldn't have to have the getModel/getModelObject within Component
in the first place (you could use mixins for this purpose).
--- Jan.
-
To
Gabor Szokoli wrote:
Hi,
We haven't worked with 1.4 enough to form an opinion, but we'll
definitely upgrade to it for the next project.
On 6/3/08, Johan Compagner [EMAIL PROTECTED] wrote:
If only... if only
we had this construct:
class ComponentT default Void
If only we had type
On 6/3/08, Jan Kriesten [EMAIL PROTECTED] wrote:
If only we had type inference :-)
Is this any nicer in scala?
in scala you wouldn't have to have the getModel/getModelObject within
Component in the first place (you could use mixins for this purpose).
I was thinking about using the
.
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 4:15 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
If only... if only
we had this construct:
class ComponentT default
Type inference alone will not really help us
To kill the verbosity on components that are not used with models we need
something like T default Void
johan
On Tue, Jun 3, 2008 at 1:34 PM, Gabor Szokoli [EMAIL PROTECTED] wrote:
Hi,
We haven't worked with 1.4 enough to form an opinion, but
to do one or two casts than trying to
conform the generics Component structure. Especially since there are cases
with 1.4 generics (like StringResourceModel) which sometimes aren't
recognized as IModelString (which of course is more a Scala than a Wicket
problem)...
Remember that 1.4 isn't done
(as of yesterday due to a fix we submitted).
We migrated from 1.3.x to 1.4 mid-project. Getting used to generics took
about 1 1/2 days, but was well worth the effort. Consider this a
two-thumbs-up success story for generics.
Thanks to the people on this list who answered my questions. I hope
Hi Gabor,
I was thinking about using the existing wicket 1.4 API from scala, if
that's any more comfortable.
I tried to migrate a bigger project from 1.3 to 1.4 api - and it isn't really
more comfortable. It's easier to do one or two casts than trying to conform the
generics Component
-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 7:47 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
really?
i still cant find information what will really be 1.7..
On Tue, Jun 3, 2008 at 1:29
Hi James,
Remember that 1.4 isn't done yet either. Perhaps these are just
growing pains that the wicket team is going through (or perhaps it's
not).
it's not... ;-)
No, really, I have invested quite some time to get comfortable with Components +
Generics. And I came to the conclusion
1) Generifying* Wicket
[X] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
2) How strongly do you feel
- the biggest win
for me, is that I directly see, what I have or what should be in the model.
I think, this is not worth the other problems.
Living with generics is a little bit harder, than living with no generics.
But I personally have no problem to live with it.
If I should say decision, based on my
Eelco Hillenius wrote:
1) Generifying* Wicket
[x] Can best be done like currently in the 1.4 branch, where models
[x] Can best be done in a limited fashion, where we only generify
Both are acceptable to me
2) How strongly do you feel about your choice above?
[x] I definitively
[ X] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
2) How strongly do you feel about your
((String)null)... I understand that this is a huge API break, with
marginal value, but it does express the Model:Component relationship a lot
more clearly.
--
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
to move our app to m1. My
experience has been that generics on components are absolutely not
worth it for our use cases. I love generics on objects that directly
hold data (IModel), but they are too verbose and not very useful for
objects that are a few levels removed from the actual data
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
* I find anon inner classes can benefit a lot from generics. - This means
both imodel and component - but I think both
sorry, still waiting for an example here...
-igor
On Tue, Jun 3, 2008 at 7:53 PM, Brill Pappin [EMAIL PROTECTED] wrote:
Actually, i did not say ... say that wicket api needs a radical refactoring
in order to support generics what I actually said was I think that if
Wicket had been written
I guess I'm not understanding why people feel strongly against generics in
the components.
The model is going to use them for the data they contain, but the component
would use them for the model it uses:
MyModelString mymodel = new MyModelString();
MyComponentMyModel mycom = new
You will wait a long time for an example generated from the API would be
different in such and such a case, based on an opinion.
If your really all that interested you could start from scratch using
generics and see what came out.
Let me know if you do, because I'd be interested to see if my
would be
different in such and such a case, based on an opinion.
If your really all that interested you could start from scratch using
generics and see what came out.
Let me know if you do, because I'd be interested to see if my opinion held
any merit.
However, if your interested in why I
of our
components don't have a model. We generally have a page containing
one or more forms with a CompoundPropModel on each form. Having
generics (particularly if they are just something like Void) on
every other object in the page is messy and confusing in my mind.
Telling people to use
the verbosity doesn't
benefit us much. Also, the vast majority of our components don't have a
model. We generally have a page containing one or more forms with a
CompoundPropModel on each form. Having generics (particularly if they are
just something like Void) on every other object in the page
). So the verbosity doesn't
benefit us much. Also, the vast majority of our components don't have a
model. We generally have a page containing one or more forms with a
CompoundPropModel on each form. Having generics (particularly if they are
just something like Void) on every other object
1) Generifying* Wicket
[X] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.
2) How strongly do you feel about your choice above?
[ ] Whatever
Didnt you encounter the big thread (at least 100 messages) where we
discussed/voted going to 1.4? (and cool down dev on 1.3)
On 6/1/08, Ayodeji Aladejebi [EMAIL PROTECTED] wrote:
scan this user forum, you will realize that there is no high demand for
generics in wicket from users. I am yet
1) Generifying* Wicket
[X] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
2) How strongly do
to use then I prefer to
fall back to only generified models. At one point someone suggested a
wiki page outlining the difficulties with generics, does such a page
exist?
2) How strongly do you feel about your choice above?
[X] Whatever choice ultimately made, I'll happily convert/ start
using
1) Generifying* Wicket
[ X ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
2) How strongly do
1) Generifying* Wicket
[X ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
2) How strongly do you
(downgraded it) and
that worked just fine and very intuitive, I was very bummed at the time
I had to add all these hideous type casts. I do not understand the fuss about
generifying everything, I did not have ANY problems using the generics in
my production project (which consists of about 30 wicket
rethink upgrading if my choice doesn't win.
Seriously, no generics at all is better than a partial solution. Since
upgrading involves more issues than generics alone, I may rethink
only... If the decision to upgrade boils down to this issue, then I
won't.
Antoine
1) Generifying* Wicket
[x] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.
2) How strongly do you feel about your choice above?
[x]
opinion: what is your take on
generics with Wicket
Hi all,
We have had several threads in this and the dev list, and some
discussions in the public on how to incorporate generics in Wicket.
I'd like to use this thread to gather the opinions of as many regular
Wicket users as we can. Please help us get
).
2) How strongly do you feel about your choice above?
[X] I might rethink upgrading if my choice doesn't win.
Seriously, no generics at all is better than a partial solution. Since
upgrading involves more issues than generics alone, I may rethink
only... If the decision to upgrade boils
1) Generifying* Wicket
[X ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
2) How strongly do you
a Component not a TextArea and setRequired is not
available on Components.
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-tp17589984p17601296.html
Sent from the Wicket - User mailing list archive
seems a little over the top with little value. It
seems that generics in the models and collections only should be sufficient.
2) How strongly do you feel about your choice above?
[X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
Any use of generics is better
The problem is that this could result in us lifting a final where we dont
want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko [EMAIL PROTECTED]
wrote:
[ x ] Can best be done in a limited fashion, where we only generify
IModel
1) Generifying* Wicket
[X] Should be avoided, definitly. All this generics stuff is ruining my
wicket experience.
2) How strongly do you feel about your choice above?
[X] I might rethink upgrading if my choice doesn't win.
--
View this message in context:
http://www.nabble.com/users
1) Generifying* Wicket
[X] Should be avoided, definitly. All this generics stuff is ruining my
wicket experience.
2) How strongly do you feel about your choice above?
[X] I might rethink upgrading if my choice doesn't win.
--
View this message in context:
http://www.nabble.com/users
models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form)
{
EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont
1) Generifying* Wicket
[x] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.
2) How strongly do you feel about your choice above?
[x] I
your opinion: what is your take on
generics with Wicket
ok maybe i misread this :
'Can best be done in a limited fashion, where we only generify IModel
but not components. I care more about what generifying can do for API
clarity (declaring a component to only accept certain models for
instance
would like to see.
generic components im not bothered about.
Using generics will do away with the casting, but only if you
genericize Component. Merely genericizing IModel won't get rid of the
casting by itself
Ok you example doesnt work..
You will need to cast there
Then IModel only only helps describing the constructor. After that you loose
the generics or you have to ofcourse keep the models and dont work anymore
directly with the components
So if we only do IModel and not component
: richardwilko [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:21 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
ok maybe i misread this :
'Can best be done in a limited fashion, where we only generify IModel
I think its not quite that simple.
Certainly both sets of components should use generics (silly to have a
partial solution) but how its done is vital so that it doesn't become a huge
mess.
I'm one of the adopters of the M1 release and I've found it quite difficult
to keep things straight
I'd really like to know how it's ruining my wicket experience?
Can you please elaborate?
I agree that the M1 release of 1.4 was less than optimum, but not having
generics is annoying to people who have gotten used to using them.
- Brill Pappin
-Original Message-
From: mozvip [mailto
us your opinion: what is your take on
generics with Wicket
Goes to show you that people have a tendency to reject things that they do
not understand rather than put in the effort :o)
-
To unsubscribe, e-mail: [EMAIL PROTECTED
On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote:
I'm not sure I like where this discussion is going. I don't see anyone
having any particular objections against current state. I think before
we even think of (partially) reverting generics we have to discuss
what's wrong
+1
-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:49 AM
To: users@wicket.apache.org
Subject: RE: users, please give us your opinion: what is your take on
generics with Wicket
I don't know, I think the discussion is going *toward* generics
+1
I would like to see what the major issues are as to why people are
rejecting model/component generics. None that I have seen so far are
that convincing- especially the complaints of verbosity.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James
are
rejecting model/component generics. None that I have seen so far are
that convincing- especially the complaints of verbosity.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James Carman
Sent: Monday, June 02, 2008 10:56 AM
To: users
Hi Elco, hi Users,
first of all thanks a lot for trying generics in wicket in the first case.
I haven't really cared about em so far, too much. So thanks a lot for
the learning experience I'm going through right now.
[x] Can best be done in a limited fashion, where we only generify
IModel
I'm not sure I like where this discussion is going. I don't see anyone
having any particular objections against current state. I think before
we even think of (partially) reverting generics we have to discuss
what's wrong (except the verbosity of course, but that's not something
we can really do
I don't know, I think the discussion is going *toward* generics.
Frankly I can't even see why its an issue at all, the language has evolved
and uses them... Why would Wicket not also use them its inline with the
current state of the language?
There is no reason that people who can't get
these cases (which are easily the majority in
my experience), genericized Components would force me to deal with the
syntactic overhead of generics with absolutely zero value.
I'm all for genericizing certain components for which the model is
central (e.g. ListView and Item) but I think genericizing
I see your point... a referendum will only be as good as the current
state of the product that is being evaluated, and the expertise of those
doing the evaluation. It seems as though in this case that some of those
doing the evaluation have limited knowledge of what benefits generics
has to offer
Hi Elco, hi Users,
first of all thanks a lot for trying generics in wicket in the first case.
I haven't really cared about em so far, too much. So thanks a lot for
the learning experience I'm going through right now.
[x] Can best be done in a limited fashion, where we only generify
IModel
Hi,
I'm not sure I like where this discussion is going. I don't see anyone
having any particular objections against current state.
@matej_k:
ugh - you should count again... if I counted right, most of the responses yet
prefer 'Component' /not/ being touched by generics.
+1, I agree. I
On Mon, Jun 2, 2008 at 11:22 AM, Jan Kriesten [EMAIL PROTECTED] wrote:
@jwcarman:
There is an issue with generics on components which is leading into a big
mess - and as far as I can see, many objections are especially on that
topic! It might not be Wicket's fault, though, it might
: Monday, June 02, 2008 11:11 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
Agreed. I don't see a problem with having to type LinkVoid or
PageVoid instead of Link/Page. That's simply the way that generics
are implemented
on
generics with Wicket
Why don't we use the Wiki page to list our *specific* gotchas we
encounter and try to come up with a solution for them. My guess is that
we can do so.
On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED]
wrote:
+1
I would like to see what the major issues
Hi,
But IMHO putting generics on Component is a bad design, since it per se
touches all of Wicket's Components without urgent need.
I *really* would like to see a clarification of this statement. In
Wicket the component and model are very tightly coupled. What is a *good
design* alternative
prefer 'Component' /not/ being touched by generics.
Question is, how many of those users actually use generified wicket on
day-to-day basis.
-Matej
+1, I agree. I think this discussion might be counter-productive if
folks who aren't using the generified versions are voting.
@jwcarman
, 2008 11:06 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
Why don't we use the Wiki page to list our *specific* gotchas we
encounter and try to come up with a solution for them. My guess is that
we can do so.
On Mon
' generics:
Why do you have to put generics on Components, when need is only in a fraction
of cases?
Discussing the possibility of Void is somewhat an obscure workaround. It's
just boilerplate in more than 70% (of my cases), and this boilerplate gets
repeated over and over again with each
Agreed. I don't see a problem with having to type LinkVoid or
PageVoid instead of Link/Page. That's simply the way that generics
are implemented in Java. Are there places in the API where an end
user would have to type something like Class? extends Page? extends
IModelT? That way madness lies
Good question... I would add to that and say:
how many of those users actually use generified wicket on day-to-day
basis?
how many of those users actually implement generics on day-to-day basis
(not just using them- like ListMyClass)?
-Original Message-
From: Matej Knopp [mailto:[EMAIL
returns IModel??
IMHO the practical solution would be to leave generics from components and have
getModelObject return Object, yes. On certain components (ListView e.g.), those
methods may be overridden by more concrete implementations.
Regards, --- Jan
Can you elaborate?
What (anti)pattern(s) make you think that generics in the components are bad
design?
Besides the effort involved for the wicket developers, as a user I was
leaning the opposite way... But maybe I missed something (not unusual).
- Brill Pappin
-Original Message-
From
if you understand what void
represents. The key point is that Java generics are not runtime generics
;o)
-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 11:37 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what
James Carman wrote:
I'm adding a Gotchas section now.
Your pallete gotcha seems more like a JIRA to me. :-) It's not really
about generics in general, but about a specific choice in 1 component
(which really seems incorrect to me, i.e., PECS).
One of the gotcha's I think is the getHomePage
?
Maybe I don't understand what you mean by raw type.
- Brill Pappin
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 11:53 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics
. Not
everybody is a generics wizz you know, nor has the need to become one.
Most users want to just build web apps in a clean, self-documenting
API that doesn't put too much burden upon them - conceptually and
number of characters to type, read and understand.
Martijn
On Mon, Jun 2, 2008 at 5:28
Hi Sebastian,
What about getModel()? If componennt is not generified I'm really
wondering if the there is any benefit to generics at all... (I do really
think it will spawn lots of questions on the list as well).
what's the problem with getModel? If you specialize on a certain Component
Why can't this be done the way the java API does it, and allow people to use
it or not as they want?
Wicket is pretty clean in terms of the API, and there are interfaces for
most things... So what's the problem with adding the generics to the
interfaces?
AFAIK this would allow them to be ignored
workaround. Why do you think they have
it? I think it's intent is very clear if you understand what void
represents. The key point is that Java generics are not runtime generics
;o)
See above, the point is having Void in there for especially nothing to gain -
Just make reading harder and each
Brill Pappin wrote:
Why can't this be done the way the java API does it, and allow people to use
it or not as they want?
Wicket is pretty clean in terms of the API, and there are interfaces for
most things... So what's the problem with adding the generics to the
interfaces?
AFAIK this would
PROTECTED]
Sent: Monday, June 02, 2008 11:53 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
James Carman wrote:
I'm adding a Gotchas section now.
Your pallete gotcha seems more like a JIRA to me. :-) It's not really about
(and the cost of),
despite effort on the initial development.
One thing that means for me, is generics... Just like TDD, it reduces the
issue count (among other things).
- Brill Pappin
-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 11:47 AM
On Mon, Jun 2, 2008 at 11:52 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
James Carman wrote:
I'm adding a Gotchas section now.
Your pallete gotcha seems more like a JIRA to me. :-) It's not really about
generics in general, but about a specific choice in 1 component (which
really seems
301 - 400 of 635 matches
Mail list logo
