users, please give us your opinion: what is your take on generics with Wicket

[Matthijs Wensveen-2]

Eelco Hillenius wrote:

>> It's good to know that when you reach the same conclusion it is a deliberate
>> one.
>> BTW, interfaces are useful for this, but not a necessity. Or am I the only
>> one thinking that
>>    
>
> No, I agree with you mostly. However, I was trying (back then) to
> define separate dimensions of components (the fact that they can be
> rendered is one, and for form components for instance, the fact that
> they can validate is another). If you have a bunch of useful
> distinctions like that, you can just decorate them for specific
> purposes. Maybe.
>  

Yeah. Some problem domains are better suited for this kind of
interfacing than others. In one project we work on we have interfaces
like PropertyHolder and TemplateHolder, but other projects keep to a
stricter OO hierarchy with only one or two interfaces at the base (or top?)

I can see merit in interfaces like IRenderable and IValidatable. An
interface for lifecycle could be useful too. One problem could be that
when only Component (or somesuch) implements all the useful interfaces,
people are never going to implement one of the interfaces themselves. An
interesting framework could be Qi4J, to be able to independently
implement the interfaces. They gave a presentation at the wicket meetup
in amsterdam (I wasn't there, but heard about it and looked it up).

>  
>> (I seem to be... hmm...). More interfaces mean even more
>> scrolling through the I's in the javadoc, nooooo, lol.
>>    
>
> Indeed, it gets ugly pretty fast. Mixins and interfaces with
> implementations like scala has would be wonderful here, but alas,
> we'll have to work with Java.
>  

Java is not so bad. We'll just have to wait until someone writes a
java2scala conversion app :)
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>  


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Matthijs Wensveen-2]

Ah, you beat me to that. I should've read the thread entirely before
posting :)

Martijn Dashorst wrote:

> Or with qi4j (http://qi4j.org)
>
> Martijn
>
> On Sat, Jun 14, 2008 at 5:37 AM, Eelco Hillenius
> <eelco.hillenius@...> wrote:
>  
>>> It's good to know that when you reach the same conclusion it is a deliberate
>>> one.
>>> BTW, interfaces are useful for this, but not a necessity. Or am I the only
>>> one thinking that
>>>      
>> No, I agree with you mostly. However, I was trying (back then) to
>> define separate dimensions of components (the fact that they can be
>> rendered is one, and for form components for instance, the fact that
>> they can validate is another). If you have a bunch of useful
>> distinctions like that, you can just decorate them for specific
>> purposes. Maybe.
>>
>>    
>>> (I seem to be... hmm...). More interfaces mean even more
>>> scrolling through the I's in the javadoc, nooooo, lol.
>>>      
>> Indeed, it gets ugly pretty fast. Mixins and interfaces with
>> implementations like scala has would be wonderful here, but alas,
>> we'll have to work with Java.
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Taranenko]

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 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 Wicket.
   [ ] 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.
   [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
in your opinion here).
   [ ] .... (anything other than these choices?)

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.
   [ ] I might rethink upgrading if my choice doesn't win.
   [ ] I definitively won't be using 1.4. if Wicket doesn't go for my
preference.

Thanks

[Ari M]

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.  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 comfortable with generics, as tricky as the syntax/semantics may be.

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 choice ultimately made, I'll happily convert/ start
using 1.4 and up.

Thanks again for a great web framework!
Ari

[Andras Hatvani]

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 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 are the advantages?
In my understanding the following:
- compile-time type safety
- improved readability
- improved robustness
- eliminiation of casts.

But are these the features, which are the most important to the users and deliver the most benefits?
I think not the ways, but the objectives should be defined by the Wicket users.

For me as a Wicket user the most important is to be more productive by writing less code. Eliminating casts doesn't mean this.

Andras

[jpswain]

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 choice ultimately made, I'll happily convert/ start
using 1.4 and up.

Wicket Rocks!

Thanks!

[Ricky-22]

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, <dvd@...> wrote:

> 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 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 side framework,  without those widgets, it
> would not help spread its use as a Java web toolkit. It is true one could
> write javascript for some of them,
> but integration with java api would distinguish wicket from the rest.
> I know there are some projects like this but it would be nice to have
> it in wicket core as a strategic effort.
>
> It might not be worth a huge undertaking for a web framework, considering
> there are so many other equally crucial factors such as the
> widget issue above to make a web app successful.
>
>
>
> >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 impression of what our
> >users think about the issue by completing this simple survey. Note
> >that it is not a vote; we only want to get an idea of what you think.
> >
> >1) Generifying* Wicket
> >   [ ] 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.
> >   [ ] 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.
> >   [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
> >in your opinion here).
> >   [ ] .... (anything other than these choices?)
> >
> >2) How strongly do you feel about your choice above?
> >   [ ] Whatever choice ultimately made, I'll happily convert/ start
> >using 1.4 and up.
> >   [ ] I might rethink upgrading if my choice doesn't win.
> >   [ ] I definitively won't be using 1.4. if Wicket doesn't go for my
> >preference.
> >
> >Thanks in advance for everyone participating, and pls feel free to
> >explain yourself further beyond just answering these questions!
> >
> >Eelco
> >
> >p.s. I suggest that the core devs and most active participants and
> >previous discussions wait a few days before giving their opinions so
> >that we don't flood the thread right from the start.
> >
> >* Parameterizing would probably be the better word to use, but
> >generifying seems to be the word that many people use.
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@...
> >For additional commands, e-mail: users-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[John Patterson]

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 models and components give Wicket.

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.

[ronaldtm]

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 about your choice above?
   [X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.