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

[Marcus Mattila]

> 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 TextField("num", Integer.class)

Agreed.

+1 for NOT generifying everything, because most components are "set it
and forget it" => generifying everything is unnecessary clutter.

I will continue to use Wicket whatever is decided, though :)

-Marcus

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Use Spring with Wicket

[Samit]

Sorry to say but U did nothing in code

I am asking fro steps...

I am awarre of few like:

1. Change in web.xml for listener..
2. make applicationContext.xml file

3.

Now what?

-
Samit :confused:
-- 
View this message in context: 
http://www.nabble.com/Use-Spring-with-Wicket-tp17600138p17617192.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]

Re: How to access properties files outside of Wicket components?

[Erik van Oosten]

Look carefully. Your code sample does:

Thread.currentThread().getContextClassLoader().getResourceAsStream("MyComponent.properties")
 


Which loads it from the default package.
I think you should do:

MyComponent.class.getResourceAsStream("MyComponent.properties")


Which loads it from the package MyComponent is in.

Regards,
Erik.



Michael Mehrle wrote:
> That's what I have been doing, mate ;-)
>
> I'm looking for a solution that allows me to load the properties file
> out of the same folder as my class or WEB-INF. Not working right now and
> I pretty much tried all approaches I could find online.
>
> Wicket does not offer a way to access resource bundles outside of Wicket
> components?
>
> Michael
>
> -Original Message-
> From: Erik van Oosten [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, June 01, 2008 10:32 PM
> To: users@wicket.apache.org
> Subject: Re: How to access properties files outside of Wicket
> components?
>
> You should the other getResource*() methods, those on Class:
> http://java.sun.com/javase/6/docs/api/java/lang/Class.html#getResourceAs
> Stream(java.lang.String)
>
> Regards,
> Erik.
>
>
> Michael Mehrle wrote:
>   
>> Right now I had to resort to the solution below, but I would very much
>> like to know the standard way of doing this, as this required me to
>> place my properties file into the src/main/resources folder:
>>
>> static {
>>  try {
>>  
>>
>> 
> properties.load(Thread.currentThread().getContextClassLoader().getResour
>   
>> ceAsStream(
>>  "MyComponent.properties"));
>>  } catch (Exception e) {
>>  LOG.error("Unable to load file
>> MyComponent.properties' - error: {}", e.getMessage(), e);
>>  }
>>  }
>>
>>  public static String getProperty(String key) {
>>  return properties.getProperty(key);
>>  }
>>   
>> 

--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Roberto Fasciolo]

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.

-- 
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-tp17589984p17616380.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]

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

[Igor Vaynberg]

you made a radical statement, just wandering if there is anything
concrete you can back it up with. in my head the generics have very
little effect on the actual api design so i am wandering what prompted
you to say that wicket api needs a radical refactoring in order to
support generics - which essentially are little more then metadata.

-igor

On Mon, Jun 2, 2008 at 8:50 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
> So am I :)
>
> I think that just like TDD generates a whole new structure to your code (IMO
> a better one) that implementing generics at the start would have produced
> something a bit different.
>
> - Brill Pappin
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 02, 2008 11:42 PM
> To: users@wicket.apache.org
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
> im really curious to hear what these changes would be...
>
> -igor
>
> On Mon, Jun 2, 2008 at 8:25 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
>>
>> I think...
>>
>> We should be able to use the untyped variants, but the explanations
>> for why that won't work directly was valid.
>>
>> So on to you're A/B question. I don't think it matters much... The
>> people doing things "inline" are going to use that method anyway and
>> generics won't hurt them, but the usefulness to people who write more
>> extensive application is likely more important (if its that simple it
>> doesn't matter much, if its complicated then it is and can be used).
>>
>>
>> Allow me to digress.
>> I think that if Wicket had been written with generics from the
>> beginning, the API would be different... And that is the root of the
> problem.
>> I think that maybe a concerted refactoring effort *must* allow the API
>> to change (call it wicket 2.0 for all of us old struts users) in order
>> for things to work out properly.
>> I don't actually think that heavy a refactoring would be such a bad
>> thing. I love what Wicket has done, but I think it could be less
>> "black-boxy" as well.
>>
>> - Brill
>>
>> -Original Message-
>> From: Stefan Lindner [mailto:[EMAIL PROTECTED]
>> Sent: Monday, June 02, 2008 12:13 PM
>> To: users@wicket.apache.org
>> Subject: AW: users, please give us your opinion: what is your take on
>> generics with Wicket
>>
>> Brill Pappin wrote
>>>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 their heads around
>> Generics can't use the older releases that don't include it, but IMO
>> any java >developer who doesn't get generics yet better make some time
>> to learn, because like it or not, they *will* be dealing with them.
>>
>> I agree totally with you. My expericence with Generics over the last
>> two years was that any project that was adopted to generics had much
>> less errors afterwards.
>>
>> But the main problem in this discussion seems to be that there are two
>> very different sorts of Web Applications that are developed with
>> wicket and both may have predecessors that are non generic.
>>
>> Type A: A Web applicatons that make heavy use of Models, like classic
>> desktop allications that are ported to the web. I think the
>> programmers of such applications like Generics becaus they help them
>> to avoid erros and the current wicket generic implementation leads to
>> a strong typed application that needs a good object model (and a good
> database design).
>> If you port an exisitng wicket application with no generic to wicket
>> 1.4 you might discover some unclear object model problems in your
>> exisitng code. And it's always easier to point to wicket's generics
>> than to blame your own code
>> :-)
>>
>> Type B: A Web Application with more static content, only some date
>> (like user logins, user profile data). In this case it's clear that
>> some people say "why should I always tyle 'Link', none of my
>> links has a Model, just about 10% of my Components have a Model". But
>> why dont't they write their own wrapper e.g. MyVoidLink extends
>> Link? I remember a dicsusson about such Components some weeks ago.
>>
>>
>> What do you think about it? Would it help users of Type B to have
>> VoidComponents?
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -

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

[Igor Vaynberg]

but there are plenty of cases where you will create a component with a
model and never call getmodelobject or getmodel on it.

-igor

On Mon, Jun 2, 2008 at 8:48 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
>  I know your trying to make a point about extra work for no gain, however I
> can't see why I'd bother to create a list and never put anything inside it
> (maybe and edge case or two)... And I couldn't think of any case where I'm
> not going to use a component or model I add to a page... Why would I even
> bother to implement it at all?
>
> - Brill Pappin
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 02, 2008 11:25 PM
> To: users@wicket.apache.org
> Subject: Re: AW: users, please give us your opinion: what is your take on
> generics with Wicket
>
> i guess my question is: if you have a list and you are never going to put
> anything inside it, do you think a generic type is still useful?
> there are plenty of usecases where component's default model slot is not
> used, so why do we have to generify it? even if the mix is 50/50 that means
> 50% is complete noise...
>
> verbousity might not be wicket's problem, but using a verbose api sucks.
> generics fit for collections because there is never a case where you would
> want a collection without putting/getting something out of it.
>
> -igor
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wrap a ListView and it cannot be updated via AJAX ?

[smallufo]

2008/6/3 Gwyn Evans <[EMAIL PROTECTED]>:

> If you're hiding the container, try setting it to output a placeholder id
> too.
>

Hmmm
It still not works... :(

In fact , there is no need to setOutputMarkupId(true) , because calling
setOutputMarkupPlaceholderTag(true) internally calls setOutputMarkupId(true)
too.

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

[Brill Pappin]

So am I :)

I think that just like TDD generates a whole new structure to your code (IMO
a better one) that implementing generics at the start would have produced
something a bit different.

- Brill Pappin

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 11:42 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

im really curious to hear what these changes would be...

-igor

On Mon, Jun 2, 2008 at 8:25 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
>
> I think...
>
> We should be able to use the untyped variants, but the explanations 
> for why that won't work directly was valid.
>
> So on to you're A/B question. I don't think it matters much... The 
> people doing things "inline" are going to use that method anyway and 
> generics won't hurt them, but the usefulness to people who write more 
> extensive application is likely more important (if its that simple it 
> doesn't matter much, if its complicated then it is and can be used).
>
>
> Allow me to digress.
> I think that if Wicket had been written with generics from the 
> beginning, the API would be different... And that is the root of the
problem.
> I think that maybe a concerted refactoring effort *must* allow the API 
> to change (call it wicket 2.0 for all of us old struts users) in order 
> for things to work out properly.
> I don't actually think that heavy a refactoring would be such a bad 
> thing. I love what Wicket has done, but I think it could be less 
> "black-boxy" as well.
>
> - Brill
>
> -Original Message-
> From: Stefan Lindner [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 02, 2008 12:13 PM
> To: users@wicket.apache.org
> Subject: AW: users, please give us your opinion: what is your take on 
> generics with Wicket
>
> Brill Pappin wrote
>>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 their heads around
> Generics can't use the older releases that don't include it, but IMO 
> any java >developer who doesn't get generics yet better make some time 
> to learn, because like it or not, they *will* be dealing with them.
>
> I agree totally with you. My expericence with Generics over the last 
> two years was that any project that was adopted to generics had much 
> less errors afterwards.
>
> But the main problem in this discussion seems to be that there are two 
> very different sorts of Web Applications that are developed with 
> wicket and both may have predecessors that are non generic.
>
> Type A: A Web applicatons that make heavy use of Models, like classic 
> desktop allications that are ported to the web. I think the 
> programmers of such applications like Generics becaus they help them 
> to avoid erros and the current wicket generic implementation leads to 
> a strong typed application that needs a good object model (and a good
database design).
> If you port an exisitng wicket application with no generic to wicket 
> 1.4 you might discover some unclear object model problems in your 
> exisitng code. And it's always easier to point to wicket's generics 
> than to blame your own code
> :-)
>
> Type B: A Web Application with more static content, only some date 
> (like user logins, user profile data). In this case it's clear that 
> some people say "why should I always tyle 'Link', none of my 
> links has a Model, just about 10% of my Components have a Model". But 
> why dont't they write their own wrapper e.g. MyVoidLink extends 
> Link? I remember a dicsusson about such Components some weeks ago.
>
>
> What do you think about it? Would it help users of Type B to have 
> VoidComponents?
>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Brill Pappin]

 I know your trying to make a point about extra work for no gain, however I
can't see why I'd bother to create a list and never put anything inside it
(maybe and edge case or two)... And I couldn't think of any case where I'm
not going to use a component or model I add to a page... Why would I even
bother to implement it at all?

- Brill Pappin

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 11:25 PM
To: users@wicket.apache.org
Subject: Re: AW: users, please give us your opinion: what is your take on
generics with Wicket

i guess my question is: if you have a list and you are never going to put
anything inside it, do you think a generic type is still useful?
there are plenty of usecases where component's default model slot is not
used, so why do we have to generify it? even if the mix is 50/50 that means
50% is complete noise...

verbousity might not be wicket's problem, but using a verbose api sucks.
generics fit for collections because there is never a case where you would
want a collection without putting/getting something out of it.

-igor



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Brill Pappin]

Hold on there... Why would you suppress warnings?

I think I must miss the point of it because I don't *ever* want an API to
decide what warnings I should and shouldn't see. 

 -Brill Pappin

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 6:05 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

I agree with the Class with @SuppressWarnings in the
framework code.  It makes it easier, and there's no drawback either way.

Jeremy

On Mon, Jun 2, 2008 at 4:54 PM, Johan Compagner <[EMAIL PROTECTED]>
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 WebPage
> > are both non-generified java classes.
>
>
> No the last one is generified..
> The first one is a raw type.
>
>
> >
> >
> >
> > Esp. if the signature of 'public abstract Class> 
> > getHomePage();' stays that way the HomePage can't be generified.
> >
> >
> No as far as i can see, the home page MUST be generified thats the 
> whole problem with that constructo What would happen if we did:
>
> public abstract Class
>
> and have a supresswarning in our code.
>
> johanm
>



--
Jeremy Thomerson
http://www.wickettraining.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Brill Pappin]

 
+1

Nicely put...
But I would say that since I agree with you :)

- Brill Pappin

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Jeremy Thomerson
Sent: Monday, June 02, 2008 3:39 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

[...]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Igor Vaynberg]

im really curious to hear what these changes would be...

-igor

On Mon, Jun 2, 2008 at 8:25 PM, Brill Pappin <[EMAIL PROTECTED]> wrote:
>
> I think...
>
> We should be able to use the untyped variants, but the explanations for why
> that won't work directly was valid.
>
> So on to you're A/B question. I don't think it matters much... The people
> doing things "inline" are going to use that method anyway and generics won't
> hurt them, but the usefulness to people who write more extensive application
> is likely more important (if its that simple it doesn't matter much, if its
> complicated then it is and can be used).
>
>
> Allow me to digress.
> I think that if Wicket had been written with generics from the beginning,
> the API would be different... And that is the root of the problem.
> I think that maybe a concerted refactoring effort *must* allow the API to
> change (call it wicket 2.0 for all of us old struts users) in order for
> things to work out properly.
> I don't actually think that heavy a refactoring would be such a bad thing. I
> love what Wicket has done, but I think it could be less "black-boxy" as
> well.
>
> - Brill
>
> -Original Message-
> From: Stefan Lindner [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 02, 2008 12:13 PM
> To: users@wicket.apache.org
> Subject: AW: users, please give us your opinion: what is your take on
> generics with Wicket
>
> Brill Pappin wrote
>>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 their heads around
> Generics can't use the older releases that don't include it, but IMO any
> java >developer who doesn't get generics yet better make some time to learn,
> because like it or not, they *will* be dealing with them.
>
> I agree totally with you. My expericence with Generics over the last two
> years was that any project that was adopted to generics had much less errors
> afterwards.
>
> But the main problem in this discussion seems to be that there are two very
> different sorts of Web Applications that are developed with wicket and both
> may have predecessors that are non generic.
>
> Type A: A Web applicatons that make heavy use of Models, like classic
> desktop allications that are ported to the web. I think the programmers of
> such applications like Generics becaus they help them to avoid erros and the
> current wicket generic implementation leads to a strong typed application
> that needs a good object model (and a good database design).
> If you port an exisitng wicket application with no generic to wicket 1.4 you
> might discover some unclear object model problems in your exisitng code. And
> it's always easier to point to wicket's generics than to blame your own code
> :-)
>
> Type B: A Web Application with more static content, only some date (like
> user logins, user profile data). In this case it's clear that some people
> say "why should I always tyle 'Link', none of my links has a Model,
> just about 10% of my Components have a Model". But why dont't they write
> their own wrapper e.g. MyVoidLink extends Link? I remember a dicsusson
> about such Components some weeks ago.
>
>
> What do you think about it? Would it help users of Type B to have
> VoidComponents?
>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Brill Pappin]

Ahh... But there in lines the real point.

What happens 2 years down the road when you need to modify that component?
A) if its not typed then you hunt around and try and find out what it was...
Maybe you do a println of the fqn...
B) its typed... Your done. 

Even the time it takes to "discover" the model has direct bearing on ROI
(although a lot of developers tend not to think on it much, we all depend on
it) and the stats (and experience) say 80% of your work is maintenance.

So, forget the 20%, lets chew away some of that 80%.

- Brill Pappin

-Original Message-
From: John Krasnay [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 3:28 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

On Mon, Jun 02, 2008 at 03:05:46PM -0400, Hoover, William  wrote:
> I got the point, but I take things as people state them. It was stated 
> that 70% of the time models are not being used (such is the case for 
> Link). As you stated, they are being used indirectly. That is 
> different. If that is the case then I agree that the percentage of 
> components using model indirectly would be reduced for "form-heavy"
> applications (as you stated). On the contrary, a lot of applications 
> are not "form-heavy" (i.e. Ajax heavy apps, etc.) which also need to 
> be accounted for in the figures.
> 

I would contend that the important thing to look at is not the percentage of
component instances that use models, but the percent for which your code
explicitly calls getModel() or getModelObject(). If you're not calling one
of these methods, you have received no value for typing the generic syntax.
I would be surprised if I explicitly call one of these methods on more than
about 20% of my Wicket component instances. 

So for me, it's not the verbosity of generics that is the problem. When the
syntax is helping you avoid a cast somewhere else, it's worth it.
What bothers me is that 80% of time (for me, anyway) it doesn't save me a
cast, it just makes for more typing and less readable code.

(Also, please keep in mind I'm referring to genericizing Component. Like
most on this thread I'm a big fan of genericizing IModel.)

jk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Brill Pappin]

I think that this has turned into a discussion is vital :)

We can't all do the work and don't have the final say, but there is nothing
like getting ideas out in the open like talking about them (even arguing
about them).

I'm glad you contributed your input!

- Brill Pappin

-Original Message-
From: atul singh [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 2:25 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

Hello everyone,
I feel bad that a vote thread has been converted to one of discussion...
At this moment wicket is *for *creating custom components. If these custom
component writing gets complicated we will not be able to appreciate wicket
as much(as much as we do now).Generics will complicate the *extend* at the
moment for new user...I feel(after reading through everything). In core-java
, fewer classes aim for extension by user. They rather are end product to be
used, to be composed of.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Brill Pappin]

+1

I think that's the right thing to do... No point making it so rigid.

- Brill Pappin 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of James Carman
Sent: Monday, June 02, 2008 12:13 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

On Mon, Jun 2, 2008 at 12:11 PM, Sebastiaan van Erk <[EMAIL PROTECTED]>
wrote:
> A raw type is a parameterized type in which the type parameters are 
> not filled in, i.e., new HashMap() (instead of new HashMap()).
>
> Just try to return one of your old (non-generified) HomePage.class 
> classes (i.e., HomePage extends WebPage instead of HomePage extends 
> WebPage) in your WebApplication's getHomePage() method, and you 
> will see that it does not compile.

There is a section on the wiki addressing this now.  I would propose that
whenever referring to "class objects that represent Page subclasses" we use
Class rather than Class>.  This allows us
to specify that it has to be a page class, but it doesn't make the page
class have to be generified.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Brill Pappin]

 
I think...  

We should be able to use the untyped variants, but the explanations for why
that won't work directly was valid.

So on to you're A/B question. I don't think it matters much... The people
doing things "inline" are going to use that method anyway and generics won't
hurt them, but the usefulness to people who write more extensive application
is likely more important (if its that simple it doesn't matter much, if its
complicated then it is and can be used).


Allow me to digress.
I think that if Wicket had been written with generics from the beginning,
the API would be different... And that is the root of the problem.
I think that maybe a concerted refactoring effort *must* allow the API to
change (call it wicket 2.0 for all of us old struts users) in order for
things to work out properly.
I don't actually think that heavy a refactoring would be such a bad thing. I
love what Wicket has done, but I think it could be less "black-boxy" as
well.

- Brill

-Original Message-
From: Stefan Lindner [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 12:13 PM
To: users@wicket.apache.org
Subject: AW: users, please give us your opinion: what is your take on
generics with Wicket

Brill Pappin wrote
>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 their heads around
Generics can't use the older releases that don't include it, but IMO any
java >developer who doesn't get generics yet better make some time to learn,
because like it or not, they *will* be dealing with them.

I agree totally with you. My expericence with Generics over the last two
years was that any project that was adopted to generics had much less errors
afterwards.

But the main problem in this discussion seems to be that there are two very
different sorts of Web Applications that are developed with wicket and both
may have predecessors that are non generic.

Type A: A Web applicatons that make heavy use of Models, like classic
desktop allications that are ported to the web. I think the programmers of
such applications like Generics becaus they help them to avoid erros and the
current wicket generic implementation leads to a strong typed application
that needs a good object model (and a good database design).
If you port an exisitng wicket application with no generic to wicket 1.4 you
might discover some unclear object model problems in your exisitng code. And
it's always easier to point to wicket's generics than to blame your own code
:-)

Type B: A Web Application with more static content, only some date (like
user logins, user profile data). In this case it's clear that some people
say "why should I always tyle 'Link', none of my links has a Model,
just about 10% of my Components have a Model". But why dont't they write
their own wrapper e.g. MyVoidLink extends Link? I remember a dicsusson
about such Components some weeks ago.


What do you think about it? Would it help users of Type B to have
VoidComponents?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Igor Vaynberg]

On Mon, Jun 2, 2008 at 8:24 PM, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
> On Mon, 02 Jun 2008, Igor Vaynberg wrote:
>> i am willing to drop component model support if the following can be met:
>
> "component model support" -- ?

generifying component for the sake of having a generified model.

-igor

>
>> certain constructors stay generified to document certain aspects, eg
>> dropdownchoice constructor should be generified.
>>
>> support generification of certain components, even if it means
>> removing final from certain methods. this code should still be
>> possible:
>> add(new ListView("people") { protected void
>> onPopulate(Item person) { where getModel() of that item
>> returns IModel
>
> Thanks Igor, you saved me a lot of typing :) A thoughtful
> message.
>
> +1
>
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oyhttp://www.ri.fi/ >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Igor Vaynberg]

i guess my question is: if you have a list and you are never going to
put anything inside it, do you think a generic type is still useful?
there are plenty of usecases where component's default model slot is
not used, so why do we have to generify it? even if the mix is 50/50
that means 50% is complete noise...

verbousity might not be wicket's problem, but using a verbose api
sucks. generics fit for collections because there is never a case
where you would want a collection without putting/getting something
out of it.

-igor


On Mon, Jun 2, 2008 at 7:48 PM, James Carman <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 2, 2008 at 10:30 PM, Jeremy Thomerson
> <[EMAIL PROTECTED]> wrote:
>
>> Basically, my feeling remains the same - generics are part of Java, so Java
>> programmers are going to have to get use to them.  They are very valuable
>> when you need them.  We just have to be careful that we implement them the
>> right way.  Let's document very well the pain points on the wiki (and
>> verbosity isn't Wicket's pain point - it's java's).
>
> +1.  I've already added a couple of pain points to the wiki.  Please
> feel free to add your own specific examples of where you think
> generics has made the code difficult.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Timo Rantalaiho]

On Mon, 02 Jun 2008, Igor Vaynberg wrote:
> i am willing to drop component model support if the following can be met:

"component model support" -- ? 

> certain constructors stay generified to document certain aspects, eg
> dropdownchoice constructor should be generified.
> 
> support generification of certain components, even if it means
> removing final from certain methods. this code should still be
> possible:
> add(new ListView("people") { protected void
> onPopulate(Item person) { where getModel() of that item
> returns IModel

Thanks Igor, you saved me a lot of typing :) A thoughtful
message.

+1


Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations Oyhttp://www.ri.fi/ >

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: continueToOriginalDestination goes to tomcat's index.jsp

[Timo Rantalaiho]

On Mon, 02 Jun 2008, liny wrote:
> 1. When I enter data into input field and key up, AjaxFormValidatingBehavior
> doesn't work. It won't validate  input field.

What do you want to happen here?

> 2. After input correct info in login page and manual because question 1, I
> have to manual press submit button. Then I was redirected to tomcat's
> index.jsp! What's wrong with it? I access X page without login, this is
> right. But after correct login, I should return to X page, not tomcat's
> index.jsp.
> 
> Please tell me what's going on and how to solve it, thanks!
> 
> http://www.nabble.com/file/p17601972/Login.java Login.java 

It's a bit unclear to me what you're trying to accomplish,
but I don't see any way of displaying the Ajax validation
error messages. The parent of the FeedbackPanel must be 
repainted to make it visible (or the FeedbackPanel itself 
if you set outputMarkupPlaceholderTag true to it). 

Also note that onkeyup doesn't get triggered by mouse
events, OnChangeAjaxBehavior is better in that respect.

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations Oyhttp://www.ri.fi/ >

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[James Carman]

On Mon, Jun 2, 2008 at 10:30 PM, Jeremy Thomerson
<[EMAIL PROTECTED]> wrote:

> Basically, my feeling remains the same - generics are part of Java, so Java
> programmers are going to have to get use to them.  They are very valuable
> when you need them.  We just have to be careful that we implement them the
> right way.  Let's document very well the pain points on the wiki (and
> verbosity isn't Wicket's pain point - it's java's).

+1.  I've already added a couple of pain points to the wiki.  Please
feel free to add your own specific examples of where you think
generics has made the code difficult.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jeremy Thomerson]

I think Stefan and Doug both summarize this well.  One additional
description of "type B" applications that seems to be appearing on this
thread is apps that are able to get by with mostly
string-property-name-based models.  Like PropertyModel,
CompoundPropertyModel, etc.

On the other hand, you have an app like Doug mentions.  This sounds similar
to what I have done on the largest Wicket site that I wrote and maintain.  I
have a common domain model across almost all sections of the site
(article-type entities, that share a common parent class, and other
entities, which are composed of a couple of common classes that contain
things like ratings, comments, and uploaded pictures / videos)  So I
have been able to make many very reusable components that utilize models...
like a common bookmarkable paging navigator, completely bookmarkable table
that supports paging and sorting, etc.  The use of generics has greatly
cleaned up and improved the code for all these components.

Basically, my feeling remains the same - generics are part of Java, so Java
programmers are going to have to get use to them.  They are very valuable
when you need them.  We just have to be careful that we implement them the
right way.  Let's document very well the pain points on the wiki (and
verbosity isn't Wicket's pain point - it's java's).

Jeremy

On Mon, Jun 2, 2008 at 6:04 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote:

>
> Stefan makes a good point.  I have raised this as an example before.
>
> My site (online.ddpoker.com, just went live) is a mix of A and B.  To make
> my code cleaner, I created several simple subclasses for cases where I
> don't
> use models.  VoidPanel, VoidContainer (only a handful, really).
>
> Also, since all my pages subclass my BasePage, all I had to do was change
> *that* page to subclass Page and voila, all my pages were proper.
>
> I also created the following models to simply my life:  DateModel,
> IntegerModel, DoubleModel, etc.  I did some fancier stuff with Generics,
> including a decent drop-down list thing.
>
> In the end, it was totally worth it.  Not only do I understand how wicket
> works much better with Generics (because the code helps document it), but
> my
> code is cleaner and easier to understand.
>
> I also agree with Bill that developers should take the time to learn the
> feature.  It can be quite powerful.
>
> -Doug
>
>
> Stefan Lindner wrote:
> >
> > Brill Pappin wrote
> >>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 their heads around
> > Generics can't use the older releases that don't include it, but IMO any
> > java >developer who doesn't get generics yet better make some time to
> > learn, because like it or not, they *will* be dealing with them.
> >
> > I agree totally with you. My expericence with Generics over the last two
> > years was that any project that was adopted to generics had much less
> > errors afterwards.
> >
> > But the main problem in this discussion seems to be that there are two
> > very different sorts of Web Applications that are developed with wicket
> > and both may have predecessors that are non generic.
> >
> > Type A: A Web applicatons that make heavy use of Models, like classic
> > desktop allications that are ported to the web. I think the programmers
> > of such applications like Generics becaus they help them to avoid erros
> > and the current wicket generic implementation leads to a strong typed
> > application that needs a good object model (and a good database design).
> > If you port an exisitng wicket application with no generic to wicket 1.4
> > you might discover some unclear object model problems in your exisitng
> > code. And it's always easier to point to wicket's generics than to blame
> > your own code :-)
> >
> > Type B: A Web Application with more static content, only some date (like
> > user logins, user profile data). In this case it's clear that some
> > people say "why should I always tyle 'Link', none of my links has
> > a Model, just about 10% of my Components have a Model". But why dont't
> > they write their own wrapper e.g. MyVoidLink extends Link? I
> > remember a dicsusson about such Components some weeks ago.
> >
> >
> > What do you think about it? Would it help users of Type B to have
> > VoidComponents?
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> --
> 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-tp17589984p17612786.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> --

Re: [ANNOUNCE] Apache Wicket 1.4 Milestone 2 is released

[Doug Donohoe]

The 1.4-m2 java doc is posted at http://www.ddpoker.com/javadoc/index.html

-Doug


Frank Bille wrote:
> 
> Help the Apache Wicket team to determine the future of your Wicket based
> web
> application development. We have released our second milestone release of
> our Java 5 based web framework and are anxious to receive feedback on our
> use of generics. Download Wicket 1.4-m2 now and help us decide whether to
> tone down, remove or increase the application of Java 5 generics to our
> API.
> We have started the discussion on the user mailing list:
> 
> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-td17589984.html
> 
> Eager people click here to download the distribution, others can read
> further:
> 
> http://www.apache.org/dyn/closer.cgi/wicket/1.4-m2
> 
> We thank you for your patience and support.
> 
> The Wicket Team
> 
> === Apache Wicket ===
> 
> Apache Wicket is a component oriented Java web application framework. With
> proper mark-up/logic separation, a POJO data model, and a refreshing lack
> of
> XML, Apache Wicket makes developing web-apps simple and enjoyable again.
> Swap the boilerplate, complex debugging and brittle code for powerful,
> reusable components written with plain Java and HTML.
> 
> You can find out more about Apache Wicket on our website:
> 
> http://wicket.apache.org
> 
> === This release ===
> 
> The Apache Wicket team is proud to announce the availability of the first
> milestone release of our first java 1.5 Wicket version: Apache Wicket
> 1.4-m2. This is the first release with java 1.5 as a minimum. Not
> everything
> has been converted to java 1.5 yet but we are getting there.
> 
> === Migrating from 1.3 ===
> 
> If you are coming from Wicket 1.3, you really want to read our migration
> guide, found on the wiki:
> 
> http://cwiki.apache.org/WICKET/migrate-14.html
> 
> === Downloading the release ===
> 
> You can download the release from the official Apache mirror system, and
> you
> can find it through the following link:
> 
> http://www.apache.org/dyn/closer.cgi/wicket/1.4-m2/
> 
> For the Maven and Ivy fans out there: update your pom's to the following,
> and everything will be downloaded automatically:
> 
>
>org.apache.wicket
>wicket
>1.4-m2
>
> 
> Substitute the artifact ID with the projects of your liking to get the
> other
> projects.
> 
> Please note that we don't prescribe a Logging implementation for SLF4J.
> You
> need to specify yourself which one you prefer. Read more about SLF4J here:
> http://slf4j.org
> 
> === Validating the release ===
> 
> The release has been signed by Frank Bille, your release manager for
> today.
> The public key can be found in the KEYS file in the download area.
> Download
> the KEYS file only from the Apache website.
> 
> http://www.apache.org/dist/wicket/1.4-m2/KEYS
> 
> Instructions on how to validate the release can be found here:
> 
> http://www.apache.org/dev/release-signing.html#check-integrity
> 
> === Reporting bugs ===
> 
> In case you do encounter a bug, we would appreciate a report in our JIRA:
> 
> http://issues.apache.org/jira/browse/WICKET
> 
> === The distribution ===
> 
> In the distribution you will find a README. The README contains
> instructions
> on how to build from source yourself. You also find a CHANEGELOG-1.4 which
> contains a list of all things that have been fixed, added and/or removed
> since the first release in the 1.4 branch.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-ANNOUNCE--Apache-Wicket-1.4-Milestone-2-is-released-tp17601655p17614063.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]

RE: java.util.Date model accepting Date incl. time?

[Michael Mehrle]

Okay, I figured it out - that was the old method - needs a type.

Using a field specific converter solved my problem as I am now
formatting the date the way I need to see it as a String.

Cheers,

Michael

-Original Message-
From: Michael Mehrle [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 4:48 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

I'm trying to override:

public IConverter getConverter();

but it's final - how is this usually done? This is way too difficult,
IMHO...

Michael

-Original Message-
From: Michael Mehrle [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 4:42 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

Well, actually your previous approach might solve my Validator problem,
and this way I could enforce specific conversion rules per field. I
didn't know that I could do that - let me dig around and see if I can
make this work.

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 4:39 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

Oh, sorry, yes, it's likely the validator, not the converter.  Ignore my
just sent email.

Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device


-Original Message-
From: Michael Mehrle <[EMAIL PROTECTED]>
Sent: Monday, June 02, 2008 6:36 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

I'm actually now thinking that is merely a DateValidator.range problem.
If there is a time I don't mind it being shown - it's the
DateValidator.range that won't accept it.

The other solution would be to remove the time from the model via the
converter below. However, I have not seen a way to do this - it seems
that one needs to provide a time format and that's it. How would I
ignore the time altogether?

Hope this all makes sense...

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 3:20 PM
To: users@wicket.apache.org
Subject: Re: java.util.Date model accepting Date incl. time?

It looks like because the DateConverter code uses
DateFormat.getDateInstance(DateFormat.SHORT, locale);, if you dig into
this
method, it uses time style "FULL", which is documented like this:
"3:30:42pm
PST".  Try using that for your date.  If that works, than the problem is
just that it expects a much longer version of the time.

If that's the case, just override the converter for java.util.Date (I
know
you know how to do this ;) and you could put a new DateConverter, and
override this method to return whatever you want.  For instance you
could do
DateFormat.getDateTimeInstance(foo, bar, foo, bar)

/**
 * @param locale
 * @return Returns the date format.
 */
public DateFormat getDateFormat(Locale locale)
{
if (locale == null)
{
locale = Locale.getDefault();
}

return DateFormat.getDateInstance(DateFormat.SHORT, locale);
}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: java.util.Date model accepting Date incl. time?

[Michael Mehrle]

I'm trying to override:

public IConverter getConverter();

but it's final - how is this usually done? This is way too difficult,
IMHO...

Michael

-Original Message-
From: Michael Mehrle [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 4:42 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

Well, actually your previous approach might solve my Validator problem,
and this way I could enforce specific conversion rules per field. I
didn't know that I could do that - let me dig around and see if I can
make this work.

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 4:39 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

Oh, sorry, yes, it's likely the validator, not the converter.  Ignore my
just sent email.

Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device


-Original Message-
From: Michael Mehrle <[EMAIL PROTECTED]>
Sent: Monday, June 02, 2008 6:36 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

I'm actually now thinking that is merely a DateValidator.range problem.
If there is a time I don't mind it being shown - it's the
DateValidator.range that won't accept it.

The other solution would be to remove the time from the model via the
converter below. However, I have not seen a way to do this - it seems
that one needs to provide a time format and that's it. How would I
ignore the time altogether?

Hope this all makes sense...

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 3:20 PM
To: users@wicket.apache.org
Subject: Re: java.util.Date model accepting Date incl. time?

It looks like because the DateConverter code uses
DateFormat.getDateInstance(DateFormat.SHORT, locale);, if you dig into
this
method, it uses time style "FULL", which is documented like this:
"3:30:42pm
PST".  Try using that for your date.  If that works, than the problem is
just that it expects a much longer version of the time.

If that's the case, just override the converter for java.util.Date (I
know
you know how to do this ;) and you could put a new DateConverter, and
override this method to return whatever you want.  For instance you
could do
DateFormat.getDateTimeInstance(foo, bar, foo, bar)

/**
 * @param locale
 * @return Returns the date format.
 */
public DateFormat getDateFormat(Locale locale)
{
if (locale == null)
{
locale = Locale.getDefault();
}

return DateFormat.getDateInstance(DateFormat.SHORT, locale);
}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: java.util.Date model accepting Date incl. time?

[Michael Mehrle]

Well, actually your previous approach might solve my Validator problem,
and this way I could enforce specific conversion rules per field. I
didn't know that I could do that - let me dig around and see if I can
make this work.

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 4:39 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

Oh, sorry, yes, it's likely the validator, not the converter.  Ignore my
just sent email.

Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device


-Original Message-
From: Michael Mehrle <[EMAIL PROTECTED]>
Sent: Monday, June 02, 2008 6:36 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

I'm actually now thinking that is merely a DateValidator.range problem.
If there is a time I don't mind it being shown - it's the
DateValidator.range that won't accept it.

The other solution would be to remove the time from the model via the
converter below. However, I have not seen a way to do this - it seems
that one needs to provide a time format and that's it. How would I
ignore the time altogether?

Hope this all makes sense...

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 3:20 PM
To: users@wicket.apache.org
Subject: Re: java.util.Date model accepting Date incl. time?

It looks like because the DateConverter code uses
DateFormat.getDateInstance(DateFormat.SHORT, locale);, if you dig into
this
method, it uses time style "FULL", which is documented like this:
"3:30:42pm
PST".  Try using that for your date.  If that works, than the problem is
just that it expects a much longer version of the time.

If that's the case, just override the converter for java.util.Date (I
know
you know how to do this ;) and you could put a new DateConverter, and
override this method to return whatever you want.  For instance you
could do
DateFormat.getDateTimeInstance(foo, bar, foo, bar)

/**
 * @param locale
 * @return Returns the date format.
 */
public DateFormat getDateFormat(Locale locale)
{
if (locale == null)
{
locale = Locale.getDefault();
}

return DateFormat.getDateInstance(DateFormat.SHORT, locale);
}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: java.util.Date model accepting Date incl. time?

[Jeremy Thomerson]

Oh, sorry, yes, it's likely the validator, not the converter.  Ignore my just 
sent email.

Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device


-Original Message-
From: Michael Mehrle <[EMAIL PROTECTED]>
Sent: Monday, June 02, 2008 6:36 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

I'm actually now thinking that is merely a DateValidator.range problem.
If there is a time I don't mind it being shown - it's the
DateValidator.range that won't accept it.

The other solution would be to remove the time from the model via the
converter below. However, I have not seen a way to do this - it seems
that one needs to provide a time format and that's it. How would I
ignore the time altogether?

Hope this all makes sense...

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 3:20 PM
To: users@wicket.apache.org
Subject: Re: java.util.Date model accepting Date incl. time?

It looks like because the DateConverter code uses
DateFormat.getDateInstance(DateFormat.SHORT, locale);, if you dig into
this
method, it uses time style "FULL", which is documented like this:
"3:30:42pm
PST".  Try using that for your date.  If that works, than the problem is
just that it expects a much longer version of the time.

If that's the case, just override the converter for java.util.Date (I
know
you know how to do this ;) and you could put a new DateConverter, and
override this method to return whatever you want.  For instance you
could do
DateFormat.getDateTimeInstance(foo, bar, foo, bar)

/**
 * @param locale
 * @return Returns the date format.
 */
public DateFormat getDateFormat(Locale locale)
{
if (locale == null)
{
locale = Locale.getDefault();
}

return DateFormat.getDateInstance(DateFormat.SHORT, locale);
}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: java.util.Date model accepting Date incl. time?

[Jeremy Thomerson]

Override getConverter on your text field.  Return a new date converter that 
overrides getDateFormat and return the format you want for that.

Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device


-Original Message-
From: Michael Mehrle <[EMAIL PROTECTED]>
Sent: Monday, June 02, 2008 5:51 PM
To: users@wicket.apache.org
Subject: RE: java.util.Date model accepting Date incl. time?

Yeah, I had a suspicion that this was related but I wasn't sure I wanted
to switch on the time format for the entire site. For instance - some
users might only type in the short date version - some others the long
one. I'm not sure how to address this.

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 3:20 PM
To: users@wicket.apache.org
Subject: Re: java.util.Date model accepting Date incl. time?

It looks like because the DateConverter code uses
DateFormat.getDateInstance(DateFormat.SHORT, locale);, if you dig into
this
method, it uses time style "FULL", which is documented like this:
"3:30:42pm
PST".  Try using that for your date.  If that works, than the problem is
just that it expects a much longer version of the time.

If that's the case, just override the converter for java.util.Date (I
know
you know how to do this ;) and you could put a new DateConverter, and
override this method to return whatever you want.  For instance you
could do
DateFormat.getDateTimeInstance(foo, bar, foo, bar)

/**
 * @param locale
 * @return Returns the date format.
 */
public DateFormat getDateFormat(Locale locale)
{
if (locale == null)
{
locale = Locale.getDefault();
}

return DateFormat.getDateInstance(DateFormat.SHORT, locale);
}


On Mon, Jun 2, 2008 at 4:53 PM, Michael Mehrle <[EMAIL PROTECTED]>
wrote:

> I have a text field that is backed by a java.util.Date model. When
> typing in a simple date (e.g. 4/1/2009) everything is fine. But when I
> type in a date including a time (e.g. 5/23/09 12:00 AM) I get a
> validation error:
>
>
>
> '5/23/09 12:00 AM' is not a valid Date.
>
>
>
> Obviously a date (unlike a Timestamp) should be able to accept a
'full'
> date - how do I fix this?
>
>
>
> Michael
>
>


-- 
Jeremy Thomerson
http://www.wickettraining.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: java.util.Date model accepting Date incl. time?

[Michael Mehrle]

I'm actually now thinking that is merely a DateValidator.range problem.
If there is a time I don't mind it being shown - it's the
DateValidator.range that won't accept it.

The other solution would be to remove the time from the model via the
converter below. However, I have not seen a way to do this - it seems
that one needs to provide a time format and that's it. How would I
ignore the time altogether?

Hope this all makes sense...

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 3:20 PM
To: users@wicket.apache.org
Subject: Re: java.util.Date model accepting Date incl. time?

It looks like because the DateConverter code uses
DateFormat.getDateInstance(DateFormat.SHORT, locale);, if you dig into
this
method, it uses time style "FULL", which is documented like this:
"3:30:42pm
PST".  Try using that for your date.  If that works, than the problem is
just that it expects a much longer version of the time.

If that's the case, just override the converter for java.util.Date (I
know
you know how to do this ;) and you could put a new DateConverter, and
override this method to return whatever you want.  For instance you
could do
DateFormat.getDateTimeInstance(foo, bar, foo, bar)

/**
 * @param locale
 * @return Returns the date format.
 */
public DateFormat getDateFormat(Locale locale)
{
if (locale == null)
{
locale = Locale.getDefault();
}

return DateFormat.getDateInstance(DateFormat.SHORT, locale);
}



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wrap a ListView and it cannot be updated via AJAX ?

[Gwyn Evans]

If you're hiding the container, try setting it to output a placeholder id too.

/Gwyn

On Mon, Jun 2, 2008 at 11:21 PM, smallufo <[EMAIL PROTECTED]> wrote:
> Hi
>
> I tried to export the listViewContainer with "getListViewContainer()"
> and in the gmap2's ClickListener : onClick() :
> target.addComponent(panel);
> target.addComponent(panel.getListViewContainer());
>
> But it's still not updated.
>
>
> 2008/6/3 greeklinux <[EMAIL PROTECTED]>:
>
>>
>> Hello,
>>
>> I do not work with wicket ajax so far...but I think you have to update
>> the whole container.
>>
>> regards
>>
>>
>> smallufo wrote:
>> >
>> > I have a WebPage , containing a gmap2 and a Panel with a ListView inside.
>> > I added the panel to the gmap2's onClick(AjaxRequestTarget ...) ,
>> > So when user clicks the gmap , the ListView (in the Panel) will be
>> > updated.
>> > It worked fine.
>> >
>> > Today , I want to add a "show/hide" link in the panel , to show/hide the
>> > ListView.
>> >
>> > Because of the error :
>> > "This component is a repeater and cannot be repainted via ajax directly"
>> > so , I wrap the ListView with a WebMarkupContainer : listViewContainer.
>> > And I also added this :
>> > listViewContainer.setOutputMarkupPlaceholderTag(true);
>> >
>> > The listView show/hide now works fine.
>> > BUT , when user clicks the gmap , the ListView doesn't update anymore.
>> > Why ?
>> > Is there any solutions ? Thanks a lot.
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Wrap-a-ListView-and-it-cannot-be-updated-via-AJAX---tp17609927p17611958.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]
>>
>>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wicket cheat sheet, solve your wicket problem fast?

[Gwyn Evans]

On Mon, Jun 2, 2008 at 7:24 PM, Frank Bille <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 2, 2008 at 8:19 PM, Frank Bille <[EMAIL PROTECTED]> wrote:
>
>> On Mon, Jun 2, 2008 at 5:37 PM, Gwyn Evans <[EMAIL PROTECTED]> wrote:
>>
>>> The "Add Attatchment" on the wiki is restricted to the Confluence
>>> "wicket-committers" group (which is probably out of sync with the real
>>> Wicket committers list).
>>
>>
>> Also the "Add Diagram" button on this page?
>>
>> http://cwiki.apache.org/confluence/display/WICKET/Index
>>
>> Frank
>>
>
> (I think I'm also asking where you see those restrictions?)

Not sure about the "Add Diagram", but
http://cwiki.apache.org/confluence/spaces/spacepermissions.action?key=WICKET
for the standard Confluence permissions.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: java.util.Date model accepting Date incl. time?

[Michael Mehrle]

Actually, I just tried to enter various time formats but it refuses all
of them (with/without seconds, PM, PST, etc.). Only a pure date works
(e.g 3/3/2009).

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 3:20 PM
To: users@wicket.apache.org
Subject: Re: java.util.Date model accepting Date incl. time?

It looks like because the DateConverter code uses
DateFormat.getDateInstance(DateFormat.SHORT, locale);, if you dig into
this
method, it uses time style "FULL", which is documented like this:
"3:30:42pm
PST".  Try using that for your date.  If that works, than the problem is
just that it expects a much longer version of the time.

If that's the case, just override the converter for java.util.Date (I
know
you know how to do this ;) and you could put a new DateConverter, and
override this method to return whatever you want.  For instance you
could do
DateFormat.getDateTimeInstance(foo, bar, foo, bar)

/**
 * @param locale
 * @return Returns the date format.
 */
public DateFormat getDateFormat(Locale locale)
{
if (locale == null)
{
locale = Locale.getDefault();
}

return DateFormat.getDateInstance(DateFormat.SHORT, locale);
}


On Mon, Jun 2, 2008 at 4:53 PM, Michael Mehrle <[EMAIL PROTECTED]>
wrote:

> I have a text field that is backed by a java.util.Date model. When
> typing in a simple date (e.g. 4/1/2009) everything is fine. But when I
> type in a date including a time (e.g. 5/23/09 12:00 AM) I get a
> validation error:
>
>
>
> '5/23/09 12:00 AM' is not a valid Date.
>
>
>
> Obviously a date (unlike a Timestamp) should be able to accept a
'full'
> date - how do I fix this?
>
>
>
> Michael
>
>


-- 
Jeremy Thomerson
http://www.wickettraining.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Doug Donohoe]

Stefan makes a good point.  I have raised this as an example before.  

My site (online.ddpoker.com, just went live) is a mix of A and B.  To make
my code cleaner, I created several simple subclasses for cases where I don't
use models.  VoidPanel, VoidContainer (only a handful, really).  

Also, since all my pages subclass my BasePage, all I had to do was change
*that* page to subclass Page and voila, all my pages were proper.

I also created the following models to simply my life:  DateModel,
IntegerModel, DoubleModel, etc.  I did some fancier stuff with Generics,
including a decent drop-down list thing.

In the end, it was totally worth it.  Not only do I understand how wicket
works much better with Generics (because the code helps document it), but my
code is cleaner and easier to understand.

I also agree with Bill that developers should take the time to learn the
feature.  It can be quite powerful.

-Doug


Stefan Lindner wrote:
> 
> Brill Pappin wrote
>>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 their heads around
> Generics can't use the older releases that don't include it, but IMO any
> java >developer who doesn't get generics yet better make some time to
> learn, because like it or not, they *will* be dealing with them.
> 
> I agree totally with you. My expericence with Generics over the last two
> years was that any project that was adopted to generics had much less
> errors afterwards.
> 
> But the main problem in this discussion seems to be that there are two
> very different sorts of Web Applications that are developed with wicket
> and both may have predecessors that are non generic.
> 
> Type A: A Web applicatons that make heavy use of Models, like classic
> desktop allications that are ported to the web. I think the programmers
> of such applications like Generics becaus they help them to avoid erros
> and the current wicket generic implementation leads to a strong typed
> application that needs a good object model (and a good database design).
> If you port an exisitng wicket application with no generic to wicket 1.4
> you might discover some unclear object model problems in your exisitng
> code. And it's always easier to point to wicket's generics than to blame
> your own code :-)
> 
> Type B: A Web Application with more static content, only some date (like
> user logins, user profile data). In this case it's clear that some
> people say "why should I always tyle 'Link', none of my links has
> a Model, just about 10% of my Components have a Model". But why dont't
> they write their own wrapper e.g. MyVoidLink extends Link? I
> remember a dicsusson about such Components some weeks ago.
> 
> 
> What do you think about it? Would it help users of Type B to have
> VoidComponents?
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
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-tp17589984p17612786.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]

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

[Doug Donohoe]

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.

* Note that we just went live with http://online.ddpoker.com/ on 1.4 trunk
using generics.  I'd prefer not to backtrack, but will if that's what the
developers decide.

Having gone through a conversion of a brand new project about 1/2 way
through, I can tell you that (a) it is not that hard, (b) it is ultimately
worth it, (c) my knowledge of java is better due to having to learn generics
better, (d) we feel we created cleaner/more maintainable code because of
generics.

I think wicket is great and seriously doubt, with good documentation, that
using generics will turn people away.
-- 
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-tp17589984p17612641.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]

RE: java.util.Date model accepting Date incl. time?

[Michael Mehrle]

Yeah, I had a suspicion that this was related but I wasn't sure I wanted
to switch on the time format for the entire site. For instance - some
users might only type in the short date version - some others the long
one. I'm not sure how to address this.

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 3:20 PM
To: users@wicket.apache.org
Subject: Re: java.util.Date model accepting Date incl. time?

It looks like because the DateConverter code uses
DateFormat.getDateInstance(DateFormat.SHORT, locale);, if you dig into
this
method, it uses time style "FULL", which is documented like this:
"3:30:42pm
PST".  Try using that for your date.  If that works, than the problem is
just that it expects a much longer version of the time.

If that's the case, just override the converter for java.util.Date (I
know
you know how to do this ;) and you could put a new DateConverter, and
override this method to return whatever you want.  For instance you
could do
DateFormat.getDateTimeInstance(foo, bar, foo, bar)

/**
 * @param locale
 * @return Returns the date format.
 */
public DateFormat getDateFormat(Locale locale)
{
if (locale == null)
{
locale = Locale.getDefault();
}

return DateFormat.getDateInstance(DateFormat.SHORT, locale);
}


On Mon, Jun 2, 2008 at 4:53 PM, Michael Mehrle <[EMAIL PROTECTED]>
wrote:

> I have a text field that is backed by a java.util.Date model. When
> typing in a simple date (e.g. 4/1/2009) everything is fine. But when I
> type in a date including a time (e.g. 5/23/09 12:00 AM) I get a
> validation error:
>
>
>
> '5/23/09 12:00 AM' is not a valid Date.
>
>
>
> Obviously a date (unlike a Timestamp) should be able to accept a
'full'
> date - how do I fix this?
>
>
>
> Michael
>
>


-- 
Jeremy Thomerson
http://www.wickettraining.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

new wicket site live: online.ddpoker.com (+1 for generics)

[Doug Donohoe]

Hi All:

We launched the new http://online.ddpoker.com/ yesterday.  It replaces an
old JSP/JDBC site with wicket/spring/jpa/hibernate.

The site is 100% bookmarkable.  The site also uses the
wicketstuff-annotations project that we contributed.   One cool thing we did
with the annotations/bookmarkable pages was map the old legacy jsp pages to
the new wicket counterparts, including mapping the old query parameters. 
Wicket made this trivial to do. 

Other useful things we did in wicket:  a bookmarkable paging navigator
(which is used across the site), components to show negative percent/dollars
in red, and a highlighting widget used to show matching search results.

We are using Wicket 1.4-trunk (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 to add
more lessons learned to my wiki page this week
(http://wiki.donohoedigital.com/wiki/Wiki.jsp?page=Wicket%20Notes).

-Doug Donohoe
-- 
View this message in context: 
http://www.nabble.com/new-wicket-site-live%3A--online.ddpoker.com-%28%2B1-for-generics%29-tp17612580p17612580.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]

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

[atul singh]

Point!--but i thought it is intended to extract a survey kind of info(with
explanation if one has one)
Just that the information here is overflowing with untraceable debates


On Tue, Jun 3, 2008 at 12:47 AM, Bernard Niset <[EMAIL PROTECTED]> wrote:

> Hi Atul,
> Please read again the initial post from Eelco. He explicitly wrote: "Note
> that it is not a vote; we only want to get an idea of what you think." and
> further away: "Thanks in advance for everyone participating, and pls feel
> free to explain yourself further beyond just answering these questions!".
> Bernard.
>
> atul singh a écrit :
>
>  Hello everyone,
>> I feel bad that a vote thread has been converted to one of discussion...
>> At this moment wicket is *for *creating custom components. If these custom
>> component writing gets complicated we will not be able to appreciate
>> wicket
>> as much(as much as we do now).Generics will complicate the *extend* at the
>> moment for new user...I feel(after reading through everything). In
>> core-java
>> , fewer classes aim for extension by user. They rather are end product to
>> be
>> used, to be composed of.
>>
>> The best way still for wicket is *to implement generics partially *and*
>> then
>> start incorporating into OUT-OF-BOX(components less prone to extension)
>> later on in further releases.
>> The fact is that less people can make to wicket core-development team, and
>> then who will maintain the bloat(meaning undesired syntactical features).
>> Who will release non-generics versions for freshers.
>>
>> In Design Patterns I learnt about the open-closed principle. Closed for
>> change and open for extension.
>> Generics forces us to see into a new design pattern---Generify the the
>> most
>> closed only, based on use cases--If there is more of a need of extension
>> of
>> classes by end user AND there is flexibility while extending(wicket is one
>> case which is flexible when you extend)--then wait, do not generify. *
>> On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>>> Hi all,
>>>
>>>  [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] I might rethink upgrading if my choice doesn't win.
>>>
>>>
>>> I didn't try wicket 1.4 yet, but I read questions and comments from users
>>> in this list. My impression so far has been that there has been a small
>>> design mistake in the way the current 1.4 implementation has been done. I
>>> perceive that IModel is conceptually correct as a Model can be seen as
>>> a
>>> container of something (of type T). Writing DropDownChoice is a
>>> shortcut
>>> that does not seem conceptually correct as in this case, the component is
>>> not a container of type T but a container of type IModel. So you
>>> should
>>> have something like DropDownChoice> (I know this not valid
>>> java).
>>> Generifying the Page component is even worse as possibly a page can hold
>>> components with different model types and not have a model type on its
>>> own.
>>> Also, wicket is designed to allow some components not to have model on
>>> their
>>> own and rely on the model stored in a parent component (very nice and
>>> powerful feature).
>>>
>>> Please note that using generic this way is already possible with wicket
>>> 1.3
>>> if you define an interface that would be for instance IMyModel extends
>>> IModel. For instance, I have a generic model defined as
>>> DetachableBeanModel where K is the key type and T is the bean type.
>>> This type is indeed a container of a key element and of a bean element.
>>>
>>> I hope it helps,
>>> Bernard.
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>>
>>
>>
>>
>

Re: Wrap a ListView and it cannot be updated via AJAX ?

[smallufo]

Hi

I tried to export the listViewContainer with "getListViewContainer()"
and in the gmap2's ClickListener : onClick() :
target.addComponent(panel);
target.addComponent(panel.getListViewContainer());

But it's still not updated.


2008/6/3 greeklinux <[EMAIL PROTECTED]>:

>
> Hello,
>
> I do not work with wicket ajax so far...but I think you have to update
> the whole container.
>
> regards
>
>
> smallufo wrote:
> >
> > I have a WebPage , containing a gmap2 and a Panel with a ListView inside.
> > I added the panel to the gmap2's onClick(AjaxRequestTarget ...) ,
> > So when user clicks the gmap , the ListView (in the Panel) will be
> > updated.
> > It worked fine.
> >
> > Today , I want to add a "show/hide" link in the panel , to show/hide the
> > ListView.
> >
> > Because of the error :
> > "This component is a repeater and cannot be repainted via ajax directly"
> > so , I wrap the ListView with a WebMarkupContainer : listViewContainer.
> > And I also added this :
> > listViewContainer.setOutputMarkupPlaceholderTag(true);
> >
> > The listView show/hide now works fine.
> > BUT , when user clicks the gmap , the ListView doesn't update anymore.
> > Why ?
> > Is there any solutions ? Thanks a lot.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Wrap-a-ListView-and-it-cannot-be-updated-via-AJAX---tp17609927p17611958.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]
>
>

Re: java.util.Date model accepting Date incl. time?

[Jeremy Thomerson]

It looks like because the DateConverter code uses
DateFormat.getDateInstance(DateFormat.SHORT, locale);, if you dig into this
method, it uses time style "FULL", which is documented like this: "3:30:42pm
PST".  Try using that for your date.  If that works, than the problem is
just that it expects a much longer version of the time.

If that's the case, just override the converter for java.util.Date (I know
you know how to do this ;) and you could put a new DateConverter, and
override this method to return whatever you want.  For instance you could do
DateFormat.getDateTimeInstance(foo, bar, foo, bar)

/**
 * @param locale
 * @return Returns the date format.
 */
public DateFormat getDateFormat(Locale locale)
{
if (locale == null)
{
locale = Locale.getDefault();
}

return DateFormat.getDateInstance(DateFormat.SHORT, locale);
}


On Mon, Jun 2, 2008 at 4:53 PM, Michael Mehrle <[EMAIL PROTECTED]>
wrote:

> I have a text field that is backed by a java.util.Date model. When
> typing in a simple date (e.g. 4/1/2009) everything is fine. But when I
> type in a date including a time (e.g. 5/23/09 12:00 AM) I get a
> validation error:
>
>
>
> '5/23/09 12:00 AM' is not a valid Date.
>
>
>
> Obviously a date (unlike a Timestamp) should be able to accept a 'full'
> date - how do I fix this?
>
>
>
> Michael
>
>


-- 
Jeremy Thomerson
http://www.wickettraining.com

Re: Wrap a ListView and it cannot be updated via AJAX ?

[greeklinux]

Hello,

I do not work with wicket ajax so far...but I think you have to update
the whole container.

regards


smallufo wrote:
> 
> I have a WebPage , containing a gmap2 and a Panel with a ListView inside.
> I added the panel to the gmap2's onClick(AjaxRequestTarget ...) ,
> So when user clicks the gmap , the ListView (in the Panel) will be
> updated.
> It worked fine.
> 
> Today , I want to add a "show/hide" link in the panel , to show/hide the
> ListView.
> 
> Because of the error :
> "This component is a repeater and cannot be repainted via ajax directly"
> so , I wrap the ListView with a WebMarkupContainer : listViewContainer.
> And I also added this :
> listViewContainer.setOutputMarkupPlaceholderTag(true);
> 
> The listView show/hide now works fine.
> BUT , when user clicks the gmap , the ListView doesn't update anymore.
> Why ?
> Is there any solutions ? Thanks a lot.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Wrap-a-ListView-and-it-cannot-be-updated-via-AJAX---tp17609927p17611958.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]

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

[Ingo Adler]

1) Generifying* Wicket   
   [x] Should be avoided, I prefer the way 1.3 works. Because it works. Please improve the framework in functional details. Make it even easier to use. Make is less verbose. Keep the API stable.
  
2) How strongly do you feel about your choice above?

   [x] I might rethink upgrading if my choice doesn't win.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jeremy Thomerson]

I agree with the Class with @SuppressWarnings in the
framework code.  It makes it easier, and there's no drawback either way.

Jeremy

On Mon, Jun 2, 2008 at 4:54 PM, Johan Compagner <[EMAIL PROTECTED]>
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 WebPage
> > are both non-generified java classes.
>
>
> No the last one is generified..
> The first one is a raw type.
>
>
> >
> >
> >
> > Esp. if the signature of 'public abstract Class>
> > getHomePage();' stays that way the HomePage can't be generified.
> >
> >
> No as far as i can see, the home page MUST be generified thats the whole
> problem with that constructo
> What would happen if we did:
>
> public abstract Class
>
> and have a supresswarning in our code.
>
> johanm
>



-- 
Jeremy Thomerson
http://www.wickettraining.com

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

[Johan Compagner]

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 WebPage
> are both non-generified java classes.


No the last one is generified..
The first one is a raw type.


>
>
>
> Esp. if the signature of 'public abstract Class>
> getHomePage();' stays that way the HomePage can't be generified.
>
>
No as far as i can see, the home page MUST be generified thats the whole
problem with that constructo
What would happen if we did:

public abstract Class

and have a supresswarning in our code.

johanm

java.util.Date model accepting Date incl. time?

[Michael Mehrle]

I have a text field that is backed by a java.util.Date model. When
typing in a simple date (e.g. 4/1/2009) everything is fine. But when I
type in a date including a time (e.g. 5/23/09 12:00 AM) I get a
validation error: 

 

'5/23/09 12:00 AM' is not a valid Date.

 

Obviously a date (unlike a Timestamp) should be able to accept a 'full'
date - how do I fix this?

 

Michael

RE: Timestamp -> java.util.Date convertion in Wicket

[Michael Mehrle]

YES - we have lift off :-)

You kick butt, Jeremy - thanks so much for sharing this and for helping
so persistently. I owe you one...

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 1:00 PM
To: users@wicket.apache.org
Subject: Re: Timestamp -> java.util.Date convertion in Wicket

Very weird.  There must be some other code interfering somewhere.  In
WebApplication (which I'm assuming you're overriding), it has this code:

protected IConverterLocator newConverterLocator()
{
return new ConverterLocator();
}

So, you should be using a ConverterLocator instance (which you must or
my
code would've caused you a ClassCastException).

In ConverterLocator's constructor, it has:
public ConverterLocator()
{
  // i snipped a bunch of lines
set(java.sql.Timestamp.class, new SqlTimestampConverter());
}

So, it must be something very silly.  Like, perhaps you are accidentally
calling
set(some.other.package.not.java.sql.Timestamp, new IConverter())

Is that possible?  Maybe your IDE imported the wrong Timestamp, which
would
explain why your set call returns null.  Try checking that, or just
using
set(java.sql.Timestamp.class, new YourConverter()...); to explicitly
name
the Timestamp with package.

Let me know - now I'm curious.

Jeremy

On Sun, Jun 1, 2008 at 4:52 PM, Michael Mehrle <[EMAIL PROTECTED]>
wrote:

> Okay, this is what I'm getting:
>
> [DEBUG EviteApplication] I OVERRODE THIS CONVERTER: null
>
> Strange - isn't it? The only thing I changed was to remove 
> from your IConverter definition. I'm using Wicket 1.3.4.
>
> Thoughts?
>
> Michael
>
> -Original Message-
> From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
> Sent: Saturday, May 31, 2008 11:18 PM
> To: users@wicket.apache.org
> Subject: Re: Timestamp -> java.util.Date convertion in Wicket
>
> Weird indeed.  Do this... capture the return of your
((ConverterLocator)
> getConverterLocator()).set(...) call.  In that method, it is returning
> the
> result of a Map.put(Timestamp.class, your-converter).  Therefore, the
> result
> should be non-null, as you should be overriding the default
> implementation
> that was already put in the map.
>
> Something like:
>
> IConverter ic = ((ConverterLocator)
> getConverterLocator()).set(Timestamp.class, new
IConverter()
> {
>
>private static final long serialVersionUID = 1L;
>
>public Timestamp convertToObject(String value, Locale
> locale) {
>if (value == null) {
>return null;
>}
>if (locale == null) {
>locale = Locale.getDefault();
>}
>DateFormat format =
> DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
>try {
>Date date = format.parse(value);
>return new Timestamp(date.getTime());
>} catch (ParseException e) {
>throw new ConversionException("Cannot parse '"
>+ value + "' using format " + format)
>.setSourceValue(value).setTargetType(
>
> Timestamp.class).setConverter(this)
>.setLocale(locale);
>}
>}
>
>public String convertToString(final Timestamp value,
> Locale
> locale) {
>if (value == null) {
>return null;
>}
>if (locale == null) {
>locale = Locale.getDefault();
>}
>DateFormat format =
> DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
>return format.format(value);
>}
>
>});
> System.out.println("I OVERRODE THIS CONVERTER: "+ ic);
>
> Also - what version are you running?
>
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> On Sun, Jun 1, 2008 at 1:05 AM, Michael Mehrle
<[EMAIL PROTECTED]>
> wrote:
>
> > Yes, exactly the way you're doing it - didn't change anything except
> for
> > removing the generic def in the IConverter interface (not using
> generics
> > yet in my current project).
> >
> > And yes, I also set my breakpoint but it's never being called. The
> field
> > simply grabs the time value and no conversion seems to be happening.
> >
> > BTW, very elegant fix - just hope I can make this work (driving me
> crazy
> > this issue).
> >
> > Michael
> >
> > -Original Message-
> > From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, May 31, 2008 7:14 PM
> > To: users@wicket.apache.org
> > Subject: RE: Timestamp -> java.util.Date convertion in Wicket
> >
> > Did you make sure to use the code exactly (it calls SET on the
> concrete
> > implementation rather than the standard way of just adding a
converter
> 

RE: Timestamp -> java.util.Date convertion in Wicket

[Michael Mehrle]

Okay, NOW we're getting somewhere :-)

[DEBUG Application] I OVERRODE THIS CONVERTER:
[EMAIL PROTECTED]

Much better output now - I'll let you know if this actually works in my
app.

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 1:00 PM
To: users@wicket.apache.org
Subject: Re: Timestamp -> java.util.Date convertion in Wicket

Very weird.  There must be some other code interfering somewhere.  In
WebApplication (which I'm assuming you're overriding), it has this code:

protected IConverterLocator newConverterLocator()
{
return new ConverterLocator();
}

So, you should be using a ConverterLocator instance (which you must or
my
code would've caused you a ClassCastException).

In ConverterLocator's constructor, it has:
public ConverterLocator()
{
  // i snipped a bunch of lines
set(java.sql.Timestamp.class, new SqlTimestampConverter());
}

So, it must be something very silly.  Like, perhaps you are accidentally
calling
set(some.other.package.not.java.sql.Timestamp, new IConverter())

Is that possible?  Maybe your IDE imported the wrong Timestamp, which
would
explain why your set call returns null.  Try checking that, or just
using
set(java.sql.Timestamp.class, new YourConverter()...); to explicitly
name
the Timestamp with package.

Let me know - now I'm curious.

Jeremy

On Sun, Jun 1, 2008 at 4:52 PM, Michael Mehrle <[EMAIL PROTECTED]>
wrote:

> Okay, this is what I'm getting:
>
> [DEBUG EviteApplication] I OVERRODE THIS CONVERTER: null
>
> Strange - isn't it? The only thing I changed was to remove 
> from your IConverter definition. I'm using Wicket 1.3.4.
>
> Thoughts?
>
> Michael
>
> -Original Message-
> From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
> Sent: Saturday, May 31, 2008 11:18 PM
> To: users@wicket.apache.org
> Subject: Re: Timestamp -> java.util.Date convertion in Wicket
>
> Weird indeed.  Do this... capture the return of your
((ConverterLocator)
> getConverterLocator()).set(...) call.  In that method, it is returning
> the
> result of a Map.put(Timestamp.class, your-converter).  Therefore, the
> result
> should be non-null, as you should be overriding the default
> implementation
> that was already put in the map.
>
> Something like:
>
> IConverter ic = ((ConverterLocator)
> getConverterLocator()).set(Timestamp.class, new
IConverter()
> {
>
>private static final long serialVersionUID = 1L;
>
>public Timestamp convertToObject(String value, Locale
> locale) {
>if (value == null) {
>return null;
>}
>if (locale == null) {
>locale = Locale.getDefault();
>}
>DateFormat format =
> DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
>try {
>Date date = format.parse(value);
>return new Timestamp(date.getTime());
>} catch (ParseException e) {
>throw new ConversionException("Cannot parse '"
>+ value + "' using format " + format)
>.setSourceValue(value).setTargetType(
>
> Timestamp.class).setConverter(this)
>.setLocale(locale);
>}
>}
>
>public String convertToString(final Timestamp value,
> Locale
> locale) {
>if (value == null) {
>return null;
>}
>if (locale == null) {
>locale = Locale.getDefault();
>}
>DateFormat format =
> DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
>return format.format(value);
>}
>
>});
> System.out.println("I OVERRODE THIS CONVERTER: "+ ic);
>
> Also - what version are you running?
>
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> On Sun, Jun 1, 2008 at 1:05 AM, Michael Mehrle
<[EMAIL PROTECTED]>
> wrote:
>
> > Yes, exactly the way you're doing it - didn't change anything except
> for
> > removing the generic def in the IConverter interface (not using
> generics
> > yet in my current project).
> >
> > And yes, I also set my breakpoint but it's never being called. The
> field
> > simply grabs the time value and no conversion seems to be happening.
> >
> > BTW, very elegant fix - just hope I can make this work (driving me
> crazy
> > this issue).
> >
> > Michael
> >
> > -Original Message-
> > From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, May 31, 2008 7:14 PM
> > To: users@wicket.apache.org
> > Subject: RE: Timestamp -> java.util.Date convertion in Wicket
> >
> > Did you make sure to use the code exactly (it calls SET on the
> concrete
> > implementation rather tha

RE: Timestamp -> java.util.Date convertion in Wicket

[Michael Mehrle]

Ayayay: import com.sun.jmx.snmp.Timestamp;

LOL

I'll change it and let you know what happens. BTW, you ARE good!

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 1:00 PM
To: users@wicket.apache.org
Subject: Re: Timestamp -> java.util.Date convertion in Wicket

Very weird.  There must be some other code interfering somewhere.  In
WebApplication (which I'm assuming you're overriding), it has this code:

protected IConverterLocator newConverterLocator()
{
return new ConverterLocator();
}

So, you should be using a ConverterLocator instance (which you must or
my
code would've caused you a ClassCastException).

In ConverterLocator's constructor, it has:
public ConverterLocator()
{
  // i snipped a bunch of lines
set(java.sql.Timestamp.class, new SqlTimestampConverter());
}

So, it must be something very silly.  Like, perhaps you are accidentally
calling
set(some.other.package.not.java.sql.Timestamp, new IConverter())

Is that possible?  Maybe your IDE imported the wrong Timestamp, which
would
explain why your set call returns null.  Try checking that, or just
using
set(java.sql.Timestamp.class, new YourConverter()...); to explicitly
name
the Timestamp with package.

Let me know - now I'm curious.

Jeremy

On Sun, Jun 1, 2008 at 4:52 PM, Michael Mehrle <[EMAIL PROTECTED]>
wrote:

> Okay, this is what I'm getting:
>
> [DEBUG EviteApplication] I OVERRODE THIS CONVERTER: null
>
> Strange - isn't it? The only thing I changed was to remove 
> from your IConverter definition. I'm using Wicket 1.3.4.
>
> Thoughts?
>
> Michael
>
> -Original Message-
> From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
> Sent: Saturday, May 31, 2008 11:18 PM
> To: users@wicket.apache.org
> Subject: Re: Timestamp -> java.util.Date convertion in Wicket
>
> Weird indeed.  Do this... capture the return of your
((ConverterLocator)
> getConverterLocator()).set(...) call.  In that method, it is returning
> the
> result of a Map.put(Timestamp.class, your-converter).  Therefore, the
> result
> should be non-null, as you should be overriding the default
> implementation
> that was already put in the map.
>
> Something like:
>
> IConverter ic = ((ConverterLocator)
> getConverterLocator()).set(Timestamp.class, new
IConverter()
> {
>
>private static final long serialVersionUID = 1L;
>
>public Timestamp convertToObject(String value, Locale
> locale) {
>if (value == null) {
>return null;
>}
>if (locale == null) {
>locale = Locale.getDefault();
>}
>DateFormat format =
> DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
>try {
>Date date = format.parse(value);
>return new Timestamp(date.getTime());
>} catch (ParseException e) {
>throw new ConversionException("Cannot parse '"
>+ value + "' using format " + format)
>.setSourceValue(value).setTargetType(
>
> Timestamp.class).setConverter(this)
>.setLocale(locale);
>}
>}
>
>public String convertToString(final Timestamp value,
> Locale
> locale) {
>if (value == null) {
>return null;
>}
>if (locale == null) {
>locale = Locale.getDefault();
>}
>DateFormat format =
> DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
>return format.format(value);
>}
>
>});
> System.out.println("I OVERRODE THIS CONVERTER: "+ ic);
>
> Also - what version are you running?
>
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> On Sun, Jun 1, 2008 at 1:05 AM, Michael Mehrle
<[EMAIL PROTECTED]>
> wrote:
>
> > Yes, exactly the way you're doing it - didn't change anything except
> for
> > removing the generic def in the IConverter interface (not using
> generics
> > yet in my current project).
> >
> > And yes, I also set my breakpoint but it's never being called. The
> field
> > simply grabs the time value and no conversion seems to be happening.
> >
> > BTW, very elegant fix - just hope I can make this work (driving me
> crazy
> > this issue).
> >
> > Michael
> >
> > -Original Message-
> > From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, May 31, 2008 7:14 PM
> > To: users@wicket.apache.org
> > Subject: RE: Timestamp -> java.util.Date convertion in Wicket
> >
> > Did you make sure to use the code exactly (it calls SET on the
> concrete
> > implementation rather than the standard way of just adding a
converter
> > to the int

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

[Sven Meier]

IMHO we should try to keep the topic on "your take on generics", not on 
"your take on others take on generics". But while we're at it:


>I've read over 100 emails on this thread, and nearly all of the ones 
against keeping generics like they are currently implemented are from 
people who do not fully understand them


That *is* offending. How do you come to your conclusion that people 
don't understand generics?
The following is not something I'd prefer, and I don't need to be a 
master in generics to form this opinion:


 DropDownChoice fruit = new DropDownChoice("fruit", new 
Model(), ...);
 new TextField num = new TextField("num", Integer.class)


you can't call "getModelObject()" and get the right type - so generics didn't 
help you within your component


IMHO generics should help in *using* components.


you can't tell the rest of us that we shouldn't have a generic component 
because it wouldn't be used 70% of the

time - that's only your use case

I doubt that, anyone using CompoundPropertyModel will easily reach that 
percentage.

It just seems wrong (to me) to generify Component just for one or two getters - 
weren't getters the root of all evil anyway? ;).

Back to the topic:

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.

 [X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up ... what should I do otherwise, use JSF? (Just kidding)

Sven


Jeremy Thomerson schrieb:

My vote:
X - Can best be done like currently in the 1.4 branch, where models and
components are both generified
X - Whatever choice ultimately made, I'll happily convert/ start using 1.4
and up.

I have to modify that last sentence, though - because I will continue using
Wicket, because it's the best.  But I have already upgraded all of my
applications to use 1.4, and there wouldn't be any "happily" about it to
back it out and stop using generics for me.  They are too valuable to lose.
I have been using 1.4 with generics since before M1 was released, with
nearly half a dozen deployed production applications now running on either
1.4-M1 or M2.

Without intending to offend anyone, the rest of my thoughts on this:

I've read over 100 emails on this thread, and nearly all of the ones against
keeping generics like they are currently implemented are from people who do
not fully understand them and have not used them on a day-to-day basis.
I'll grant you that the first switch to 1.4 was a little intimidating, but I
had been wishing for generics in IModel since early 1.2 releases
(fortunately I never switched to 2.0).  Once you use them regularly, you
will grow to appreciate them.  I also agree that there are still some method
signatures that may be done better - we'll put those on the wiki as we come
across them.

Some are saying we don't need to "generify" component - but then you can't
call "getModelObject()" and get the right type - so generics didn't help you
within your component.  Where else will a generified model help you?  Where
are you using it that's not in a component?  Some say we should not generify
component, but they want getModelObject() to return the right type - they
don't understand generics.  There's a large discussion that says "I don't
use models in my components" - interesting, because nearly all of the
framework components use models - nearly all of my components use models - a
model is a pretty core part of a component - it's what stores the data that
the component is rendering or modifying - you can't tell the rest of us that
we shouldn't have a generic component because it wouldn't be used 70% of the
time - that's only your use case.

When we talk about new users being intimidated by Wicket because of
generics, it makes me think of the blog post by Martijn on Jonathan's
statement "don't hire wicket programmers" [1] - a good programmer with a
solid understanding of generics will not be intimidated when they start
using this framework.  This in no way implies that if you do not currently
like the generics that you are a bad programmer.  It only means that
generics are still new to some, they have not used them enough yet to be
really comfortable with them.  They are very valuable, but yes, java
could've implemented them better.  So, we'd all better get good with
generics - they've been in java for quite a while now, and they're here to
stay.  No reason Wicket shouldn't / can't do the same!

Jeremy Thomerson

1 - http://martijndashorst.com/blog/2008/03/30/dont-hire-wicket-programmers/

On Sun, Jun 1, 2008 at 3:44 PM, Eelco Hillenius <[EMAIL PROTECTED]>
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 regul

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

[Igor Vaynberg]

after using 1.4 full time i am more and more coming around to this
point of view also.

disclaimer: terms like "vast majority" are based on my own coding experience...

the fact is, it doesnt matter how often you use models in components,
its how often you actually have to cast the model object to a type, eg
when you call getmodelobject() or getmodel() on the component. a big
percentage of the time you bind the model to a property - like in form
components, or push in a model once and never access it again - like
in dropdownchoice choices model, generics offer you no benefit in
these two cases.

here are a couple of thoughts i have:

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 TextField("num", Integer.class)

a lot of times there is no clear type, eg Label. should that be
Label? why do i need to repeat the type twice? new
Label("username", new PropertyModel(this,
"username")); it is very redundant for some components. new
Label("username", new ProeprtyModel(this, "usenrame")) is just
as self documenting.

a vast majority of components are "set it and forget it": add(new
TextField("foo", new PropertyModel(this, "username"));
developer doesnt keep a reference to these components, so generics are
just noise, the type of the model is enough.

i think the fact remains that component's default model is just there
for user's convenience. it would really suck to have to write an
ondetach() handler every time, especially since a single model
instance per component covers 90% usecase. if java had something like
scala's traits, model would not be part of Component.

i am willing to drop component model support if the following can be met:

certain constructors stay generified to document certain aspects, eg
dropdownchoice constructor should be generified.

support generification of certain components, even if it means
removing final from certain methods. this code should still be
possible:
add(new ListView("people") { protected void
onPopulate(Item person) { where getModel() of that item
returns IModel

for me, the driving point is that i havent enjoyed writing wicket code
against 1.4 trunk as much.

-igor


On Mon, Jun 2, 2008 at 7:47 AM, John Krasnay <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 01, 2008 at 01:44:59PM -0700, Eelco Hillenius wrote:
>>
>> 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.
>
> IMHO storing a model in a Component is more a convenience than a
> fundamental part of component-ness. This may be part of the reason that
> genericizing Component is so contentious.
>
> I have many components with no model and many others, such as a
> TextField that uses a parent's CompoundPropertyModel, the component has
> a model but I really don't care about the type, since I never call
> getModelObject(). In all 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 Component is
> overkill, since it's relatively rare that I care about the type of a
> component's model.
>
> jk
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Wicket-Security and Wicket 1.4

[Zappaterrini, Larry]

Is there any timeframe for the development of a version of
Wicket-Security that is compatible with Wicket 1.4? I know Wicket 1.4 is
still a moving target, but I am curious to know what the plan for
Wicket-Security is.

Thanks,
Larry


__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Wrap a ListView and it cannot be updated via AJAX ?

[smallufo]

I have a WebPage , containing a gmap2 and a Panel with a ListView inside.
I added the panel to the gmap2's onClick(AjaxRequestTarget ...) ,
So when user clicks the gmap , the ListView (in the Panel) will be updated.
It worked fine.

Today , I want to add a "show/hide" link in the panel , to show/hide the
ListView.

Because of the error :
"This component is a repeater and cannot be repainted via ajax directly"
so , I wrap the ListView with a WebMarkupContainer : listViewContainer.
And I also added this :
listViewContainer.setOutputMarkupPlaceholderTag(true);

The listView show/hide now works fine.
BUT , when user clicks the gmap , the ListView doesn't update anymore.
Why ?
Is there any solutions ? Thanks a lot.

Re: Timestamp -> java.util.Date convertion in Wicket

[Jeremy Thomerson]

Very weird.  There must be some other code interfering somewhere.  In
WebApplication (which I'm assuming you're overriding), it has this code:

protected IConverterLocator newConverterLocator()
{
return new ConverterLocator();
}

So, you should be using a ConverterLocator instance (which you must or my
code would've caused you a ClassCastException).

In ConverterLocator's constructor, it has:
public ConverterLocator()
{
  // i snipped a bunch of lines
set(java.sql.Timestamp.class, new SqlTimestampConverter());
}

So, it must be something very silly.  Like, perhaps you are accidentally
calling
set(some.other.package.not.java.sql.Timestamp, new IConverter())

Is that possible?  Maybe your IDE imported the wrong Timestamp, which would
explain why your set call returns null.  Try checking that, or just using
set(java.sql.Timestamp.class, new YourConverter()...); to explicitly name
the Timestamp with package.

Let me know - now I'm curious.

Jeremy

On Sun, Jun 1, 2008 at 4:52 PM, Michael Mehrle <[EMAIL PROTECTED]>
wrote:

> Okay, this is what I'm getting:
>
> [DEBUG EviteApplication] I OVERRODE THIS CONVERTER: null
>
> Strange - isn't it? The only thing I changed was to remove 
> from your IConverter definition. I'm using Wicket 1.3.4.
>
> Thoughts?
>
> Michael
>
> -Original Message-
> From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
> Sent: Saturday, May 31, 2008 11:18 PM
> To: users@wicket.apache.org
> Subject: Re: Timestamp -> java.util.Date convertion in Wicket
>
> Weird indeed.  Do this... capture the return of your ((ConverterLocator)
> getConverterLocator()).set(...) call.  In that method, it is returning
> the
> result of a Map.put(Timestamp.class, your-converter).  Therefore, the
> result
> should be non-null, as you should be overriding the default
> implementation
> that was already put in the map.
>
> Something like:
>
> IConverter ic = ((ConverterLocator)
> getConverterLocator()).set(Timestamp.class, new IConverter()
> {
>
>private static final long serialVersionUID = 1L;
>
>public Timestamp convertToObject(String value, Locale
> locale) {
>if (value == null) {
>return null;
>}
>if (locale == null) {
>locale = Locale.getDefault();
>}
>DateFormat format =
> DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
>try {
>Date date = format.parse(value);
>return new Timestamp(date.getTime());
>} catch (ParseException e) {
>throw new ConversionException("Cannot parse '"
>+ value + "' using format " + format)
>.setSourceValue(value).setTargetType(
>
> Timestamp.class).setConverter(this)
>.setLocale(locale);
>}
>}
>
>public String convertToString(final Timestamp value,
> Locale
> locale) {
>if (value == null) {
>return null;
>}
>if (locale == null) {
>locale = Locale.getDefault();
>}
>DateFormat format =
> DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
>return format.format(value);
>}
>
>});
> System.out.println("I OVERRODE THIS CONVERTER: "+ ic);
>
> Also - what version are you running?
>
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> On Sun, Jun 1, 2008 at 1:05 AM, Michael Mehrle <[EMAIL PROTECTED]>
> wrote:
>
> > Yes, exactly the way you're doing it - didn't change anything except
> for
> > removing the generic def in the IConverter interface (not using
> generics
> > yet in my current project).
> >
> > And yes, I also set my breakpoint but it's never being called. The
> field
> > simply grabs the time value and no conversion seems to be happening.
> >
> > BTW, very elegant fix - just hope I can make this work (driving me
> crazy
> > this issue).
> >
> > Michael
> >
> > -Original Message-
> > From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, May 31, 2008 7:14 PM
> > To: users@wicket.apache.org
> > Subject: RE: Timestamp -> java.util.Date convertion in Wicket
> >
> > Did you make sure to use the code exactly (it calls SET on the
> concrete
> > implementation rather than the standard way of just adding a converter
> > to the interface)?
> >
> > Which version are you using?  This problem appeared in 1.3, and I have
> > tested my fix in all versions of of 1.3 and 1.4-m1 and m2.
> >
> > You can set a breakpoint in your implementation and in the default
> with
> > Wicket to see which is getting called.  Let me know what you find.
> >
> > Jeremy Thomerson
> > htt

Re: autocomplete show div while textfield is empty

[taygolf]

Got it. It is being released in the new 1.4-m2 that came out today.

Thanks

T

taygolf wrote:
> 
> no one???
> 
> 
> 
> 
> 
> taygolf wrote:
>> 
>> Hey guys. I have been playing with autocompletetextfield and I really
>> like it now that the ie bug is fixed with the 1.4 milestone. The only
>> question I have about it is how do I make the list visible all the time.
>> Basically I want the div to be visible all the time no matter what has
>> been entered in the textfield. that way the user can start typing the
>> name and the choices will be narrowed down but if they simply want to
>> select from all choices they can. I have tried several things but none of
>> them have worked so far. There has to be a set div to visible some where
>> that I am missing
>> 
>> Thanks
>> 
>> T
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/autocomplete-show-div-while-textfield-is-empty-tp17497376p17609336.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]

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

[Jeremy Thomerson]

My vote:
X - Can best be done like currently in the 1.4 branch, where models and
components are both generified
X - Whatever choice ultimately made, I'll happily convert/ start using 1.4
and up.

I have to modify that last sentence, though - because I will continue using
Wicket, because it's the best.  But I have already upgraded all of my
applications to use 1.4, and there wouldn't be any "happily" about it to
back it out and stop using generics for me.  They are too valuable to lose.
I have been using 1.4 with generics since before M1 was released, with
nearly half a dozen deployed production applications now running on either
1.4-M1 or M2.

Without intending to offend anyone, the rest of my thoughts on this:

I've read over 100 emails on this thread, and nearly all of the ones against
keeping generics like they are currently implemented are from people who do
not fully understand them and have not used them on a day-to-day basis.
I'll grant you that the first switch to 1.4 was a little intimidating, but I
had been wishing for generics in IModel since early 1.2 releases
(fortunately I never switched to 2.0).  Once you use them regularly, you
will grow to appreciate them.  I also agree that there are still some method
signatures that may be done better - we'll put those on the wiki as we come
across them.

Some are saying we don't need to "generify" component - but then you can't
call "getModelObject()" and get the right type - so generics didn't help you
within your component.  Where else will a generified model help you?  Where
are you using it that's not in a component?  Some say we should not generify
component, but they want getModelObject() to return the right type - they
don't understand generics.  There's a large discussion that says "I don't
use models in my components" - interesting, because nearly all of the
framework components use models - nearly all of my components use models - a
model is a pretty core part of a component - it's what stores the data that
the component is rendering or modifying - you can't tell the rest of us that
we shouldn't have a generic component because it wouldn't be used 70% of the
time - that's only your use case.

When we talk about new users being intimidated by Wicket because of
generics, it makes me think of the blog post by Martijn on Jonathan's
statement "don't hire wicket programmers" [1] - a good programmer with a
solid understanding of generics will not be intimidated when they start
using this framework.  This in no way implies that if you do not currently
like the generics that you are a bad programmer.  It only means that
generics are still new to some, they have not used them enough yet to be
really comfortable with them.  They are very valuable, but yes, java
could've implemented them better.  So, we'd all better get good with
generics - they've been in java for quite a while now, and they're here to
stay.  No reason Wicket shouldn't / can't do the same!

Jeremy Thomerson

1 - http://martijndashorst.com/blog/2008/03/30/dont-hire-wicket-programmers/

On Sun, Jun 1, 2008 at 3:44 PM, Eelco Hillenius <[EMAIL PROTECTED]>
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 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.
>
> -

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

[Martin Funk]

Hi Sebastiann,

just for clarifying my understanding of the vocabulary:

A_HomePage extends WebPage
and
B_HomePage extends WebPage
are both non-generified java classes.

It is just that
A_HomePage extends the raw type of the generic type WebPage

whereas
B_HomePage extends the parameterized type, with type parameter 'Void' of the
generic type WebPage

So if I get it right it is not the generification of the HomePage, that
makes the difference but its weather it is derived of a parameterized type.

Esp. if the signature of 'public abstract Class>
getHomePage();' stays that way the HomePage can't be generified.

Can someone pleas elaborate on this?

mf

2008/6/2 Sebastiaan van Erk <[EMAIL PROTECTED]>:

> A raw type is a parameterized type in which the type parameters are not
> filled in, i.e., new HashMap() (instead of new HashMap()).
>
> Just try to return one of your old (non-generified) HomePage.class classes
> (i.e., HomePage extends WebPage instead of HomePage extends WebPage)
> in your WebApplication's getHomePage() method, and you will see that it does
> not compile.
>
> Regards,
> Sebastiaan
>
>
> Brill Pappin wrote:
>
>> I'm likely missing something here, but why would you want to return
>> something other than a *Page object? Wouldn't that cause some issues with
>> the application?
>>
>> 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 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
>> 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() signature...
>>
>>public abstract Class> getHomePage();
>>
>> This breaks raw types (you can't return raw home page).
>>
>> I don't see any way out of this one without making the getHomePage()
>> signature incorrect (i.e., you can't make it a generic method, which was
>> used to solve the problem where a method argument had the type Class> extends Page>).
>>
>> Regards,
>> Sebastiaan
>>
>>
>>
>>
>>  On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William <[EMAIL PROTECTED]>
>>>
>> wrote:
>>
>>> Sounds like a good idea... Are you going to create it?

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 ]
 On Behalf Of James Carman
 Sent: Monday, June 02, 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, Jun 2, 2008 at 11:03 AM, Hoover, William <[EMAIL PROTECTED]>
 wrote:

> +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 Carman
> Sent: Monday, June 02, 2008 10:56 AM
> To: users@wicket.apache.org
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
> 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
>> (except the verbosity of course, but that's not something we can really 
>> do
>> about) with current state. I use wicket with generics daily and I don't 
>> see
>> any particular show stopper so far.
>>
>>  +1, I agree.  I think this discussion might be counter-productive if
> folks who aren't using the generified versions are voting.
>
> 
> - To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> 
> - To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>  -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 --

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

[John Krasnay]

On Mon, Jun 02, 2008 at 03:05:46PM -0400, Hoover, William  wrote:
> I got the point, but I take things as people state them. It was stated
> that 70% of the time models are not being used (such is the case for
> Link). As you stated, they are being used indirectly. That is
> different. If that is the case then I agree that the percentage of
> components using model indirectly would be reduced for "form-heavy"
> applications (as you stated). On the contrary, a lot of applications are
> not "form-heavy" (i.e. Ajax heavy apps, etc.) which also need to be
> accounted for in the figures.
> 

I would contend that the important thing to look at is not the
percentage of component instances that use models, but the percent for
which your code explicitly calls getModel() or getModelObject(). If
you're not calling one of these methods, you have received no value for
typing the generic syntax. I would be surprised if I explicitly call one
of these methods on more than about 20% of my Wicket component
instances. 

So for me, it's not the verbosity of generics that is the problem. When
the syntax is helping you avoid a cast somewhere else, it's worth it.
What bothers me is that 80% of time (for me, anyway) it doesn't save me
a cast, it just makes for more typing and less readable code.

(Also, please keep in mind I'm referring to genericizing Component. Like
most on this thread I'm a big fan of genericizing IModel.)

jk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Bernard Niset]

Hi Atul,
Please read again the initial post from Eelco. He explicitly wrote: 
"Note that it is not a vote; we only want to get an idea of what you 
think." and further away: "Thanks in advance for everyone participating, 
and pls feel free to explain yourself further beyond just answering 
these questions!".

Bernard.

atul singh a écrit :

Hello everyone,
I feel bad that a vote thread has been converted to one of discussion...
At this moment wicket is *for *creating custom components. If these custom
component writing gets complicated we will not be able to appreciate wicket
as much(as much as we do now).Generics will complicate the *extend* at the
moment for new user...I feel(after reading through everything). In core-java
, fewer classes aim for extension by user. They rather are end product to be
used, to be composed of.

The best way still for wicket is *to implement generics partially *and* then
start incorporating into OUT-OF-BOX(components less prone to extension)
later on in further releases.
The fact is that less people can make to wicket core-development team, and
then who will maintain the bloat(meaning undesired syntactical features).
Who will release non-generics versions for freshers.

In Design Patterns I learnt about the open-closed principle. Closed for
change and open for extension.
Generics forces us to see into a new design pattern---Generify the the most
closed only, based on use cases--If there is more of a need of extension of
classes by end user AND there is flexibility while extending(wicket is one
case which is flexible when you extend)--then wait, do not generify. *
On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset <[EMAIL PROTECTED]> wrote:

  

Hi all,

 [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] I might rethink upgrading if my choice doesn't win.


I didn't try wicket 1.4 yet, but I read questions and comments from users
in this list. My impression so far has been that there has been a small
design mistake in the way the current 1.4 implementation has been done. I
perceive that IModel is conceptually correct as a Model can be seen as a
container of something (of type T). Writing DropDownChoice is a shortcut
that does not seem conceptually correct as in this case, the component is
not a container of type T but a container of type IModel. So you should
have something like DropDownChoice> (I know this not valid java).
Generifying the Page component is even worse as possibly a page can hold
components with different model types and not have a model type on its own.
Also, wicket is designed to allow some components not to have model on their
own and rely on the model stored in a parent component (very nice and
powerful feature).

Please note that using generic this way is already possible with wicket 1.3
if you define an interface that would be for instance IMyModel extends
IModel. For instance, I have a generic model defined as
DetachableBeanModel where K is the key type and T is the bean type.
This type is indeed a container of a key element and of a bean element.

I hope it helps,
Bernard.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





  

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

[Hoover, William]

I got the point, but I take things as people state them. It was stated
that 70% of the time models are not being used (such is the case for
Link). As you stated, they are being used indirectly. That is
different. If that is the case then I agree that the percentage of
components using model indirectly would be reduced for "form-heavy"
applications (as you stated). On the contrary, a lot of applications are
not "form-heavy" (i.e. Ajax heavy apps, etc.) which also need to be
accounted for in the figures.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Al Maw
Sent: Monday, June 02, 2008 2:09 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

I think you miss John's point, which is that when you use a
CompoundPropertyModel for a component, all its children typically do not
reference models explicitly.

Thus you typically use an explicit model on < 30% of your components if
you have a form-heavy web-app; the other components use the implicit
model provided by the parent's CompoundPropertyModel.

Regards,

Al

On Mon, Jun 2, 2008 at 6:42 PM, Hoover, William <[EMAIL PROTECTED]>
wrote:

> Wow, last time I checked CompoundPropertyModel is a model ;o)
>
> -Original Message-
> From: John Krasnay [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 02, 2008 1:22 PM
> To: users@wicket.apache.org
> Subject: Re: users, please give us your opinion: what is your take on 
> generics with Wicket
>
> On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William  wrote:
> > I read it, but I think most people will be using models more 
> > frequently than 30% of the time. Personally, I use them 99% of the
> time.
>
> Really? Haven't you heard of CompoundPropertyModel?
>
> jk
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[atul singh]

Hello everyone,
I feel bad that a vote thread has been converted to one of discussion...
At this moment wicket is *for *creating custom components. If these custom
component writing gets complicated we will not be able to appreciate wicket
as much(as much as we do now).Generics will complicate the *extend* at the
moment for new user...I feel(after reading through everything). In core-java
, fewer classes aim for extension by user. They rather are end product to be
used, to be composed of.

The best way still for wicket is *to implement generics partially *and* then
start incorporating into OUT-OF-BOX(components less prone to extension)
later on in further releases.
The fact is that less people can make to wicket core-development team, and
then who will maintain the bloat(meaning undesired syntactical features).
Who will release non-generics versions for freshers.

In Design Patterns I learnt about the open-closed principle. Closed for
change and open for extension.
Generics forces us to see into a new design pattern---Generify the the most
closed only, based on use cases--If there is more of a need of extension of
classes by end user AND there is flexibility while extending(wicket is one
case which is flexible when you extend)--then wait, do not generify. *
On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset <[EMAIL PROTECTED]> wrote:

> Hi all,
>
>  [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] I might rethink upgrading if my choice doesn't win.
>
>
> I didn't try wicket 1.4 yet, but I read questions and comments from users
> in this list. My impression so far has been that there has been a small
> design mistake in the way the current 1.4 implementation has been done. I
> perceive that IModel is conceptually correct as a Model can be seen as a
> container of something (of type T). Writing DropDownChoice is a shortcut
> that does not seem conceptually correct as in this case, the component is
> not a container of type T but a container of type IModel. So you should
> have something like DropDownChoice> (I know this not valid java).
> Generifying the Page component is even worse as possibly a page can hold
> components with different model types and not have a model type on its own.
> Also, wicket is designed to allow some components not to have model on their
> own and rely on the model stored in a parent component (very nice and
> powerful feature).
>
> Please note that using generic this way is already possible with wicket 1.3
> if you define an interface that would be for instance IMyModel extends
> IModel. For instance, I have a generic model defined as
> DetachableBeanModel where K is the key type and T is the bean type.
> This type is indeed a container of a key element and of a bean element.
>
> I hope it helps,
> Bernard.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Wicket cheat sheet, solve your wicket problem fast?

[Frank Bille]

On Mon, Jun 2, 2008 at 8:19 PM, Frank Bille <[EMAIL PROTECTED]> wrote:

> On Mon, Jun 2, 2008 at 5:37 PM, Gwyn Evans <[EMAIL PROTECTED]> wrote:
>
>> The "Add Attatchment" on the wiki is restricted to the Confluence
>> "wicket-committers" group (which is probably out of sync with the real
>> Wicket committers list).
>
>
> Also the "Add Diagram" button on this page?
>
> http://cwiki.apache.org/confluence/display/WICKET/Index
>
> Frank
>

(I think I'm also asking where you see those restrictions?)

Frank

Re: Wicket cheat sheet, solve your wicket problem fast?

[Frank Bille]

On Mon, Jun 2, 2008 at 5:37 PM, Gwyn Evans <[EMAIL PROTECTED]> wrote:

> The "Add Attatchment" on the wiki is restricted to the Confluence
> "wicket-committers" group (which is probably out of sync with the real
> Wicket committers list).


Also the "Add Diagram" button on this page?

http://cwiki.apache.org/confluence/display/WICKET/Index

Frank

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

[Al Maw]

I think you miss John's point, which is that when you use a
CompoundPropertyModel for a component, all its children typically do not
reference models explicitly.

Thus you typically use an explicit model on < 30% of your components if you
have a form-heavy web-app; the other components use the implicit model
provided by the parent's CompoundPropertyModel.

Regards,

Al

On Mon, Jun 2, 2008 at 6:42 PM, Hoover, William <[EMAIL PROTECTED]> wrote:

> Wow, last time I checked CompoundPropertyModel is a model ;o)
>
> -Original Message-
> From: John Krasnay [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 02, 2008 1:22 PM
> To: users@wicket.apache.org
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
> On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William  wrote:
> > I read it, but I think most people will be using models more
> > frequently than 30% of the time. Personally, I use them 99% of the
> time.
>
> Really? Haven't you heard of CompoundPropertyModel?
>
> jk
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

RE: How to access properties files outside of Wicket components?

[Michael Mehrle]

That's what I have been doing, mate ;-)

I'm looking for a solution that allows me to load the properties file
out of the same folder as my class or WEB-INF. Not working right now and
I pretty much tried all approaches I could find online.

Wicket does not offer a way to access resource bundles outside of Wicket
components?

Michael

-Original Message-
From: Erik van Oosten [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 01, 2008 10:32 PM
To: users@wicket.apache.org
Subject: Re: How to access properties files outside of Wicket
components?

You should the other getResource*() methods, those on Class:
http://java.sun.com/javase/6/docs/api/java/lang/Class.html#getResourceAs
Stream(java.lang.String)

Regards,
Erik.


Michael Mehrle wrote:
> Right now I had to resort to the solution below, but I would very much
> like to know the standard way of doing this, as this required me to
> place my properties file into the src/main/resources folder:
>
> static {
>   try {
>   
>
properties.load(Thread.currentThread().getContextClassLoader().getResour
> ceAsStream(
>   "MyComponent.properties"));
>   } catch (Exception e) {
>   LOG.error("Unable to load file
> MyComponent.properties' - error: {}", e.getMessage(), e);
>   }
>   }
>
>   public static String getProperty(String key) {
>   return properties.getProperty(key);
>   }
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Hoover, William]

Wow, last time I checked CompoundPropertyModel is a model ;o)

-Original Message-
From: John Krasnay [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 1:22 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William  wrote:
> I read it, but I think most people will be using models more 
> frequently than 30% of the time. Personally, I use them 99% of the
time.

Really? Haven't you heard of CompoundPropertyModel?

jk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Zappaterrini, Larry]

I am currently using 1.4 M1 and here are my choices:

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 information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Bernard Niset]

Hi all,

  [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] I might rethink upgrading if my choice doesn't win.


I didn't try wicket 1.4 yet, but I read questions and comments from 
users in this list. My impression so far has been that there has been a 
small design mistake in the way the current 1.4 implementation has been 
done. I perceive that IModel is conceptually correct as a Model can 
be seen as a container of something (of type T). Writing 
DropDownChoice is a shortcut that does not seem conceptually correct 
as in this case, the component is not a container of type T but a 
container of type IModel. So you should have something like 
DropDownChoice> (I know this not valid java). Generifying the 
Page component is even worse as possibly a page can hold components with 
different model types and not have a model type on its own. Also, wicket 
is designed to allow some components not to have model on their own and 
rely on the model stored in a parent component (very nice and powerful 
feature).


Please note that using generic this way is already possible with wicket 
1.3 if you define an interface that would be for instance IMyModel 
extends IModel. For instance, I have a generic model defined as 
DetachableBeanModel where K is the key type and T is the bean type. 
This type is indeed a container of a key element and of a bean element.


I hope it helps,
Bernard.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[John Krasnay]

On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William  wrote:
> I read it, but I think most people will be using models more frequently
> than 30% of the time. Personally, I use them 99% of the time.

Really? Haven't you heard of CompoundPropertyModel?

jk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Jozsa]

Eelco Hillenius <[EMAIL PROTECTED]> wrote:1) Generifying* Wicket
[X] They, the core developers, knows better then me
(everyday users doesn't have in-depth and extensive view on
generification pro and cons. As usual, to find a good compromise
may be _very_ tricky business).

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.

Stefan Jozsa


   

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

[Charlie Dobbie]

On Sun, Jun 1, 2008 at 9:44 PM, Eelco Hillenius
<[EMAIL PROTECTED]> 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.
>   [half-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.
>   [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
> in your opinion here).
>   [ ]  (anything other than these choices?)

I see the stronger-typing made possible with Generics as a step
forward for Java and for Wicket.  I believe that Generics will improve
my code, and make my life easier.  I understand that actually
implementing the Generified objects is harder than using them, and
that this task rests mostly on the devs' shoulders!


> 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.

Whatever the devs decide, I'm not going to stop using Wicket (or
refuse to upgrade forever more) just because they've not implemented
something exactly the way I personally prefer!  I have faith that,
with discussion, the "right" decision will be made for the framework
as a whole.  After all, if I weren't happy to go along with the
majority view, I'd have to write everything myself...

Charlie.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Matej Knopp]

You really have to use it to appreciate the benefits. Quick glance
will just be scary :)

-Matej

On Mon, Jun 2, 2008 at 6:45 PM, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
>> Question is, how many of those users actually use generified wicket on
>> day-to-day basis.
>
> Common, a quick glance and comparing some of the code/ examples you
> see with the code you write now (with 1.2/ 1.3) is enough to get a
> good - and as far as I am concerned informed well enough - idea.
>
> Eelco
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Eelco Hillenius]

> Question is, how many of those users actually use generified wicket on
> day-to-day basis.

Common, a quick glance and comparing some of the code/ examples you
see with the code you write now (with 1.2/ 1.3) is enough to get a
good - and as far as I am concerned informed well enough - idea.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Sebastiaan van Erk]

Yes, property model (and compound friends) don't mix well with generics.
With generics a type safe alternative is wanted (and a very good start 
is Matej and Johan's type-safe model implementation).


Regards,
Sebastiaan

Jan Kriesten wrote:


hi al,

The second is almost certainly worth doing. That said, I use 
PropertyModel

more often than anything else, and that doesn't allow you to make any
guarantees anyway. :-/


good point. :-)

regards, --- jan.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Eelco Hillenius]

> IMHO storing a model in a Component is more a convenience than a
> fundamental part of component-ness. This may be part of the reason that
> genericizing Component is so contentious.

I agree.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Hoover, William]

Then we are on the same page with one thing... some level in the
component hierarchy would have to be generic.

Your original example specified "T getModel()" - you must have meant "T
getModelObject()" ;o)

-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 12:34 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


hi william,

> Enlighten me with an example

just like that:

Component { public object getModelObject(){ ... } } FormComponent
extends Component { public T getModelObject() { ... } }

regards, --- jan.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Eelco Hillenius]

On Mon, Jun 2, 2008 at 7: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 (except the verbosity of course, but that's not something
> we can really do about) with current state. I use wicket with generics
> daily and I don't see any particular show stopper so far.

I just want to get a hunch of what people are thinking at the moment.
It's not meant to be a discussion thread, nor a decision thread.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reminder: London Wicket event at Google UK on Wednesday

[Al Maw]

Hi folks,

Quick reminder that we're hosting another London Wicket event *this
Wednesday* at Google's London office.

It's looking like it might well be the best one to date, with a bunch of
really interesting stuff and some cracking talks.

Lots of cool stuff is lined up:
 - *Richard Wilkinson * on Wicket
Google Maps controls and mash-ups.
 - *Wille Faler * talking how to get the
"OpenSessionInView" enterprise pattern working in your Wicket app.
 - *Cemal Bayramoglu * demonstrating how to tame your
drop downs and make them behave just so.
 - *Al Maw * walking you through an entire
crazy-cool AJAX-heavy app, using some of the components previously created
for past London Wicket talks.

As usual there will be:
 - Lots of pizza.
 - A visit to the pub afterwards.
 - People to help you out with any thorny Wicket issues you may be having
(bring your code!).

In short, it's shaping up to be rather ace.

You should come.

*You'll need to sign up, which you can do here: *
http://jweekend.co.uk/dev/LWUGReg/

A reminder: talks and code from previous events available here:
http://londonwicket.org

Hope to see you there!


Best regards,

Al & Cemal

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

[Jan Kriesten]

hi william,


Enlighten me with an example


just like that:

Component { public object getModelObject(){ ... } }
FormComponent extends Component { public T getModelObject() { ... } }

regards, --- jan.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jan Kriesten]

hi sebastiaan,

You could use Java's covariant return types to override getModel() to 
return a specific type. Which would mean that you would need to subclass 
to "simulate" generics (with a new subclass for each type).


not really, you can do generify your components from a certain level and 
wouldn't have to subclass for each type. that way you could require 
formcomponents to have generics on them, without the whole component tree 
generified.


but i guess this would also lead to many questions why this and not that...

i'd prefer living with have to cast when it comes to getModel/getModelObject...

regards, --- jan.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Hoover, William]

Enlighten me with an example

-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 12:23 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


hi william,

> Wouldn't that infer that the component has to have generics, or am I 
> missing something here?

you miss something...

getModel/getModelObject would have to be non-final and overriden by the
specialized component (return types are covariant, so you can override
object with something more specific).

regards, --- jan.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jan Kriesten]

hi al,


The second is almost certainly worth doing. That said, I use PropertyModel
more often than anything else, and that doesn't allow you to make any
guarantees anyway. :-/


good point. :-)

regards, --- jan.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jan Kriesten]

hi william,


Wouldn't that infer that the component has to have generics, or am I
missing something here?


you miss something...

getModel/getModelObject would have to be non-final and overriden by the 
specialized component (return types are covariant, so you can override object 
with something more specific).


regards, --- jan.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Sebastiaan van Erk]

You could use Java's covariant return types to override getModel() to 
return a specific type. Which would mean that you would need to subclass 
to "simulate" generics (with a new subclass for each type). Also, when 
using anonymous subclasses it becomes rather pointless and you'd be back 
to casting.


Regards,
Sebastiaan

Hoover, William wrote:

Wouldn't that infer that the component has to have generics, or am I
missing something here?

Something like...

public abstract class Component, T> implements
IClusterable, IConverterLocator {
...
public final M getModel(){
...
}
...
public final T getModelObject(){
...
}
...
}

-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 12:03 PM

To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


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, you can implement T getModel() ?

Regards, --- Jan.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Hoover, William]

Wouldn't that infer that the component has to have generics, or am I
missing something here?

Something like...

public abstract class Component, T> implements
IClusterable, IConverterLocator {
...
public final M getModel(){
...
}
...
public final T getModelObject(){
...
}
...
}

-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 12:03 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


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, you can implement T getModel() ?

Regards, --- Jan.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Alastair Maw]

On Mon, Jun 2, 2008 at 3:54 PM, Martin Funk <[EMAIL PROTECTED]>
wrote:

> There are quite some methods that don't return the component,
> but its class. Maybe most prominently 'getHomePage()' in Application.
>
> This used to have the signature:
> public abstract Class getHomePage();
>
> And a popular implementation would be:
> public Class getHomePage() {
>   return HomePage.class
> }
>
> So maybe in favor of that popular implementation its current signature is:
>
> Application: public abstract Class> getHomePage();
>
> which is not a generic method but a method with a generified return
> parameter.
> But at least this works with the existing user code basis very well.
> But it also implies a circle I can't break up in my mind yet.
> This signature forces you to implement HomePage as a raw type, a class
> without type parameters, esp. not generic.
> Though on the other hand HomePage is a descendant of Component which is
> generic, of course.
> Which is a strong sign for HomePage to be generic too.
>
> I think both ends don't go together well.
>
> How is this going to be solved? Or, explained?



One could generify Application. ;-)

class Application {
   public abstract P getHomePage();
}

Generifying Component buys you no casting, at the expense of being hideously
verbose at times.
Generifying IModel buys you more obvious method signatures, particularly for
things like DropDownChoice.

The second is almost certainly worth doing. That said, I use PropertyModel
more often than anything else, and that doesn't allow you to make any
guarantees anyway. :-/

Al

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

[James Carman]

On Mon, Jun 2, 2008 at 12:11 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> A raw type is a parameterized type in which the type parameters are not
> filled in, i.e., new HashMap() (instead of new HashMap()).
>
> Just try to return one of your old (non-generified) HomePage.class classes
> (i.e., HomePage extends WebPage instead of HomePage extends WebPage)
> in your WebApplication's getHomePage() method, and you will see that it does
> not compile.

There is a section on the wiki addressing this now.  I would propose
that whenever referring to "class objects that represent Page
subclasses" we use Class rather than Class>.  This allows us to specify that it has to be a page class,
but it doesn't make the page class have to be generified.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Stefan Lindner]

Brill Pappin wrote
>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 their heads around
Generics can't use the older releases that don't include it, but IMO any
java >developer who doesn't get generics yet better make some time to
learn, because like it or not, they *will* be dealing with them.

I agree totally with you. My expericence with Generics over the last two
years was that any project that was adopted to generics had much less
errors afterwards.

But the main problem in this discussion seems to be that there are two
very different sorts of Web Applications that are developed with wicket
and both may have predecessors that are non generic.

Type A: A Web applicatons that make heavy use of Models, like classic
desktop allications that are ported to the web. I think the programmers
of such applications like Generics becaus they help them to avoid erros
and the current wicket generic implementation leads to a strong typed
application that needs a good object model (and a good database design).
If you port an exisitng wicket application with no generic to wicket 1.4
you might discover some unclear object model problems in your exisitng
code. And it's always easier to point to wicket's generics than to blame
your own code :-)

Type B: A Web Application with more static content, only some date (like
user logins, user profile data). In this case it's clear that some
people say "why should I always tyle 'Link', none of my links has
a Model, just about 10% of my Components have a Model". But why dont't
they write their own wrapper e.g. MyVoidLink extends Link? I
remember a dicsusson about such Components some weeks ago.


What do you think about it? Would it help users of Type B to have
VoidComponents?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Sebastiaan van Erk]

A raw type is a parameterized type in which the type parameters are not 
filled in, i.e., new HashMap() (instead of new HashMap()).


Just try to return one of your old (non-generified) HomePage.class 
classes (i.e., HomePage extends WebPage instead of HomePage extends 
WebPage) in your WebApplication's getHomePage() method, and you 
will see that it does not compile.


Regards,
Sebastiaan

Brill Pappin wrote:

I'm likely missing something here, but why would you want to return
something other than a *Page object? Wouldn't that cause some issues with
the application?

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 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
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() signature...

public abstract Class> getHomePage();

This breaks raw types (you can't return raw home page).

I don't see any way out of this one without making the getHomePage()
signature incorrect (i.e., you can't make it a generic method, which was
used to solve the problem where a method argument had the type Classextends Page>).


Regards,
Sebastiaan





On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William <[EMAIL PROTECTED]>

wrote:

Sounds like a good idea... Are you going to create it?

-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]

On Behalf Of James Carman
Sent: Monday, June 02, 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, Jun 2, 2008 at 11:03 AM, Hoover, William 
<[EMAIL PROTECTED]>

wrote:

+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 Carman
Sent: Monday, June 02, 2008 10:56 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take 
on generics with Wicket


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 (except the verbosity of course, but 
that's not something we can really do about) with current state. I 
use wicket with generics daily and I don't see any particular show 
stopper so far.



+1, I agree.  I think this discussion might be counter-productive if
folks who aren't using the generified versions are voting.


- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Jan Kriesten]

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, you 
can implement T getModel() ?


Regards, --- Jan.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Brill Pappin]

+1

Even if its one of the built in composite models, you still kind of need
them for most things you do.

- Brill 

-Original Message-
From: Hoover, William [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 11:59 AM
To: users@wicket.apache.org
Subject: RE: users, please give us your opinion: what is your take on
generics with Wicket

I read it, but I think most people will be using models more frequently than
30% of the time. Personally, I use them 99% of the time.

-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 11:54 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


Hi William,

> If you use more than one type of model for a given component I would 
> hardly say that it is only a fraction of the time. Do you use only one

> type of model on all your components? :o)

read again - I said 70% of my components don't have a Model...

> The use of Void is not an obscure 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  in there for especially nothing to
gain - Just make reading harder and each assignment even longer...

Regards, --- Jan.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Hoover, William]

I read it, but I think most people will be using models more frequently
than 30% of the time. Personally, I use them 99% of the time.

-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 11:54 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


Hi William,

> If you use more than one type of model for a given component I would 
> hardly say that it is only a fraction of the time. Do you use only one

> type of model on all your components? :o)

read again - I said 70% of my components don't have a Model...

> The use of Void is not an obscure 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  in there for especially nothing to
gain - Just make reading harder and each assignment even longer...

Regards, --- Jan.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Sebastiaan van Erk]

Jan Kriesten wrote:


Hi Sebastiaan,

I *really* would like to see a clarification of this statement. In 
Wicket the component and model are very tightly coupled.


that's part of the problem, agreed.


Kind of "late in the game" to do anything about that it seems though. 
And I don't know if I agree that it's a problem (I haven't seen anything 
better yet).


What is a *good design* alternative, where only IModel is generified? 
getModelObject() returns Object? getModel 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.


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).


Regards,
Sebastiaan


Regards, --- Jan.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Brill Pappin]

I'm likely missing something here, but why would you want to return
something other than a *Page object? Wouldn't that cause some issues with
the application?

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 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
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() signature...

public abstract Class> getHomePage();

This breaks raw types (you can't return raw home page).

I don't see any way out of this one without making the getHomePage()
signature incorrect (i.e., you can't make it a generic method, which was
used to solve the problem where a method argument had the type Class>).

Regards,
Sebastiaan




> On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William <[EMAIL PROTECTED]>
wrote:
>> Sounds like a good idea... Are you going to create it?
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED]
>> On Behalf Of James Carman
>> Sent: Monday, June 02, 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, Jun 2, 2008 at 11:03 AM, Hoover, William 
>> <[EMAIL PROTECTED]>
>> wrote:
>>> +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 Carman
>>> Sent: Monday, June 02, 2008 10:56 AM
>>> To: users@wicket.apache.org
>>> Subject: Re: users, please give us your opinion: what is your take 
>>> on generics with Wicket
>>>
>>> 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 (except the verbosity of course, but 
 that's not something we can really do about) with current state. I 
 use wicket with generics daily and I don't see any particular show 
 stopper so far.

>>> +1, I agree.  I think this discussion might be counter-productive if
>>> folks who aren't using the generified versions are voting.
>>>
>>> 
>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>> 
>>> - To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[James Carman]

Yes, the trick here is to not muddy up Wicket for the newcomers.
Wicket needs to be easy to learn and understand in order for it to be
adopted by the masses!

On Mon, Jun 2, 2008 at 11:46 AM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
> Question is, how many of those users are core committers. 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 PM, Matej Knopp <[EMAIL PROTECTED]> wrote:
>> On Mon, Jun 2, 2008 at 5:22 PM, Jan Kriesten <[EMAIL PROTECTED]> wrote:
>>>
>>> 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.
>>
>> 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:
>>>
>>> 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 be a language
>>> problem (i.e. Java's to blame).
>>>
>>> But IMHO putting generics on Component is a bad design, since it per se
>>> touches all of Wicket's Components without urgent need. Boilerplate over and
>>> over. If I look at my components and libraries (and yes, i have tried out
>>> 1.4!) - I have at most 30% of my components containing a Model!
>>>
>>> Best regards, --- Jan.
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.3 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Sebastiaan van Erk]

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 allow them to be ignored if the user didn't have a place
for them.


Well for one, getHomePage() does not compile if you returned home page 
is not generified, so it's not really that simple (opt in vs opt out).


Regards,
Sebastiaan

- Brill Pappin 


-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 02, 2008 11:46 AM

To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


Hi Sebastiaan,

I *really* would like to see a clarification of this statement. In 
Wicket the component and model are very tightly coupled.


that's part of the problem, agreed.


What is a *good
design* alternative, where only IModel is generified? getModelObject() 
returns Object? getModel 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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



smime.p7s
Description: S/MIME Cryptographic Signature

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

[Brill Pappin]

Lets not forget the stats we're all aware of (or should be) that 80% of
resources in software development are in maintenance... If I'm looking at my
ROI, then my developers can type a few extra words in order to reduce that
resource load.

And lets face it; it *all* comes down to maintenance (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
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

Question is, how many of those users are core committers. 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 PM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 2, 2008 at 5:22 PM, Jan Kriesten <[EMAIL PROTECTED]>
wrote:
>>
>> 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.
>
> 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:
>>
>> 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 be a 
>> language problem (i.e. Java's to blame).
>>
>> But IMHO putting generics on Component is a bad design, since it per 
>> se touches all of Wicket's Components without urgent need. 
>> Boilerplate over and over. If I look at my components and libraries 
>> (and yes, i have tried out
>> 1.4!) - I have at most 30% of my components containing a Model!
>>
>> Best regards, --- Jan.
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released Get it now:
http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[James Carman]

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 incorrect to me, i.e., PECS).
>
> One of the gotcha's I think is the getHomePage() signature...
>
>public abstract Class> getHomePage();
>
> This breaks raw types (you can't return raw home page).
>
> I don't see any way out of this one without making the getHomePage()
> signature incorrect (i.e., you can't make it a generic method, which was
> used to solve the problem where a method argument had the type Class extends Page>).
>

So, add that to the wiki so that we can discuss it.
> Regards,
> Sebastiaan
>
>
>
>
>> On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Sounds like a good idea... Are you going to create it?
>>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>> On Behalf Of James Carman
>>> Sent: Monday, June 02, 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, Jun 2, 2008 at 11:03 AM, Hoover, William <[EMAIL PROTECTED]>
>>> wrote:

 +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 Carman
 Sent: Monday, June 02, 2008 10:56 AM
 To: users@wicket.apache.org
 Subject: Re: users, please give us your opinion: what is your take on
 generics with Wicket

 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 (except the verbosity of course, but that's not
> something
> we can really do about) with current state. I use wicket with
> generics
> daily and I don't see any particular show stopper so far.
>
 +1, I agree.  I think this discussion might be counter-productive if
 folks who aren't using the generified versions are voting.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jan Kriesten]

Hi William,


If you use more than one type of model for a given component I would
hardly say that it is only a fraction of the time. Do you use only one
type of model on all your components? :o)


read again - I said 70% of my components don't have a Model...


The use of Void is not an obscure 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  in there for especially nothing to gain - 
Just make reading harder and each assignment even longer...


Regards, --- Jan.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Sebastiaan van Erk]

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() signature...

public abstract Class> getHomePage();

This breaks raw types (you can't return raw home page).

I don't see any way out of this one without making the getHomePage() 
signature incorrect (i.e., you can't make it a generic method, which was 
used to solve the problem where a method argument had the type Classextends Page>).


Regards,
Sebastiaan





On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William <[EMAIL PROTECTED]> wrote:

Sounds like a good idea... Are you going to create it?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James Carman
Sent: Monday, June 02, 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, Jun 2, 2008 at 11:03 AM, Hoover, William <[EMAIL PROTECTED]>
wrote:

+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 Carman
Sent: Monday, June 02, 2008 10:56 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

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 (except the verbosity of course, but that's not
something
we can really do about) with current state. I use wicket with
generics
daily and I don't see any particular show stopper so far.


+1, I agree.  I think this discussion might be counter-productive if
folks who aren't using the generified versions are voting.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Wicket cheat sheet, solve your wicket problem fast?

[Michael Allan]

Nino Saturnino Martinez Vazquez Wael wrote:
> I've created a small wicket cheat sheet for issues and features, please see 
> here :  http://www.flyupload.com/?fid=9436254
>
> ...Any comment will be welcome:)

That page is so ridden with ad-spam, Nino, there's no visible content!
My browser blocked 3 popup windows.  Then an Ajax window floated out,
informing me I won $3,000.  Behind it, are 4 banner ads, nearly
obscuring some Google text ads - so many ads, altogether, they spill
over the edges of the screen.

I'm surprised that your message got a response from people.

-- 
Michael Allan

Toronto, 647-436-4521
http://zelea.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Ryan Sonnek]

>
> 1) Generifying* Wicket
>   [x] Should be avoided, I prefer the way 1.3 works. Because... (fill
> in your opinion here).
>
After seeing the impact that generics had on the codebase, I'm begining to
feel that it's not worth the effort.  Trying to *JUST* generify models seems
like a half baked solution which will constantly trigger users asking, "why
isn't foo using generics?"  My biggest fear is that the API will bloat and
become less understandable by adopting generics.

>
> 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 trust the wicket core devs 100% so whatever they implement, I'll take a
look at.  Just remember to Keep It Simple!!!  =)