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
Just started using the half-way approach and I really miss the type safety of
generified Component.
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
Menu is a good idea! I worked on this piece a little bit, (Took some cues
from Swing menu component), but i hit a dead end with keeping markup
consistent. Probably because i dont know wicket well enough; But i am pretty
sure it will be a good add on!.
Rick
On Thu, Jun 5, 2008 at 2:36 AM, [EMAIL
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 ]
Hello,
my answers to the questions:
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
Ditto Taranenko's reply. Static type checking is a real boon, and users
should remember that using a generified framework is much easier than
actually generifying the framework. Once the framework is properly
generified, using it is typically quite easy, and clarity is significantly
improved.
Hi *,
My point of view, static type checking is more important as API cleareness.
In any case using modern IDE make more help in this area.
Some exercises in also useful for programmers (but not coders though :).
Wicket was born as a framework for the qualified programmers. I think no
reason
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 an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I vote the same way. with almost the exact same sentiments.
Wouter de Vaal 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
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
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
[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
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
like matej already told you
There is no default slot or field..
A component with no model doesnt have a a slot what so ever.
johan
On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
like i said, i dont mind removing the default slot if we add nice
automatic detachment
i didnt mean the memory slot, i ment the actual default model each
component can have. if i can write something like this:
add(new webmarkupcontainer(foo) {
private imodelperson model;
protected void isvisible() { return model.getobject()!=null; });
then i am perfectly happy. notice how
[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
For that we have 1.3
1.4 will be java 5
On 6/5/08, pkcinna [EMAIL PROTECTED] wrote:
[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
This might also screw up stuff like CompoundPropertyModel, no? We
discussed this a bit on ##wicket.
On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
i didnt mean the memory slot, i ment the actual default model each
component can have. if i can write something like this:
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 stay that way.
-igor
On Thu, Jun 5, 2008 at 10:16 AM, James Carman
[EMAIL
Personally, I find CompoundPropertyModel too magicy for my tastes
anyway. Yes, it's very convenient to just use property names for
component ids and it all just works out fine, but that can sometimes
be difficult to understand from a new person's perspective. When
learning a technology, I don't
There are plenty of cases where there isn't much risk and where using
CompoundPropertyModels is just convenient and leads to nicer readable
(imho) code. I use those models quite a bit, and I like them. I use
plenty of other (custom LDMs mainly) as well though.
Eelco
On Thu, Jun 5, 2008 at 10:29
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
it all depends, on how and what you're developing.
Yeah. I actually 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
i think the only real other way is what is already possible
Just dont keep references to the Component (just add them to there parents)
and keep references to the models of those components.
and work with models only
johan
On Wed, Jun 4, 2008 at 10:24 AM, Eelco Hillenius [EMAIL PROTECTED]
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
it all depends, on how and what you're developing.
Yeah. I actually 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
There are also implementation issues that need to be considered.
Currently the model is stored in a way that it doesn't take any place
when not used.
Having multiple models is rare, however, having one model that can
(but doesn't have to) be used is more common imho. Wicket is kinda
optimized for
soo
interface IModelComponentT
{
public IModelT getModel()
}
and remove getModel/getModelObject methods from component itself?
But then everybody that does use models have to implement it..
On Wed, Jun 4, 2008 at 12:37 PM, James Carman [EMAIL PROTECTED]
wrote:
On Wed, Jun 4, 2008 at
I don't really think this is the right discussion we should be having now :)
Maybe 1.5 would be the right release for changes like that (if they
are justified, which i'm not really convinced it is. Anyway, as I said
before, storing (single) model in component has no overhead, so I
don't really see
why even have an interface? just detach all imodel fields via reflection!
-igor
On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
it all depends, on how and what you're developing.
Yeah. I actually
and if i store it in metadata ;)
On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
why even have an interface? just detach all imodel fields via reflection!
-igor
On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED]
wrote:
On Wed, Jun 4, 2008 at 4:24 AM,
Eelco Hillenius wrote:
et an idea of what you think.
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.
you still have ondetach()...but for convinience we can automatically
detach any imodel fields, i actually wanted to do this for a while...
-igor
On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner [EMAIL PROTECTED] wrote:
and if i store it in metadata ;)
On Wed, Jun 4, 2008 at 5:16 PM, Igor
Having multiple models is rare, however, having one model that can
(but doesn't have to) be used is more common imho.
Not that rare if I look at my code, especially if you take panels and
fragments into account. I have plenty of places where I use two or
three models.
Wicket is kinda
I was talking about the model slot. If you don't have a model in
component it doesn't cost you anything.
-Matej
On Wed, Jun 4, 2008 at 6:49 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
Having multiple models is rare, however, having one model that can
(but doesn't have to) be used is more
On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
you still have ondetach()...but for convinience we can automatically
detach any imodel fields, i actually wanted to do this for a while...
I tried to write this two days ago, but wasn't able to pull it off...
I wrote an
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
but IModel implementations can have Imodels inside too
And the LDM doesn't play wel with detach unfortunately as it keeps an
attached boolean that prevents the detach from entering the nested
IModel
Martijn
On Wed, Jun 4, 2008 at 6:43 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
you still have
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
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 proper caching of the actual fields lookup this should be pretty performant
If besides formcomponent you get links/buttons and so on, then i still
think the example i see of verbosity is still there, like
dropdownchoice is then generified??
On 6/4/08, Eelco Hillenius [EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
you
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)) {
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
+1
I'm also for moving getModel()/getModelObject() out of Component and only
putting them
We should definitely discuss this after 1.4.
-Matej
On Wed, Jun 4, 2008 at 7:30 PM, Patrick Angeles [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
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
Opinion, not statement :)
But i get where your coming from.
- Brill
On Tue, Jun 3, 2008 at 11:29 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
no worries, i wasnt holding my breath. its just that when i make
sweeping statements i tend to have something to back them up that
other people can
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
I agree with that and I think that is *the* key point.
If implementing regular language features exposes a flaw, fix the flaw.
I'm one of those that would rather have to refactor my code to
upgrade to a new major version than try and work around some flaw
just to maintain compatibility.
- Brill
Thats a pretty major api change (although it looks simple) maybe that
should be in the next major release?
- Brill
On Wed, Jun 4, 2008 at 1:30 PM, Patrick Angeles [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if
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
I have to admit I haven't read thru all of this thread, so my answer
might be to something else... But here we go:
I think we actually do something very similar to this in our system,
we automatically detach any instances of jpa-enitities (replacing them
with a surrogate with only the
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
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
On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
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
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
not just getModelObject() also the toString variants for rendering and so on
The component has to get its data. Ok this isnt the case for Component
itself or the containers
But for Labels, Links, buttons and all form components it is pretty needed.
So the component should be able to access any
Brill Pappin wrote:
I don't know if you have every done true TDD (most people can't or think
they can), but it actually changes your code and the way you write it.
Starting with 2 users of your code makes a significant impact on what it
looks like in the end.
Just out of curiosity: Do
A component could add a behavior for each model it wants to use:
public class ModelBehavior extends AbstractBehavior {
private IModel model;
public ModelBehavior(IModel model) {
this.model = model;
}
public void detach(Component component) {
this.model.detach();
}
}
public class
like i said, i dont mind removing the default slot if we add nice
automatic detachment for fields.
-igor
On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
i dont think it exposes anything, or that
yuck! :)
-igor
On Wed, Jun 4, 2008 at 2:29 PM, Sven Meier [EMAIL PROTECTED] wrote:
A component could add a behavior for each model it wants to use:
public class ModelBehavior extends AbstractBehavior {
private IModel model;
public ModelBehavior(IModel model) {
this.model = model;
}
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:
TextFieldStirng tf = new TextField(id);
And both ways type guessing, so
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
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
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
[x] Can best be done in a limited fashion, where we only generify
IModel but not components.
[x] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
I basically agree to what Igor says on this issue.
-
--
Kent Tong
Wicket tutorials freely available at
In java 1.7 it will allow: TextFieldStirng tf = new TextField(id);
So, at least one of your wishes will come true ;o)
I like the default idea.
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 4:15 AM
To: users@wicket.apache.org
Subject: Re:
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
really?
i still cant find information what will really be 1.7..
On Tue, Jun 3, 2008 at 1:29 PM, Hoover, William [EMAIL PROTECTED] wrote:
In java 1.7 it will allow: TextFieldStirng tf = new TextField(id);
So, at least one of your wishes will come true ;o)
I like the default idea.
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
On Tue, Jun 3, 2008 at 8:46 AM, Jan Kriesten [EMAIL PROTECTED] wrote:
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
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
Look in the section Laguage Proposals Shorter Instance Creations
in:
http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf
Other useful links:
http://blogs.sun.com/ahe/resource/java-se-7-EclipseCon-2007.pdf
http://puredanger.com/techfiles/java7.pdf
-Original Message-
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
I am one of adopters laterst release and I invested much time
for upgrading all our projects to 1.4M2 .
I think, that generification of Wicket has many positive impacts, but
also some negative impact on simplicity and ease of use.
I don't see too many advantages of fully typed components - the
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
Eelco Hillenius wrote:
[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.
[x] Whatever
[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.
I've spent a couple of afternoons trying to
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.
[X] Can best be done in a limited fashion, where we only generify
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
1 - 100 of 222 matches
Mail list logo
