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
]
--
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
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,
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
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
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.
:
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
.
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
.
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
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
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
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
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]
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
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
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
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
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
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
/generics
am I the only one running into this:
mvn clean install
[...]
[INFO]
[INFO] Building Wicket
[INFO]task-segment: [clean, install]
[INFO
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
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
/sandbox/ivaynberg/generics
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail
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
. I understand that users are worried about complexity, but the
complexity of generics really rests upon the framework authors' shoulders,
not the users of the framework. I believe within the next 2-3 years, as we
see the phasing in of JDK 5-based app servers, that JEE programmers will
become pretty
why wicket should demote self for anybody, who can not understand
generics.
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
Eelco Hillenius wrote:
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
generifying everything, I did not have ANY problems using the generics in
my production project (which consists of about 30 wicket classes) and it
was not a simple crud app, I did some funky wicket stuff with this
project (loads
of panels, fragment, own custom component, ajax) and it all just
of this generics episode.
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]
Component might
be the best thing to have come out of this generics episode.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Hi,
if the consequences are a cleaner api then I think to decouple the model is
right.
The migration for older code may be hard. But I think it will be worth it
when the new code base is more robust.
--
View this message in context:
http://www.nabble.com/wicket-generics-tp17706107p17757524
I don't know if i was clear enough, sorry about that.
I meant if you have something like :
public ComponentMODEL extends IMODELID, ID extends Serializable{
// getter here
public MODEL getModel() { }
// setter here
public void setModel(final MODEL model){ }
}
then, you don't have to do
which is exactly what we are trying to avoid - having generics in Component.
-Matej
On Tue, Jun 10, 2008 at 6:19 PM, Ricky [EMAIL PROTECTED] wrote:
I don't know if i was clear enough, sorry about that.
I meant if you have something like :
public ComponentMODEL extends IMODELID, ID extends
we are trying to avoid - having generics in
Component.
-Matej
On Tue, Jun 10, 2008 at 6:19 PM, Ricky [EMAIL PROTECTED] wrote:
I don't know if i was clear enough, sorry about that.
I meant if you have something like :
public ComponentMODEL extends IMODELID, ID extends Serializable
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] Whatever
Strong typing is my friend. Refactoring is my friend. The stronger
and clearer we make typing throughout Wicket the happier I'll be.
Code is written once and maintained a hundred thousand times. I'd
always trade verbosity for maintainability.
+1 for that --- very nice said! I totally
Strong typing is my friend. Refactoring is my friend. The stronger and
clearer we make typing throughout Wicket the happier I'll be.
Code is written once and maintained a hundred thousand times. I'd
always trade verbosity for maintainability.
Yes! Good summary!
Stefan
so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void setmodel(imodel? model) {...}
public imodel? getmodel();
}
that is all good until you want to have
+1 for do it right, no matter if the api breaks or not
Am 07.06.2008 um 09:20 schrieb Igor Vaynberg:
so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void
hi igor,
that's a mess. :-(
i would go for decoupling component/model for 1.4 - that makes a clean cut for
the api towards generics. everything else is just half-baked.
my 2c, --- jan.
-
To unsubscribe, e-mail: [EMAIL
On Sat, Jun 7, 2008 at 8:20 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
thoughts and ideas?
Is there much else apart from Generic's that's in 1.4 that would
benefit from a release 'sooner' rather than 'later'?
I know the intentions's not to have it much different, but not
changing 1.3's
I'm +1 for trying to decouple model from component, and if it takes
longer then so be it.
I'm pretty convinced that the problem is the 1-1 model-component
coupling and that generics only pointed out this problem.
Regards,
Sebastiaan
Igor Vaynberg wrote:
so i tried to remove the generic
and that generics only pointed out this problem.
Regards,
Sebastiaan
Igor Vaynberg wrote:
so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design
class component {
public void setmodel
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
and its scope and opt to include a model
decoupling (however and if that is possible) refactor in it. otherwise
i fear we will break the whole generics model again in 1.5 and users
will have to relearn how to use them with wicket.
Model decoupling would mean removing the default IModel of
Component
reconsider 1.4 and its scope and opt to include a model
decoupling (however and if that is possible) refactor in it. otherwise
i fear we will break the whole generics model again in 1.5 and users
will have to relearn how to use them with wicket.
Model decoupling would mean removing the default IModel
(with less reuse of type variable names than what
I'm guilty of :)). That is if we want to provide a fairly
compatible alternative for migrating from 1.3.
But on longer term, decoupling IModel from Component might
be the best thing to have come out of this generics episode.
Best wishes,
Timo
--
Timo
[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.
I am just a little annoyed when a component not having a model causes generics
warning
The way 1.3 works currently has been fine with me and any type mismatch
in programming error usually result in crash with obvious location of error
and easily fixed.
So to me, it is optional and not very important. Switching to java 5 does not
mean wicket must include generics, there are many
around the world this is not a good
design. Each error(type mismatch) that can be avoided during development
costs
- less time in quality assurance
- debugging
- maintaining and update releases
And: less money in development at all.
So Generics are not only a nice thing wicket adopts as Java 5 hhas
- 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 simply omit
, 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
[x] Should be avoided, I prefer the way 1.3 works. Because sometimes I
still run into web servers like websphere 5.x that still depend on jdk 1.4
(also some tomcat 5.5 hosting sites). The beauty of Wicket is its
simplicity and adding generics doesn't seem be worth the cost. I like
generics
is its
simplicity and adding generics doesn't seem be worth the cost. I like
generics but I get tons of warnings in Eclipse now about wicket generics
just from using components. Please focus on making Wicket even more
concise, elegant, and easy to use... seems like thats always where web
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 simply omit the model, whereas
- 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 simply omit
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
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 simply omit the model, whereas
with generified
On Thu, Jun 5, 2008 at 10:20 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
yes. thats what i meant by wrapping. when/if we evaluate this we can
obviously put more thought into what it will effect and how to make it
all work. right now it was just a two minute idea i had, and it may
yet forever
On Thu, Jun 5, 2008 at 1:45 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Thu, Jun 5, 2008 at 10:20 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
yes. thats what i meant by wrapping. when/if we evaluate this we can
obviously put more thought into what it will effect and how to make it
all work.
Right, we need to figure out what we're going to do for 1.4. Have we
decided on that? It seems like a lot of folks like the idea of making
the model methods non-final on Component, thereby allowing components
to type themselves by overriding them (using JDK5 covariant return
types) when it
next week a good rest?
next week i dont have much rest.. I am on vacation!
Bern, Switzerland!
johan
On Thu, Jun 5, 2008 at 8:05 PM, Eelco Hillenius [EMAIL PROTECTED]
wrote:
Right, we need to figure out what we're going to do for 1.4. Have we
decided on that? It seems like a lot of folks
Johan Compagner wrote
next week i dont have much rest.. I am on vacation!
Bern, Switzerland!
You are visiting an EM match? That's not a rest? :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
On 2008/06/02, at 5:44, Eelco Hillenius wrote:
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.
For me, the most
On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
i think we should have qualified this rfi with a requirement that
responders use 1.4 on a non-trivial project...these things only become
apparent from real-world day-to-day usage. anything else is pretty
much speculation.
On Tue, Jun 3, 2008 at 11:30 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
i think we should have qualified this rfi with a requirement that
responders use 1.4 on a non-trivial project...these things only become
apparent
i was of the generify component and model mind while i was
generifying the framework, but after coding against it i began to see
some of the ugliness and now my mind is almost changed.
yep, day to day usage is the main point.
i came to that conclusion as well when i was trying to migrate
Igor Vaynberg wrote
i am wondering how many of the keep as is in trunk votes came from
people who only imagined what their code would look like and havent
actually hit the numerous pain points those of us who did code gainst
it hit.
I'm one of the keep as is in trunk users and I use 1.4 trunk
. But indeed YMMV.
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
. But indeed YMMV.
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
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 components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member
of the parent. But indeed YMMV.
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
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 components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor
.
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
use less and less models 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
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 components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor
-is-your-take-on-generics-with-Wicket-tp17589984p17651064.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]
.
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
optimized for the later, so if you don't use the model there
is no
runtime cost associated. If we didn't have default model slot this
would be more difficult to achieve.
The problem with generics now is that the model isn't as optional
anymore. So you'd have to use void or whatever.
Eelco
default model slot this
would be more difficult to achieve.
The problem with generics now is that the model isn't as optional
anymore. So you'd have to use void or whatever.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED
let
components have models by default where it actually always makes
sense, such as form components.
Anyway, that's something for 1.5. If it is fixable, I think that would
be the way out of the generics controversy :-)
Eelco
On Wed, Jun 4, 2008 at 9:52 AM, Matej Knopp [EMAIL PROTECTED] wrote:
I was talking about the model slot. If you don't have a model in
component it doesn't cost you anything.
The cost in this case is the fact that having the model slot, even
when not used, results in the assumption that a
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 longer
On Wed, Jun 4, 2008 at 10:05 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
but IModel implementations can have Imodels inside too
Whether done automatically or by components as we do now, ultimately
the calls to detach will be the same, right?
Eelco
detach model members, we
could get rid of the model member in component and instead just let
components have models by default where it actually always makes
sense, such as form components.
Anyway, that's something for 1.5. If it is fixable, I think that would
be the way out of the generics
sense, such as form components.
Anyway, that's something for 1.5. If it is fixable, I think that would
be the way out of the generics controversy :-)
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
sounds way too complicated to me dude...
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
with
On Wed, Jun 4, 2008 at 10:23 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
sounds way too complicated to me dude...
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
in things that really use models, like Label and
FormComponent...
I agree, though, that this should probably wait for 1.5...
--
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-tp17589984p17652189.html
Sent from
://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17652189.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL
So it would be no generics or it would be:
MyComponentCompoundPropertyModel mycom = new
MyComponentCompoundPropertyModel();
and I was saying that the suppress *should not* be in the API because
people need the ability to control that sort of thing at their own
code level, which should address
...
-igor
On Tue, Jun 3, 2008 at 8:19 PM, Brill Pappin [EMAIL PROTECTED] wrote:
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
I *have* used the m1 release and although its not yet an RC and there
are some issues to work out, it was a breath of fresh air.
The biggest problem I had was understanding what kind of type to set
things to, but once I sorted that out for a component, it made working
with it later much easier.
If the type of component is getting in the way doesn't that mean the
problem (non-trivial) component may need to be redesigned?
- Brill Pappin
On Wed, Jun 4, 2008 at 2:50 AM, Jan Kriesten [EMAIL PROTECTED] wrote:
i was of the generify component and model mind while i was
generifying the
Pappin
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
[...]
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
probably wait for 1.5...
--
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-tp17589984p17652189.html
Sent from the Wicket - User mailing list archive at Nabble.com
i dont think it exposes anything, 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.
for example, sometimes i want to have a webmarkupcontainer with a
model
On Wed, Jun 4, 2008 at 11:35 AM, Brill Pappin [EMAIL PROTECTED] wrote:
Thats a pretty major api change (although it looks simple) maybe that
should be in the next major release?
It's something we can consider yeah. We'll have to think it through
and get back to the drawing board to see what
of the model member in component and instead just let
components have models by default where it actually always makes
sense, such as form components.
Anyway, that's something for 1.5. If it is fixable, I think that would
be the way out of the generics controversy :-)
Eelco
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
201 - 300 of 635 matches
Mail list logo
