WicketTester and ajax call from javascript

2011-11-27 Thread Sebastiaan van Erk

Hi all,

I've got a page which calls wicket from javascript as described by the page:

https://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html

That is, in my JavaScript I call a function:

function callWicket() {
   var wcall = wicketAjaxGet('$url$' + '$args$', function() { }, 
function() { });

}

The args are of the form foo=bar as described. I also retrieve this 
argument when I receive the call in Wicket using (also as described):


String paramFoo = RequestCycle.get().getRequest().getParameter(foo);

However, I'm wondering, how can I test this using WicketTester?

I first use startPage to render the page, but how can I now simulate the 
wicketAjaxGet, and how can I make sure the parameter is set on the 
request so paramFoo does not end up being null?


Best regards,
Sebastiaan





smime.p7s
Description: S/MIME Cryptographic Signature


Re: WicketTester and ajax call from javascript

2011-11-27 Thread Sebastiaan van Erk

Hi,

Thanks for your answer. Unfortunately for the moment I don't have the 
opportunity to upgrade to Wicket 1.5 on this project. Is there a way to 
achieve this using Wicket 1.4?


If not, I can live with it, but it would be nice if possible.

Best regards,
Sebastiaan

On 11/28/2011 07:35 AM, Martin Grigorov wrote:

Hi,

With Wicket 1.5 you can use executeUrl() to do that.
p = startPage
c = p.get()
b = c.getBehaviorByXyz()
u = b.getCallbackUrl()
fullUrl = u + foo=barwicket-ajax=true
executeUrl(fullUrl)


On Mon, Nov 28, 2011 at 6:59 AM, Sebastiaan van Erksebs...@sebster.com  wrote:

Hi all,

I've got a page which calls wicket from javascript as described by the page:

https://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html

That is, in my JavaScript I call a function:

function callWicket() {
   var wcall = wicketAjaxGet('$url$' + '$args$', function() { }, function() {
});
}

The args are of the form foo=bar as described. I also retrieve this
argument when I receive the call in Wicket using (also as described):

String paramFoo = RequestCycle.get().getRequest().getParameter(foo);

However, I'm wondering, how can I test this using WicketTester?

I first use startPage to render the page, but how can I now simulate the
wicketAjaxGet, and how can I make sure the parameter is set on the request
so paramFoo does not end up being null?

Best regards,
Sebastiaan












smime.p7s
Description: S/MIME Cryptographic Signature


Re: WicketTester and ajax call from javascript

2011-11-27 Thread Sebastiaan van Erk

Hi,

The following (based on your answer, but then 'backported' to 1.4) seems 
to work: I basically copied the implementation of executeBehavior from 
WicketTester.


public void executeBehaviorWithParameters(AbstractAjaxBehavior 
behavior, MapString, ? parameters) {
StringBuffer url = new 
StringBuffer(behavior.getCallbackUrl(false));

for (Map.EntryString, ? entry : parameters.entrySet()) {
try {
url.append('');
url.append(URLEncoder.encode(entry.getKey(), UTF-8));
url.append('=');

url.append(URLEncoder.encode(entry.getValue().toString(), UTF-8));
} catch (UnsupportedEncodingException e) {
// Should not happen.
throw new RuntimeException(e);
}
}
WebRequestCycle cycle = tester.setupRequestAndResponse(true);

tester.getServletRequest().setRequestToRedirectString(url.toString());
tester.processRequestCycle(cycle);
}

Regards,
Sebastiaan

On 11/28/2011 08:20 AM, Sebastiaan van Erk wrote:

Hi,

Thanks for your answer. Unfortunately for the moment I don't have the
opportunity to upgrade to Wicket 1.5 on this project. Is there a way to
achieve this using Wicket 1.4?

If not, I can live with it, but it would be nice if possible.

Best regards,
Sebastiaan

On 11/28/2011 07:35 AM, Martin Grigorov wrote:

Hi,

With Wicket 1.5 you can use executeUrl() to do that.
p = startPage
c = p.get()
b = c.getBehaviorByXyz()
u = b.getCallbackUrl()
fullUrl = u + foo=barwicket-ajax=true
executeUrl(fullUrl)


On Mon, Nov 28, 2011 at 6:59 AM, Sebastiaan van
Erksebs...@sebster.com wrote:

Hi all,

I've got a page which calls wicket from javascript as described by
the page:

https://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html

That is, in my JavaScript I call a function:

function callWicket() {
var wcall = wicketAjaxGet('$url$' + '$args$', function() { },
function() {
});
}

The args are of the form foo=bar as described. I also retrieve this
argument when I receive the call in Wicket using (also as described):

String paramFoo = RequestCycle.get().getRequest().getParameter(foo);

However, I'm wondering, how can I test this using WicketTester?

I first use startPage to render the page, but how can I now simulate the
wicketAjaxGet, and how can I make sure the parameter is set on the
request
so paramFoo does not end up being null?

Best regards,
Sebastiaan














smime.p7s
Description: S/MIME Cryptographic Signature


WicketTester, enclosures, and assertInvisible

2011-10-31 Thread Sebastiaan van Erk

Hi,

I'm using WicketTester to assertInvisible some components. Now I have 
the following situation:


wicket:enclosure child=comp1
  div wicket:id=comp1/div
  div wicket:id=comp2/div
/wicket:enclosure

In the code I say comp1 is invisible, so the whole enclosure is 
invisible. However, in WicketTester, assertInvisible(comp2) fails.


I am aware of a previous post about this: 
http://apache-wicket.1842946.n4.nabble.com/WicketTester-assertInvisible-td3303769.html


However, I don't really see an answer there. What is the expected 
behavior of WicketTester, and is this bug? Or am I doing something wrong?


Best regards,
Sebastiaan



smime.p7s
Description: S/MIME Cryptographic Signature


Re: WicketTester, enclosures, and assertInvisible

2011-10-31 Thread Sebastiaan van Erk

Hi,

Thanks for the answer.

I guess this is the expected behavior of WicketTester then.

Best regards,
Sebastiaan

On 2011-10-31 14:12, Martin Grigorov wrote:

Hi,

I hit the very same problem while trying to make a test case for
https://issues.apache.org/jira/browse/WICKET-4172.
It seems WicketTester is not able to check that because the Enclosure
component is used only at render time (the so called 'auto component')
where it says I'm not visible and thus all its children are not
rendered.
But with WicketTester.assert(In)Visible() you actually do:
page.get(some:path).isVisible() and here there is no knowledge about
the Enclosure at all and #isVisibleInHierarchy() returns true for
comp2.

It seems the only way to verify that comp2 is invisible when an
enclosure is involved is to assert that there is no markup for it in
the rendered page as string.

On Mon, Oct 31, 2011 at 3:01 PM, Sebastiaan van Erksebs...@sebster.com  wrote:

Hi,

I'm using WicketTester to assertInvisible some components. Now I have the
following situation:

wicket:enclosure child=comp1
  div wicket:id=comp1/div
  div wicket:id=comp2/div
/wicket:enclosure

In the code I say comp1 is invisible, so the whole enclosure is invisible.
However, in WicketTester, assertInvisible(comp2) fails.

I am aware of a previous post about this:
http://apache-wicket.1842946.n4.nabble.com/WicketTester-assertInvisible-td3303769.html

However, I don't really see an answer there. What is the expected behavior
of WicketTester, and is this bug? Or am I doing something wrong?

Best regards,
Sebastiaan










smime.p7s
Description: S/MIME Cryptographic Signature


Custom resource loading

2009-12-06 Thread Sebastiaan van Erk

Hi,

I'm implementing a Wicket application that has heavy use of styling and 
localization. I want to place the resources for these styles and locales 
in an external directory structure (not in the war). Basically, I want 
the following structure:


/external/style/locale/images
/external/style/locale/css
/external/style/locale/messages.properties
/external/style/locale/templates

The reason I want all these files externally is because I want to be 
able to add and modify these files while the application is running. I 
also want the directory structure like this because it's basically 
branding and I want to easily be able to restrict access to the subtree 
under /external/brand1 (using for example ftp or webdav) to a specific 
person responsible for that tree.


I also want to use the standard fallback mechanism, so if I look for a 
css file called my.css with style style1 and locale locale1, I want to try:


1. /external/style1/locale1/css/my.css
2. /external/_default/locale1/css/my.css
3. /external/style1/_default/css/my.css
4. /external/_default/_default/css/my.css
5. Wicket's standard mechanism for finding my.css

Question 1:
- how can I add this scheme to the resource locating mechanism?

I looked into IResourceStreamLocator and IResourceSettings, and what I 
can think of is writing my own IResourceStreamLocator which wraps 
Wicket's implementation, does 1-4 and if nothing is found calls Wicket's 
implementation.


However, there is a class ResourceNameIterator which immplements the 
locale/style sequence of finding pathnames, and it used not only in 
ResourceStreamLocator, but also in all the IStringResourceLoaders. This 
leads me to believe that I must also add my own IStringResourceLoader to 
look in the property files above. I'm also wondering how I can do this 
efficiently though: how can I make sure I don't have to read the 
property files 100 times for message keys (once for each key)? Do I have 
to implement my own caching in the IStringResourceLoader implementation? 
Is there anything I can reuse from Wicket which already reads property 
files for keys.


Question 2:
- Some of the resources listed above are public, and I want to be able 
to mount them. Is it possible to mount an entire directory at a time, 
e.g., mount /images and then automatically have 
http://www.mywicketapplication.com/app/images/.jpg use my resource 
loader with the path images/.jpg?


Question 3:
- Are there any tips with regards to Wicket's caching mechanism and my 
desire to be able to change resources on the fly (I'm especially 
concerned about negative caching (i.e., resource was not found before, 
but now it has been added), and new resources appearing for a more 
specific style/locale, overriding the previously more generic resource 
(i.e., style1/_default/my.css was previously found, but now 
style1/nl/my.css suddenly exists and should be used instead))?



Regards,
Sebastiaan



smime.p7s
Description: S/MIME Cryptographic Signature


validation string resource name prefix

2009-12-01 Thread Sebastiaan van Erk

Hi,

I would like all the validation strings on a specific page to have a 
specified prefix, e.g., if I have a field password with a length 
validator on my page, I would like the following resource strings tried 
in the listed order:


myPageLabel.password.StringValidator.minimum
password.StringValidator.minimum
StringVaildator.mininum

I would like to be able to specify the label for the page manually 
(i.e., they get stored in the db, and I don't want the full java class 
name prepended if possible).


Is this possible?

Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: error messages due to hack/search-bots

2008-12-22 Thread Sebastiaan van Erk

Pointbreak wrote:

Not an answer to your question, but why fight this kind of stuff? It's
an invalid request, so it should result in an error.


I actually prefer it would result in a 404 for the client and nothing 
more. Perhaps, when enabling DEBUG, it can log the message + exception 
it is currently logging as ERROR.



If you don't want these entries in your log, you could just add a filter
to your logger (e.g. filtering out error messages from
org.apache.wicket.request.target.resource.SharedResourceRequestTarget
where the message equals unable to lazily register shared resource).


It is annoying (and dangerous) to filter your log in this way. The 
problem is that you may accidentally filter too much and miss real 
errors. Also, it requires you to know a lot about wicket internals (is 
this a real error, or should this be considered a warning?). And it is 
cumbersome (every time a new exception appears, you have to go through 
this process again).


To the Wicket developers: why is this logged using log.error and not 
using log.debug (in SharedResourceRequestTarget#respond? It's not really 
an error, it's a reference to a resource that does not exist, and a 404 
should be sufficient (without ERRORs in the log).


Regards,
Sebastiaan


On Mon, 22 Dec 2008 14:05 +0100, Antoine van Wel
antoine.van@gmail.com wrote:

Heya,

we're trying to catch all errors caused by hack  search-bots on our
wicket-app. AFAIK these bots take existing links, chop 'em up in
smaller chunks and try to append all kind of . We've caught most
of the errors which result due to these bots, but this one still
stands:

XXX.XXX.XXX.XXX - - [22/Dec/2008:00:03:37 +0100] GET
/resources/org.apache.wicket.markup.html.WicketEventReference_false_61497/
HTTP/1.1 404 952 - - -

Causing errors such as

2008-12-22 00:03:41,654 ERROR -
[TP-Processor7][org.apache.wicket.request.target.resource.SharedResourceRequestTarget:172]
unable to lazily register shared resource
org.apache.wicket.ajax.WicketAjaxReference_false_61497/
java.lang.ClassNotFoundException:
org.apache.wicket.ajax.WicketAjaxReference_false_61497
  at
  
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)

[...snip...]


So... any ideas to catch these errors?



Antoine



--
We don't see things as they are, we see things as we are. - Anais Nin
Whether you think you can or whether you think you can't, you're
right. - Henry Ford

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



smime.p7s
Description: S/MIME Cryptographic Signature


Re: error messages due to hack/search-bots

2008-12-22 Thread Sebastiaan van Erk

I created a JIRA issue (with trivial patch).

https://issues.apache.org/jira/browse/WICKET-1991

Regards,
Sebastiaan

Antoine van Wel wrote:

agree with Sebastiaan and Michael here

when a user types a wrong url, you're not going to log that
404 - client error, file not found - no fixes necessary, so not logged
500 - server error - log it, needs to be fixed


so instead of implementing the filter, I prefer waiting for a Wicket
patch..  :-)


Antoine

On Mon, Dec 22, 2008 at 7:16 PM, Michael Sparer michael.spa...@gmx.at wrote:

the thing is that 404 is a client error. I'd only log server errors (i.e.
errors in the code) as Error. Of course a 404 can also happen due to a error
in the code, but logging 404 as errors will flood your log file ...

just my two cents



Jeremy Thomerson-5 wrote:

A 404 is an error - so on the one hand you say it is an error, but on the
other, you say it isn't.  I think it should remain an error.

Just my 0.02 though.

On Mon, Dec 22, 2008 at 7:56 AM, Sebastiaan van Erk
sebs...@sebster.comwrote:


Pointbreak wrote:


Not an answer to your question, but why fight this kind of stuff? It's
an invalid request, so it should result in an error.


I actually prefer it would result in a 404 for the client and nothing
more.
Perhaps, when enabling DEBUG, it can log the message + exception it is
currently logging as ERROR.

If you don't want these entries in your log, you could just add a filter

to your logger (e.g. filtering out error messages from
org.apache.wicket.request.target.resource.SharedResourceRequestTarget
where the message equals unable to lazily register shared resource).


It is annoying (and dangerous) to filter your log in this way. The
problem
is that you may accidentally filter too much and miss real errors. Also,
it
requires you to know a lot about wicket internals (is this a real error,
or
should this be considered a warning?). And it is cumbersome (every time a
new exception appears, you have to go through this process again).

To the Wicket developers: why is this logged using log.error and not
using
log.debug (in SharedResourceRequestTarget#respond? It's not really an
error,
it's a reference to a resource that does not exist, and a 404 should be
sufficient (without ERRORs in the log).

Regards,
Sebastiaan


On Mon, 22 Dec 2008 14:05 +0100, Antoine van Wel

antoine.van@gmail.com wrote:


Heya,

we're trying to catch all errors caused by hack  search-bots on our
wicket-app. AFAIK these bots take existing links, chop 'em up in
smaller chunks and try to append all kind of . We've caught most
of the errors which result due to these bots, but this one still
stands:

XXX.XXX.XXX.XXX - - [22/Dec/2008:00:03:37 +0100] GET

/resources/org.apache.wicket.markup.html.WicketEventReference_false_61497/
HTTP/1.1 404 952 - - -

Causing errors such as

2008-12-22 00:03:41,654 ERROR -

[TP-Processor7][org.apache.wicket.request.target.resource.SharedResourceRequestTarget:172]
unable to lazily register shared resource
org.apache.wicket.ajax.WicketAjaxReference_false_61497/
java.lang.ClassNotFoundException:
org.apache.wicket.ajax.WicketAjaxReference_false_61497
 at


org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)

[...snip...]


So... any ideas to catch these errors?



Antoine



--
We don't see things as they are, we see things as we are. - Anais Nin
Whether you think you can or whether you think you can't, you're
right. - Henry Ford

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




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




-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context: 
http://www.nabble.com/error-messages-due-to-hack-search-bots-tp21127488p21132409.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org








smime.p7s
Description: S/MIME Cryptographic Signature


Re: Can't get round this problem

2008-06-09 Thread Sebastiaan van Erk
Don't use a HiddenField on the Wicket side but a WebMarkupContainer. The 
HTML side remains the same (i.e., input tag).


Regards,
Sebastiaan

Mathias P.W Nilsson wrote:

I have a page that has 2 fragment. One for normal ordering and one for credit
card ordering.

When sending the input type hidden names they must have the exact name but
wicket changes it

orderPanel:Merchant_id
must be Merchant_id. How can I remove the orderPanel that adds to the
markup.

I have tried to extend the hidden field and override the protected void
onComponentTag(ComponentTag tag)  but this just makes it work even worse.
Why must wicket change the name of the input tag? Is there a way around
this. I must be able to specify my own name. I was hoping that just

 new HiddenField(  Merchant_id, new Model(   ) ); would do the trick but
wicket changes that name.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-06-09 Thread Sebastiaan van Erk

Zappaterrini, Larry wrote:

Sebastiaan,

Point 1 is a good one. I haven't puzzled that through completely. Upon
initial inspection it seems that it is just the compiler being pedantic
about a scenario that wouldn't arise in practice. I'll have to think
about it some more.

I might be missing something with point 2, but what is wrong with
ClassFoo clazz = Foo.class?


If Foo is a generic type (as in the example I gave), then the above 
assignment will give you a warning (which I don't know how to get rid 
off without a suppress)...


Foo is a raw type. References to generic type FooT should be parameterized

Regards,
Sebastiaan


Cheers,
Larry

-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Saturday, June 07, 2008 3:57 AM

To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

Zappaterrini, Larry wrote:

Sorry, I should have been more clear about subtype. :) When dealing

with

raw types, the raw type is considered a super type of the generic

type.

So Bar is a super type of Bar?. Since RawType extends the raw type
Bar, consider it to be a peer of Bar?. When you consider them as
peers, a warning is warranted. The new example you use works due to
erasure. Bar? as declared in source code becomes Bar in byte code.

So

the statement becomes:

Bar bar = new RawBar();

Which is perfectly legal. I have found that most of perceived
inconsistencies in Java generics stems  from erasure and sub type
substitution. The golden rule of generics is that the byte code

produced

by compiling generics will never produce an invalid cast so long as

the

code does not produce any warnings. This causes some things that may
seem intuitive to be illegal.


Thanks for your explanation. I still think it's all rather horrible 
though. Type erasure was a huge mistake if you ask me. Two questions for


you though...

1) Can you come up with an example where assigning a Foo? extends Bar 
to a Foo? extends Bar? causes an invalid cast? (So I can understand 
why this intuitive seeming assignment is illegal).


2) How do you get rid of the warning in ClassFoo clazz = Foo.class 
without using Class?? Because it would seem strange if there is no 
warning free way to use a certain language construct...


Regards,
Sebastiaan


-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 4:16 PM

To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

Zappaterrini, Larry wrote:

In the example you have detailed, RawBar is not a subtype of Bar?
since it extends the raw type Bar.

I guess it depends on the definition of subtype. It is at least the

case
that the following assignment compiles without warnings (without 
warnings about unchecked casts):


   Bar? bar = new RawBar();

So is it then a subtype? Or isn't it? It's all terribly inconsistent
if 

you ask me. :-(

Regards,
Sebastiaan




-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 11:31 AM

To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:

Martin Funk wrote:


Class? extends Page? means class of (anything that extends

(page of

anything)).

I'm not so sure.

There are 2 separate issues:

ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
where RawBar extends Bar as a raw type. That is, given:


  static class FooT {
  }

  static class BarT {
  }

  static class RawBar extends Bar {
  }

  static class SubBarT extends BarT {
  }

Thus:

   Bar? bar = new RawBar(); // works, because RawBar is a subtype

of

Bar?

But:

   Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
THIS 

IS CAUSING ONE HALF OF ALL OUR HEADACHES

(correction:)
Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT

WORK

-

THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES

Btw, this does work (like you expect):
Foo? extends Bar? rawbar2 = new FooSubBar?();


Note that this is the issue that complete baffles me, as RawBar is a



subtype of Bar?, so I *really* *really* *REALLY* have no idea why
the 

compiler chokes on this.

ISSUE 2: The class literal of a generic type returns a class of a

raw

type.  Thus Foo.class return ClassFoo. This is also really messed
up, 

because:

ClassFoo fc = Foo.class;


compiles, but generates a warning (reference to raw type). But if

you

type this in eclipse:

x fc = Foo.class;

and use eclipse quickfix to change x to the correct type, it'll 
change it to precisely ClassFoo (the JLS is very short about this,
see 
also 


http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
5.8.2). 

So what the heck is the proper type for the class literal??? I
couldn't 

find any!

Finally, note that when you define a method like this:

  static void method1(Foo? extends Bar? y) {
  }

it works like a charm for a new

Re: (Class? extends Page?) casting troubles

2008-06-07 Thread Sebastiaan van Erk

Zappaterrini, Larry wrote:

Sorry, I should have been more clear about subtype. :) When dealing with
raw types, the raw type is considered a super type of the generic type.
So Bar is a super type of Bar?. Since RawType extends the raw type
Bar, consider it to be a peer of Bar?. When you consider them as
peers, a warning is warranted. The new example you use works due to
erasure. Bar? as declared in source code becomes Bar in byte code. So
the statement becomes:

Bar bar = new RawBar();

Which is perfectly legal. I have found that most of perceived
inconsistencies in Java generics stems  from erasure and sub type
substitution. The golden rule of generics is that the byte code produced
by compiling generics will never produce an invalid cast so long as the
code does not produce any warnings. This causes some things that may
seem intuitive to be illegal.


Thanks for your explanation. I still think it's all rather horrible 
though. Type erasure was a huge mistake if you ask me. Two questions for 
you though...


1) Can you come up with an example where assigning a Foo? extends Bar 
to a Foo? extends Bar? causes an invalid cast? (So I can understand 
why this intuitive seeming assignment is illegal).


2) How do you get rid of the warning in ClassFoo clazz = Foo.class 
without using Class?? Because it would seem strange if there is no 
warning free way to use a certain language construct...


Regards,
Sebastiaan


-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 4:16 PM

To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

Zappaterrini, Larry wrote:

In the example you have detailed, RawBar is not a subtype of Bar?
since it extends the raw type Bar.


I guess it depends on the definition of subtype. It is at least the case

that the following assignment compiles without warnings (without 
warnings about unchecked casts):


   Bar? bar = new RawBar();

So is it then a subtype? Or isn't it? It's all terribly inconsistent if 
you ask me. :-(


Regards,
Sebastiaan




-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 11:31 AM

To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:

Martin Funk wrote:


Class? extends Page? means class of (anything that extends

(page of

anything)).

I'm not so sure.

There are 2 separate issues:

ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
where RawBar extends Bar as a raw type. That is, given:


  static class FooT {
  }

  static class BarT {
  }

  static class RawBar extends Bar {
  }

  static class SubBarT extends BarT {
  }

Thus:

   Bar? bar = new RawBar(); // works, because RawBar is a subtype

of

Bar?

But:

   Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
THIS 

IS CAUSING ONE HALF OF ALL OUR HEADACHES

(correction:)
Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK

-

THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES

Btw, this does work (like you expect):
Foo? extends Bar? rawbar2 = new FooSubBar?();

Note that this is the issue that complete baffles me, as RawBar is a 
subtype of Bar?, so I *really* *really* *REALLY* have no idea why
the 

compiler chokes on this.

ISSUE 2: The class literal of a generic type returns a class of a raw



type.  Thus Foo.class return ClassFoo. This is also really messed
up, 

because:

ClassFoo fc = Foo.class;


compiles, but generates a warning (reference to raw type). But if you



type this in eclipse:

x fc = Foo.class;

and use eclipse quickfix to change x to the correct type, it'll 
change it to precisely ClassFoo (the JLS is very short about this,
see 
also 


http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
5.8.2). 

So what the heck is the proper type for the class literal??? I
couldn't 

find any!

Finally, note that when you define a method like this:

  static void method1(Foo? extends Bar? y) {
  }

it works like a charm for a new FooSubBarString, i.e., the Foo

of
(anything that extends (bar of anything)) really is the correct 
interpretation.


It's just that the interaction with raw types is completely *foobar* 
(pun intended).


Regards,
Sebastiaan








__

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

Re: wicket generics

2008-06-07 Thread Sebastiaan van Erk
I'm +1 for trying to decouple model from component, and if it takes 
longer then so be it.


I'm pretty convinced that the problem is the 1-1 model-component 
coupling and that generics only pointed out this problem.


Regards,
Sebastiaan

Igor Vaynberg wrote:

so i tried to remove the generic type from component in
sandbox/ivaynberg/wicket-generics branch and ran into what i think is
a deal breaker for this design

class component {
  public void setmodel(imodel? model) {...}
  public imodel? getmodel();
}

that is all good until you want to have a generified subclass eg a listitem:

class listitemt extends component {
  public imodelt getmodel() { return (imodelt)super.getmodel(); }
== works like a charm
  public void setmodel(imodelt model) {..} == woops, compilation error

Name clash: The method setModel(IModelT) of type ListItemT has the
same erasure as
 setModel(IModel?) of type MarkupContainer but does not override it

unfortunately the error makes sense and there is no way around it.
same goes for setmodelobject(). i think this makes this design variant
pretty useless. as long as we have the model coupled to component i
dont see a clean way of doing this :(

class listitemt extends component {
  public imodelt getmodel(..);
  public void setmodel(imodel? model);
}

looks half baked and broken by design

i would almost reconsider 1.4 and its scope and opt to include a model
decoupling (however and if that is possible) refactor in it. otherwise
i fear we will break the whole generics model again in 1.5 and users
will have to relearn how to use them with wicket.

so as far as i can see, and this is only my opinion, our options are:

continue 1.4 as it is now with fully typed components
remove component type but make the api ugly ( i will let matej explain )
attempt to fix 1.4 by decoupling model from component - 1.4 takes a
lot longer and is not a simple drop-in/upgrade/whatever

thoughts and ideas?

-igor

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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-06-06 Thread Sebastiaan van Erk

Martin Funk wrote:

Jeremy Thomerson wrote:

I haven't read the whole thread, but you should be fine as long as your
returned page class uses generics...

Here's what I use in one app, no warnings, no casts:

@Override
public Class? extends Page? getHomePage() {
return Home.class;
}


public class Home extends WebPageVoid {
}

  

Hi Jeremy,

I'm still picking on the words. What do you mean by 'uses generics'?

I think the point is class Home has to be a non generic type subclassing 
the generic class WebPage with a concrete type parameter.


Why should the HomePage class be non generic, and why should you use a 
concrete type parameter?


Class? extends Page? means class of (anything that extends (page of 
anything)).


That means your home page can have as many type parameters as you wish 
(or none at all), as long as it extends Page?. This also means you you 
can define a generic HomePage like this:


class HomePageT extends WebPageT { ... }

if you feel like it, and don't have to use a concrete type.

And I still really don't understand why java has a problem with this:

class HomePage extends WebPage { ... }

since here it *is still* the case that HomePage is a subtype of 
WebPage? (you prove this by the assignment:


WebPage? wp = new HomePage();

which works fine). So you would expect to be able to return this in the 
getHomePage() method. But you can't because the compiler chokes on it. I 
have not seen a convincing reason why this shouldn't work yet, though.


Regards,
Sebastiaan


mf

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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-06-06 Thread Sebastiaan van Erk

ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:

Martin Funk wrote:


Class? extends Page? means class of (anything that extends (page of
anything)).


I'm not so sure.


There are 2 separate issues:

ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
where RawBar extends Bar as a raw type. That is, given:


  static class FooT {
  }

  static class BarT {
  }

  static class RawBar extends Bar {
  }

  static class SubBarT extends BarT {
  }

Thus:

   Bar? bar = new RawBar(); // works, because RawBar is a subtype of 
Bar?


But:

   Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK - THIS 
IS CAUSING ONE HALF OF ALL OUR HEADACHES


(correction:)
   Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK - 
THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES


Btw, this does work (like you expect):
   Foo? extends Bar? rawbar2 = new FooSubBar?();

Note that this is the issue that complete baffles me, as RawBar is a 
subtype of Bar?, so I *really* *really* *REALLY* have no idea why the 
compiler chokes on this.


ISSUE 2: The class literal of a generic type returns a class of a raw 
type.  Thus Foo.class return ClassFoo. This is also really messed up, 
because:

ClassFoo fc = Foo.class;


compiles, but generates a warning (reference to raw type). But if you 
type this in eclipse:


x fc = Foo.class;

and use eclipse quickfix to change x to the correct type, it'll 
change it to precisely ClassFoo (the JLS is very short about this, see 
also 
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.8.2). 



So what the heck is the proper type for the class literal??? I couldn't 
find any!


Finally, note that when you define a method like this:

  static void method1(Foo? extends Bar? y) {
  }

it works like a charm for a new FooSubBarString, i.e., the Foo of 
(anything that extends (bar of anything)) really is the correct 
interpretation.


It's just that the interaction with raw types is completely *foobar* 
(pun intended).


Regards,
Sebastiaan









smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-06-06 Thread Sebastiaan van Erk

Zappaterrini, Larry wrote:

In the example you have detailed, RawBar is not a subtype of Bar?
since it extends the raw type Bar.


I guess it depends on the definition of subtype. It is at least the case 
that the following assignment compiles without warnings (without 
warnings about unchecked casts):


  Bar? bar = new RawBar();

So is it then a subtype? Or isn't it? It's all terribly inconsistent if 
you ask me. :-(


Regards,
Sebastiaan




-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 11:31 AM

To: users@wicket.apache.org
Subject: Re: (Class? extends Page?) casting troubles

ARgh, you always make typos with this stuff.

See correction.

Sebastiaan van Erk wrote:

Martin Funk wrote:


Class? extends Page? means class of (anything that extends

(page of

anything)).

I'm not so sure.

There are 2 separate issues:

ISSUE 1: Foo? extends Bar? is not assignable from a FooRawBar 
where RawBar extends Bar as a raw type. That is, given:


  static class FooT {
  }

  static class BarT {
  }

  static class RawBar extends Bar {
  }

  static class SubBarT extends BarT {
  }

Thus:

   Bar? bar = new RawBar(); // works, because RawBar is a subtype of



Bar?

But:

   Foo? extends Bar? rawbar = new RawBar(); // DOES NOT WORK -
THIS 

IS CAUSING ONE HALF OF ALL OUR HEADACHES


(correction:)
Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK -

THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES

Btw, this does work (like you expect):
Foo? extends Bar? rawbar2 = new FooSubBar?();

Note that this is the issue that complete baffles me, as RawBar is a 
subtype of Bar?, so I *really* *really* *REALLY* have no idea why
the 

compiler chokes on this.

ISSUE 2: The class literal of a generic type returns a class of a raw 
type.  Thus Foo.class return ClassFoo. This is also really messed
up, 

because:

ClassFoo fc = Foo.class;


compiles, but generates a warning (reference to raw type). But if you 
type this in eclipse:


x fc = Foo.class;

and use eclipse quickfix to change x to the correct type, it'll 
change it to precisely ClassFoo (the JLS is very short about this,
see 
also 


http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1
5.8.2). 


So what the heck is the proper type for the class literal??? I
couldn't 

find any!

Finally, note that when you define a method like this:

  static void method1(Foo? extends Bar? y) {
  }

it works like a charm for a new FooSubBarString, i.e., the Foo of


(anything that extends (bar of anything)) really is the correct 
interpretation.


It's just that the interaction with raw types is completely *foobar* 
(pun intended).


Regards,
Sebastiaan









__

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]



smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-06-06 Thread Sebastiaan van Erk

Martin Funk wrote:
   Foo? extends Bar? rawbar = new FooRawBar(); // DOES NOT WORK 
- THIS IS CAUSING ONE HALF OF ALL OUR HEADACHES


Btw, this does work (like you expect):
   Foo? extends Bar? rawbar2 = new FooSubBar?();

maybe some more wisdom can be found here:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/TechnicalDetails.html#FAQ209 

In her words it would mean 'raw types are not part of the type family 
denoted by the wildcard parametrized type Bar?'
But I'm still puzzled, since taking that FAQ it doesn't explain why in 
the case of the generic method


public T extends Component? void dol(ClassT clazz)

the raw types are all of a sudden member of that family


Nor does it explain why assignment:

  Bar? bar = new RawBar();

works, without errors or warnings...


the faq comes up with this:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ106 


and this:
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.html#FAQ310 


I find the argumentation rather mind-bending. And I still wonder how you 
can rationalize away that Foo.class returns a type that generates 
warnings if you  want to use it!


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


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

2008-06-02 Thread Sebastiaan van Erk

Hi,

But IMHO putting generics on Component is a bad design, since it per se 
touches all of Wicket's Components without urgent need.


I *really* would like to see a clarification of this statement. In 
Wicket the component and model are very tightly coupled. What is a *good 
design* alternative, where only IModel is generified? getModelObject() 
returns Object? getModel returns IModel??


Regards,
Sebastiaan




Best 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

2008-06-02 Thread 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? extends Page? 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]



-
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

2008-06-02 Thread 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 HashMapString, Integer()).


Just try to return one of your old (non-generified) HomePage.class 
classes (i.e., HomePage extends WebPage instead of HomePage extends 
WebPageVoid) 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? extends Page? 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]



-
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

2008-06-02 Thread 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

2008-06-02 Thread 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

2008-06-02 Thread 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

2008-06-02 Thread 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 ComponentM extends IModelT, 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: (Class? extends Page?) casting troubles

2008-05-22 Thread Sebastiaan van Erk

Jan Kriesten wrote:


Hi Johan,


ahh yes thats true i overlooked your changes..
then yes currently you have to do new LinkVoid (to get rid of the
warnings)


there are quite annoying many cases of this kind, where you really just 
don't need to add models to components and have to boilerplate these 
with Void or anything else.


So, I can really understand and support Martijns objections to have 
Component generified just for the sake of it.


Well, I'd hardly say it's just for the sake of it! It's *required* to 
*properly* generify Wicket. Due to the strong coupling in the design of 
Wicket of a component to a model, when you refer to a component you 
*must* specify the type of the model... Anything else is just plain bad 
(and strange) use of generics... :-(


If it's to clearify the API - make those cases generic or have them 
implement a different IModel (like ListModel e.g.).


I'm very much against using generics to do something other from what 
generics where meant to do (i.e., type safety).


Regards,
Sebastiaan


Best regards, --- Jan.



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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Sebastiaan van Erk

Jan Kriesten wrote:


hi johan,


But if you have a lot of LinkVoid for you cases
then make 1 simple subclass of Link


so anyone make your own wrapper to get readable sources again? let me 
think: how many webmarkupcontainer, link, page etc. classes do i use 
with void?


i don't think that's a serious option.


While LinkVoid is somewhat more verbose than Link, I seriously think 
that people are making too big a deal out of it. Is LinkVoid really 
that unreadable? Is it really that hard to code? Personally I think 
*adds* to the clarity; it says you're not going to use the model of the 
Link component.


Regards,
Sebastiaan


--- jan.



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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Sebastiaan van Erk

Jeremy Thomerson wrote:

I haven't said anything up to this point, but we really don't seem to be
getting anywhere with what is turning into a religious war.  I, for one,
have already started using 1.4, and love the generics, despite the extra
verbosity.  It gives me extra type safety and code self-documentation.  I
would be very against having the framework do a cast as has been suggested
on here, because that is a hack, and not useful for anything - I lose the
value of generics because the compiler is no longer checking my type safety
throughout the application.  If I came to a framework without previous
experience with it, and discovered that ugly hack, I would be worried about
the quality of all of the code.

I think that we should:
 - continue with 1.4-M2
 - create a wiki page where we can get one master list of  things we like
and don't like
 - see what we can do to address those

We're really not getting anywhere with this conversation until we have a
finite list, and some options for each con on the list.  Then we can either
choose the best options or say forget it.


I agree with the above points.

Furthermore, we're not really getting any idea about how the community 
feels about generics. A vocal minority speaks up. On the list, things 
tend to be biased towards the problems and not the things working well 
(the people happily going about their business without issues are less 
likely to be reading along and posting their experiences).


There were about 100 votes +1 *quick* generic release and I don't see 
very many complaints. Why not wait a bit, polish some of the rough edges 
and have a poll or something to ask the community how they feel...


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Sebastiaan van Erk

Martijn Dashorst wrote:

That is not my problem. The problem is that ComponentT is confusing
as hell and opens up the box of pandorra wrt generics. I *like*
IModelT but I fail to see how setResponsePage(? extends ? extends
?) is necessary for this. The only reason iirc to generify
component is to remove the casts for these two methods:

IModel getModel()
Object getModelObject()

I can live with having these methods not being generified.

Martijn


Ugh,

-1 (nonbinding of course ;-)) for me on that.

Almost all accesses to the model objects or models are via Component. If 
that one is gone, then in my opinion you might as well get rid of the 
IModel generics as well.


Plus as Johan said, with a half/half IModel-only approach you'll really 
have bunches of warnings to suppress.


Generics are hard, especially for library/framework designers: it's hard 
to get them exactly right, especially with wildcards in complex cases. 
But just because they are not currently exactly right yet in M1 seems no 
reason to throw them all overboard again...


Regards,
Sebastiaan




On Wed, May 21, 2008 at 11:36 AM, Peter Ertl [EMAIL PROTECTED] wrote:

Maybe this can help a little:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6384510
(verified with java 1.5 on mac os x leopard)


Am 21.05.2008 um 11:13 schrieb Martijn Dashorst:


On Wed, May 21, 2008 at 11:03 AM, Johan Compagner [EMAIL PROTECTED]
wrote:

if we drop that then we can pretty much drop also model

Not sure. I think having Component(String id, IModelT model) is a
good thing. However, generifying Component further to get rid of the
cast when doing getModelObject() or getModel() turns out not to be
great.


Because the model goes into the Component and gone is the generified
model.

I don't have a direct problem with that. The generics of Component are
really hard on the eye and the brain. We are trying to make things
simpler and clearer. Having Component(String id, IModelT model)
makes things clearer.


For example the DropDownChoice that is generified now makes sure that i
have
a lot less explaining to on this list..

Yes, I am not in favor of dropping DDC(String, IModelT,
IModelList? extends T). I am in favor of dropping the generics
from the Component class definition.


Martijn

-
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: (Class? extends Page?) casting troubles

2008-05-21 Thread Sebastiaan van Erk

Martijn Dashorst wrote:

On Wed, May 21, 2008 at 2:19 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Generics are hard, especially for library/framework designers: it's hard to
get them exactly right, especially with wildcards in complex cases. But just
because they are not currently exactly right yet in M1 seems no reason to
throw them all overboard again...


Not only for framework designers. *I* as a user of Wicket don't know
how to perform a setResponsePage() with the above code. This is not a
problem for framework designers. This is generics getting out of
control.


Well the fact that setResponsePage doesn't work with just a Page class 
seems to be an issue of the framework not the user (and yes it may be 
caused by an issue with generics, but in the end, the user of the 
framework should just be able to do: setResponsePage(MyPage.class) as 
they always did, and as is logical).



They make my code unreadable, hence unmaintainable. There is little
benefit of removing those 2 casts (where I never have had any
problems) compared to the UGLY stick that generified component smacks
on my code.


I agree that generics are overly verbose sometimes... but they give you 
back extra type safety. I guess whether you like this tradeoff or not is 
a personal choice (I like it, even though I would have preferred less 
verbose code and I hate erasure).



Generified component touches *ALL* code in Wicket, wether you care or
not. IModelT itself is rather contained.


Yes, but in my opinion rather useless as well. Plus you get heaps of 
@SuppressWarnings all over the place. Then just get rid of generics 
completely...


Regards,
Sebastiaan





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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Sebastiaan van Erk

Martijn Dashorst wrote:

On Wed, May 21, 2008 at 2:44 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Generified component touches *ALL* code in Wicket, wether you care or
not. IModelT itself is rather contained.

Yes, but in my opinion rather useless as well. Plus you get heaps of
@SuppressWarnings all over the place. Then just get rid of generics
completely...


It is not useless. It *documents* the API in a self describing manner,
without getting out of control, or without having to read fricking
LISP code.


Hmm.. I'm not really sure I find that a good argument. Documentation 
should be done by: 1) javadoc, 2) good naming conventions (IMHO). And 
where would you use the generics of IModel if you can't use getModel() 
on component? If I define a model I'd say:


class PersonModel implements IModelPerson {
}

but after that I'd be using the model with new PersonModel(...) and not 
referring to the generics at all...



The suppress warnings can be turned off by telling your compiler not to warn.


Yes, and that kills all other warnings which you LIKE to have in your 
own and other generics code! And all that to use Wicket without warnings!



And why would you need suppress warnings? Not for this:

Link link = new Link(link, personmodel) {
onclick() {
Person p = (Person)getModelObject();
}
};


You're right, not for that. But as soon as you use getModel() you do. 
Because it returns an IModel (which is a raw type, WARNING). Then you 
want to cast the model back to something useful (unchecked conversion, 
WARNING).



Typesafety through obscurity is not a direction I want Wicket to go.
It is already hard enough to learn Wicket's basics. With ComponentT
it gets too difficult.


Well I can't argue with where you want Wicket to go. :-) I like the 
generics, and have no problems with a few rough edges in M1. But I can 
understand that some people find it overly complex or verbose, and they 
are entitled to their opinions of course. If you guys decide to drop 
generics again, then I'll still use Wicket happily...


But please no half/half and forced turning of generics warnings to be 
able to use the framework properly!! :-)



Martijn


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Sebastiaan van Erk

Joni Freeman wrote:

On Wed, 2008-05-21 at 14:44 +0200, Sebastiaan van Erk wrote:

Martijn Dashorst wrote:

Generified component touches *ALL* code in Wicket, wether you care or
not. IModelT itself is rather contained.
Yes, but in my opinion rather useless as well. Plus you get heaps of 
@SuppressWarnings all over the place. Then just get rid of generics 
completely...


In which case would you need @SuppressWarnings? Consider for instance:

interface IModelT {
}

class Component {

private IModel? model;

public T IModelT getModel() {
return (IModelT) model;
}
}

class MyComp extends Component {

public MyComp() {
IModelInteger model = getModel();
}
}

This compiles and the only warning is within wicket code. There's an
unsafe cast to IModelT. Of course this would mean that getModel and
getModelObject could throw classcastexception. It's a tradeoff: simple
and more conservative usage of generics vs. fully type safe but complex
and verbose usage of generics.

Joni


That's pretty ok I guess, hadn't though of that. Better than returning a 
raw IModel. :-)


Does this always work nicely though, because you need to do a capture 
which means that the compiler must be able to infer the type... I've had 
problems before in these kind of situations that for me it seems 
obvious, but the compiler gives me an error and says it doesn't know 
what the type should be...


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: (Class? extends Page?) casting troubles

2008-05-21 Thread Sebastiaan van Erk

Johan Compagner wrote:

yes i also thought about some time ago.

But this is not really better... Now without you doing a cast in the code
(so that you know what you are doing)
you suddenly have a class cast exception at some point later on


class MyComp extends Component {
   public MyComp() {
   IModelInteger model = getModel();
   Integer myInt = model.getObject(); // KABOOM

   }

because this thing gives you really a false kind of protection.

This is really an abuse of generics if you ask me..


When I think about it, I have to agree. You can do ugly stuff like:

IModelInteger x = getModel();
IModelDouble y = getModel();

and it will compile just fine... :-(

I'd rather have no generics than a dirty hack like this.

Regards,
Sebastiaan



johan

On Wed, May 21, 2008 at 3:01 PM, Joni Freeman [EMAIL PROTECTED] wrote:


On Wed, 2008-05-21 at 14:44 +0200, Sebastiaan van Erk wrote:

Martijn Dashorst wrote:

Generified component touches *ALL* code in Wicket, wether you care or
not. IModelT itself is rather contained.

Yes, but in my opinion rather useless as well. Plus you get heaps of
@SuppressWarnings all over the place. Then just get rid of generics
completely...

In which case would you need @SuppressWarnings? Consider for instance:

   interface IModelT {
   }

   class Component {
   private IModel? model;

   public T IModelT getModel() {
   return (IModelT) model;
   }
   }

   class MyComp extends Component {
   public MyComp() {
   IModelInteger model = getModel();
   }
   }

This compiles and the only warning is within wicket code. There's an
unsafe cast to IModelT. Of course this would mean that getModel and
getModelObject could throw classcastexception. It's a tradeoff: simple
and more conservative usage of generics vs. fully type safe but complex
and verbose usage of generics.

Joni







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






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Using generics with some non-generic classes in Wicket

2008-05-15 Thread Sebastiaan van Erk

Igor Vaynberg wrote:

well, apparently johan ran into a situation where component? is too
restrictive...


As I understand it, Johan ran into a situation where Component? causes 
*warnings* for users who use raw types. Which I've been arguing all 
along that they SHOULD get: they should use ComponentObject or 
ComponentVoid instead of raw types, or live-with/suppress the warning.


To make it clear, I made the following test class:

public class TestT {

public void doTest(Test? extends Test? test) {
System.out.println(test);
}

public static void main(String[] args) {
TestTestInteger test1 = newInstance(); // fine - no 
warnings.
TestTest test2 = newInstance(); // not fine, use of raw type, 
warning
Test test3 = newInstance(); // not fine, use of raw type, 
warning

test1.doTest(test1); // fine - no warnings.
		test1.doTest(test2); // error - generic types don't match, can be 
fixed by line below

test1.doTest((Test) test2); // warning - unchecked conversion
test1.doTest(test3); // warning - unchecked conversion
}

public static T TestT newInstance() {
return new TestT();
}
}

As you can see, there is only one case when you get a compile error when 
using the ? extends Test? generic type, and that is a case where 
there is on the user side an incorrect generic type: TestTest. The 
user here declares he's using generics, but then inserts a raw type of a 
known generic type - a situation that should not happen.


Regards,
Sebastiaan


-igor


On Wed, May 14, 2008 at 2:37 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Igor Vaynberg wrote:

since then the thread has evolved into whether or not we should use ?
extends Component or ? extends Component?

-igor

I don't understand how that changes any of my points. The first is incorrect
(from a generics point of view) since you're referencing an unparameterized
generic type.

So the second gives warnings only in code that is not properly generified...

Regards,
Sebastiaan



On Wed, May 14, 2008 at 1:54 PM, Sebastiaan van Erk [EMAIL PROTECTED]
wrote:

Igor Vaynberg wrote:


i do like generics. did i ever say otherwise? the problem here is that
if we scope something as Class? extends Component then even though
you ARE using generics in your code you will still get a warning
because we did not scope the class as Class? extends Component?.

on the other hand if we do scope it as Class? extends Component?
then you can no longer pass a raw reference when calling the function.

But that's exactly the point isn't it? If you're using generics then you
shouldn't be using raw Components anymore...


so we are screwed if we do and we are screwed if we dont, i expected
generics to be better.

Well they definitely could have been better (erasure is terrible if you
ask
me), but I don't see what's wrong in this case. It warns you if you
should
be using a parameterized type but you don't.


And especially if you look at the vote result, I think the majority
wants
the generics...

that vote was before we uncovered this issue. we voted on the idea of
generics, not on the implementation.

That's true, but I wonder if this issue would change the vote much. I
don't
really understand why it's an issue, because you can use generified
Components always: ComponentObject if you don't want to constrain the
model object, and ComponentVoid if you don't need a model.

The question that started the thread was about StringResourceModel which
was
not yet generified, and in that case, the warning seems to me to be
perfectly ok: it just says StringResourceModel should be generified. It's
not a release yet, so that some users who use the current snapshot run
into
these kind of warnings which cannot be removed seems to be fine to me...

Regards,
Sebastiaan



-
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: Using generics with some non-generic classes in Wicket

2008-05-14 Thread Sebastiaan van Erk
My post kind of missed the point, I shouldn't post when I'm already half 
asleep. :-)


Obviously MarkupContainerObject satisfies the MarkupContainer? in a 
method argument, so it accepts the raw type. However, it generates a 
warning because the method says it's generified, so you should be using 
the generic type.


Johan Compagner wrote:

I dont care, because i cant do any thing with the ? The only thing it
enforces is that it must now be a generic class which is annoying. Not
to mention that in that area eclipse and javac accept different
things


The reason it warns you to use generics when generics are wanted is 
because Sun wants to be able to make it *required* (in a future release) 
to use generics where generics are wanted; at least, so I read... I 
think in the real world they wouldn't dare to do this because it would 
piss off so many users and break so much stuff. :-)


But the idea is that if something is generified you should be using a 
type parameter, and using a raw type is *purely* for backwards 
compatibility with legacy code.


Regards,
Sebastiaan


So or we in wicket dont use ? any where and have supress warning
everywhere for that or we do use it and then suddenly it is in my eyes
restricted to much.


I don't understand


On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Johan Compagner wrote:

yes thats the reason

you are calling the method add with a generified component but that
container itself is not generified

i dont like this about generics expecially the onces like this:

add(MarkupContainer? container)

then suddenly a none generified component cant be added...
thats really stupid ? should mean anything.. including none generics

No, that's not correct. For example, List? is much more restrictive
than a raw List (which is a ListObject). To a raw list you can add an
instance of any type whatever, i.e., list.add(new Object()). But in
List? the ? is a wildcard which says it could be any type there, i.e.,
it could be a ListInteger. But you can't add a new Object() to a
ListInteger!

Thus MarkupContainer? means MarkupContainer parameterized by some
unknown type, and *not* MarkupContainer parameterized by Object, which
is what the raw type means.

Regards,
Sebastiaan


johan


On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
wrote:


I have one idea,

the reason of the warnigs is, that parent of AjaxPagingNavigator is
PagingNavigator,
which has parent Panel --- that is not parameterized.

The same problem is with LoopItem, which extends the
WebMarkupContainer --- that is not parameterized.

? could this be the reason ?






Stefan Simik wrote:

Mhmm, it is meaningful ;) I will know in future, thx

One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.

Example:  I have a simple AjaxPagingNavigator, to which I add a simple
ListView
---
ListViewInteger menu = new ListViewInteger(id, numbers){
//populate metods
}
add(menu);//warning here

The warning says:
Type safety: The method add(Component...) belongs to the raw type
MarkupContainer.
References to generic type MarkupContainerT should be parameterized

I cannot find out, what's the warning reason, because ListView self is
parameterized.



--
View this message in context:


http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.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]



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Using generics with some non-generic classes in Wicket

2008-05-14 Thread Sebastiaan van Erk

Igor Vaynberg wrote:

then our users have to suppress warnings in their code, which is
unacceptable at least to me. the whole generics thing turned out to be
quiet a lot crappier then i thought it would.


I actually like having the generics better than not having it. In both 
cases sometimes it's a pain: generics is verbose, non-generics you have 
to use typecasts all the time and a bunch of errors are delayed to runtime.


What I don't really understand is, if you don't like generics, why can't 
you just tell the compiler to ignore the warnings? I mean, in Java 5 
generics is just not really optional, not in the JDK libs either - if 
you ignore generics there you get warnings as well; so there too, it's 
the user's burden to bear.


And especially if you look at the vote result, I think the majority 
wants the generics...


Regards,
Sebastiaan



-igor


On Wed, May 14, 2008 at 12:48 PM, Johan Compagner [EMAIL PROTECTED] wrote:

yes then all the call to that method must be of a generic type.
cant be raw

i dont know what are we going to do in wicket i think we should decide it
should we just where we dont care about generic delete/not use the ? and
then
supresswarning?

johan


On Wed, May 14, 2008 at 9:45 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:


so i just implemented IAuthorizationStrategy and on this line in my class:

public boolean isInstantiationAuthorized(Class ? extends Component
componentClass)

i get: Component is a raw type. References to generic type
ComponentT should be parameterized

so that means we have to change our sig to ? extends Component?
but then we are back to the problem described in this thread.

generics suck.

-igor

On Wed, May 14, 2008 at 12:12 AM, Johan Compagner [EMAIL PROTECTED]
wrote:

I dont think that user gets a warning if a param is of raw type. But
we have a warning there.
The problem is that for example MarkupContainer.add(Component) or
IVisitor.visit(Component) i dont care what component is put in
generified or not.
In add it really doesnt matter because we dont do anything with it.
With visitor it is different because the user could use it inside the
method. But it should be useable without warnings for generified and
none generfied components..


On 5/14/08, Igor Vaynberg [EMAIL PROTECTED] wrote:

if we have a signature that accepts a raw type, will that also cause a
warning in user's code?

also having those suppress annotations practically _everywhere_ will be
annoying

-igor


On Tue, May 13, 2008 at 11:56 PM, Johan Compagner [EMAIL PROTECTED]
wrote:

I dont care, because i cant do any thing with the ? The only thing it
 enforces is that it must now be a generic class which is annoying.

Not

 to mention that in that area eclipse and javac accept different
 things

 So or we in wicket dont use ? any where and have supress warning
 everywhere for that or we do use it and then suddenly it is in my

eyes

 restricted to much.



 On 5/14/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
  Johan Compagner wrote:
   yes thats the reason
  
   you are calling the method add with a generified component but

that

   container itself is not generified
  
   i dont like this about generics expecially the onces like this:
  
   add(MarkupContainer? container)
  
   then suddenly a none generified component cant be added...
   thats really stupid ? should mean anything.. including none

generics

 
  No, that's not correct. For example, List? is much more

restrictive

  than a raw List (which is a ListObject). To a raw list you can

add an

  instance of any type whatever, i.e., list.add(new Object()). But in
  List? the ? is a wildcard which says it could be any type there,

i.e.,

  it could be a ListInteger. But you can't add a new Object() to a
  ListInteger!
 
  Thus MarkupContainer? means MarkupContainer parameterized by

some

  unknown type, and *not* MarkupContainer parameterized by Object,

which

  is what the raw type means.
 
  Regards,
  Sebastiaan
 
   johan
  
  
   On Tue, May 13, 2008 at 5:55 PM, Stefan Simik

[EMAIL PROTECTED]

   wrote:
  
   I have one idea,
  
   the reason of the warnigs is, that parent of AjaxPagingNavigator

is

   PagingNavigator,
   which has parent Panel --- that is not parameterized.
  
   The same problem is with LoopItem, which extends the
   WebMarkupContainer --- that is not parameterized.
  
   ? could this be the reason ?
  
  
  
  
  
  
   Stefan Simik wrote:
   Mhmm, it is meaningful ;) I will know in future, thx
  
   One of the last occuring warning is, when working with
   MarkupContainer#add(...)  or  #addOrReplace(...)  method.
  
   Example:  I have a simple AjaxPagingNavigator, to which I add a

simple

   ListView
  

---

   ListViewInteger menu = new ListViewInteger(id, numbers){
   //populate metods
   }
   add(menu);//warning here
  
   The warning says:
   Type safety: The method add(Component...) belongs

Re: Using generics with some non-generic classes in Wicket

2008-05-14 Thread Sebastiaan van Erk

Igor Vaynberg wrote:


i do like generics. did i ever say otherwise? the problem here is that
if we scope something as Class? extends Component then even though
you ARE using generics in your code you will still get a warning
because we did not scope the class as Class? extends Component?.

on the other hand if we do scope it as Class? extends Component?
then you can no longer pass a raw reference when calling the function.


But that's exactly the point isn't it? If you're using generics then you 
shouldn't be using raw Components anymore...



so we are screwed if we do and we are screwed if we dont, i expected
generics to be better.


Well they definitely could have been better (erasure is terrible if you 
ask me), but I don't see what's wrong in this case. It warns you if you 
should be using a parameterized type but you don't.



And especially if you look at the vote result, I think the majority wants
the generics...


that vote was before we uncovered this issue. we voted on the idea of
generics, not on the implementation.


That's true, but I wonder if this issue would change the vote much. I 
don't really understand why it's an issue, because you can use 
generified Components always: ComponentObject if you don't want to 
constrain the model object, and ComponentVoid if you don't need a model.


The question that started the thread was about StringResourceModel which 
was not yet generified, and in that case, the warning seems to me to be 
perfectly ok: it just says StringResourceModel should be generified. 
It's not a release yet, so that some users who use the current snapshot 
run into these kind of warnings which cannot be removed seems to be fine 
to me...


Regards,
Sebastiaan



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Using generics with some non-generic classes in Wicket

2008-05-14 Thread Sebastiaan van Erk

Igor Vaynberg wrote:

since then the thread has evolved into whether or not we should use ?
extends Component or ? extends Component?

-igor


I don't understand how that changes any of my points. The first is 
incorrect (from a generics point of view) since you're referencing an 
unparameterized generic type.


So the second gives warnings only in code that is not properly generified...

Regards,
Sebastiaan




On Wed, May 14, 2008 at 1:54 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Igor Vaynberg wrote:


i do like generics. did i ever say otherwise? the problem here is that
if we scope something as Class? extends Component then even though
you ARE using generics in your code you will still get a warning
because we did not scope the class as Class? extends Component?.

on the other hand if we do scope it as Class? extends Component?
then you can no longer pass a raw reference when calling the function.

But that's exactly the point isn't it? If you're using generics then you
shouldn't be using raw Components anymore...


so we are screwed if we do and we are screwed if we dont, i expected
generics to be better.

Well they definitely could have been better (erasure is terrible if you ask
me), but I don't see what's wrong in this case. It warns you if you should
be using a parameterized type but you don't.


And especially if you look at the vote result, I think the majority wants
the generics...

that vote was before we uncovered this issue. we voted on the idea of
generics, not on the implementation.

That's true, but I wonder if this issue would change the vote much. I don't
really understand why it's an issue, because you can use generified
Components always: ComponentObject if you don't want to constrain the
model object, and ComponentVoid if you don't need a model.

The question that started the thread was about StringResourceModel which was
not yet generified, and in that case, the warning seems to me to be
perfectly ok: it just says StringResourceModel should be generified. It's
not a release yet, so that some users who use the current snapshot run into
these kind of warnings which cannot be removed seems to be fine to me...

Regards,
Sebastiaan




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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Using generics with some non-generic classes in Wicket

2008-05-13 Thread Sebastiaan van Erk

Johan Compagner wrote:

yes thats the reason

you are calling the method add with a generified component but that
container itself is not generified

i dont like this about generics expecially the onces like this:

add(MarkupContainer? container)

then suddenly a none generified component cant be added...
thats really stupid ? should mean anything.. including none generics


No, that's not correct. For example, List? is much more restrictive 
than a raw List (which is a ListObject). To a raw list you can add an 
instance of any type whatever, i.e., list.add(new Object()). But in 
List? the ? is a wildcard which says it could be any type there, i.e., 
it could be a ListInteger. But you can't add a new Object() to a 
ListInteger!


Thus MarkupContainer? means MarkupContainer parameterized by some 
unknown type, and *not* MarkupContainer parameterized by Object, which 
is what the raw type means.


Regards,
Sebastiaan


johan


On Tue, May 13, 2008 at 5:55 PM, Stefan Simik [EMAIL PROTECTED]
wrote:


I have one idea,

the reason of the warnigs is, that parent of AjaxPagingNavigator is
PagingNavigator,
which has parent Panel --- that is not parameterized.

The same problem is with LoopItem, which extends the
WebMarkupContainer --- that is not parameterized.

? could this be the reason ?






Stefan Simik wrote:

Mhmm, it is meaningful ;) I will know in future, thx

One of the last occuring warning is, when working with
MarkupContainer#add(...)  or  #addOrReplace(...)  method.

Example:  I have a simple AjaxPagingNavigator, to which I add a simple
ListView
---
ListViewInteger menu = new ListViewInteger(id, numbers){
//populate metods
}
add(menu);//warning here

The warning says:
Type safety: The method add(Component...) belongs to the raw type
MarkupContainer.
References to generic type MarkupContainerT should be parameterized

I cannot find out, what's the warning reason, because ListView self is
parameterized.



--
View this message in context:
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-tp17208928p17212015.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]






smime.p7s
Description: S/MIME Cryptographic Signature


Re: unmount sub url

2008-05-09 Thread Sebastiaan van Erk

I made a JIRA for this (with patch).

https://issues.apache.org/jira/browse/WICKET-1603

Regards,
Sebastiaan

Sebastiaan van Erk wrote:

Eelco Hillenius wrote:
On Thu, May 8, 2008 at 3:15 PM, Sebastiaan van Erk 
[EMAIL PROTECTED] wrote:

2) using a special RequestCodingStrategy, i.e.
UnmountedRequestCodingStrategy and tweaking isWicketRequest to return 
false

if it detects this request coding strategy...

What do you guys think?


Well, my first impulse is to say that mounting was never meant to
serve complex cases, and that instead of mounting you'd do best with a
custom request coding strategy instead.

That said though, I'm not against something like 2 if we have a nice
construct for it.

Eelco


I made a proof of concept which works, though I have some questions 
about it (I'm not really into the whole request coding strategy API). 
Basically what I did was:


1) Add PassThroughUrlCodingStrategy:

public class PassThroughUrlCodingStrategy extends 
AbstractRequestTargetUrlCodingStrategy

{
public PassThroughUrlCodingStrategy(final String mountPath) {
super(mountPath);
}

public IRequestTarget decode(RequestParameters requestParameters) {
return null;
}

public CharSequence encode(IRequestTarget requestTarget) {
return null;
}

public boolean matches(IRequestTarget requestTarget) {
return false;
}
}

That's the one I have questions about: I'm not quite sure how to 
implement these methods properly.


2) Modify wicket filter isWicketRequest

// Mounted page
IRequestTargetUrlCodingStrategy urlCodingStrategy = 
webApplication.getRequestCycleProcessor()

.getRequestCodingStrategy()
.urlCodingStrategyForPath(relativePath);

// Mounted and not pass through?
return urlCodingStrategy != null 
!(urlCodingStrategy instanceof PassThroughUrlCodingStrategy);

3) Mount my PassThroughUrlCodingStrategy in my Application.init() method:

mount(new QueryStringUrlCodingStrategy(/path1, MyPage.class));
mount(new PassThroughUrlCodingStrategy(/path1/dir));

4) Fired up tomcat and tested it. :-) It works...

That leaves me with the questions about the decode, encode and 
matches... How should I implement them properly? :-)


Regards,
Sebastiaan



smime.p7s
Description: S/MIME Cryptographic Signature


unmount sub url

2008-05-08 Thread Sebastiaan van Erk

Hi,

I've got a page mounted on /path1.

I've got some files in a directory in my webapp root on /path1/dir

How can I tell Wicket to give control back to the servlet container for 
dir? Currently (even using QueryStringUrlCodingStrategy) the mount eats 
/path1/dir and doesn't let me access the files there...


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: unmount sub url

2008-05-08 Thread Sebastiaan van Erk

 Hi,

 I've got a page mounted on /path1.

 I've got some files in a directory in my webapp root on /path1/dir

 How can I tell Wicket to give control back to the servlet container for
 dir? Currently (even using QueryStringUrlCodingStrategy) the mount eats
 /path1/dir and doesn't let me access the files there...

 Regards,
 Sebastiaan

I looked at the wicket filter code, and it does not seem that this is 
possible at the moment (though I might be missing something). I see at 
least two possible ways to add this feature:


1) using a special exception (I did not think about the name):

if (isWicketRequest(relativePath))
{
try
{
...
}
catch (NotWicketAfterAllException e) {
// Pass down the filter chain.
chain.doFilter(request, response);
}
finally
{
// always unset the application thread local
Application.unset();
RequestContext.unset();
}
}

2) using a special RequestCodingStrategy, i.e. 
UnmountedRequestCodingStrategy and tweaking isWicketRequest to return 
false if it detects this request coding strategy...


The first solution is more powerful (it allows you to pass the request 
down the filter chain from pretty much anywhere), but it might be a bit 
dangerous (what if you already read from the request/response, etc), and 
it requires your own request strategy implementation to check if it 
happens to be an url that you want to pass down the filter chain which 
usually ends up being ugly string compares)...


The second solution is cleaner in my opinion and it would allow you to 
unmount or mount as a pass through specific urls...


What do you guys think?

Regards,
Sebastiaan

Sebastiaan van Erk wrote:



smime.p7s
Description: S/MIME Cryptographic Signature


Re: unmount sub url

2008-05-08 Thread Sebastiaan van Erk

Eelco Hillenius wrote:

On Thu, May 8, 2008 at 3:15 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

2) using a special RequestCodingStrategy, i.e.
UnmountedRequestCodingStrategy and tweaking isWicketRequest to return false
if it detects this request coding strategy...

What do you guys think?


Well, my first impulse is to say that mounting was never meant to
serve complex cases, and that instead of mounting you'd do best with a
custom request coding strategy instead.

That said though, I'm not against something like 2 if we have a nice
construct for it.

Eelco


I made a proof of concept which works, though I have some questions 
about it (I'm not really into the whole request coding strategy API). 
Basically what I did was:


1) Add PassThroughUrlCodingStrategy:

public class PassThroughUrlCodingStrategy extends 
AbstractRequestTargetUrlCodingStrategy

{
public PassThroughUrlCodingStrategy(final String mountPath) {
super(mountPath);
}

public IRequestTarget decode(RequestParameters requestParameters) {
return null;
}

public CharSequence encode(IRequestTarget requestTarget) {
return null;
}

public boolean matches(IRequestTarget requestTarget) {
return false;
}
}

That's the one I have questions about: I'm not quite sure how to 
implement these methods properly.


2) Modify wicket filter isWicketRequest

// Mounted page
IRequestTargetUrlCodingStrategy urlCodingStrategy = 
webApplication.getRequestCycleProcessor()

.getRequestCodingStrategy()
.urlCodingStrategyForPath(relativePath);

// Mounted and not pass through?
return urlCodingStrategy != null 
!(urlCodingStrategy instanceof PassThroughUrlCodingStrategy);

3) Mount my PassThroughUrlCodingStrategy in my Application.init() method:

mount(new QueryStringUrlCodingStrategy(/path1, MyPage.class));
mount(new PassThroughUrlCodingStrategy(/path1/dir));

4) Fired up tomcat and tested it. :-) It works...

That leaves me with the questions about the decode, encode and 
matches... How should I implement them properly? :-)


Regards,
Sebastiaan



smime.p7s
Description: S/MIME Cryptographic Signature


Re: VOTE: Generics of IDataProvider

2008-04-24 Thread Sebastiaan van Erk

[ ] IDataProviderI,T
[X] IteratorIModelT , drop model
[ ] Leave as is.

Regards,
Sebastiaan

Jan Kriesten wrote:


Hi,

I have a usecase where the current proposed generic Interface for 
IDataProvider with upcoming v1.4 of Wicket would break the 
implementation concept working with Wicket 1.3. The usecase needs 
different types for iterator + model. Example and explanation are found 
below the vote:


VOTE:

[ ] IDataProviderI,T
[ ] IteratorIModelT , drop model
[ ] Leave as is.


Example:
new IDataProviderInteger, Topics {
  public IteratorInteger iterator( int first, int count ) { 
getForum().getTopics( first, count ); }


  public int size() { getForum().getTopicsCount(); }

  public IModelTopics model( Integer id ) { return new 
TopicsDetachableModel( id ); }

 }

The current proposed IDataProviderT would enforce model + iterator to 
be of the same type, resulting in the above not working without hassle. 
I.e. either to work without type safetey (always use Object to comply), 
or wrapping/querying the type within iterator + model (which could cause 
time consuming lookups when remote services are involved).


To get around this, there are 2 solutions:

- drop the 'model' method and have iterator return an IteratorIModelT

That would fit this usecase since the Model could just be wrapped within 
iterator and no extra lookups would be necessary. Implementation code of 
iterator might get a bit uglier, though.


- add a second type as shown with example above

Would lead to redundant type definitions for many usecases where 
iterator + model actually return the same type.



I'd really like to see support for generics with these cases as well.

Best regards, --- Jan.

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



smime.p7s
Description: S/MIME Cryptographic Signature


Localization, Bookmarkable pages, and mounting strategies

2008-04-14 Thread Sebastiaan van Erk

Hi,

I have localized my Wicket site, but I have a problem with localization 
+ (mounted) bookmarkable pages.


When mounting a bookmarkable page:

mount(new WhateverUrlCodingStrategy(/mypage, MyPage.class));

there is no locale parameter...

This means:

1) I cannot give my stateless pages of different locales different URLs, 
which means that nobody can link directly to a non-default locale 
version of the page.


2) My stateless pages are impossible to index in different locales. 
Google either finds only the default locale pages, or must follow a 
stateful change locale link, which will cause it to index pages which 
will be expired by the time they're in Google's search results.


I know that I can make my own workaround, i.e., write my own url coding 
strategy with the locale in the root, /en/mypage to the english version, 
/mypage to the default locale, etc.. Or I could use 
IndexedParameterCodingStrategy to make the first parameter the locale 
(although this does not work if I want to use another coding strategy).


However they're still workarounds for something that I think is 
conceptually not quite right in Wicket currently: the fact that it 
should be possible to mount different locales of a page on different 
urls, for *whatever* coding strategy I choose to use.


Any ideas on this? Anybody already implemented the coding strategy for 
the locale in the root? Anybody got another easier workaround?


Regards,
Sebastiaan



smime.p7s
Description: S/MIME Cryptographic Signature


DynamicWebResource filename

2008-04-14 Thread Sebastiaan van Erk

Hi,

Any reason why the filename field in DynamicWebResource does not at 
least have a protected getter so you can use it in subclasses without 
having to add the field again?


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Localization, Bookmarkable pages, and mounting strategies

2008-04-14 Thread Sebastiaan van Erk

Gwyn Evans wrote:

On Mon, Apr 14, 2008 at 11:40 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:


 However they're still workarounds for something that I think is
conceptually not quite right in Wicket currently: the fact that it should be
possible to mount different locales of a page on different urls, for
*whatever* coding strategy I choose to use.


I suspect that it's just that the default behaviour (automatically
using the user's locale to return the locale-specific page) covers the
majority of requirements  no-one's raised an issue to modify the url
coding strategies, let alone contributed code!  A quick search back on
the list suggested something similar had been asked by various people
a couple of times before, but it's not clear if anything was then
coded or if they found a different approach.


Yes, I did the search as well, and saw nobody with a clear answer on how 
they went about it. The best approach I saw on the list was getting the 
locale from the root part of the URL, but I'm not that deep into wicket 
that I'd know how to go about building that in a proper way.



Note that even if you think you can't contribute code for one reason
or another, an discussion here followed by a JIRA issue with specific
use-cases will mean it's not forgotten, at least.


It does seem unlogical to me that you would *mount* different versions 
of a resource on a single URL, so I'll open a JIRA on it.




/Gwyn




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Localization, Bookmarkable pages, and mounting strategies

2008-04-14 Thread Sebastiaan van Erk

Johan Compagner wrote:

So when you do this:

mount(new WhateverUrlCodingStrategy(/mypage, MyPage.class, Locale.NL));

then when i hit

/mypage

we have to set the sessions locale to NL then?


I don't think so. The *resource* has the specified locale, i.e., the 
Page, but I think it's bad to have as side effect that the session's 
locale is suddenly changed.


I realize this introduces other issues... what happens with a Link to 
another page class? It should use the Page locale, not the session 
locale... So a component uses its locale, or its parent locale, or its 
parent's parent, etc, and if Page doesn't have a locale, THEN the 
session locale...


But I don't know the inner workings of Wicket's localization, nor have I 
thought long and hard about this yet, so I don't know if any of this 
make sense...


I just think it's weird that I cannot mount 2 locales of a page on two 
different paths... leading to the crawler and reference issues I 
mentioned before... What the best solution is, is probably something 
that needs to be discussed further. :-)


Regards,
Sebastiaan



Regards,
Sebastiaan


johan


On Mon, Apr 14, 2008 at 12:40 PM, Sebastiaan van Erk [EMAIL PROTECTED]
wrote:


Hi,

I have localized my Wicket site, but I have a problem with localization +
(mounted) bookmarkable pages.

When mounting a bookmarkable page:

   mount(new WhateverUrlCodingStrategy(/mypage, MyPage.class));

there is no locale parameter...

This means:

1) I cannot give my stateless pages of different locales different URLs,
which means that nobody can link directly to a non-default locale version of
the page.

2) My stateless pages are impossible to index in different locales. Google
either finds only the default locale pages, or must follow a stateful
change locale link, which will cause it to index pages which will be
expired by the time they're in Google's search results.

I know that I can make my own workaround, i.e., write my own url coding
strategy with the locale in the root, /en/mypage to the english version,
/mypage to the default locale, etc.. Or I could use
IndexedParameterCodingStrategy to make the first parameter the locale
(although this does not work if I want to use another coding strategy).

However they're still workarounds for something that I think is
conceptually not quite right in Wicket currently: the fact that it should be
possible to mount different locales of a page on different urls, for
*whatever* coding strategy I choose to use.

Any ideas on this? Anybody already implemented the coding strategy for the
locale in the root? Anybody got another easier workaround?

Regards,
Sebastiaan






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Localization, Bookmarkable pages, and mounting strategies

2008-04-14 Thread Sebastiaan van Erk

Hi Jan,

Would you be willing to share that code? Because in the short term I 
think it's the best solution.


Regards,
Sebastiaan

Jan Kriesten wrote:


hi sebastiaan,

Any ideas on this? Anybody already implemented the coding strategy for 
the locale in the root? Anybody got another easier workaround?


i don't use a coding strategy for this but an extension to wicket filter 
that parses the 'relative path' of the url for locale definitions, 
strips them and sets a locale-attribute to the application.


e.g.:

http://my.host.de/app/en/mymount/ -- /mymount/ with locale 'en'
http://my.host.de/app/pt/mymount/ -- /mymount/ with locale 'pt'

best regards, --- jan.



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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Localization, Bookmarkable pages, and mounting strategies

2008-04-14 Thread Sebastiaan van Erk

Hmm.. Scala :-)

I guess I'll opt for English then :-)

I don't quite understand what you do... taking it out of the filter is 
easy enough I guess, but then? When you set a property on the 
application how does this work with different threads? Do you use thread 
local? Then you do you render the selected page in the specified locale?


Regards,
Sebastiaan

Jan Kriesten wrote:


hi sebastiaan,

Would you be willing to share that code? Because in the short term I 
think it's the best solution.


it's all Scala - if you want that... ;-)

best regards, --- jan.




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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Localization, Bookmarkable pages, and mounting strategies

2008-04-14 Thread Sebastiaan van Erk

Johan Compagner wrote:

The problem is that a component has not a locale by default
So then we should give a Page a locale field.
and then that will be set..

But the problem is

if you do setResponsePage(Page.class)

what should then be taken? The session locale mount?


The most logical thing to me seems to be the result of getLocale(), because:

1) if the locale in the page is explicitly set, that means you're 
browsing the site explicitly in the selected locale... This seems 
logical to me: if you reqeuest the english version of a page through a 
bookmarkable link, then it would be weird if the next page you go to is 
suddenly in German, even if your session locale is German...


2) if it is not explicitly the session locale should be used...

Regards,
Sebastiaan


johan


On Mon, Apr 14, 2008 at 6:14 PM, Sebastiaan van Erk [EMAIL PROTECTED]
wrote:


Johan Compagner wrote:


So when you do this:

mount(new WhateverUrlCodingStrategy(/mypage, MyPage.class,
Locale.NL));

then when i hit

/mypage

we have to set the sessions locale to NL then?


I don't think so. The *resource* has the specified locale, i.e., the Page,
but I think it's bad to have as side effect that the session's locale is
suddenly changed.

I realize this introduces other issues... what happens with a Link to
another page class? It should use the Page locale, not the session locale...
So a component uses its locale, or its parent locale, or its parent's
parent, etc, and if Page doesn't have a locale, THEN the session locale...

But I don't know the inner workings of Wicket's localization, nor have I
thought long and hard about this yet, so I don't know if any of this make
sense...

I just think it's weird that I cannot mount 2 locales of a page on two
different paths... leading to the crawler and reference issues I mentioned
before... What the best solution is, is probably something that needs to be
discussed further. :-)

Regards,
Sebastiaan



Regards,
Sebastiaan


 johan


On Mon, Apr 14, 2008 at 12:40 PM, Sebastiaan van Erk 
[EMAIL PROTECTED]
wrote:

 Hi,

I have localized my Wicket site, but I have a problem with
localization +
(mounted) bookmarkable pages.

When mounting a bookmarkable page:

  mount(new WhateverUrlCodingStrategy(/mypage, MyPage.class));

there is no locale parameter...

This means:

1) I cannot give my stateless pages of different locales different
URLs,
which means that nobody can link directly to a non-default locale
version of
the page.

2) My stateless pages are impossible to index in different locales.
Google
either finds only the default locale pages, or must follow a stateful
change locale link, which will cause it to index pages which will be
expired by the time they're in Google's search results.

I know that I can make my own workaround, i.e., write my own url
coding
strategy with the locale in the root, /en/mypage to the english
version,
/mypage to the default locale, etc.. Or I could use
IndexedParameterCodingStrategy to make the first parameter the locale
(although this does not work if I want to use another coding
strategy).

However they're still workarounds for something that I think is
conceptually not quite right in Wicket currently: the fact that it
should be
possible to mount different locales of a page on different urls, for
*whatever* coding strategy I choose to use.

Any ideas on this? Anybody already implemented the coding strategy for
the
locale in the root? Anybody got another easier workaround?

Regards,
Sebastiaan







smime.p7s
Description: S/MIME Cryptographic Signature


Re: Redirect after post Issue

2008-03-21 Thread Sebastiaan van Erk
Looking at your mod_proxy config again I noticed that you are using 
ProxyPreserveHost on. I think this is causing the problems, you should 
remove this directive.


What I think is happening is this:

1) Wicket says: redirect to /web/
2) Tocmat makes the url absolute by prepending the virtual host. Since 
you have ProxyPreserveHost on, tomcat sees the virtual host as 
localhost and NOT localhost:8080, and returns 
http://localhost/web/xxx as the new lcoation.
3) Apache mod_proxy does NOT reverse proxy the url, because it does not 
have the :8080 on it and does not match your rule.


If you remove the ProxyPreserveHost on, tomcat will return 
http://localhost:8080/web/x as the redirect location and Apache will 
reverse proxy it.


The only downside of this is that your wicket app will not know the REAL 
virtual host, and so automatically generated absolute URL's (for example 
in emails) will be wrong.


Regards,
Sebastiaan

Sebastiaan van Erk wrote:

Hi,

Jeremy Levy wrote:
I have been having trouble with this for a couple of months, it seems 
that
redirects in Wicket 1.3.x seem to be writing out the URL incorrectly 
in our

set up.

We are running JBoss 4.2 with embedded Tomcat 5.5 using Apache/2.2.4 with
mod_proxy.

The Tomcat URL for the application is http://localhost:8080/web/

The Apache URL for the application is http://localhost

For the most part the site works well when accessed via Apache (and
perfectly directly via Tomcat), except on links/urls that involve 
(from what

I can tell) a redirect from Wicket.  These redirect the users browser to
/web/ which shouldn't happen from infront of the proxy.


 From what I can tell your mod_proxy config looks correct, you could 
check the log to see what it's doing. But Wicket redirecting you to 
/web/ is perfectly fine, as far as Wicket is concerned, that's where 
the site is at! It seems that mod_proxy is not properly reverse proxying 
the redirect...


Regards,
Sebastiaan


Examples of this are:

1. Form submits (they go through, but the next page is requested with the
/web in the url)
2. Redirects from Application.getHomePage()
3. Any use of RestartResponseAtInterceptPageException
4. setResponsePage(MyPage.class) inside of an
Link.onClick(BookmarkablePageLink works fine to the same page)

Further evidence that this is a bug is that if I set my application to
IRequestCycleSettings.ONE_PASS_RENDER everything works perfectly but with
both IRequestCycleSettings.REDIRECT_TO_BUFFER and
IRequestCycleSettings.REDIRECT_TO_RENDER it fails.

Our mod_proxy / virtualhost configuration:

VirtualHost *
ServerAdmin [EMAIL PROTECTED]
ServerAlias localhost

ServerSignature On

DocumentRoot /var/www

ProxyRequests Off

Proxy *
Order deny,allow
Allow from all
/Proxy

RewriteEngine on

RewriteLog /var/log/apache2/rewrite.log
RewriteLogLevel 2

ProxyPass / http://localhost:8080/web/
ProxyPassReverse / http://localhost:8080/web/
ProxyPassReverseCookiePath  /web /
ProxyPreserveHost On

ErrorLog /var/log/apache2/error.log
LogLevel warn
/VirtualHost

I'm not 100% sure that the mod_proxy configuration is correct, but 
I've read
all the articles on this list about it as well as the wiki page and 
have run

out of ideas to mess with.

Any help is appreciated.

Jeremy



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Display of own message in FeedbackPanel

2008-03-21 Thread Sebastiaan van Erk
This is elementary Java... you should probably use an IDE like eclipse, 
works much better than finding errors later on with a build tool like 
ant. You're declaring a method and you don't declare it's return type... 
add the workd void before validate... the compiler gives you the exact 
location of the problem...


Regards,
Sebastiaan

Fabien D. wrote:

Thank you all for your help,

There is no problem for the password, but now I'm trying to create my own
validator. I have a problem during compilation (with ant).

I have done this :

email.add(new IValidator() {
validate(IValidatable v) {
if ( !CDataVerification.validEmail( 
(String)v.getvalue() ) )
	v.add(new ValidationError().addMessageKey(error)); 
			} 
		});


where CDataVerification.validEmail is a method to check if it's a correct
email ( with @, . , ...), in input a string and in output a boolean.

During compilation, I have this message : invalid method declaration; return
type required  validate(IValidatable v)

In the java doc, the method validate don't have any return type, that's why
I don't understand what is my mistake.

Thank you for your help.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: SingleSortState multiple sorts?

2008-03-21 Thread Sebastiaan van Erk
I wanted to have this the other day, so I came up with (see attached). 
I'd like to see your ideas about it, since this was just a 20 minute 
first hack...


IClusterable is just a tagging interface for the sole purpose of 
clustering via Terracotta. So if you don't need TC, then Serializable 
should be fine.


Regards,
Sebastiaan


Hoover, William wrote:

I was looking into providing a ListSortParam in a ISortState/IClusterable 
(multiple version of SingleSortState) for a SortableDataProvider. Does the list 
within the sort state need to be IClusterable?


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

package com.sebster.util.wicket;

import java.util.Collections;
import java.util.List;

import org.apache.wicket.extensions.markup.html.repeater.data.sort.ISortState;
import org.apache.wicket.extensions.markup.html.repeater.data.table.ISortableDataProvider;
import org.apache.wicket.extensions.markup.html.repeater.util.SortParam;

public abstract class MultiSortableDataProvider implements ISortableDataProvider {

	private static final long serialVersionUID = 1L;

	private MultiSortState state = new MultiSortState();

	/**
	 * @see ISortableDataProvider#getSortState()
	 */
	public final ISortState getSortState() {
		return state;
	}

	/**
	 * @see ISortableDataProvider#setSortState(org.apache.wicket.extensions.markup.html.repeater.data.sort.ISortState)
	 */
	public final void setSortState(final ISortState state) {
		if (!(state instanceof MultiSortState)) {
			throw new IllegalArgumentException(state must be an instance of  + MultiSortState.class.getName());
		}
		this.state = (MultiSortState) state;
	}

	public ListSortParam getSort() {
		return state.getSort();
	}

	@SuppressWarnings(unchecked)
	public void clearSort() {
		state.setSort(Collections.EMPTY_LIST);
	}

	/**
	 * Sets the current sort state
	 * 
	 * @param sortParams
	 *list of parameters containing new sorting information
	 */
	public void setSort(ListSortParam sortParams) {
		state.setSort(sortParams);
	}

	public void sortBy(final String property, final boolean ascending) {
		state.setPropertySortOrder(property, ascending ? ISortState.ASCENDING : ISortState.DESCENDING);
	}

	/**
	 * @see ISortableDataProvider#detach()
	 */
	public void detach() {
		// Do nothing.
	}

}
package com.sebster.util.wicket;

import java.util.ArrayList;
import java.util.Collections;
import java.util.Iterator;
import java.util.List;

import org.apache.wicket.IClusterable;
import org.apache.wicket.extensions.markup.html.repeater.data.sort.ISortState;
import org.apache.wicket.extensions.markup.html.repeater.util.SortParam;

public class MultiSortState implements ISortState, IClusterable {

	private static final long serialVersionUID = 1L;

	private final ListSortParam sortParams = new ArrayListSortParam();

	public int getPropertySortOrder(final String property) {
		if (property == null) {
			throw new NullPointerException(property);
		}
		for (final SortParam sortParam : sortParams) {
			if (property.equals(sortParam.getProperty())) {
return sortParam.isAscending() ? ISortState.ASCENDING : ISortState.DESCENDING;
			}
		}
		return ISortState.NONE;
	}

	public void setPropertySortOrder(final String property, final int state) {
		if (property == null) {
			throw new NullPointerException(property);
		}
		for (final IteratorSortParam i = sortParams.iterator(); i.hasNext();) {
			if (property.equals(i.next().getProperty())) {
i.remove();
break;
			}
		}
		if (state != ISortState.NONE) {
			sortParams.add(0, new SortParam(property, state == ISortState.ASCENDING));
		}
	}
	
	public ListSortParam getSort() {
		return Collections.unmodifiableList(sortParams);
	}
	
	public void setSort(final ListSortParam sortParams) {
		sortParams.clear();
		sortParams.addAll(sortParams);
	}
	
}


smime.p7s
Description: S/MIME Cryptographic Signature


Re: SingleSortState multiple sorts?

2008-03-21 Thread Sebastiaan van Erk
Yes, I too would prefer multisort to be in Wicket by default. It is much 
more logical for the sort to be stable, i.e., it sorts the *current* 
list with respect to the new sort order, rather than the original list.


Especially when the original list is from the database and it is 
essentially undefined what order it is coming out (with respect to 
non-sort columns).


Problem is that it is an incompatible change and a hassle for the 
implementors of sortable data providers, because suddenly they need to 
take into account many sorts instead of only 1.


Regards,
Sebastiaan

Hoover, William wrote:

It seems as though this would be a good candidate for a replacement for 
SingleSortState/SortableDataProvider. We really don't need the single sort 
version if we have a multiple sort version (reduce bloat ;o)?

-Original Message-
From: Hoover, William [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 9:23 AM
To: users@wicket.apache.org
Subject: RE: SingleSortState multiple sorts?


Ironically, your code looks very similar to what I have done on my end. Can we 
create a feature request for this?

-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 9:13 AM
To: users@wicket.apache.org
Subject: Re: SingleSortState multiple sorts?


I wanted to have this the other day, so I came up with (see attached). 
I'd like to see your ideas about it, since this was just a 20 minute 
first hack...


IClusterable is just a tagging interface for the sole purpose of 
clustering via Terracotta. So if you don't need TC, then Serializable 
should be fine.


Regards,
Sebastiaan


Hoover, William wrote:

I was looking into providing a ListSortParam in a ISortState/IClusterable 
(multiple version of SingleSortState) for a SortableDataProvider. Does the list 
within the sort state need to be IClusterable?


-
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: SingleSortState multiple sorts?

2008-03-21 Thread Sebastiaan van Erk
I guess that could work, though I'd like to think this stuff through 
some more...


The problem that I have with the current design is that ISortState is 
not designed for multiple sorts. The setting works fine as it is, but 
the order is not recoverable from the current ISortState interface.


This means that in the data provider you need to cast the interface to a 
specific class (which kind of defeats the purpose of the interface 
IMHO). That's why we have to do the ugly casts to MultiSortState.


I'd like to see the state properly included in ISortState. If you look 
at the ISortState interface, it has


public void setPropertySortOrder(String property, int state);

If this is the only thing you can do to CHANGE the sort state, then a 
list of property/state pairs is the only thing you should be able to get 
out of it, so I'd like to see more of a:


public ListSortOrder getPropertySortOrders();

With SortOrder having a property and a state. Then a sortable data 
provider could decide on its own what it would want to do, i.e., use 
only 1 sort order, or use multiple... SingleSortState would simply 
return a singleton list every time... Casts would no longer be necessary...


Anyway, this is probably a big too big of an API break. But in my 
opinion the main problem is in the design of the ISortState interface.


Regards,
Sebastiaan



Hoover, William wrote:
I'm just thinking out loud, but what if we added a getSorts() to avoid incompatibility issues? 


public ListSortParam getSorts() {
return state.getSorts();
}

public SortParam getSort() {
return (state.getSorts().isEmpty()) ? null : 
state.getSorts().get(0);
}

-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 9:34 AM
To: users@wicket.apache.org
Subject: Re: SingleSortState multiple sorts?


Yes, I too would prefer multisort to be in Wicket by default. It is much 
more logical for the sort to be stable, i.e., it sorts the *current* 
list with respect to the new sort order, rather than the original list.


Especially when the original list is from the database and it is 
essentially undefined what order it is coming out (with respect to 
non-sort columns).


Problem is that it is an incompatible change and a hassle for the 
implementors of sortable data providers, because suddenly they need to 
take into account many sorts instead of only 1.


Regards,
Sebastiaan

Hoover, William wrote:

It seems as though this would be a good candidate for a replacement for 
SingleSortState/SortableDataProvider. We really don't need the single sort 
version if we have a multiple sort version (reduce bloat ;o)?

-Original Message-
From: Hoover, William [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 9:23 AM
To: users@wicket.apache.org
Subject: RE: SingleSortState multiple sorts?


Ironically, your code looks very similar to what I have done on my end. Can we 
create a feature request for this?

-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 9:13 AM
To: users@wicket.apache.org
Subject: Re: SingleSortState multiple sorts?


I wanted to have this the other day, so I came up with (see attached). 
I'd like to see your ideas about it, since this was just a 20 minute 
first hack...


IClusterable is just a tagging interface for the sole purpose of 
clustering via Terracotta. So if you don't need TC, then Serializable 
should be fine.


Regards,
Sebastiaan


Hoover, William wrote:

I was looking into providing a ListSortParam in a ISortState/IClusterable 
(multiple version of SingleSortState) for a SortableDataProvider. Does the list 
within the sort state need to be IClusterable?


-
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: Multiple wicket:child/ panels like behaviour

2008-03-20 Thread Sebastiaan van Erk

Gerolf Seitz wrote:
 you can provide factory methods in your base page like
 protected abstract Component newHeader(String id, IModel model);

 in the constructor of base page do:
 add(newHeader(header, someModelOrNull));

 and just override/implement the factory method in your concrete page
 classes.

 hth,
   Gerolf


I'll be so happy when multiple child is implemented, because I really 
think this is an anti-pattern.


Basically, in the constructor of the base page you call an overridable 
method, which is terrible. For example you have in your subclass:


public class MySubClass extends MyBaseClass {

// my fields
public int answer = 42;

public MySubClass(int suppliedAnswer) {
// implicit (or explicity call to super)
super();

// init class state and establish class invariants
// this stuff could be really complicated!
if (suppliedAnswer != -1) {
answer = suppliedAnswer;
}
}

@Override
public Component getUniverseComponent(String id) {
// create universe component using state of this class
// the structure of this component could depend on this
// the component could even depend on constructor
// args that the base class knows nothing about (as
// is the case now).
if (answer == 42) {
return new HHGTGPanel(id);
}
return new Label(id, String.valueOf(answer));
}

}

The problem is that getUniverseComponent gets called from the base class 
before the constructor of the subclass gets evaluated. :-( This means 
that the = 42 assignment has not been done yet, nor the override of the 
value with the value from the constructor arg. The (partial) workaround 
I've used (a special private init method and initialized flag) is just 
plain ugly (and partial, since you still can't use your constructor args).


Regards,
Sebastiaan




On Thu, Mar 20, 2008 at 9:25 AM, Cristi Manole [EMAIL PROTECTED]
wrote:


Hello,

I've searched the web and I see there are a lot of hits for what I'm
looking
for but I cannot quite pinpoint the perfect solution (easiest) for this
simple thing.

What I need is to be able to extend a base page and put into some places
some extra panels. I designed the places in the base page.

For only one panel, I can use wicket:child tag. If I need more than one
panel inserted, how do I do that?

Thanks,
Cristi Manole





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Multiple wicket:child/ panels like behaviour

2008-03-20 Thread Sebastiaan van Erk

Yes, Johan told me about that one. :-)

But I really think that's quite ugly too... :( I really don't want to 
add hooks to do something that is just regular initialization of the 
component hierarchy of the page... And whenever possible I think my 
other work around is at least more intuitive...


Regards,
Sebastiaan


Igor Vaynberg wrote:

the workaround is quiet easy

class mypage extends webpage {
  onbeforerender() {
  if (get(panel1)==null) {
add(newPanel1(panel1));
  }
  super.onbeforerender();
   }
}

-igor


On Thu, Mar 20, 2008 at 2:12 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Gerolf Seitz wrote:
   you can provide factory methods in your base page like
   protected abstract Component newHeader(String id, IModel model);
  
   in the constructor of base page do:
   add(newHeader(header, someModelOrNull));
  
   and just override/implement the factory method in your concrete page
   classes.
  
   hth,
 Gerolf


 I'll be so happy when multiple child is implemented, because I really
 think this is an anti-pattern.

 Basically, in the constructor of the base page you call an overridable
 method, which is terrible. For example you have in your subclass:

 public class MySubClass extends MyBaseClass {

// my fields
public int answer = 42;

public MySubClass(int suppliedAnswer) {
// implicit (or explicity call to super)
super();

// init class state and establish class invariants
// this stuff could be really complicated!
if (suppliedAnswer != -1) {
answer = suppliedAnswer;
}
}

@Override
public Component getUniverseComponent(String id) {
// create universe component using state of this class
// the structure of this component could depend on this
// the component could even depend on constructor
// args that the base class knows nothing about (as
// is the case now).
if (answer == 42) {
return new HHGTGPanel(id);
}
return new Label(id, String.valueOf(answer));
}

 }

 The problem is that getUniverseComponent gets called from the base class
 before the constructor of the subclass gets evaluated. :-( This means
 that the = 42 assignment has not been done yet, nor the override of the
 value with the value from the constructor arg. The (partial) workaround
 I've used (a special private init method and initialized flag) is just
 plain ugly (and partial, since you still can't use your constructor args).

 Regards,
 Sebastiaan




 
  On Thu, Mar 20, 2008 at 9:25 AM, Cristi Manole [EMAIL PROTECTED]
  wrote:
 
  Hello,
 
  I've searched the web and I see there are a lot of hits for what I'm
  looking
  for but I cannot quite pinpoint the perfect solution (easiest) for this
  simple thing.
 
  What I need is to be able to extend a base page and put into some places
  some extra panels. I designed the places in the base page.
 
  For only one panel, I can use wicket:child tag. If I need more than one
  panel inserted, how do I do that?
 
  Thanks,
  Cristi Manole
 
 



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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Wicketstuff source pages - can we make them stateless?

2008-03-18 Thread Sebastiaan van Erk

Yes, or just even increase the timeout as a temporary fix. :-)

It's like 5 minutes now, which means that if you go to your own code to 
implement something like in the example, and then want to view the 
source code of the next logical file, it says page expired. If it was 
30 minutes, then for me it would be much less of an issue.


Regards,
Sebastiaan

Igor Vaynberg wrote:

i think they meant to make only source code viewing pages stateless...

-igor


On Tue, Mar 18, 2008 at 12:26 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:

-1

 You can download and run the examples yourself if you want to do so.
 The examples are just that: examples of normal wicket pages. Forcing
 them stateless gives new users the wrong impressions.

 Martijn



 On 3/18/08, Ned Collyer [EMAIL PROTECTED] wrote:
 
   Hi,
 
   I enjoy clicking around the source at http://www.wicketstuff.org/wicket13/.
   It's interesting stuff :)
 
   Page expiry is very frustrating, especially when you tab back to the code to
   see how something is achieved.
 
   Can we make the code pages either static or stateless, so I can bookmark
   them, send them to colleagues, or  come back 30mins later and click a link
   without it saying page expired?
 
   Rgds
 
   Ned
 
  --
   View this message in context: 
http://www.nabble.com/Wicketstuff-source-pages---can-we-make-them-stateless--tp16111827p16111827.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]
 
 


 --
 Buy Wicket in Action: http://manning.com/dashorst
 Apache Wicket 1.3.2 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2



 -
 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: Wicketstuff source pages - can we make them stateless?

2008-03-18 Thread Sebastiaan van Erk

Martijn Dashorst wrote:

Making the source code viewing pages stateless won't help: next
question: but when I close the source code, my page doesn't work
anymore.


The source code opens up in separate window. If the URL's there were 
bookmarkable pages they would always work. Since the source is in a 
separate window you can study the source code there and if the example 
page expires, that's ok... Just refresh it.


I see no reason why the source code browser links should not be 
bookmarkable; the reason they're not now is because they're ajax links, 
and I'd prefer bookmarkable over ajax any day.


Regards,
Sebastiaan


The online examples are not fit for a long studying session: they are
for demoing, or visitors. Studying or long running demoes: DOWNLOAD
the thing and run them locally.


Martijn

On 3/18/08, Igor Vaynberg [EMAIL PROTECTED] wrote:

i think they meant to make only source code viewing pages stateless...


 -igor



 On Tue, Mar 18, 2008 at 12:26 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:
  -1
 
   You can download and run the examples yourself if you want to do so.
   The examples are just that: examples of normal wicket pages. Forcing
   them stateless gives new users the wrong impressions.
 
   Martijn
 
 
 
   On 3/18/08, Ned Collyer [EMAIL PROTECTED] wrote:
   
 Hi,
   
 I enjoy clicking around the source at 
http://www.wicketstuff.org/wicket13/.
 It's interesting stuff :)
   
 Page expiry is very frustrating, especially when you tab back to the 
code to
 see how something is achieved.
   
 Can we make the code pages either static or stateless, so I can bookmark
 them, send them to colleagues, or  come back 30mins later and click a 
link
 without it saying page expired?
   
 Rgds
   
 Ned
   
--
 View this message in context: 
http://www.nabble.com/Wicketstuff-source-pages---can-we-make-them-stateless--tp16111827p16111827.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]
   
   
 
 
   --
   Buy Wicket in Action: http://manning.com/dashorst
   Apache Wicket 1.3.2 is released
   Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2
 
 
 
   -
   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: Wicketstuff source pages - can we make them stateless?

2008-03-18 Thread Sebastiaan van Erk

Matej Knopp wrote:

Why can't we just put a 5 minute timer on each page which would casuse
active sessions never expire?


That's fine by me, :-) though I tend to leave windows open in my browser 
for hours or days even, so that would be less server friendly than 
bookmarkable links...


Regards,
Sebastiaan


-Matej

On Tue, Mar 18, 2008 at 8:52 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Martijn Dashorst wrote:
  Making the source code viewing pages stateless won't help: next
  question: but when I close the source code, my page doesn't work
  anymore.

 The source code opens up in separate window. If the URL's there were
 bookmarkable pages they would always work. Since the source is in a
 separate window you can study the source code there and if the example
 page expires, that's ok... Just refresh it.

 I see no reason why the source code browser links should not be
 bookmarkable; the reason they're not now is because they're ajax links,
 and I'd prefer bookmarkable over ajax any day.

 Regards,
 Sebastiaan



  The online examples are not fit for a long studying session: they are
  for demoing, or visitors. Studying or long running demoes: DOWNLOAD
  the thing and run them locally.
 
 
  Martijn
 
  On 3/18/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
  i think they meant to make only source code viewing pages stateless...
 
 
   -igor
 
 
 
   On Tue, Mar 18, 2008 at 12:26 AM, Martijn Dashorst
   [EMAIL PROTECTED] wrote:
-1
   
 You can download and run the examples yourself if you want to do so.
 The examples are just that: examples of normal wicket pages. Forcing
 them stateless gives new users the wrong impressions.
   
 Martijn
   
   
   
 On 3/18/08, Ned Collyer [EMAIL PROTECTED] wrote:
 
   Hi,
 
   I enjoy clicking around the source at 
http://www.wicketstuff.org/wicket13/.
   It's interesting stuff :)
 
   Page expiry is very frustrating, especially when you tab back to the 
code to
   see how something is achieved.
 
   Can we make the code pages either static or stateless, so I can 
bookmark
   them, send them to colleagues, or  come back 30mins later and click 
a link
   without it saying page expired?
 
   Rgds
 
   Ned
 
  --
   View this message in context: 
http://www.nabble.com/Wicketstuff-source-pages---can-we-make-them-stateless--tp16111827p16111827.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]
 
 
   
   
 --
 Buy Wicket in Action: http://manning.com/dashorst
 Apache Wicket 1.3.2 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2
   
   
   
 -
 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: Amsterdam Community meeting 2008

2008-03-18 Thread Sebastiaan van Erk

Since it's pretty close, I was wondering if there is anything known about:

1) what time does it start?
2) what presentations are being held?

Regards,
Sebastiaan


Martijn Dashorst wrote:

Yes, it is tuesday april 8th.

Martijn

On 3/18/08, Uwe Schäfer [EMAIL PROTECTED] wrote:

hi

 is there a definite Date for the Meetup in Amsterdam, yet?
 At least people from abroad might have to plan for it, make/move Dates,
 book trains etc., so that it would be nice to have a Date people agreed
 upon soon.

 cu uwe
 --

 THOMAS DAILY GmbH
 Adlerstraße 19
 79098 Freiburg
 Deutschland
 T  + 49 761 3 85 59 0
 F  + 49 761 3 85 59 550
 E  [EMAIL PROTECTED]
 www.thomas-daily.de

 Geschäftsführer/Managing Directors:
 Wendy Thomas, Susanne Larbig
 Handelsregister Freiburg i.Br., HRB 3947

 Registrieren Sie sich unter http://morningnews.thomas-daily.de für die
 kostenfreien TD Morning News, eine Auswahl aktueller Themen des Tages
 morgens um 9:00 in Ihrer Mailbox.

 Hinweis: Der Redaktionsschluss für unsere TD Morning News ist täglich um
 8:30 Uhr. Es werden vorrangig Informationen berücksichtigt, die nach
 16:00 Uhr des Vortages eingegangen sind. Die Email-Adresse unserer
 Redaktion lautet [EMAIL PROTECTED]


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









smime.p7s
Description: S/MIME Cryptographic Signature


Re: Amsterdam Community meeting 2008

2008-03-18 Thread Sebastiaan van Erk

Nice list. :-)

Unfortunately I'm not very good at any of them, the only one I know a 
bit about is the serialization one, and even that is just what I learned 
from the presentation last time...


Generally I'm also good at messing up things, but haven't had enough 
wicket experience to present much on that. I can show why I need 
multiple extend/child (because overridable methods called from a 
base-class constructor returning fragments get called before the 
subclass constructor, causing a real mess of workarounds), or how not to 
use LDM's with hibernate in lists (my pages are quickly becoming a mess 
trying to avoid the 1 query per object deserialization issue), but I 
can't tell you how to do it right (maybe someone else can. :-))


The one about authors sounds like a good one for you. :-) I sense some 
frustration there! ;-)


If I (or someone else) comes up with something that I *can* present, 
I'll see what I can do.


I'd like to see a Wicket Patterns presentation myself: things that you 
need to do a lot and the standard solution to do them (i.e., similar to 
the multiple child, but then only those cases where there is a good 
solution available). Or a Wicket Antipatterns would be cool as well, 
i.e., how NOT to do things in Wicket and then show the right way to do 
them (standard example is not using a model which causes constructor 
time binding and people wondering why their page isn't updated).


Regards,
Sebastiaan

Martijn Dashorst wrote:

Subjects I can come up with are:
 - sexy components (a genuine date picker, such as meetmoi)
 - openid integration
 - building applications with wicket web beans
 - flex/silverlight/air: threat or opportunity
 - social networking integration (open social, facebook)
 - integrations with other frameworks (extjs?)
 - how serialization works, why it matters
 - behind the scenes of Apache Wicket (how do I become a committer)
 - groovy/grails integration
 - terracotta, but now with a real wicket demo
 - scala + wicket
 - why authors don't get rich from book writing
 - web framework shoot out: jsf vs tapestry vs wicket vs spring mvc
 - top 10 ways to mess up your Wicket application
 - top 10 ways to speed up your Wicket application
 - scaling out (show how to run your wicket application in a cluster)

Martijn

On 3/18/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Hmm...

 Currently I don't think I have very much to present that is interesting
 to the Wicket community, unless you guys are interested in relational
 variants of classical mechanics. :-) I've been kinda busy trying to
 write my physics master's thesis...

 On the other hand, what *are* people interested in having presented? If
 there is something that I feel is within my Wicket skills, who knows. :-)


 Regards,
 Sebastiaan

 Martijn Dashorst wrote:
  I see that you haven't volunteered yet to present something.
 
  Martijn
 
  On 3/18/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
  Since it's pretty close, I was wondering if there is anything known about:
 
   1) what time does it start?
   2) what presentations are being held?
 
   Regards,
 
  Sebastiaan
 
 
 
   Martijn Dashorst wrote:
Yes, it is tuesday april 8th.
   
Martijn
   
On 3/18/08, Uwe Schäfer [EMAIL PROTECTED] wrote:
hi
   
 is there a definite Date for the Meetup in Amsterdam, yet?
 At least people from abroad might have to plan for it, make/move Dates,
 book trains etc., so that it would be nice to have a Date people agreed
 upon soon.
   
 cu uwe
 --
   
 THOMAS DAILY GmbH
 Adlerstraße 19
 79098 Freiburg
 Deutschland
 T  + 49 761 3 85 59 0
 F  + 49 761 3 85 59 550
 E  [EMAIL PROTECTED]
 www.thomas-daily.de
   
 Geschäftsführer/Managing Directors:
 Wendy Thomas, Susanne Larbig
 Handelsregister Freiburg i.Br., HRB 3947
   
 Registrieren Sie sich unter http://morningnews.thomas-daily.de für die
 kostenfreien TD Morning News, eine Auswahl aktueller Themen des Tages
 morgens um 9:00 in Ihrer Mailbox.
   
 Hinweis: Der Redaktionsschluss für unsere TD Morning News ist täglich 
um
 8:30 Uhr. Es werden vorrangig Informationen berücksichtigt, die nach
 16:00 Uhr des Vortages eingegangen sind. Die Email-Adresse unserer
 Redaktion lautet [EMAIL PROTECTED]
   
   
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
   
   
   
   
 
 
 
 
 










smime.p7s
Description: S/MIME Cryptographic Signature


Re: [discuss] Release 1.4 with only generics and stop support for 1.3

2008-03-17 Thread Sebastiaan van Erk

Hi,

I was wondering to what extent it is possible to have generics added to 
1.3 but have it compile to 1.4 if necessary? Isn't that a just a 
question of not using other Java 1.5 constructs such as enums and new 
JDK classes? Wouldn't that solve most people's problems that need to 
stick to Java 1.4?


Regards,
Sebastiaan

Martijn Dashorst wrote:

This thread is the accompanying discussion thread for the ongoing vote
on the same subject. Please use this discussion thread for voicing
your opinion or asking questions. This makes counting the votes much
easier.

The discussion on our development list makes it clear that a lot of
folks are anxious for generified models. Most users if not all wish us
to release a quick release which is 1.3 + generics. The consequence is
that the core team will stop to support 1.3, and that everybody that
wishes updates will have to migrate to 1.4, and upgrade to Java 5.

Why should we keep supporting 1.3 and JDK 1.4?

Why only a generified release, and not a full release with more Java5
conversions?

Martijn

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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [discuss] Release 1.4 with only generics and stop support for 1.3

2008-03-17 Thread Sebastiaan van Erk

Hmm... bummer. :-)

How hard can it be to throw out all references to generics and insert 
the casts where necessary? :-) But you're right... at least in eclipse 
it complains if you put the source compliance level higher than the 
class file compliance level...


Regards,
Sebastiaan

Johan Compagner wrote:

dont think you can compile java 5 source (with generics) to 1.4
you have to use something like retroweaver then

On Mon, Mar 17, 2008 at 9:27 AM, Sebastiaan van Erk [EMAIL PROTECTED]
wrote:


Hi,

I was wondering to what extent it is possible to have generics added to
1.3 but have it compile to 1.4 if necessary? Isn't that a just a
question of not using other Java 1.5 constructs such as enums and new
JDK classes? Wouldn't that solve most people's problems that need to
stick to Java 1.4?

Regards,
Sebastiaan

Martijn Dashorst wrote:

This thread is the accompanying discussion thread for the ongoing vote
on the same subject. Please use this discussion thread for voicing
your opinion or asking questions. This makes counting the votes much
easier.

The discussion on our development list makes it clear that a lot of
folks are anxious for generified models. Most users if not all wish us
to release a quick release which is 1.3 + generics. The consequence is
that the core team will stop to support 1.3, and that everybody that
wishes updates will have to migrate to 1.4, and upgrade to Java 5.

Why should we keep supporting 1.3 and JDK 1.4?

Why only a generified release, and not a full release with more Java5
conversions?

Martijn

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





smime.p7s
Description: S/MIME Cryptographic Signature


Re: [vote] Release 1.4 with only generics and stop support for 1.3

2008-03-17 Thread Sebastiaan van Erk

[X] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: getPageParameters() NullPointer

2008-03-16 Thread Sebastiaan van Erk

Hi,

I was actually trying to use getPageParameters() as well, and it was 
returning null too...


The reason I want to use it is, I have a base page which adds a context 
panel fragment in the page, which it gets by an abstract method 
getContextPanel(). Now in the sub page I wanted to use the state that 
was set in the constructor using the page parameters to build my context 
panel. But this does not work: the constructor of my sub page has not 
been called yet... the stack is:


MyPage.getContextPanel()
BasePage.init()
MyPage.init(PageParams params)

So I figured, I'd use getPageParams() in my context panel and explicitly 
initialize the state as a (very ugly) workaround. (If we get multiple 
wicket:child in 1.4 this problem is completely and nicely solved). If 
anybody knows a nicer way to work around this, let me know. (I'm 
actually against using overridable methods in constructors... but I see 
no alternative).


Anyway, checking the source code I noticed why getPageParams() returned 
null... I didn't do a super() call to my BasePage with the parameters, 
which in turn didn't do super() call to WebPage with the parameters... I 
just expected it to work. :-)


Maybe it would be useful to explicitly state in the getPageParams() 
method JavaDoc that you explicitly need to call the super() with the 
page parameters. :-)


Regards,
Sebastiaan

Martijn Dashorst wrote:

OK,
hangon...

You need to define a constructor *taking* a pageparameters object.

In that object you can find the parameters.

Martijn

On 1/22/08, Martijn Dashorst [EMAIL PROTECTED] wrote:

Stating the obvious, but did you check if the parameter was actually
present in the URL?

Martijn

On 1/22/08, Stephan Koch [EMAIL PROTECTED] wrote:

Hi all,

I'm experiencing a problem using getPageParameters().

The parameter id is passed to MyPage:
setResponsePage(MyPage.class, new PageParameters(id=+evalId));

In the constructor of MyPage I try to access the parameter id:
Integer evalId = Integer.parseInt(getPageParameters().getKey(id));

This fails with a NullPointerException. I thought the usage of
PageParameters was pretty straightforward- did I miss something here?

I'm using Wicket 1.3.

Regards,
Stephan




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




--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0







smime.p7s
Description: S/MIME Cryptographic Signature


setBefore/AfterDisabledLink and chaining

2008-03-15 Thread Sebastiaan van Erk

Hi,

Is it possible to make setAfterDisabledLink on AbstractLink return 
this so that chaining is possible. Now I have somthing similar to the 
following:


	fragment.add(new BookmarkablePageLink(season2Link, 
ProgramsPage.class, new PageParameters(0=2008)) {

{
setAfterDisabledLink();
setBeforeDisabledLink();
}

@Override
public boolean isEnabled() {
return 2008.equals(season);
}
});

But it would be nice if I could do:

	fragment.add(new BookmarkablePageLink(season2Link, 
ProgramsPage.class, new PageParameters(0=2008)) {

@Override
public boolean isEnabled() {
return 2008.equals(season);
}
}.setBeforeDisabledLink().setAfterDisabledLink());

Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: setBefore/AfterDisabledLink and chaining

2008-03-15 Thread Sebastiaan van Erk
Ok. :-) Just put it on here before reporting in the jira just in case 
it's was a stupid idea. ;-)


https://issues.apache.org/jira/browse/WICKET-1427

Regards,
Sebastiaan

Igor Vaynberg wrote:

jira...

-igor

On Sat, Mar 15, 2008 at 6:18 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Hi,

 Is it possible to make setAfterDisabledLink on AbstractLink return
 this so that chaining is possible. Now I have somthing similar to the
 following:

fragment.add(new BookmarkablePageLink(season2Link,
 ProgramsPage.class, new PageParameters(0=2008)) {
{
setAfterDisabledLink();
setBeforeDisabledLink();
}

@Override
public boolean isEnabled() {
return 2008.equals(season);
}
});

 But it would be nice if I could do:

fragment.add(new BookmarkablePageLink(season2Link,
 ProgramsPage.class, new PageParameters(0=2008)) {
@Override
public boolean isEnabled() {
return 2008.equals(season);
}
}.setBeforeDisabledLink().setAfterDisabledLink());

 Regards,
 Sebastiaan



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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: StringResourceModel labels within values

2008-03-13 Thread Sebastiaan van Erk
At one point I wanted to do interpolation in constant strings, so I just 
used the property interpolator directly:


PropertyVariableInterpolator.interpolate(value, modelObject);

You can use that to build a model that recursively interpolates until 
there are no more ${...} occurrences in the value.


Regards,
Sebastiaan

i ii wrote:

thank you for help! which way is better? my own component or srm model that 
gets from localizer?


Date: Wed, 12 Mar 2008 13:57:10 -0700
From: [EMAIL PROTECTED]
To: users@wicket.apache.org
Subject: Re: StringResourceModel labels within values

but will that work recusively? :)

-igor


On Wed, Mar 12, 2008 at 1:44 PM, Johan Compagner [EMAIL PROTECTED] wrote:

I think if you just give SRM a model that again gets the values from
 the localizer then it should work fine.




 On 3/12/08, i ii [EMAIL PROTECTED] wrote:
 
  is there way to do something like:
 
  .properties file:
 
  some.label=Some Label
  some.text=Some Text
  some.key=This text will have ${some.label} and ${some.text}
 

 -
 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: object sharing between pages

2008-03-13 Thread Sebastiaan van Erk

Maurice Marrink wrote:

Assuming B has a reference to Page A, wont A be Serialized with B,
when you go to C, and both still share the same serialized object?


When B is serialized, so is A, and serialization makes sure the 
instances to your object are kept shared


But when A is serialized alone (and if A does not have a reference to 
B), then when A is deserialized you'll have a copy of the instance you 
gave to B and the reference is no longer shared.



 So the best thing is that you shouldnt depend on shared variablen.


Ok so there are a lot of gotchas :)


Yep!


Maurice

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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: object sharing between pages

2008-03-13 Thread Sebastiaan van Erk

Sebastiaan van Erk wrote:

Maurice Marrink wrote:

Assuming B has a reference to Page A, wont A be Serialized with B,
when you go to C, and both still share the same serialized object?


When B is serialized, so is A, and serialization makes sure the 
instances to your object are kept shared


 But when A is serialized alone (and if A does not have a reference to
 B), then when A is deserialized you'll have a copy of the instance you
 gave to B and the reference is no longer shared.

Actually, that's how serialization would NORMALLY work. :-) I'm not 
really 100% sure how Wicket serialization works (I believe a referenced 
page is not serialized inline, but instead a page id is written, which 
could mean you always get copies of your instances on deserialize, but 
then again I'm not sure).


In either case, even with standard serialization you would have 
issues... But to be honest I've never really run into this issue with 
Wicket at all... When do you have *instance* variables in a page that 
point to shared objects which are not immutable? I hardly have any 
instance variables (other than maybe a few Components and Spring beans).


Regards,
Sebastiaan



 So the best thing is that you shouldnt depend on shared variablen.


Ok so there are a lot of gotchas :)


Yep!


Maurice

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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: object sharing between pages

2008-03-13 Thread Sebastiaan van Erk

Frank van Lankvelt wrote:

Assuming B has a reference to Page A, wont A be Serialized with B,
when you go to C, and both still share the same serialized object?
When B is serialized, so is A, and serialization makes sure the 
instances to your object are kept shared



how can this be?  Aren't different pages written to different streams
and thereby incapable of sharing objects?


Yes, I believe you are correct.

But when A is serialized alone (and if A does not have a reference to 
B), then when A is deserialized you'll have a copy of the instance you 
gave to B and the reference is no longer shared.



 So the best thing is that you shouldnt depend on shared variablen.

Ok so there are a lot of gotchas :)

Yep!


ok, I'll go ahead with storing the object in the session directly (as
meta-data) and use models in the pages to access this object.


May I ask what your use case is?

Regards,
Sebastiaan


cheers, Frank


Maurice

-
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: object sharing between pages

2008-03-13 Thread Sebastiaan van Erk

Frank van Lankvelt wrote:

ok, I'll go ahead with storing the object in the session directly (as
meta-data) and use models in the pages to access this object.

May I ask what your use case is?


it's very simple; when carrying out an action on page A, I want to
display a modal window (are you sure? with ok/cancel).  The modal
window creates a separate page, B, with the label and the buttons.

The information (a boolean) about what option was chosen determines what
to do on page A when the modal window is closed.

cheers, Frank


Ok, that definitely seems like something you should *not* be using the 
session for. I'd think that's what you normally use a callback for, but 
unfortunately I don't know how in Wicket (not without using shared 
state), because for example, the onClose() method does not pass you the 
contents of the ModalWindow...


I mean, you could do something like this if the contents were given back 
to you:


modal1.setWindowClosedCallback(new ModalWindow.WindowClosedCallback()
{
// Hypothetical callback with extra contents argument...
public void onClose(Component modalWindowPage, 
AjaxRequestTarget target)

{
boolean myBoolean = myModalWindowPage.getResult();
// do whatever with the result...
target.addComponent(result);
}
});

When I look at the Wicket examples for ModalWindow there is actually 
shared state passed between pages (i.e., the page with the modal window 
is passed as a parameter to the page IN the modal window). The modal 
window page then calls methods (setResult(...)) to change the state on 
the page that opened the modal window


I'm wondering now if this is safe in combination with serialization, if 
so, why, and if not, what is the proper way to do this, because via the 
session is awful.


Regards,
Sebastiaan



smime.p7s
Description: S/MIME Cryptographic Signature


Re: StringResourceModel labels within values

2008-03-13 Thread Sebastiaan van Erk

How's this:

public class RecursiveStringResourceModel extends AbstractReadOnlyModel {

private final String resourceKey;

private final Component component;

	public RecursiveStringResourceModel(final String resourceKey, final 
Component component) {

this.resourceKey = resourceKey;
this.component = component;
}

@Override
public Object getObject() {
		return new StringResourceModel(resourceKey, component, new 
CompoundPropertyModel(new AbstractMap() {

@Override
public Object get(Object key) {
return new RecursiveStringResourceModel((String) key, 
component).getObject();

}

@Override
public Setjava.util.Map.EntryString, String 
entrySet() {
return null;
}
})).getObject();
}

}

I'm sure it can be done more efficiently (i.e., less model creation), 
but hey, it works! ;-)


Regards,
Sebastiaan

i ii wrote:
how will this work with example i gave? i'm not sure how to get some.label and some.text back into some.key? would i use something like 


StringResourceModel srm = new StringResourceModel(some.key, this, null);
PropertyVariableInterpolator.interpolate(some.label, srm);

not sure that works :(


Date: Thu, 13 Mar 2008 12:17:09 +0100
From: [EMAIL PROTECTED]
To: users@wicket.apache.org
Subject: Re: StringResourceModel labels within values

At one point I wanted to do interpolation in constant strings, so I just 
used the property interpolator directly:


PropertyVariableInterpolator.interpolate(value, modelObject);

You can use that to build a model that recursively interpolates until 
there are no more ${...} occurrences in the value.


Regards,
Sebastiaan

i ii wrote:

thank you for help! which way is better? my own component or srm model that 
gets from localizer?


Date: Wed, 12 Mar 2008 13:57:10 -0700
From: [EMAIL PROTECTED]
To: users@wicket.apache.org
Subject: Re: StringResourceModel labels within values

but will that work recusively? :)

-igor


On Wed, Mar 12, 2008 at 1:44 PM, Johan Compagner [EMAIL PROTECTED] wrote:

I think if you just give SRM a model that again gets the values from
 the localizer then it should work fine.




 On 3/12/08, i ii [EMAIL PROTECTED] wrote:
 
  is there way to do something like:
 
  .properties file:
 
  some.label=Some Label
  some.text=Some Text
  some.key=This text will have ${some.label} and ${some.text}
 

 -
 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: StringResourceModel labels within values

2008-03-13 Thread Sebastiaan van Erk

Sebastiaan van Erk wrote:

How's this:

public class RecursiveStringResourceModel extends AbstractReadOnlyModel {

private final String resourceKey;

private final Component component;

public RecursiveStringResourceModel(final String resourceKey, final 
Component component) {

this.resourceKey = resourceKey;
this.component = component;
}

@Override

public Object getObject() {
return new StringResourceModel(resourceKey, component, new 
CompoundPropertyModel(new AbstractMap() {

@Override
public Object get(Object key) {
return new RecursiveStringResourceModel((String) key, 
component).getObject();

}

@Override
public Setjava.util.Map.EntryString, String entrySet() {
return null;
}
})).getObject();
}

}

I'm sure it can be done more efficiently (i.e., less model creation), 
but hey, it works! ;-)


For starters, it's much better to subclass LoadableDetachableModel and 
move the getOjbect() to load(). :-)


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Nabble users: don't edit your posts!

2008-03-12 Thread Sebastiaan van Erk
Considering the number of times certain questions are asked on this list 
that are answered 1000 times in the archive, I'm kind of afraid this 
isn't really going to help (unless it's posted frequently).


Is it not possible for nabble to disable the edit function for 
specifically the wicket lists? In the last 24 hours there have been at 
least 8 double posts!


Regards,
Sebastiaan

Martijn Dashorst wrote:

Dear nabble users,

The amount of messages coming in through nabble is astounding.
Unfortunately this is mostly due to the ability of you editing your
messages, which causes them to be sent twice or thrice to this list.
As nabble hides that fact from you (it knows which message you have
edited), this may not be something you are aware of.

By editing you messages you cause the core devs, and others that have
subscribed to the list to see your message two or three times.

This causes a lot of irritation for us: it is annoying to see the same
post twice, or more. It is annoying to reply to them (which one do we
need to reply to?) It makes following the thread hard.

Therefore I urge you to stop editing your messages once you have sent
them. If you don't do so, we will have to close down the option of
posting through nabble and only allow messages coming in from
subscribed users.

Martijn Dashorst

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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Nabble users: don't edit your posts!

2008-03-12 Thread Sebastiaan van Erk

I posted the problem to their support forum, hopefully it will help. :-)

http://www.nabble.com/Double-posts-to-mailing-lists-due-to-edits-on-nabble-to16000975.html

Regards,
Sebastiaan

Martijn Dashorst wrote:

On 3/12/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Considering the number of times certain questions are asked on this list
 that are answered 1000 times in the archive, I'm kind of afraid this
 isn't really going to help (unless it's posted frequently).


I know, but not asking is most certainly not going to help.


 Is it not possible for nabble to disable the edit function for
 specifically the wicket lists? In the last 24 hours there have been at
 least 8 double posts!


I asked, and they don't have that facility. Maybe if you ask too
(support at nabble.com), and others that see this as a problem, they
will fix it. Until then...

Martijn



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Serialisation/serialization documentation?

2008-03-12 Thread Sebastiaan van Erk

Look for page store in the archives and the IPageStore interface.

To get your application to deserialize stuff, simply press the back 
button on a wicket page, and click on a wicket link in the resulting 
page. That should get your page loaded from the page store.


Regards,
Sebastiaan

Sam Hough wrote:

Dear All,

I'm trying to get a better understanding off when/how/where Wicket
serialises components and non-transient/non-static references they hold. To
tune and sanity check our application.

Playing with writeObject, readObject I can see it writing on every ajax
request but only reading when I restart Tomcat (with serialised session
store).

I've searched around (with both spellings) but not found a recent
explanation of this.

Many thanks. I'll try not to post twice!

Thanks

Sam


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Serialisation/serialization documentation?

2008-03-12 Thread Sebastiaan van Erk
I just remember Johan gave a presentation about this at the last WUG in 
Amsterdam:


http://www.slideshare.net/jcompagner/session-stores-page-maps-and-pages

Regards,
Sebastiaan

Sam Hough wrote:

Dear All,

I'm trying to get a better understanding off when/how/where Wicket
serialises components and non-transient/non-static references they hold. To
tune and sanity check our application.

Playing with writeObject, readObject I can see it writing on every ajax
request but only reading when I restart Tomcat (with serialised session
store).

I've searched around (with both spellings) but not found a recent
explanation of this.

Many thanks. I'll try not to post twice!

Thanks

Sam


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Default Focus Behavior?

2008-03-11 Thread Sebastiaan van Erk

Sebastiaan van Erk wrote:

Johan Compagner wrote:

i still think that behaviors to control focus is a bit wrong
focus should have 1 entry point


I agree.


and i guess that is WebPage.focusComponent()


I agree on that one too.


or maybe Form (but you could have 2)


Exactly, so not a good idea. The page should determine which form gets 
focus.



By the way we have focus support in ajax mode... see AjaxRequestTarget

johan


It would still be useful to have some strategies for selecting the 
component to focus lying around, so you can plug them in, e.g., first 
blank field, first error, etc. These strategies could then work on a 
form. If you have multiple forms on a page, you'll have to make up your 
own strategy to choose which form you focus, but you can still use the 
provided strategies once you've chosen that.


Regards,
Sebastiaan


Thinking about it some more, you probably want to delegate the *choice* 
of which form field is focused to the form which is selected for focus. 
That is, page decides which form to focus, form decides which field to 
focus. That way you can encapsulate complicated focusing behavior in the 
components themselves instead of having to put it the page. A good 
default behavior for a page could be to ask the first form in the 
component hierarchy which field to focus. Another good default is to 
focus nothing.


Regards,
Sebastiaan




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Default Focus Behavior?

2008-03-11 Thread Sebastiaan van Erk

Johan Compagner wrote:

i still think that behaviors to control focus is a bit wrong
focus should have 1 entry point


I agree.


and i guess that is WebPage.focusComponent()


I agree on that one too.


or maybe Form (but you could have 2)


Exactly, so not a good idea. The page should determine which form gets 
focus.



By the way we have focus support in ajax mode... see AjaxRequestTarget

johan


It would still be useful to have some strategies for selecting the 
component to focus lying around, so you can plug them in, e.g., first 
blank field, first error, etc. These strategies could then work on a 
form. If you have multiple forms on a page, you'll have to make up your 
own strategy to choose which form you focus, but you can still use the 
provided strategies once you've chosen that.


Regards,
Sebastiaan





On Tue, Mar 11, 2008 at 12:41 PM, James Carman [EMAIL PROTECTED]
wrote:


On 3/11/08, Martijn Dashorst [EMAIL PROTECTED] wrote:

Another option would be (if there is enough interest) to add it to
 wicketstuff minis.


Yeah, I thought about that.  And, I may try to put that in there.
Perhaps there could be a few focus behaviors in there?  Perhaps even a
FocusBehaviors class with static helper methods:

public FocusBehaviors
{
 public static void focusOnLoad(FormComponent fc);
 public static void focusFirstError(Form form);
}

Something like that.

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






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Default Focus Behavior?

2008-03-11 Thread Sebastiaan van Erk

Gerolf Seitz wrote:

how about boolean WebPage#isAutoFocusEnabled and the possibility
to provide several IFocusStrategy instances with different priority?
this would allow to eg only set the focus on the first formcomponent of the
first form if no other formcomponent has an error...


I like something like this idea, though I don't really see the need for 
the isAutoFocusEnabled?


If you have an IFocusStrategy with a method getFocusComponent() which 
returns the component that should get the focus, then null could mean 
none (i.e., no autofocus), and anything else could mean focus that 
component. You could just have 1 single IFocusStrategy on a page, and if 
you want to chain them just make a ChainingFocusStrategy (i.e., one of 
them returns null, then go to the next).


What I would also like is if components can have their own 
IFocusStrategy, so that you can use these to compose your focus strategy 
for the page. This way complex components can manage their own focus 
strategy and you don't break encapsulation.


This all amounts to a setFocusStrategy on Component, with the one in the 
page ultimately choosing the component which gets the focus.


Just some thoughts...

Regards,
Sebastiaan




On Tue, Mar 11, 2008 at 3:36 PM, James Carman [EMAIL PROTECTED]
wrote:


On 3/11/08, Johan Compagner [EMAIL PROTECTED] wrote:

yes so it is not the last one you ask to have focus on
 Very confusing for an average user

 thats why there should be a single point just like
 AjaxRequestTarget.focusComponent() works.

Ok, you've sold me.  So, is this something that belongs in core?
Shouldn't the core have facilities for managing component focus?  The
Ajax folks shouldn't be the only ones who get this luxury. :)  Perhaps
an IFocusManager interface?  Would that go on the IRequestCycle (since
you can only focus one component per request) or on the Page?

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






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Custom Exception/Error page

2008-03-10 Thread Sebastiaan van Erk
I would say that the standard practice is probably to use your logging 
subsystem to email you the exception.


For example, if you are using log4j to log, you could add something like 
this to your log4j.xml file:


appender name=ERRORMAILER
class=org.apache.log4j.net.SMTPAppender
param name=from value=[EMAIL PROTECTED] /
param name=to value=[EMAIL PROTECTED] /
param name=subject value=[mydomain] ERROR /
param name=SMTPHost value=localhost /
param name=threshold value=ERROR /
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%d %-5p - [%C:%L] 
%m%n /
/layout
/appender

Regards,
Sebastiaan


Edvin Syse wrote:

Hi. In my application I do:

getApplicationSettings().setInternalErrorPage(ErrorPage.class);
getExceptionSettings().setUnexpectedExceptionDisplay(IExceptionSettings.SHOW_INTERNAL_ERROR_PAGE); 



to display a custom page for error messages. I would also like to email 
myself the exception - is it possible that I can get a hold of the 
throwable from the ErrorPage.class, or do I have to explicitly catch and 
rethrow a RestartResponseException to obtain the exception?


-- Edvin



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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Custom Exception/Error page

2008-03-10 Thread Sebastiaan van Erk
Logging stuff in endless loops is generally a good way to blow things 
up. ;-) I remember back in my university days a friend of mine did some 
logging on /tmp on 150 or so Sun workstations. It  went into an endless 
loop and all of the workstations became inaccessible (/tmp and virtual 
memory were connected, don't ask why, so login failed with an out of 
memory error :-))


What you can do in case your mail server doesn't throttle and protect 
you against DOS-attacks, is use log4j's triggering event evaluator and 
put throttling into that.


See:

http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/SMTPAppender.html

and:

http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/spi/TriggeringEventEvaluator.html)

Thus by limiting your buffer size of the SMTPAppender and make sure you 
can only have N triggering events per hour, you can easily avoid this 
problem.


Good point though, Martijn. :-)

Regards,
Sebastiaan



Martijn Dashorst wrote:

It is a really good way to blow up your exchange server... We had a
bug somewhere that generated exceptions in an endless loop. It took
exchange over a whole day to empty the queue.

Martijn

On 3/10/08, Edvin Syse [EMAIL PROTECTED] wrote:

Wow, that's a very nice solution. Thanks :))

 -- Edvin

 Sebastiaan van Erk skrev:


I would say that the standard practice is probably to use your logging

  subsystem to email you the exception.
 
  For example, if you are using log4j to log, you could add something like
  this to your log4j.xml file:
 
  appender name=ERRORMAILER
  class=org.apache.log4j.net.SMTPAppender
  param name=from value=[EMAIL PROTECTED] /
  param name=to value=[EMAIL PROTECTED] /
  param name=subject value=[mydomain] ERROR /
  param name=SMTPHost value=localhost /
  param name=threshold value=ERROR /
  layout class=org.apache.log4j.PatternLayout
  param name=ConversionPattern value=%d %-5p - [%C:%L]
  %m%n /
  /layout
  /appender
 
  Regards,
  Sebastiaan
 
 
  Edvin Syse wrote:
  Hi. In my application I do:
 
  getApplicationSettings().setInternalErrorPage(ErrorPage.class);
  
getExceptionSettings().setUnexpectedExceptionDisplay(IExceptionSettings.SHOW_INTERNAL_ERROR_PAGE);
 
 
  to display a custom page for error messages. I would also like to
  email myself the exception - is it possible that I can get a hold of
  the throwable from the ErrorPage.class, or do I have to explicitly
  catch and rethrow a RestartResponseException to obtain the exception?
 
  -- Edvin
 
 
 
  -
  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: Default Focus Behavior?

2008-03-09 Thread Sebastiaan van Erk
I think he means that, suppose you have a username and password field; 
then if the username is already filled in (e.g. from a cookie), then 
focus should go to the next field (password field).


It probably should be the same as the tab order (first empty field in 
tab order gets focus) from a ui perspective...


Regards,
Sebastiaan

James Carman wrote:

I don't think I understand what you mean here.  Do you mean something
like setting the tab order like in Swing?

On 3/9/08, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote:

What about a chaining component?

 EG you enter something in form.field a, and when thats filled then it
 jumps to form field b..? Etc...



 regards Nino

 James Carman wrote:


On 3/9/08, Warren [EMAIL PROTECTED] wrote:

 
  WebMarkupContainer bodyTag = new WebMarkupContainer(bodyTag);
   bodyTag.add(new SimpleAttributeModifier(onload,
   form.username.focus();));
 
 
  Ok, but wouldn't it be cooler/easier/more java-oriented to do:
 
  TextField userName = new TextField(userName);
  userName.addBehavior(new DefaultFocusBehavior());
 
  or
 
  Behaviors.defaultFocus(userName); // Assuming Behaviors existed.
 
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of James Carman
Sent: Sunday, March 09, 2008 7:58 AM
To: users@wicket.apache.org
Subject: Default Focus Behavior?
   
   
Is there a behavior (or some other way) for having a field receive the
focus when the page loads?  For instance, in a login form, you'd want
the focus to go to the username field or perhaps the password field if
you've got remember me turned on.
   
 
 
  -
 
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]
 
 
 

 --

-Wicket for love
 -Jme for fun

 Nino Martinez Wael
 Java Specialist @ Jayway DK
 http://www.jayway.dk
 +45 2936 7684


 -

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: Security Features offered by Wicket

2008-03-04 Thread Sebastiaan van Erk
Wicket does nothing to protect from CSRF attacks, and it is trivially 
vulnerable. Sure it's a lot more difficult with the standard 
?wicket:interface type URLs than it would be with more predictable URLs, 
but you can still quite easily guess the URLs, and futhermore, to 
improve your chances of success you can simply include many images in 
the attacking page with different values for the URLs, i.e.,


img 
src=http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1;


and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in 
one page.


Furthermore, most people actually LIKE predictable urls and go to great 
length to mount pages and make them bookmarkable. There's even a 
StatelessForm component, which is entirely vulnerable to CSRF.


Thus, I'd say that even without a quickstart, it's obvious that Wicket 
does not offer any CSRF protection out of the box, and that if you want 
this kind of protection, you will have to do it yourself (which is 
probably not really difficult; though I think many people are not aware 
of these kind of attack vectors and don't even think about it, which is 
why it would be nice if Wicket *could* do it out of the box).


I believe that answers the original question, that CSRF protection is 
*NOT* a security feature offered by Wicket.


Regards,
Sebastiaan

Nino Saturnino Martinez Vazquez Wael wrote:
While that is true.. It's also true that wicket devs favor stuff proven 
with a quickstart, because it becomes easier to make a fix for something 
you can see in code..


So as I've written once before a quickstart should be the way to go or 
just use one of the existing applications, phone book or blog tutorial 
etc. And make a hack at that...


regards Nino

Ned Collyer wrote:
Nick, I think you would be quite surprised at the level of auditing 
something
has to pass to be used in a financial system, especially a bank.  
(unless u

have some dodgy bank)

If something is theoretically possible, then thats as good as proven.

Gotta remember that hackers are a lot smarter in many instances than the
people who wrote the software to keep them out.


Nick Heudecker wrote:
 

Arthur,

Only what you can *prove* matters, not what you think.  Have you created
an
example application with a CSRF attack?




  




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Security Features offered by Wicket

2008-03-04 Thread Sebastiaan van Erk

The point of CSRF attack is that you *DONT* have to hijack the session.

By including for example an image on the attacking website with a src 
reference to the vulnerable website, the browser load the page of 
vulnerable website, and if you currently have a session, the browser 
will be tricked into using your current session. That means, if you're 
logged in, the attacking website can trick your browser into 
(unknowingly and against your will) requesting any url on the vulnerable 
website in the context of your current session.


No session hijacking required.

Regards,
Sebastiaan

Ned Collyer wrote:

My point is, if the code path exists, doing some elaborate session hijacking
sniffer something something predict blah... can be a pain in the arse and
not really a valuable investment.

A better thing would be to ask the devs if it is plausible (regardless of
how hard it might be in the real world).

If the answer to plausibility is yes, then there needs to be a solution.
Not a yeah its plausible try to hack it approach.

If the OP cannot hack the system, but an attacker uses the exact methods
he's described here, then that would be pretty embarrassing for all parties.


Martijn Dashorst wrote:

I can claim anything in thought experiments. That is easy. Making it
true is something different.

Martijn





smime.p7s
Description: S/MIME Cryptographic Signature


Re: Security Features offered by Wicket

2008-03-04 Thread Sebastiaan van Erk

Hi,

The tampering with data part is resolved by Wicket, since Wicket does 
not use hidden fields but stores the data in the session on the server side.


Furthermore, Wicket by default does server side validation of all input, 
even if you add ajaxy behaviors to also do client side validation.


Regards,
Sebastiaan

Arthur Ahiceh wrote:

I believe that answers the original question, that CSRF protection is

*NOT* a security feature offered by Wicket.

I think the same, I said it and they tell me that URLs wasn't predictables
when the page identifiers are a correlative numbers, so vulnerable to CSRF
attacks.

I want to emphasize that I think that these tasks (avoid CSRF attacks, to
offer confidentiality, avoid tampering data in forms) would must be resolved
by default by frameworks like Wicket to offer a security framework.

Arthur.







2008/3/4, Sebastiaan van Erk [EMAIL PROTECTED]:

Wicket does nothing to protect from CSRF attacks, and it is trivially
vulnerable. Sure it's a lot more difficult with the standard
?wicket:interface type URLs than it would be with more predictable URLs,
but you can still quite easily guess the URLs, and futhermore, to
improve your chances of success you can simply include many images in
the attacking page with different values for the URLs, i.e.,

img
src=
http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1


and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in
one page.

Furthermore, most people actually LIKE predictable urls and go to great
length to mount pages and make them bookmarkable. There's even a
StatelessForm component, which is entirely vulnerable to CSRF.

Thus, I'd say that even without a quickstart, it's obvious that Wicket
does not offer any CSRF protection out of the box, and that if you want
this kind of protection, you will have to do it yourself (which is
probably not really difficult; though I think many people are not aware
of these kind of attack vectors and don't even think about it, which is
why it would be nice if Wicket *could* do it out of the box).

I believe that answers the original question, that CSRF protection is
*NOT* a security feature offered by Wicket.

Regards,
Sebastiaan

Nino Saturnino Martinez Vazquez Wael wrote:

While that is true.. It's also true that wicket devs favor stuff proven
with a quickstart, because it becomes easier to make a fix for something
you can see in code..

So as I've written once before a quickstart should be the way to go or
just use one of the existing applications, phone book or blog tutorial
etc. And make a hack at that...

regards Nino

Ned Collyer wrote:

Nick, I think you would be quite surprised at the level of auditing
something
has to pass to be used in a financial system, especially a bank.
(unless u
have some dodgy bank)

If something is theoretically possible, then thats as good as proven.

Gotta remember that hackers are a lot smarter in many instances than

the

people who wrote the software to keep them out.


Nick Heudecker wrote:


Arthur,

Only what you can *prove* matters, not what you think.  Have you

created

an
example application with a CSRF attack?










smime.p7s
Description: S/MIME Cryptographic Signature


Re: Security Features offered by Wicket

2008-03-04 Thread Sebastiaan van Erk

Hi,

Nino Saturnino Martinez Vazquez Wael wrote:
As with all thing's you can make them more or less secure. As stated 
before, depending on a level of paranoia nothing are secure!


But that's got nothing to do with the question: does Wicket offer 
security feature X? Nor does it help answer the follow up question: 
should Wicket off security feature X?


If the application is a web one, well use CSRF attacks, use random 
attacks, Bruteforce the site, go to their operator and get inside the 
database. Eventually you will get in, if you cover your tracks.


I disagree. You don't necessary eventually get in. Brute force is 
infeasible (in well designed systems). Going to their operator leaves 
tracks and has high risk and high costs. Doing a CSRF attack is easy, 
anonymous, and can be done remotely.



Nothing is secure.


Oh darn, well I guess I'll just remove my password protection from my 
computer, it's not secure anyway!!!


Having an quickstart as a usecase could help developers decide if its 
worth the effort. Whats a reasonable level for security... I guess the 
best one is telling the users to use the browser exclusivly for the bank 
site and be sure to logout before leaving it.


I don't see how a quickstart will help... Maybe it will help show *what* 
a CSRF attack is for those who don't know. :-)


I think the original poster makes a good point. I think a CSRF attack is 
relatively high risk, and relatively low cost to fix. All it takes (I 
think, don't pin me on this, I have to research it a bit more) is 
something like a secure token to be kept in the state of the form which 
must be sent back on submit by the user, which is then matched. The 
wicket user does not have to know about this at all, it is transparent. 
As added benefit it blocks double form posts.


In the case that it is desired that posts can be made without first 
having to request the page with the form, one should be able to turn 
CSRF protection off.


Considering its 1) ease of implementation, 2) low intrusiveness, 3) 
added value, I definately think it's worth considering protecting Wicket 
from CSRF by default.


Regards,
Sebastiaan




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Security Features offered by Wicket

2008-03-04 Thread Sebastiaan van Erk
How does the crypted web url request coding strategy work with 
bookmarkable pages and nice urls? Do they play nice together?


The form with the token looks good, the question I have is, why is 
something like it not the default (since almost everybody's site will be 
vulnerable without it)?


Currently protection from CSRF requires people 1) to know about CSRF and 
either 2a) to code their own form solution (which might be broken) or to 
rip it from the web (which might also be broken ;-)), or 2b) to enable 
the CryptedUrlWebRequestCodingStrategy.


In any case, knowledge of such attacks is required and an action needs 
to be taken, if you want to be protected. That's something maybe the 
framework could do for you?


Regards,
Sebastiaan

Nino Saturnino Martinez Vazquez Wael wrote:

Hmm, Im a little slow this week.. Theres even an article about it:

http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html 



Johan Compagner wrote:

Wicket has support for protection just enable it:

CryptedUrlWebRequestCodingStrategy

and you can use that in combination with:

UrlCompressingWebRequestProcessor

The problem with this is i guess that the normal form get then also still
works but i am not sure






On Tue, Mar 4, 2008 at 11:42 AM, Sebastiaan van Erk [EMAIL PROTECTED]
wrote:

 

Wicket does nothing to protect from CSRF attacks, and it is trivially
vulnerable. Sure it's a lot more difficult with the standard
?wicket:interface type URLs than it would be with more predictable URLs,
but you can still quite easily guess the URLs, and futhermore, to
improve your chances of success you can simply include many images in
the attacking page with different values for the URLs, i.e.,

img
src=
http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::myparam1=val1 




and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all in
one page.

Furthermore, most people actually LIKE predictable urls and go to great
length to mount pages and make them bookmarkable. There's even a
StatelessForm component, which is entirely vulnerable to CSRF.

Thus, I'd say that even without a quickstart, it's obvious that Wicket
does not offer any CSRF protection out of the box, and that if you want
this kind of protection, you will have to do it yourself (which is
probably not really difficult; though I think many people are not aware
of these kind of attack vectors and don't even think about it, which is
why it would be nice if Wicket *could* do it out of the box).

I believe that answers the original question, that CSRF protection is
*NOT* a security feature offered by Wicket.

Regards,
Sebastiaan

Nino Saturnino Martinez Vazquez Wael wrote:
   

While that is true.. It's also true that wicket devs favor stuff proven
with a quickstart, because it becomes easier to make a fix for 
something

you can see in code..

So as I've written once before a quickstart should be the way to go or
just use one of the existing applications, phone book or blog tutorial
etc. And make a hack at that...

regards Nino

Ned Collyer wrote:
 

Nick, I think you would be quite surprised at the level of auditing
something
has to pass to be used in a financial system, especially a bank.
(unless u
have some dodgy bank)

If something is theoretically possible, then thats as good as 
proven.


Gotta remember that hackers are a lot smarter in many instances than


the
   

people who wrote the software to keep them out.


Nick Heudecker wrote:

   

Arthur,

Only what you can *prove* matters, not what you think.  Have you
  

created
   

an
example application with a CSRF attack?


  



  




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Page title when using markup inheritance

2008-03-04 Thread Sebastiaan van Erk
I do basically the same thing, but since the title does not change on my 
pages I see no need to have a (dynamic) model for the property, plus I 
just use the constructor to set it, which saves some loc. In other words:


public abstract class BasePage extends WebPage
{
  // ...
  public BasePage(String title)
  {
add(new Label(title, title));
  }
}

public class SubPage extends BasePage
{
  public SubPage(PageParameters parameters) {
 super(whatever title);
  }
}

If you need the page parameters in the BasePage constructor then feel 
free to pass them with the constructor too...


Regards,
Sebastiaan

Kaspar Fischer wrote:
I am using markup inheritance (wicket:child and wicket:extend) and 
need to set the
page title from my subpage. I currently add a label in the base class 
(BasePage.java)
and make it use an abstract method getTitle(), which is overridden in 
the subclass

(SubPage.java). Has anybody found a better way?

Here's my solution:

!-- BasePage.html --
html
head
  title wicket:id=title[Page title]/title
/head
body
  wicket:child/
/body
/html

!-- SubPage.html --
wicket:extend
  !-- anything ... --
/wicket:extend


public abstract class BasePage extends WebPage
{
  // ...
  public BasePage(final PageParameters parameters)
  {
add(new Label(title, new PropertyModel(this, title)));
  }
  public abstract String getTitle();
}

public class SubPage extends BasePage
{
  // ...
  public String getTitle()
  {
return whatever title;
  }
}

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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Page title when using markup inheritance

2008-03-04 Thread Sebastiaan van Erk

James Carman wrote:


The problem with this approach is that you're not able to localize the
title if you hard-code it.  What I've done is actually specify a key
for my messages file and I use that.  So, every page has to define its
page.title key in its PageClass.properties file.


That's what I do it too. :-) In applications that are localized I change the

add(new Label(title, title))

with

add(new Label(title, new StringResourceModel(titleKey, this, new 
CompoundPropertyModel(this)));


This has the added benefit that you can do nice property substitutions, 
that is, if the titleKey resolves to Profile for ${session.userName} 
then you'll get a nice title Profile for Sebastiaan dynamically. :-) I 
don't use a static key though (like page.title) because my keys come 
from the database and I have little web page with a tree view where you 
can edit the key values. :-)


Regards,
Sebastiaan


 Kaspar Fischer wrote:
  I am using markup inheritance (wicket:child and wicket:extend) and
  need to set the
  page title from my subpage. I currently add a label in the base class
  (BasePage.java)
  and make it use an abstract method getTitle(), which is overridden in
  the subclass
  (SubPage.java). Has anybody found a better way?
 
  Here's my solution:
 
  !-- BasePage.html --
  html
  head
title wicket:id=title[Page title]/title
  /head
  body
wicket:child/
  /body
  /html
 
  !-- SubPage.html --
  wicket:extend
!-- anything ... --
  /wicket:extend
 
 
  public abstract class BasePage extends WebPage
  {
// ...
public BasePage(final PageParameters parameters)
{
  add(new Label(title, new PropertyModel(this, title)));
}
public abstract String getTitle();
  }
 
  public class SubPage extends BasePage
  {
// ...
public String getTitle()
{
  return whatever title;
}
  }
 
  -
  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: SpringBean in AuthenticatedWebSession

2008-02-29 Thread Sebastiaan van Erk

One option is to add:

InjectorHolder.getInjector().inject(this)

In your session constructor.

Regards,
Sebastiaan

Bert Radke wrote:

Hi List,

thanks to the help i received so far here, i managed to load objects
through JPA using DAOs.
The DAOs get injected just fine using the wicket-spring extension (i
used the blog example [1]
as a starting point). So this is all fine, but now i tried using the
same technique to load and
verify a user for login purposes, but the userDao does not get injected.

My Session extends AuthenticatedWebSession and is created fine, but no
DAO is injected.

@SpringBean(name = userDao)
private UserDao dao;

the userDao is defined in the application.xml just like all the others...

Do i have to take any additional steps to get Spring to inject the DAO
into the session?

[1] http://cwiki.apache.org/WICKET/blog-tutorial.html

Thanks in advance for your time.
Bert

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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Small shared resource question...

2008-02-27 Thread Sebastiaan van Erk

Hi,

The resource key for a shared resource is generated by the following 
method which I'm not allowed to call.


/**
 * THIS METHOD IS NOT PART OF THE WICKET PUBLIC API. DO NOT CALL IT.
 *
 * @param scope
 *The scope of the resource
 * @param path
 *The resource path
 * @param locale
 *The locale
 * @param style
 *The style (see [EMAIL PROTECTED] 
org.apache.wicket.Session})
 * @return The localized path
 */
	public String resourceKey(final Class scope, final String path, final 
Locale locale,

final String style)
{
String alias = (String)classAliasMap.get(scope);
if (alias == null)
{
alias = scope.getName();
}
return alias + '/' + resourceKey(path, locale, style);
}

I add the resource using the following method:

/**
 * Adds a resource.
 *
 * @param name
 *Logical name of resource
 * @param resource
 *Resource to store
 */
public final void add(final String name, final Resource resource)
{
add(Application.class, name, null, null, resource);
}

Which decides for me that the scope is Application.class. Now all this 
is fine, except I don't really like the fact that I don't get the 
resource key and have to make a new throwaway ResourceReference to get 
at it.


I was wondering, could add not just return the resource key of the added 
resource?


Regards,
Sebastiaan


Sebastiaan van Erk wrote:

Johan Compagner wrote:

Isnt the getResourceKey() returning exactly the name? It should
because else the first call to shared resources with just the name
doesnt make much sense! Those should be the same.


Well I tried using the name first and it kept complaining that it 
couldn't find the resource, so I just tried this ResourceReference thing 
not expecting it to work but it did. I added a log line to the 
application.init() and it says:


mounted resource: name=cvs_nl.pdf 
key=org.apache.wicket.Application/cvs_nl.pdf


Thus the name and key are *not* the same, and mounting by name did not 
work.



Also doesnt ResourceLink uses LocalizedImageResource? That one takes
care of that. But i guess it needs a resource per locale also in the
shared resources. So that the shared resource key is there for all the
locales.


In my web page with the resource link I do the following:

fragment.add(new ResourceLink(cvEnglishLink, new 
ResourceReference(cvs_en.pdf)) {

@Override
public boolean isVisible() {
return en.equals(getLocale().getLanguage());
}
});

It's a bit of a dirty hack, but it works. As you can see, I make a 
ResourceLink with a ResourceReference. I don't even know *how* to make 
the referenced resource different for two locales. The names of the 
resource are just cvs_ + language + .pdf. I don't see that 
ResourceLink uses LocalizedImageResource anywhere. There is this 
somewhat cryptic comment though in ResourceLink:


protected final CharSequence getURL()
{
if (resourceReference != null)
{
// TODO post 1.2: should we have support for locale changes 
when the

// resource reference (or resource??) is set manually..
// We should get a new resource reference for the current 
locale

// then
// that points to the same resource but with another locale 
if it

// exists.
// something like
// 
SharedResource.getResourceReferenceForLocale(resourceReference);


resourceReference.bind(getApplication());
return getRequestCycle().urlFor(resourceReference, 
resourceParameters);

}
return urlFor(IResourceListener.INTERFACE);
}

It seems that I need to register a resource with the same name for 
different locales? But can I still mount them on different paths then? 
And obviously, what the comment alludes to would need to be implemented 
of course. :-)


So what I would want to do is mount the English resource on 
/downloads/cvs_en.pdf, the Dutch resource on /downloads/cvs_nl.pdf 
and have a resource link on my page which links to the proper one 
depending on the locale.


Regards,
Sebastiaan




On 2/24/08, Sebastiaan van Erk [EMAIL PROTECTED] wrote:

Hi,

I register some DynamicWebResources in my Application's init method, as
well as mount them (in a loop, a different one for every locale):

getSharedResources().add(name, resource);
mountSharedResource(/downloads/ + name, new
ResourceReference(name).getSharedResourceKey());

I was wondering if there was another way to get the shared resource key
without having to construct a throwaway resource reference.

Futherhmore, in a web page I want

Re: Small shared resource question...

2008-02-27 Thread Sebastiaan van Erk

Hi,

Thanks for the answer.

I don't quite understand it though!

As far as I can tell, there's still only 1 resource, which has the 
locale of the page (at creation time).


But I have a link on the page which allows you to change the locale. 
This link is stateful, so it just calls the callback on the current page 
and sets the locale.


Since one ResourceReference doesn't seem to have more than one (version 
of a) Resource associated with it, I don't see how the code below is 
going to help me...


Thus my situation is:

I have 2 versions of a resource, an english generated pdf and a dutch 
one. They represent the same content, but in different languages. I want 
to mount them respectively on /downloads/cvs_en.pdf and 
/downloads/cvs_nl.pdf (in general, /downloads/resourcename_locale.pdf).
And I want a resource link in the page which links to the proper one of 
the two depending on the current locale...


Currently I just have multiple links, one to each (version of the) 
resource, with only one link visible at a time, but that feels like a 
hack to me.


Regards,
Sebastiaan

Kent Tong wrote:


Sebastiaan van Erk wrote:

In my web page with the resource link I do the following:

	fragment.add(new ResourceLink(cvEnglishLink, new 
ResourceReference(cvs_en.pdf)) {

@Override
public boolean isVisible() {
return en.equals(getLocale().getLanguage());
}
});



Try:

public class P1 extends WebPage {
public P1() {
ResourceReference resourceRef = new 
ResourceReference(cvs.pdf) {
protected Resource newResource() {
return new PDFResource(getLocale());
}
};
resourceRef.setLocale(getLocale()); //THIS IS THE LINE
ResourceLink link = new ResourceLink(link, resourceRef);
add(link);
}
}



-
--
Kent Tong
Wicket tutorials freely available at http://www.agileskills2.org/EWDW
Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA


smime.p7s
Description: S/MIME Cryptographic Signature


Re: Small shared resource question...

2008-02-27 Thread Sebastiaan van Erk



Kent Tong wrote:


Sebastiaan van Erk wrote:
As far as I can tell, there's still only 1 resource, which has the 
locale of the page (at creation time).




Every time the page is rendered, it will generate a different variant of
the resource reference due to the setLocale() call.


Sebastiaan van Erk wrote:
But I have a link on the page which allows you to change the locale. 
This link is stateful, so it just calls the callback on the current page 
and sets the locale.




No problem. If the link is a normal link (not ajax), you'll render the
page again and thus will have a new resource reference. If it's
ajax, you need to put the setLocale() call into a callback and
refresh the link.



Your code was:

public class P1 extends WebPage {
public P1() {
ResourceReference resourceRef = new ResourceReference(cvs.pdf) {
protected Resource newResource() {
return new PDFResource(getLocale());
}
};
resourceRef.setLocale(getLocale()); //THIS IS THE LINE
ResourceLink link = new ResourceLink(link, resourceRef);
add(link);
}
}

As far as I can see, the line marked //THIS IS THE LINE is only called 
in the constructor, which means it's called every time the page is 
*constructed* and not every time the page is *rendered*.


You're right that I could do the setLocale() on the reference manually 
in the callback (I'd have to do that for a non-ajax locale link as 
well). However, I don't really like that solution either, because my 
switch locale links are on a ChangeLocalePanel which knows nothing about 
my page or the resource links on that page (and shouldn't as far as I'm 
concerned).


The last problem, and the problem which might actually require me to 
have 2 different resources is that I want the shared resources for 
different locales to be mounted on *different* locations, 
/dowloads/resourceX_localeY.pdf. I've tried variations on the code 
above, but I couldn't get it working (for one, the ResourceReference 
class seems to require that it's string argument is the name of the 
shared resource, and thus I can't have 2 different mount paths which 
always work regardless of the locale you're in: i.e., if you're in the 
Dutch locale and you request /downloads/cvs_en.pdf I want you to get the 
English version).


Regards,
Sebastiaan


-
--
Kent Tong
Wicket tutorials freely available at http://www.agileskills2.org/EWDW
Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA


smime.p7s
Description: S/MIME Cryptographic Signature


Re: CompoundModel based on proxies

2008-02-26 Thread Sebastiaan van Erk

Matej Knopp wrote:

model.getFirstName() can't really return IModel, if
Customer.getFirstName() returns string.

Anyway, I like the idea, but I don't like the syntax. instead of one
line [add(new TextField(id, model).setRequred(true)) ] you have now
three separate lines.

So I was thinking of something more like

SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer);

add(new TextField(tf, model.bind(model.proxy().getCustomerName()
)).setRequired(true));

This way you can have it one one line.

-Matej


So proxy() returns a Customer proxy?

And model.bind() takes an Object argument (considering we don't know in 
advance what type getCustomerName() returns)... What about primitive 
types? Overload bind() for those as well?


And the call to getCustomerName() has the side effect of setting a model 
 object somewhere (e.g., in an instance field of model) which 
model.bind() can subsequently return?


Very interesting. I don't like the proxy() method name though. If you 
call it something like property() it will look more like you're binding 
to a property of Customer:


model.bind(model.property().getCustomerName())

VERY neat idea though... :-)

Regards,
Sebastiaan



On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote:

don't worry about creating the models
 That will happen anyway in 1.3 (that needs to be done for example to get the
 right object especially when we generify stuff)

 see CompoundPropertyModel.wrapOnInheritance()

 joan





 On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote:

  Interesting.  So
 
model.getFirstName()
 
  would return a PropetyModel based on the results of proxy.eval()?  If
  I understand you correctly that creates many models (one per
  component) instead of reusing a single model, but that may well not be
  the end of the world.  Or does getFirstName() return a CompoundModel
  that is properly bound this this component?  Intriguing none the less.
   I hadn't considered this option, but I'm going to play with it a bit.
   I rather like that direction.
 
 
  On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote:
   i try to look at this this weekend, but i have a quick question
   I find it a bit verbose can't it be a bit shorter like this (just an
   example)
  
   SharedPropertyModelCustomer model = new
   SharedPropertyModelCustomer(customer);
   this.setModel(model);
  
   FormComponent firstName = new CustomerNameField(firstName,
   model.getFirstName()).setRequired(true);
   add(firstName);
  
   where getFirstName() returns the model
  
   johan
  
  
  
  
  
   On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote:
  
One of our more clever developers created a CompoundPropertyModel that
uses a cglib proxy to strongly bind the mutators to the model.  It
looks like this:
   
   SharedPropertyModelCustomer model = new
SharedPropertyModelCustomer(customer);
   this.setModel(model);
   
   FormComponent firstName = new
CustomerNameField(firstName).setRequired(true);
   model.bind(firstName).to().getFirstName();
   add(firstName);
   
   FormComponent lastName = new
CustomerNameField(lastName).setRequired(true);
   model.bind(lastName).to().getLastName();
   add(lastName);
   
   FormComponent addr1 = new
AddressField(address1).setRequired(true);
   model.bind(addr1).to().getAddress().getAddress1();
   add(addr1);
   
   FormComponent addr2 = new AddressField(address2);
   model.bind(addr2).to().getAddress().getAddress2();
   add(addr2);
   
   FormComponent city = new CityField(city);
   model.bind(city).to().getAddress().getCity();
   add(city);
   
We're happy to share if folk like this approach.  N.B. that the .to()
call is for readability rather than out of any necessity.
   
Cheers,
Scott
   
--
Scott Swank
reformed mathematician
   
  
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
 
 
 
  --
   Scott Swank
  reformed mathematician
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 







smime.p7s
Description: S/MIME Cryptographic Signature


Re: CompoundModel based on proxies

2008-02-26 Thread Sebastiaan van Erk

Matej Knopp wrote:

Hi,

On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:

Matej Knopp wrote:
  model.getFirstName() can't really return IModel, if
  Customer.getFirstName() returns string.
 
  Anyway, I like the idea, but I don't like the syntax. instead of one
  line [add(new TextField(id, model).setRequred(true)) ] you have now
  three separate lines.
 
  So I was thinking of something more like
 
  SafePropertyModelCustomer model = new 
SafePropertyModelCustomer(customer);
 
  add(new TextField(tf, model.bind(model.proxy().getCustomerName()
  )).setRequired(true));
 
  This way you can have it one one line.
 
  -Matej

 So proxy() returns a Customer proxy?

 And model.bind() takes an Object argument (considering we don't know in
 advance what type getCustomerName() returns)... What about primitive
 types? Overload bind() for those as well?

Well, the return object is not important at all. What is important is
the getCustomerName() call. That marks somewhere in the model that
last accessed property was called customerName. and then immediately
after this model.bind takes this information.


OK, that's what I described. :-) And I was being stupid with respect to 
the overloading. If bind takes an object as argument, then overloading 
will not be necessary due to autoboxing. :-)



 And the call to getCustomerName() has the side effect of setting a model
  object somewhere (e.g., in an instance field of model) which
 model.bind() can subsequently return?

Model bind will return a model (variation of propertymodel probably).
It will take the information that getCustomerName call on proxy
provided.


Ok, so the proxy remembers which getter was called last, and you use 
that to construct the model in bind(). Of course.



 Very interesting. I don't like the proxy() method name though. If you
 call it something like property() it will look more like you're binding
 to a property of Customer:

Well, the naming can certainly be improved. I'm not sure about
property() though. Well, we can discuss this more anyway.

 model.bind(model.property().getCustomerName())


Neither am I. :-) For one, it's quite long. But on the other hand, you 
do bind to a model property, and so it reads ok. I think that proxies 
should be invisible for general users, so they shouldn't have to 
understand the magic going on here, nor that proxies are involved.



 VERY neat idea though... :-)

Thanks.


What I really like about this solution is that it can be implemented 
completely separately from wicket-core, so you can just put it in it's 
own project. :-)


Regards,
Sebastiaan


-Matej

 Regards,
 Sebastiaan



 
  On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote:
  don't worry about creating the models
   That will happen anyway in 1.3 (that needs to be done for example to get 
the
   right object especially when we generify stuff)
 
   see CompoundPropertyModel.wrapOnInheritance()
 
   joan
 
 
 
 
 
   On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote:
 
Interesting.  So
   
  model.getFirstName()
   
would return a PropetyModel based on the results of proxy.eval()?  If
I understand you correctly that creates many models (one per
component) instead of reusing a single model, but that may well not be
the end of the world.  Or does getFirstName() return a CompoundModel
that is properly bound this this component?  Intriguing none the less.
 I hadn't considered this option, but I'm going to play with it a bit.
 I rather like that direction.
   
   
On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 i try to look at this this weekend, but i have a quick question
 I find it a bit verbose can't it be a bit shorter like this (just an
 example)

 SharedPropertyModelCustomer model = new
 SharedPropertyModelCustomer(customer);
 this.setModel(model);

 FormComponent firstName = new CustomerNameField(firstName,
 model.getFirstName()).setRequired(true);
 add(firstName);

 where getFirstName() returns the model

 johan





 On Feb 6, 2008 6:57 PM, Scott Swank [EMAIL PROTECTED] wrote:

  One of our more clever developers created a CompoundPropertyModel 
that
  uses a cglib proxy to strongly bind the mutators to the model.  It
  looks like this:
 
 SharedPropertyModelCustomer model = new
  SharedPropertyModelCustomer(customer);
 this.setModel(model);
 
 FormComponent firstName = new
  CustomerNameField(firstName).setRequired(true);
 model.bind(firstName).to().getFirstName();
 add(firstName);
 
 FormComponent lastName = new
  CustomerNameField(lastName).setRequired(true);
 model.bind(lastName).to().getLastName();
 add(lastName

Re: CompoundModel based on proxies

2008-02-26 Thread Sebastiaan van Erk
Well, there's a problem with normal PropertyModels (or 
CompoundPropertyModels).


For example, if you have the following textfield:

TextField tf = new TextField(name, new PropertyModel(customer, 
customerName));


Then a refactor of the customerName property (and the getCustomerName() 
method) in an IDE such as Eclipse or NetBeans will *silently* break the 
above code, which you will discover only at runtime...


The proxy based approach solves exactly this problem.

Regards,
Sebastiaan



atul singh wrote:

I feel this approach does NOT solve a problem.Its just an alternative ..

On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL PROTECTED] wrote:


We've reworked the implementation a bit,it works like this:


SafePropertyModelPerson p = new SafePropertyModelPerson(new Person());
TextField field = new TextField(name, p.bind(p.property
().getFirstName()));

It's attached to the JIRA issue:
https://issues.apache.org/jira/browse/WICKET-1327

-Matej


On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk
[EMAIL PROTECTED] wrote:

Matej Knopp wrote:
  Hi,
 
  On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk
  [EMAIL PROTECTED] wrote:
  Matej Knopp wrote:
model.getFirstName() can't really return IModel, if
Customer.getFirstName() returns string.
   
Anyway, I like the idea, but I don't like the syntax. instead of

one

line [add(new TextField(id, model).setRequred(true)) ] you have

now

three separate lines.
   
So I was thinking of something more like
   
SafePropertyModelCustomer model = new

SafePropertyModelCustomer(customer);

   
add(new TextField(tf, model.bind(model.proxy

().getCustomerName()

)).setRequired(true));
   
This way you can have it one one line.
   
-Matej
 
   So proxy() returns a Customer proxy?
 
   And model.bind() takes an Object argument (considering we don't

know in

   advance what type getCustomerName() returns)... What about

primitive

   types? Overload bind() for those as well?
  Well, the return object is not important at all. What is important is
  the getCustomerName() call. That marks somewhere in the model that
  last accessed property was called customerName. and then

immediately

  after this model.bind takes this information.

 OK, that's what I described. :-) And I was being stupid with respect to
 the overloading. If bind takes an object as argument, then overloading
 will not be necessary due to autoboxing. :-)


   And the call to getCustomerName() has the side effect of setting a

model

object somewhere (e.g., in an instance field of model) which
   model.bind() can subsequently return?
  Model bind will return a model (variation of propertymodel probably).
  It will take the information that getCustomerName call on proxy
  provided.

 Ok, so the proxy remembers which getter was called last, and you use
 that to construct the model in bind(). Of course.


   Very interesting. I don't like the proxy() method name though. If

you

   call it something like property() it will look more like you're

binding

   to a property of Customer:
  Well, the naming can certainly be improved. I'm not sure about
  property() though. Well, we can discuss this more anyway.
   model.bind(model.property().getCustomerName())

 Neither am I. :-) For one, it's quite long. But on the other hand, you
 do bind to a model property, and so it reads ok. I think that proxies
 should be invisible for general users, so they shouldn't have to
 understand the magic going on here, nor that proxies are involved.


   VERY neat idea though... :-)
  Thanks.

 What I really like about this solution is that it can be implemented
 completely separately from wicket-core, so you can just put it in it's
 own project. :-)

 Regards,
 Sebastiaan



  -Matej
   Regards,
   Sebastiaan
 
 
 
   
On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner 

[EMAIL PROTECTED] wrote:

don't worry about creating the models
 That will happen anyway in 1.3 (that needs to be done for

example to get the

 right object especially when we generify stuff)
   
 see CompoundPropertyModel.wrapOnInheritance()
   
 joan
   
   
   
   
   
 On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED]

wrote:

   
  Interesting.  So
 
model.getFirstName()
 
  would return a PropetyModel based on the results of

proxy.eval()?  If

  I understand you correctly that creates many models (one per
  component) instead of reusing a single model, but that may

well not be

  the end of the world.  Or does getFirstName() return a

CompoundModel

  that is properly bound this this component?  Intriguing none

the less.

   I hadn't considered this option, but I'm going to play with

it a bit.

   I rather like that direction.
 
 
  On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED]

wrote:

   i try to look at this this weekend, but i have a quick

question

   I find it a bit verbose can't

Small shared resource question...

2008-02-24 Thread Sebastiaan van Erk

Hi,

I register some DynamicWebResources in my Application's init method, as 
well as mount them (in a loop, a different one for every locale):


getSharedResources().add(name, resource);
	mountSharedResource(/downloads/ + name, new 
ResourceReference(name).getSharedResourceKey());


I was wondering if there was another way to get the shared resource key 
without having to construct a throwaway resource reference.


Futherhmore, in a web page I want to link to the shared resources, i.e, 
I thought of using a ResourceLink. However, I was wondering how I can 
make sure that the resource being linked to is the correct (localized) 
resource. (They're generated PDF's, one in English, one in Dutch, and I 
want the link to point to the correct one depending on the locale). My 
currentsolution is just to have 2 links and override isVisible() on each 
of them to check the locale, but I don't know if that's the correct 
way to go about it.


Regards,
Sebastiaan


smime.p7s
Description: S/MIME Cryptographic Signature


  1   2   >