date:20080522

It isnt all or nothing.. i never said that

I just say if you dont want Component but you do want IModel
then you will get a warning at getModel()
we as a framework shouldnt hide the warning at that call.

But i am also curious how many people get really the model back from a
component (not counting specific places like repeaters.onpopuplate)

because i think most people do component.getModelObject() which then needs a
cast

But i like that extra helper method way more then having an extra
getUnsafeModel() method..
because thats explicit a developer has to really choose for it.

i think there are 3 options

1 keep it what we have now, tweak it with the feedback we get from 1.4M2
2 drop it on Component only and have a class like you described above to do
this:  IModelString model = Unsafe.cast(component.getModel()); (its still
a hack and a sense of false security but ok. if people really want this..)
3 drop it on Component and Model


i am +1 on 1
and -0 on 2 and 3

I still think it is not bad. and you can come around it really easy by just
creating a few extra classes like

StringLabel
NumberLabel
StringTextField
NumberTextField

if you only have a few of those extra all your code is cleanup

johan

On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED] wrote:

 Yeah, it could even be in its separate utility class:

 interface IModelT {}

 class Component {
private IModel? model;

 public IModel? getModel() {
return model;
}
 }

 public class Unsafe {
public static T IModelT cast(IModel? model) {
 return (IModelT) model;
}
 }

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

 I'm merely pointing out that there exists a solution to do unsafe cast
 without getting compiler warning. Just like normal casts are handled.

 I don't think Johan's all or nothing proposition is very pragmatic one.
 Without generic IModel we do not get any API discoverability and our
 APIs continue to suck. For instance, how can API user know what kind of
 model this needs: MyJuicyComponent(String id, IModel model). At one
 point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
 model) but this convention is far from optimal. To be sure, one needs to
 browse the sources...

 Joni

 On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
  Well, maybe it really is a hack that's too ugly. We might have two
 methods,
 
  default getModel() that doesn't cast it and alternative convenience
  one that does.
 
  -Matej
 
  On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 class Component {
 private IModel? model;
  
 public T IModelT getModel() {
 return (IModelT) model;
 }
 }
  
   I like this. Even with the possible class cast exception. Because
   without generics, it doesn't leave you no other option than to cast it
   to your model, which isn't much better either, as you get the same
   result except that it looks uglier.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
 [EMAIL PROTECTED] wrote:
   no i am really against that falls V IModelV getModel() method
   that really abuses everything that generics stands for. For such a
 basic
   thing.
   this is really bad programming
   If we drop it we also pretty much drop it from IModel or have warnings
 in
   the user code.
  
   But then drop it completely is better because then we have to do a
 cast and
   you really think about that
   Not having that fake assurance..
  
   johan
  
  
   On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
   [EMAIL PROTECTED] wrote:
  
   Before we do a vote I want to make sure what our alternatives are.
  
   I still like Joni's alternative. I don't think they are an
   abomination, because the /potential/ class cast exception you get is
   the same as with current 1.3. But the benefit of documenting the
 model
   parameters in DDC, LV, etc. is HUGE.
  
   I really appreciate the time and effort that went into implementing
   the generification. But I also see what kind of mess this brought and
   I really don't like the Component generification part.
  
   Martijn
  
   On Wed, May 21, 2008 at 9:24 PM, Igor Vaynberg 
 [EMAIL PROTECTED]
   wrote:
ok so we pretty much have some core people wanting to back out the
generics support.
   
shall we start a vote? johan, gerolf and i have spent a ridiculous
amount of time trying to generify the codebase and remove all the
shitty warnings. if there is even a slight chance of this getting
backed out i do not want to spend any more time on this until the
issue is resolved.
   
also we should halt m2 until this is resolved.
   
personally i do not mind backing out generics, they turned out to
 be
quiet a disappointment for me as well, but my feelings about this
 are
not strong.
   
we can still use generics such as setresponsepage(class? extends

Re: localization properties file

2008-05-22 Thread Eyal Golan

thanks :)

On Thu, May 22, 2008 at 10:25 AM, Gwyn Evans [EMAIL PROTECTED] wrote:

 See http://cwiki.apache.org/WICKET/i18n-and-resource-bundles.html for
 more options

 On Thu, May 22, 2008 at 8:05 AM, Maurice Marrink [EMAIL PROTECTED]
 wrote:
  That would be the easiest yes.
 
  Maurice
 
  On Thu, May 22, 2008 at 7:45 AM, Eyal Golan [EMAIL PROTECTED] wrote:
  Hi,
  If I want a centralized properties file for localization, where should I
 put
  it and how should I call it?
  Is it supposed to be in the same folder as my WebApplication class?
  Is is supposed to have the same name as this class (with extension
  properties)?
 
  Thanks
 
  --
  Eyal Golan
  [EMAIL PROTECTED]
 
  Visit: http://jvdrums.sourceforge.net/
 
 
  -
  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]




-- 
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Matej Knopp

I would all be easier if getModel() and getModelObject() weren't
final. (I know there's a reason why they are, I'm not questioning it).

Then in your component subclass you coud do IModelInteger getModel()
{ return (IModelInteger)super.getModel() }, similiar with
getmodelobject so you wouldn't have casts all over places and it would
 be safer too).

-Matej

On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 It isnt all or nothing.. i never said that

 I just say if you dont want Component but you do want IModel
 then you will get a warning at getModel()
 we as a framework shouldnt hide the warning at that call.

 But i am also curious how many people get really the model back from a
 component (not counting specific places like repeaters.onpopuplate)

 because i think most people do component.getModelObject() which then needs a
 cast

 But i like that extra helper method way more then having an extra
 getUnsafeModel() method..
 because thats explicit a developer has to really choose for it.

 i think there are 3 options

 1 keep it what we have now, tweak it with the feedback we get from 1.4M2
 2 drop it on Component only and have a class like you described above to do
 this:  IModelString model = Unsafe.cast(component.getModel()); (its still
 a hack and a sense of false security but ok. if people really want this..)
 3 drop it on Component and Model


 i am +1 on 1
 and -0 on 2 and 3

 I still think it is not bad. and you can come around it really easy by just
 creating a few extra classes like

 StringLabel
 NumberLabel
 StringTextField
 NumberTextField

 if you only have a few of those extra all your code is cleanup

 johan

 On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED] wrote:

 Yeah, it could even be in its separate utility class:

 interface IModelT {}

 class Component {
private IModel? model;

 public IModel? getModel() {
return model;
}
 }

 public class Unsafe {
public static T IModelT cast(IModel? model) {
 return (IModelT) model;
}
 }

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

 I'm merely pointing out that there exists a solution to do unsafe cast
 without getting compiler warning. Just like normal casts are handled.

 I don't think Johan's all or nothing proposition is very pragmatic one.
 Without generic IModel we do not get any API discoverability and our
 APIs continue to suck. For instance, how can API user know what kind of
 model this needs: MyJuicyComponent(String id, IModel model). At one
 point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
 model) but this convention is far from optimal. To be sure, one needs to
 browse the sources...

 Joni

 On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
  Well, maybe it really is a hack that's too ugly. We might have two
 methods,
 
  default getModel() that doesn't cast it and alternative convenience
  one that does.
 
  -Matej
 
  On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 class Component {
 private IModel? model;
  
 public T IModelT getModel() {
 return (IModelT) model;
 }
 }
  
   I like this. Even with the possible class cast exception. Because
   without generics, it doesn't leave you no other option than to cast it
   to your model, which isn't much better either, as you get the same
   result except that it looks uglier.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
 [EMAIL PROTECTED] wrote:
   no i am really against that falls V IModelV getModel() method
   that really abuses everything that generics stands for. For such a
 basic
   thing.
   this is really bad programming
   If we drop it we also pretty much drop it from IModel or have warnings
 in
   the user code.
  
   But then drop it completely is better because then we have to do a
 cast and
   you really think about that
   Not having that fake assurance..
  
   johan
  
  
   On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
   [EMAIL PROTECTED] wrote:
  
   Before we do a vote I want to make sure what our alternatives are.
  
   I still like Joni's alternative. I don't think they are an
   abomination, because the /potential/ class cast exception you get is
   the same as with current 1.3. But the benefit of documenting the
 model
   parameters in DDC, LV, etc. is HUGE.
  
   I really appreciate the time and effort that went into implementing
   the generification. But I also see what kind of mess this brought and
   I really don't like the Component generification part.
  
   Martijn
  
   On Wed, May 21, 2008 at 9:24 PM, Igor Vaynberg 
 [EMAIL PROTECTED]
   wrote:
ok so we pretty much have some core people wanting to back out the
generics support.
   
shall we start a vote? johan, gerolf and i have spent a ridiculous
amount of time trying to generify the codebase and remove all the

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Matej Knopp

Although I'm not sure how many people call getModel/getModelObject
anyway. I think it's mostly about ListItems etc an i doubt anyone
would subclass it just because of getModel/getModelObject...

-Matej

On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED] wrote:
 I would all be easier if getModel() and getModelObject() weren't
 final. (I know there's a reason why they are, I'm not questioning it).

 Then in your component subclass you coud do IModelInteger getModel()
 { return (IModelInteger)super.getModel() }, similiar with
 getmodelobject so you wouldn't have casts all over places and it would
  be safer too).

 -Matej

 On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 It isnt all or nothing.. i never said that

 I just say if you dont want Component but you do want IModel
 then you will get a warning at getModel()
 we as a framework shouldnt hide the warning at that call.

 But i am also curious how many people get really the model back from a
 component (not counting specific places like repeaters.onpopuplate)

 because i think most people do component.getModelObject() which then needs a
 cast

 But i like that extra helper method way more then having an extra
 getUnsafeModel() method..
 because thats explicit a developer has to really choose for it.

 i think there are 3 options

 1 keep it what we have now, tweak it with the feedback we get from 1.4M2
 2 drop it on Component only and have a class like you described above to do
 this:  IModelString model = Unsafe.cast(component.getModel()); (its still
 a hack and a sense of false security but ok. if people really want this..)
 3 drop it on Component and Model


 i am +1 on 1
 and -0 on 2 and 3

 I still think it is not bad. and you can come around it really easy by just
 creating a few extra classes like

 StringLabel
 NumberLabel
 StringTextField
 NumberTextField

 if you only have a few of those extra all your code is cleanup

 johan

 On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED] wrote:

 Yeah, it could even be in its separate utility class:

 interface IModelT {}

 class Component {
private IModel? model;

 public IModel? getModel() {
return model;
}
 }

 public class Unsafe {
public static T IModelT cast(IModel? model) {
 return (IModelT) model;
}
 }

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

 I'm merely pointing out that there exists a solution to do unsafe cast
 without getting compiler warning. Just like normal casts are handled.

 I don't think Johan's all or nothing proposition is very pragmatic one.
 Without generic IModel we do not get any API discoverability and our
 APIs continue to suck. For instance, how can API user know what kind of
 model this needs: MyJuicyComponent(String id, IModel model). At one
 point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
 model) but this convention is far from optimal. To be sure, one needs to
 browse the sources...

 Joni

 On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
  Well, maybe it really is a hack that's too ugly. We might have two
 methods,
 
  default getModel() that doesn't cast it and alternative convenience
  one that does.
 
  -Matej
 
  On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 class Component {
 private IModel? model;
  
 public T IModelT getModel() {
 return (IModelT) model;
 }
 }
  
   I like this. Even with the possible class cast exception. Because
   without generics, it doesn't leave you no other option than to cast it
   to your model, which isn't much better either, as you get the same
   result except that it looks uglier.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
 [EMAIL PROTECTED] wrote:
   no i am really against that falls V IModelV getModel() method
   that really abuses everything that generics stands for. For such a
 basic
   thing.
   this is really bad programming
   If we drop it we also pretty much drop it from IModel or have warnings
 in
   the user code.
  
   But then drop it completely is better because then we have to do a
 cast and
   you really think about that
   Not having that fake assurance..
  
   johan
  
  
   On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
   [EMAIL PROTECTED] wrote:
  
   Before we do a vote I want to make sure what our alternatives are.
  
   I still like Joni's alternative. I don't think they are an
   abomination, because the /potential/ class cast exception you get is
   the same as with current 1.3. But the benefit of documenting the
 model
   parameters in DDC, LV, etc. is HUGE.
  
   I really appreciate the time and effort that went into implementing
   the generification. But I also see what kind of mess this brought and
   I really don't like the Component generification part.
  
   Martijn
  
   On Wed, May 21, 2008 at 9:24 PM, Igor

Re: AjaxLink not clickable in IE

2008-05-22 Thread richardwilko


I have found ie to be rubbish it comes to javascript, any error in any file
can stop all the javascript on the page working.  make sure you dont have
other javascript on the page which causes problems.

Also open up the wicket ajax debug window and see you anything happens in
there when you click on the link.


richard



igor.vaynberg wrote:
 
 wow. we spoil our users too much when they complain about not getting
 a response after 3 hours...
 
 -igor
 
 On Wed, May 21, 2008 at 5:24 PM, Michael Mehrle [EMAIL PROTECTED]
 wrote:
 Anyone? Or are we only talking generics today? ;-)

 Seriously, could use a 2nd pair of eyes on this one... any input
 appreciated.

 -Original Message-
 From: Michael Mehrle [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, May 21, 2008 2:31 PM
 To: users@wicket.apache.org
 Subject: AjaxLink not clickable in IE

 I've got this AjaxLink:



 fooLink = new AjaxLink(fooLink) {

@Override

public void
 onClick(AjaxRequestTarget target) {

Boolean
 selected = (Boolean) fooCheckBox.getModelObject();

if
 (!selected) {


 fooCheckBox.setModelObject((new Boolean(true)));

}


 target.addComponent(fooCheckBox);

// pop up
 the modal


 showRecurringFooModal(recurringFooModalWindow, target);

}

};



   wicket:message
 key=fooLabel / 



 Works fine in Safari and Firefox but in IE it's not clickable - looks
 like a link but the mouse pointer doesn't change and nothing happens
 when clicking. No error message either in IE's JS console or in AJAX.
 Any idea what I'm doing wrong here?



 Michael


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

-- 
View this message in context: 
http://www.nabble.com/AjaxLink-not-clickable-in-IE-tp17379705p17399591.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Tomcat discards content-type with StringRequestTarget

2008-05-22 Thread richardwilko


You could implement your own dynamic web resource.  eg for a kml page on our
site:


public class KMLResource extends DynamicWebResource
{

Document kml;

public KMLResource(Document kml)
{
this.kml = kml;
}

@Override
protected ResourceState getResourceState()
{
final XMLOutputter out = new XMLOutputter();

KMLResourceState kmlResourceState = new KMLResourceState();
try
{
ByteArrayOutputStream byteout = new 
ByteArrayOutputStream();
out.output(kml, byteout);
kmlResourceState.setData(byteout.toByteArray());
byteout.close();
}
catch (IOException e)
{
e.printStackTrace();
}
return kmlResourceState;
}


class KMLResourceState extends ResourceState
{
@Override
public String getContentType()
{
return application/vnd.google-earth.kml+xml;
}

private byte[] data = new byte[0];
@Override
public byte[] getData()
{
return data;
}
public void setData(byte[] data)
{
this.data = data;
}

@Override
public int getLength()
{
return data.length;
}
}
}

then use it like this in your page

final KMLResource kmlResource = new KMLResource(kml);

getRequestCycle().setRequestTarget(new IRequestTarget() {

public void detach(RequestCycle requestCycle) {

}
public void respond(RequestCycle requestCycle) {

ResourceStreamRequestTarget target = new
ResourceStreamRequestTarget(kmlResource.getResourceStream());
target.setFileName(name);

getRequestCycle().setRequestTarget(target); 
}
});

just alter it for text rather than a Document
-- 
View this message in context: 
http://www.nabble.com/Tomcat-discards-content-type-with-StringRequestTarget-tp17380397p17399964.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: (Class? extends Page?) casting troubles

But if you are willing to subclass it and make that extra method

Then why not subclass the component itself and for example:
IntegerTextFieldInteger
thats the same thing 1 subclass, no extra generics in your code...

johan


On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED] wrote:

 I would all be easier if getModel() and getModelObject() weren't
 final. (I know there's a reason why they are, I'm not questioning it).

 Then in your component subclass you coud do IModelInteger getModel()
 { return (IModelInteger)super.getModel() }, similiar with
 getmodelobject so you wouldn't have casts all over places and it would
  be safer too).

 -Matej

 On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  It isnt all or nothing.. i never said that
 
  I just say if you dont want Component but you do want IModel
  then you will get a warning at getModel()
  we as a framework shouldnt hide the warning at that call.
 
  But i am also curious how many people get really the model back from a
  component (not counting specific places like repeaters.onpopuplate)
 
  because i think most people do component.getModelObject() which then
 needs a
  cast
 
  But i like that extra helper method way more then having an extra
  getUnsafeModel() method..
  because thats explicit a developer has to really choose for it.
 
  i think there are 3 options
 
  1 keep it what we have now, tweak it with the feedback we get from 1.4M2
  2 drop it on Component only and have a class like you described above to
 do
  this:  IModelString model = Unsafe.cast(component.getModel()); (its
 still
  a hack and a sense of false security but ok. if people really want
 this..)
  3 drop it on Component and Model
 
 
  i am +1 on 1
  and -0 on 2 and 3
 
  I still think it is not bad. and you can come around it really easy by
 just
  creating a few extra classes like
 
  StringLabel
  NumberLabel
  StringTextField
  NumberTextField
 
  if you only have a few of those extra all your code is cleanup
 
  johan
 
  On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED]
 wrote:
 
  Yeah, it could even be in its separate utility class:
 
  interface IModelT {}
 
  class Component {
 private IModel? model;
 
  public IModel? getModel() {
 return model;
 }
  }
 
  public class Unsafe {
 public static T IModelT cast(IModel? model) {
  return (IModelT) model;
 }
  }
 
  class MyComp extends Component {
 public MyComp() {
  IModelInteger model = Unsafe.cast(getModel());
 }
  }
 
  I'm merely pointing out that there exists a solution to do unsafe cast
  without getting compiler warning. Just like normal casts are handled.
 
  I don't think Johan's all or nothing proposition is very pragmatic one.
  Without generic IModel we do not get any API discoverability and our
  APIs continue to suck. For instance, how can API user know what kind of
  model this needs: MyJuicyComponent(String id, IModel model). At one
  point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
  model) but this convention is far from optimal. To be sure, one needs to
  browse the sources...
 
  Joni
 
  On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
   Well, maybe it really is a hack that's too ugly. We might have two
  methods,
  
   default getModel() that doesn't cast it and alternative convenience
   one that does.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
  wrote:
  class Component {
  private IModel? model;
   
  public T IModelT getModel() {
  return (IModelT) model;
  }
  }
   
I like this. Even with the possible class cast exception. Because
without generics, it doesn't leave you no other option than to cast
 it
to your model, which isn't much better either, as you get the same
result except that it looks uglier.
   
-Matej
   
On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
  [EMAIL PROTECTED] wrote:
no i am really against that falls V IModelV getModel() method
that really abuses everything that generics stands for. For such a
  basic
thing.
this is really bad programming
If we drop it we also pretty much drop it from IModel or have
 warnings
  in
the user code.
   
But then drop it completely is better because then we have to do a
  cast and
you really think about that
Not having that fake assurance..
   
johan
   
   
On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:
   
Before we do a vote I want to make sure what our alternatives are.
   
I still like Joni's alternative. I don't think they are an
abomination, because the /potential/ class cast exception you get
 is
the same as with current 1.3. But the benefit of documenting the
  model
parameters in DDC, LV, etc. is HUGE.
   
I really appreciate the time and effort that went into
 implementing
the

Re: (Class? extends Page?) casting troubles

I often do the following:

populateItem(ListItem item) {
add(new Link(edit, item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
}

So both are used often, but mostly to pass things around.

Martijn

On Thu, May 22, 2008 at 11:25 AM, Johan Compagner [EMAIL PROTECTED] wrote:
 getModel() i agree, but getModelObject() is something that is used the most
 if i have to guess.

 Because in an onSubmit() of a form or a onClick of a Link what do most of
 you do?

 onSubmit()
 {
 dao.save(getModelObject())
 }

 onClick()
 {
 dao.delete(getModelObject())
 }

 johan

 On Thu, May 22, 2008 at 10:05 AM, Matej Knopp [EMAIL PROTECTED] wrote:

 Although I'm not sure how many people call getModel/getModelObject
 anyway. I think it's mostly about ListItems etc an i doubt anyone
 would subclass it just because of getModel/getModelObject...

 -Matej

 On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED]
 wrote:
  I would all be easier if getModel() and getModelObject() weren't
  final. (I know there's a reason why they are, I'm not questioning it).
 
  Then in your component subclass you coud do IModelInteger getModel()
  { return (IModelInteger)super.getModel() }, similiar with
  getmodelobject so you wouldn't have casts all over places and it would
   be safer too).
 
  -Matej
 
  On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  It isnt all or nothing.. i never said that
 
  I just say if you dont want Component but you do want IModel
  then you will get a warning at getModel()
  we as a framework shouldnt hide the warning at that call.
 
  But i am also curious how many people get really the model back from a
  component (not counting specific places like repeaters.onpopuplate)
 
  because i think most people do component.getModelObject() which then
 needs a
  cast
 
  But i like that extra helper method way more then having an extra
  getUnsafeModel() method..
  because thats explicit a developer has to really choose for it.
 
  i think there are 3 options
 
  1 keep it what we have now, tweak it with the feedback we get from
 1.4M2
  2 drop it on Component only and have a class like you described above
 to do
  this:  IModelString model = Unsafe.cast(component.getModel()); (its
 still
  a hack and a sense of false security but ok. if people really want
 this..)
  3 drop it on Component and Model
 
 
  i am +1 on 1
  and -0 on 2 and 3
 
  I still think it is not bad. and you can come around it really easy by
 just
  creating a few extra classes like
 
  StringLabel
  NumberLabel
  StringTextField
  NumberTextField
 
  if you only have a few of those extra all your code is cleanup
 
  johan
 
  On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED]
 wrote:
 
  Yeah, it could even be in its separate utility class:
 
  interface IModelT {}
 
  class Component {
 private IModel? model;
 
  public IModel? getModel() {
 return model;
 }
  }
 
  public class Unsafe {
 public static T IModelT cast(IModel? model) {
  return (IModelT) model;
 }
  }
 
  class MyComp extends Component {
 public MyComp() {
  IModelInteger model = Unsafe.cast(getModel());
 }
  }
 
  I'm merely pointing out that there exists a solution to do unsafe cast
  without getting compiler warning. Just like normal casts are handled.
 
  I don't think Johan's all or nothing proposition is very pragmatic one.
  Without generic IModel we do not get any API discoverability and our
  APIs continue to suck. For instance, how can API user know what kind of
  model this needs: MyJuicyComponent(String id, IModel model). At one
  point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
  model) but this convention is far from optimal. To be sure, one needs
 to
  browse the sources...
 
  Joni
 
  On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
   Well, maybe it really is a hack that's too ugly. We might have two
  methods,
  
   default getModel() that doesn't cast it and alternative convenience
   one that does.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 
  wrote:
  class Component {
  private IModel? model;
   
  public T IModelT getModel() {
  return (IModelT) model;
  }
  }
   
I like this. Even with the possible class cast exception. Because
without generics, it doesn't leave you no other option than to cast
 it
to your model, which isn't much better either, as you get the same
result except that it looks uglier.
   
-Matej
   
On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
  [EMAIL PROTECTED] wrote:
no i am really against that falls V IModelV getModel() method
that really abuses everything that generics stands for. For such a
  basic
thing.
this is really bad programming
If we drop it we also pretty much drop it from IModel or have
 warnings

Re: (Class? extends Page?) casting troubles

getModel() i agree, but getModelObject() is something that is used the most
if i have to guess.

Because in an onSubmit() of a form or a onClick of a Link what do most of
you do?

onSubmit()
{
dao.save(getModelObject())
}

onClick()
{
dao.delete(getModelObject())
}

johan

On Thu, May 22, 2008 at 10:05 AM, Matej Knopp [EMAIL PROTECTED] wrote:

 Although I'm not sure how many people call getModel/getModelObject
 anyway. I think it's mostly about ListItems etc an i doubt anyone
 would subclass it just because of getModel/getModelObject...

 -Matej

 On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED]
 wrote:
  I would all be easier if getModel() and getModelObject() weren't
  final. (I know there's a reason why they are, I'm not questioning it).
 
  Then in your component subclass you coud do IModelInteger getModel()
  { return (IModelInteger)super.getModel() }, similiar with
  getmodelobject so you wouldn't have casts all over places and it would
   be safer too).
 
  -Matej
 
  On Thu, May 22, 2008 at 9:39 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  It isnt all or nothing.. i never said that
 
  I just say if you dont want Component but you do want IModel
  then you will get a warning at getModel()
  we as a framework shouldnt hide the warning at that call.
 
  But i am also curious how many people get really the model back from a
  component (not counting specific places like repeaters.onpopuplate)
 
  because i think most people do component.getModelObject() which then
 needs a
  cast
 
  But i like that extra helper method way more then having an extra
  getUnsafeModel() method..
  because thats explicit a developer has to really choose for it.
 
  i think there are 3 options
 
  1 keep it what we have now, tweak it with the feedback we get from
 1.4M2
  2 drop it on Component only and have a class like you described above
 to do
  this:  IModelString model = Unsafe.cast(component.getModel()); (its
 still
  a hack and a sense of false security but ok. if people really want
 this..)
  3 drop it on Component and Model
 
 
  i am +1 on 1
  and -0 on 2 and 3
 
  I still think it is not bad. and you can come around it really easy by
 just
  creating a few extra classes like
 
  StringLabel
  NumberLabel
  StringTextField
  NumberTextField
 
  if you only have a few of those extra all your code is cleanup
 
  johan
 
  On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED]
 wrote:
 
  Yeah, it could even be in its separate utility class:
 
  interface IModelT {}
 
  class Component {
 private IModel? model;
 
  public IModel? getModel() {
 return model;
 }
  }
 
  public class Unsafe {
 public static T IModelT cast(IModel? model) {
  return (IModelT) model;
 }
  }
 
  class MyComp extends Component {
 public MyComp() {
  IModelInteger model = Unsafe.cast(getModel());
 }
  }
 
  I'm merely pointing out that there exists a solution to do unsafe cast
  without getting compiler warning. Just like normal casts are handled.
 
  I don't think Johan's all or nothing proposition is very pragmatic one.
  Without generic IModel we do not get any API discoverability and our
  APIs continue to suck. For instance, how can API user know what kind of
  model this needs: MyJuicyComponent(String id, IModel model). At one
  point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
  model) but this convention is far from optimal. To be sure, one needs
 to
  browse the sources...
 
  Joni
 
  On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
   Well, maybe it really is a hack that's too ugly. We might have two
  methods,
  
   default getModel() that doesn't cast it and alternative convenience
   one that does.
  
   -Matej
  
   On Wed, May 21, 2008 at 10:10 PM, Matej Knopp [EMAIL PROTECTED]
 
  wrote:
  class Component {
  private IModel? model;
   
  public T IModelT getModel() {
  return (IModelT) model;
  }
  }
   
I like this. Even with the possible class cast exception. Because
without generics, it doesn't leave you no other option than to cast
 it
to your model, which isn't much better either, as you get the same
result except that it looks uglier.
   
-Matej
   
On Wed, May 21, 2008 at 10:07 PM, Johan Compagner 
  [EMAIL PROTECTED] wrote:
no i am really against that falls V IModelV getModel() method
that really abuses everything that generics stands for. For such a
  basic
thing.
this is really bad programming
If we drop it we also pretty much drop it from IModel or have
 warnings
  in
the user code.
   
But then drop it completely is better because then we have to do a
  cast and
you really think about that
Not having that fake assurance..
   
johan
   
   
On Wed, May 21, 2008 at 9:53 PM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:
   
Before we do a vote I want to make sure what our alternatives
 are.
   
I

Re: Quick question regarding TabbedPanel and forms

2008-05-22 Thread Justin Morgan - Logic Sector

Overriding newLink() was the key.  However, rather than using a  
SubmitLink, I decided to bypass the whole issue entirely by simply  
disabling the currently selected link.  In my page's constructor, I  
added the following code:


TabbedPanel tabbedPanel = new TabbedPanel(tabs, tabs) {
@Override
protected WebMarkupContainer newLink(String linkId, final  
int index) {

Link link = new Link(linkId) {
private static final long serialVersionUID = 1L;

@Override
public void onClick() {
setSelectedTab(index);
}
};
link.setEnabled(getSelectedTab() != index);
return link;
}
};
tabbedPanel.setSelectedTab(0);
add(tabbedPanel);

A couple of minor CSS tweaks were needed so the tabs would display  
correctly since the disabled a link turns into a span instead.


Anyway, it works like a charm.

Just a suggestion...It would be great if TabbedPanel had a boolean  
method called, for example, wantsDisabledSelectedTab() which could be  
easily overridden to provide this behavior for us;  the default  
implementation of newLink() could incorporate this check and disable  
the selected tab appropriately.


Thanks,

Justin

On May 21, 2008, at 10:43 PM, Igor Vaynberg wrote:


you can override tabbedpanel.newlink and return a submitlink
instead.that way the form has to be submitted/validated before tabs
can be switched.

-igor


On Wed, May 21, 2008 at 9:51 PM, Justin Morgan - Logic Sector
[EMAIL PROTECTED] wrote:

Hi all,

I'm running into an issue with my TabbedPanel.  Currently I have a
TabbedPanel containing two tabs.  Each tab panel contains a form.   
Here's my

problem scenario:
1.  User clicks on a tab to view it (which is really just a link  
with fancy

CSS styling)
2.  User enters text in that tab's form
3.  Without submitting the form via submit button, the user clicks  
the tab

again
4.  User loses everything typed in the form (DOH!)

The problem occurs because the user clicked on a link which didn't  
submit

the form, and so the form contents were lost.

My question is:  Is there any way to configure a TabbedPanel to  
*not* make a

live link for the currently selected tab?

Thanks for any help,

Justin


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




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

Re: (Class? extends Page?) casting troubles



Hi Johan,


I thing that the example below is exactly the thing that generics are pretty
good:

populateItem(ListItemPerson item) {
   add(new LinkPerson(edit, item.getModel()) {
   public void onClick() {
   setResponsePage(new EditPage(getModelObject()));
   }
   });

(and EditPage is by itself already generified to Person)


well, just that the LinkPerson is IMHO redundant and unnecessary(just dropped 
a note to Martijn, but since you brought that up...)


populateItem(final ListItemPerson item) {
item.add(new Link(edit) {
public void onClick() {
setResponsePage(new EditPage(item.getModelObject()));
}
});

So, it might have sense with ListItem, but not necissarily with Link...

Regards, --- Jan.



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

Re: (Class? extends Page?) casting troubles

exactly Repeaters is very nice that the populateItem is generified.. I think
that is really handy..

And if the EditPage now wanted a specific type then you need now to cast at
that place..

I thing that the example below is exactly the thing that generics are pretty
good:

populateItem(ListItemPerson item) {
   add(new LinkPerson(edit, item.getModel()) {
   public void onClick() {
   setResponsePage(new EditPage(getModelObject()));
   }
   });

(and EditPage is by itself already generified to Person)

This is just a perfect thing that i say yes very nice you see exactly what
the code should do
and cant say that this is really verbose..

johan



On Thu, May 22, 2008 at 11:28 AM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:

 I often do the following:

 populateItem(ListItem item) {
add(new Link(edit, item.getModel()) {
public void onClick() {
setResponsePage(new EditPage(getModelObject()));
}
});
 }

 So both are used often, but mostly to pass things around.

 Martijn

 On Thu, May 22, 2008 at 11:25 AM, Johan Compagner [EMAIL PROTECTED]
 wrote:
  getModel() i agree, but getModelObject() is something that is used the
 most
  if i have to guess.
 
  Because in an onSubmit() of a form or a onClick of a Link what do most of
  you do?
 
  onSubmit()
  {
  dao.save(getModelObject())
  }
 
  onClick()
  {
  dao.delete(getModelObject())
  }
 
  johan
 
  On Thu, May 22, 2008 at 10:05 AM, Matej Knopp [EMAIL PROTECTED]
 wrote:
 
  Although I'm not sure how many people call getModel/getModelObject
  anyway. I think it's mostly about ListItems etc an i doubt anyone
  would subclass it just because of getModel/getModelObject...
 
  -Matej
 
  On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED]
  wrote:
   I would all be easier if getModel() and getModelObject() weren't
   final. (I know there's a reason why they are, I'm not questioning it).
  
   Then in your component subclass you coud do IModelInteger getModel()
   { return (IModelInteger)super.getModel() }, similiar with
   getmodelobject so you wouldn't have casts all over places and it would
be safer too).
  
   -Matej
  
   On Thu, May 22, 2008 at 9:39 AM, Johan Compagner 
 [EMAIL PROTECTED]
  wrote:
   It isnt all or nothing.. i never said that
  
   I just say if you dont want Component but you do want IModel
   then you will get a warning at getModel()
   we as a framework shouldnt hide the warning at that call.
  
   But i am also curious how many people get really the model back from
 a
   component (not counting specific places like repeaters.onpopuplate)
  
   because i think most people do component.getModelObject() which then
  needs a
   cast
  
   But i like that extra helper method way more then having an extra
   getUnsafeModel() method..
   because thats explicit a developer has to really choose for it.
  
   i think there are 3 options
  
   1 keep it what we have now, tweak it with the feedback we get from
  1.4M2
   2 drop it on Component only and have a class like you described
 above
  to do
   this:  IModelString model = Unsafe.cast(component.getModel()); (its
  still
   a hack and a sense of false security but ok. if people really want
  this..)
   3 drop it on Component and Model
  
  
   i am +1 on 1
   and -0 on 2 and 3
  
   I still think it is not bad. and you can come around it really easy
 by
  just
   creating a few extra classes like
  
   StringLabel
   NumberLabel
   StringTextField
   NumberTextField
  
   if you only have a few of those extra all your code is cleanup
  
   johan
  
   On Thu, May 22, 2008 at 9:12 AM, Joni Freeman [EMAIL PROTECTED]
  wrote:
  
   Yeah, it could even be in its separate utility class:
  
   interface IModelT {}
  
   class Component {
  private IModel? model;
  
   public IModel? getModel() {
  return model;
  }
   }
  
   public class Unsafe {
  public static T IModelT cast(IModel? model) {
   return (IModelT) model;
  }
   }
  
   class MyComp extends Component {
  public MyComp() {
   IModelInteger model = Unsafe.cast(getModel());
  }
   }
  
   I'm merely pointing out that there exists a solution to do unsafe
 cast
   without getting compiler warning. Just like normal casts are
 handled.
  
   I don't think Johan's all or nothing proposition is very pragmatic
 one.
   Without generic IModel we do not get any API discoverability and our
   APIs continue to suck. For instance, how can API user know what kind
 of
   model this needs: MyJuicyComponent(String id, IModel model). At one
   point we did this: MyJuicyComponent(String id, IModel/*Chocolate*/
   model) but this convention is far from optimal. To be sure, one
 needs
  to
   browse the sources...
  
   Joni
  
   On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
Well, maybe it really is a hack that's too ugly. We might have two
   methods,
   
default getModel() that doesn't cast it and alternative
 convenience

Re: (Class? extends Page?) casting troubles

Yeah that is the problem with Generics

You cant say take the T from the model you get in the constructor
Then everything would be perfect.

But i really dont think that Person in link is redundant why is it?
You call later on getModelObject() on it.. so you use the model/modelobject
of Link
so you need to say what Link has..

johan


On Thu, May 22, 2008 at 11:45 AM, Jan Kriesten [EMAIL PROTECTED]
wrote:


 Hi Johan,

  I thing that the example below is exactly the thing that generics are
 pretty
 good:

 populateItem(ListItemPerson item) {
   add(new LinkPerson(edit, item.getModel()) {
   public void onClick() {
   setResponsePage(new EditPage(getModelObject()));
   }
   });

 (and EditPage is by itself already generified to Person)


 well, just that the LinkPerson is IMHO redundant and unnecessary(just
 dropped a note to Martijn, but since you brought that up...)

 populateItem(final ListItemPerson item) {
item.add(new Link(edit) {
public void onClick() {
setResponsePage(new EditPage(item.getModelObject()));
}
});

 So, it might have sense with ListItem, but not necissarily with Link...

 Regards, --- Jan.




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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Peter Ertl

+1 for finishing generics (no matter how ugly it gets), then  
refactoring / removing the things that suck


Am 22.05.2008 um 11:37 schrieb Johan Compagner:

exactly Repeaters is very nice that the populateItem is generified..  
I think

that is really handy..

And if the EditPage now wanted a specific type then you need now to  
cast at

that place..

I thing that the example below is exactly the thing that generics  
are pretty

good:

populateItem(ListItemPerson item) {
  add(new LinkPerson(edit, item.getModel()) {
  public void onClick() {
  setResponsePage(new EditPage(getModelObject()));
  }
  });

(and EditPage is by itself already generified to Person)

This is just a perfect thing that i say yes very nice you see  
exactly what

the code should do
and cant say that this is really verbose..

johan



On Thu, May 22, 2008 at 11:28 AM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:


I often do the following:

populateItem(ListItem item) {
  add(new Link(edit, item.getModel()) {
  public void onClick() {
  setResponsePage(new EditPage(getModelObject()));
  }
  });
}

So both are used often, but mostly to pass things around.

Martijn

On Thu, May 22, 2008 at 11:25 AM, Johan Compagner [EMAIL PROTECTED] 


wrote:
getModel() i agree, but getModelObject() is something that is used  
the

most

if i have to guess.

Because in an onSubmit() of a form or a onClick of a Link what do  
most of

you do?

onSubmit()
{
dao.save(getModelObject())
}

onClick()
{
dao.delete(getModelObject())
}

johan

On Thu, May 22, 2008 at 10:05 AM, Matej Knopp  
[EMAIL PROTECTED]

wrote:



Although I'm not sure how many people call getModel/getModelObject
anyway. I think it's mostly about ListItems etc an i doubt anyone
would subclass it just because of getModel/getModelObject...

-Matej

On Thu, May 22, 2008 at 10:04 AM, Matej Knopp [EMAIL PROTECTED] 


wrote:

I would all be easier if getModel() and getModelObject() weren't
final. (I know there's a reason why they are, I'm not  
questioning it).


Then in your component subclass you coud do IModelInteger  
getModel()

{ return (IModelInteger)super.getModel() }, similiar with
getmodelobject so you wouldn't have casts all over places and it  
would

be safer too).

-Matej

On Thu, May 22, 2008 at 9:39 AM, Johan Compagner 

[EMAIL PROTECTED]

wrote:

It isnt all or nothing.. i never said that

I just say if you dont want Component but you do want IModel
then you will get a warning at getModel()
we as a framework shouldnt hide the warning at that call.

But i am also curious how many people get really the model back  
from

a
component (not counting specific places like  
repeaters.onpopuplate)


because i think most people do component.getModelObject() which  
then

needs a

cast

But i like that extra helper method way more then having an extra
getUnsafeModel() method..
because thats explicit a developer has to really choose for it.

i think there are 3 options

1 keep it what we have now, tweak it with the feedback we get  
from

1.4M2

2 drop it on Component only and have a class like you described

above

to do
this:  IModelString model =  
Unsafe.cast(component.getModel()); (its

still
a hack and a sense of false security but ok. if people really  
want

this..)

3 drop it on Component and Model


i am +1 on 1
and -0 on 2 and 3

I still think it is not bad. and you can come around it really  
easy

by

just

creating a few extra classes like

StringLabel
NumberLabel
StringTextField
NumberTextField

if you only have a few of those extra all your code is cleanup

johan

On Thu, May 22, 2008 at 9:12 AM, Joni Freeman  
[EMAIL PROTECTED]

wrote:



Yeah, it could even be in its separate utility class:

interface IModelT {}

class Component {
  private IModel? model;

   public IModel? getModel() {
  return model;
  }
}

public class Unsafe {
  public static T IModelT cast(IModel? model) {
   return (IModelT) model;
  }
}

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

I'm merely pointing out that there exists a solution to do  
unsafe

cast

without getting compiler warning. Just like normal casts are

handled.


I don't think Johan's all or nothing proposition is very  
pragmatic

one.
Without generic IModel we do not get any API discoverability  
and our
APIs continue to suck. For instance, how can API user know  
what kind

of
model this needs: MyJuicyComponent(String id, IModel model).  
At one
point we did this: MyJuicyComponent(String id, IModel/ 
*Chocolate*/

model) but this convention is far from optimal. To be sure, one

needs

to

browse the sources...

Joni

On Wed, 2008-05-21 at 22:19 +0200, Matej Knopp wrote:
Well, maybe it really is a hack that's too ugly. We might  
have two

methods,


default getModel() that doesn't cast it and alternative

convenience

one that does.

-Matej

On Wed, May 21, 2008 at 10:10 PM, Matej Knopp 

[EMAIL PROTECTED]



wrote:

 class

Re: javascript error in internet explorer

2008-05-22 Thread Newgro



Johan Compagner wrote:
 
 is there a jira issue for this patch?
 

Hello Johan

i added an issue for this here 
https://issues.apache.org/jira/browse/WICKET-1653 WICKET-1653 

I have the same error with my ie 6. Will it be fixed in an 1.3 or only in an
1.4 version?

Thanks
Per
-- 
View this message in context: 
http://www.nabble.com/javascript-error-in-internet-explorer-tp16732896p17400631.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: (Class? extends Page?) casting troubles



Hi Johan,


But i really dont think that Person in link is redundant why is it?


the point was, that in this case Link simply doesn't need to have given a model 
at all, since you can access the surrounding final vars (you can access the item 
in onClick):



populateItem(final ListItemPerson item) {
   item.add(new Link(edit) {
   public void onClick() {
   setResponsePage(new EditPage(item.getModelObject()));
   }
   });


What else could you do/access in Link what is not possible with this approach?


Regards, --- Jan.


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

Re: (Class? extends Page?) casting troubles



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.


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


Best regards, --- Jan.



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

Re: AjaxLink not clickable in IE

I had this exact problem, but it was because the text inside my a
tag was inside a label tag (at least I think that's what was causing
it).  For some reason, IE didn't like that.  I had to tell the label
to just spit out its contents.

On Wed, May 21, 2008 at 5:31 PM, Michael Mehrle [EMAIL PROTECTED] wrote:
 I've got this AjaxLink:



 fooLink = new AjaxLink(fooLink) {

@Override

public void
 onClick(AjaxRequestTarget target) {

Boolean
 selected = (Boolean) fooCheckBox.getModelObject();

if
 (!selected) {


 fooCheckBox.setModelObject((new Boolean(true)));

}


 target.addComponent(fooCheckBox);

// pop up
 the modal


 showRecurringFooModal(recurringFooModalWindow, target);

}

};



 a href= wicket:id= fooLink  class=textlinkwicket:message
 key=fooLabel //a



 Works fine in Safari and Firefox but in IE it's not clickable - looks
 like a link but the mouse pointer doesn't change and nothing happens
 when clicking. No error message either in IE's JS console or in AJAX.
 Any idea what I'm doing wrong here?



 Michael



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

Re: (Class? extends Page?) casting troubles

ahh yes thats true i overlooked your changes..

then yes currently you have to do new LinkVoid (to get rid of the
warnings)

johan


On Thu, May 22, 2008 at 11:54 AM, Jan Kriesten [EMAIL PROTECTED]
wrote:


 Hi Johan,

  But i really dont think that Person in link is redundant why is it?


 the point was, that in this case Link simply doesn't need to have given a
 model at all, since you can access the surrounding final vars (you can
 access the item in onClick):

  populateItem(final ListItemPerson item) {
   item.add(new Link(edit) {
   public void onClick() {
   setResponsePage(new EditPage(item.getModelObject()));
   }
   });


 What else could you do/access in Link what is not possible with this
 approach?



 Regards, --- Jan.


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

Re: Tomcat discards content-type with StringRequestTarget

Sure I could, but since the StringRequestTarget constructor takes a 
content-type argument, I find it strange that this isn't sent to the 
browser. Sure enough, StringRequestTarget#respond, creates as 
StringBufferResourcesStream with the contentType field set correctly, 
but then it just copies the stream, and doesn't set any headers.


Maybe this will work?

RequestCycle.get().setRequestTarget(new StringRequestTarget(text/html, 
body) {

public void respond(RequestCycle requestCycle) {
requestCycle.getResponse().setContentType(text/html);
super.respond(requestCycle);
}
});

-- Edvin

richardwilko skrev:

You could implement your own dynamic web resource.  eg for a kml page on our
site:


public class KMLResource extends DynamicWebResource
{

Document kml;

public KMLResource(Document kml)
{
this.kml = kml;
}

@Override
protected ResourceState getResourceState()
{
final XMLOutputter out = new XMLOutputter();

KMLResourceState kmlResourceState = new KMLResourceState();
try
{
ByteArrayOutputStream byteout = new 
ByteArrayOutputStream();
out.output(kml, byteout);
kmlResourceState.setData(byteout.toByteArray());
byteout.close();
}
catch (IOException e)
{
e.printStackTrace();
}
return kmlResourceState;
}


class KMLResourceState extends ResourceState
{
@Override
public String getContentType()
{
return application/vnd.google-earth.kml+xml;
}

private byte[] data = new byte[0];
@Override
public byte[] getData()
{
return data;
}
public void setData(byte[] data)
{
this.data = data;
}

@Override
public int getLength()
{
return data.length;
}
}
}

then use it like this in your page

final KMLResource kmlResource = new KMLResource(kml);

getRequestCycle().setRequestTarget(new IRequestTarget() {

public void detach(RequestCycle requestCycle) {

}
public void respond(RequestCycle requestCycle) {

ResourceStreamRequestTarget target = new
ResourceStreamRequestTarget(kmlResource.getResourceStream());
target.setFileName(name);

getRequestCycle().setRequestTarget(target); 
			}

});

just alter it for text rather than a Document


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

Re: [PROPOSAL] wicketstuff SVN reorganization...

All,

Ok, folks, so where are we on this?  There has been some desire to
reorganize things a bit.  There are at least 3 options that I have
heard:

1.  Leave everything the way it is.
2.  Set everything up the way I suggested (the projects can still have
a common parent that's a sibling of theirs like we do in commons)
3.  Use a hybrid approach, creating some umbrella project that is
updated/released with the Wicket releases and follows the Wicket
release numbering/schedule.

Is this what folks have proposed as solutions?  If so, should we start
a [VOTE] just to see where we are on these three solutions?

James

p.s. Sorry to be such a stickler, but I'm one of those folks who has
to have order.  I can't work until I clean my desk up first! :)  The
first step is identifying the problem and I'll get right on that when
I'm done cleaning up my desk!


On Wed, May 21, 2008 at 3:31 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 flattery will get you everywhere

 -igor

 On Wed, May 21, 2008 at 12:29 PM, James Carman
 [EMAIL PROTECTED] wrote:
 With the quick release cycles that Wicket goes through, that just
 seems weird to me.  They should pick a version and go with it.  The
 Wicket team is very good about keeping things fresh.  I have been very
 surprised at how many releases have gone out in my brief experience
 with Wicket.

 On Wed, May 21, 2008 at 3:27 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 well, the problem is that most trunks depend on wicket snapshots

 -igor

 On Wed, May 21, 2008 at 12:05 PM, James Carman
 [EMAIL PROTECTED] wrote:
 On Wed, May 21, 2008 at 3:00 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 well, thats what we get for having virtually no entry barrier. for me
 branching the entire repo with every major release of wicket is much
 easier because i can do it with one command. if each project has their
 own tree i am not going to do it. that means when there is an api
 change in wicket all projects will have to be upgraded or they wont
 compile.

 They will compile because they're dependencies are not being modified
 by the Wicket release.  Existing projects (if they don't follow the
 release cycle of Wicket) can specify whatever version of Wicket they
 *do* compile/run against.  As long as nobody changes that (and nobody
 checks in messed up code), the project should compile and run just
 fine against the specified release(s) (remember, you can specify
 version ranges in Maven, too).

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



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



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



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



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

Re: (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

Wicket and inline JavaScript


Hi,

I have a webdesigner who keeps harassing me with the way Wicket does 
JavaScript, attaching behaviour to onclick events etc. instead of doing 
it the jquery way of picking up the components and attaching the 
events afterwards, thus keeping all the nasty bits away from the actual 
markup.


Ofcourse the code looks a lot cleaner the jquery way, and he tells me 
that debugging and working with the code is also much easier. Personally 
I don't know enough about html/javascript to decide what's the better 
approach, but I just wanted to know if there are any plans to rework 
this in Wicket, or if the current approach is just as good?


-- Edvin

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

Re: (Class? extends Page?) casting troubles

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

johan


On Thu, May 22, 2008 at 12:41 PM, Jan Kriesten [EMAIL PROTECTED]
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.

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

 Best regards, --- Jan.




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

Re: (Class? extends Page?) casting troubles



hi sebastiaan,

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


i'm all in when you're talking about type safety. having compile-time checks on 
the types is a time-saver during development.


with wicket generics it's just that the time-saver get's in it's own way, i.e. 
bringing in so much boilerplate, that coding is getting harder to do right 
(besides from source readability).


regards, --- jan.

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

Re: (Class? extends Page?) casting troubles



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.

--- jan.



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

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: [PROPOSAL] wicketstuff SVN reorganization...

2008-05-22 Thread Martin Funk


James Carman wrote:

All,

Ok, folks, so where are we on this?  There has been some desire to
reorganize things a bit.  There are at least 3 options that I have
heard:

1.  Leave everything the way it is.
2.  Set everything up the way I suggested (the projects can still have
a common parent that's a sibling of theirs like we do in commons)
3.  Use a hybrid approach, creating some umbrella project that is
updated/released with the Wicket releases and follows the Wicket
release numbering/schedule.

Is this what folks have proposed as solutions?  If so, should we start
a [VOTE] just to see where we are on these three solutions?
  

+1

James

p.s. Sorry to be such a stickler, but I'm one of those folks who has
to have order.  I can't work until I clean my desk up first! :)  The
first step is identifying the problem and I'll get right on that when
I'm done cleaning up my desk!


On Wed, May 21, 2008 at 3:31 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
  

flattery will get you everywhere

-igor

On Wed, May 21, 2008 at 12:29 PM, James Carman
[EMAIL PROTECTED] wrote:


With the quick release cycles that Wicket goes through, that just
seems weird to me.  They should pick a version and go with it.  The
Wicket team is very good about keeping things fresh.  I have been very
surprised at how many releases have gone out in my brief experience
with Wicket.

On Wed, May 21, 2008 at 3:27 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
  

well, the problem is that most trunks depend on wicket snapshots

-igor

On Wed, May 21, 2008 at 12:05 PM, James Carman
[EMAIL PROTECTED] wrote:


On Wed, May 21, 2008 at 3:00 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
  

well, thats what we get for having virtually no entry barrier. for me
branching the entire repo with every major release of wicket is much
easier because i can do it with one command. if each project has their
own tree i am not going to do it. that means when there is an api
change in wicket all projects will have to be upgraded or they wont
compile.


They will compile because they're dependencies are not being modified
by the Wicket release.  Existing projects (if they don't follow the
release cycle of Wicket) can specify whatever version of Wicket they
*do* compile/run against.  As long as nobody changes that (and nobody
checks in messed up code), the project should compile and run just
fine against the specified release(s) (remember, you can specify
version ranges in Maven, too).

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


  

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




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


  

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





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

  



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

Re: Tomcat discards content-type with StringRequestTarget

Update: overriding respond and setting the contentType directly works 
great :)


-- Edvin

Edvin Syse skrev:
Sure I could, but since the StringRequestTarget constructor takes a 
content-type argument, I find it strange that this isn't sent to the 
browser. Sure enough, StringRequestTarget#respond, creates as 
StringBufferResourcesStream with the contentType field set correctly, 
but then it just copies the stream, and doesn't set any headers.


Maybe this will work?

RequestCycle.get().setRequestTarget(new StringRequestTarget(text/html, 
body) {

public void respond(RequestCycle requestCycle) {
requestCycle.getResponse().setContentType(text/html);
super.respond(requestCycle);
}
});

-- Edvin

richardwilko skrev:
You could implement your own dynamic web resource.  eg for a kml page 
on our

site:


public class KMLResource extends DynamicWebResource
{

Document kml;

public KMLResource(Document kml)

{
this.kml = kml;
}

@Override

protected ResourceState getResourceState()
{
final XMLOutputter out = new XMLOutputter();
   
KMLResourceState kmlResourceState = new KMLResourceState();

try
{
ByteArrayOutputStream byteout = new ByteArrayOutputStream();
out.output(kml, byteout);
kmlResourceState.setData(byteout.toByteArray());
byteout.close();
}
catch (IOException e)
{
e.printStackTrace();
}
return kmlResourceState;
}


class KMLResourceState extends ResourceState

{
@Override
public String getContentType()
{
return application/vnd.google-earth.kml+xml;
}

private byte[] data = new byte[0];
@Override
public byte[] getData()
{
return data;
}
public void setData(byte[] data)
{
this.data = data;
}
   
@Override

public int getLength()
{
return data.length;
}
}
}

then use it like this in your page

final KMLResource kmlResource = new KMLResource(kml);
   
getRequestCycle().setRequestTarget(new IRequestTarget() {


public void detach(RequestCycle requestCycle) {
   
}

public void respond(RequestCycle requestCycle) {
   
ResourceStreamRequestTarget target = new

ResourceStreamRequestTarget(kmlResource.getResourceStream());
target.setFileName(name);

getRequestCycle().setRequestTarget(target); }
});

just alter it for text rather than a Document


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



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

Re: (Class? extends Page?) casting troubles

harder to comprehend??
come on, you must be kidding!

Link is many times uses (you did give an example your self 2 emails back) as
a model object holder
So if developers use it sometimes as just a link and sometimes just as an
object.

I think if we made Link default Object that many people would complain..

johan


On Thu, May 22, 2008 at 1:49 PM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:

 It is. If you haven't noticed, about a bazillion folks around the
 world are discarding Java because of its verbosity. Having to type
 LinkVoid(link) {} really makes it harder to comprehend. Why does
 the link need a type? It is not needed. what is not needed doesn't
 need to be specified. Period.

 Martijn

 On Thu, May 22, 2008 at 1:45 PM, Sebastiaan van Erk [EMAIL PROTECTED]
 wrote:
  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]
 
 



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

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

Re: (Class? extends Page?) casting troubles

harder to comprehend??
come on, you must be kidding!

Link is many times uses (you did give an example your self 2 emails back) as
a model object holder
So if developers use it sometimes as just a link and sometimes just as an
object.

I think if we made Link default Object that many people would complain..

johan


On Thu, May 22, 2008 at 1:49 PM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:

 It is. If you haven't noticed, about a bazillion folks around the
 world are discarding Java because of its verbosity. Having to type
 LinkVoid(link) {} really makes it harder to comprehend. Why does
 the link need a type? It is not needed. what is not needed doesn't
 need to be specified. Period.

 Martijn

 On Thu, May 22, 2008 at 1:45 PM, Sebastiaan van Erk [EMAIL PROTECTED]
 wrote:
  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]
 
 



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

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

Re: Tomcat discards content-type with StringRequestTarget

hmm that is a bug then of StringRequestTarget
It should set that header if the content type is specified.

I will fix that




On Thu, May 22, 2008 at 2:02 PM, Edvin Syse [EMAIL PROTECTED] wrote:

 Update: overriding respond and setting the contentType directly works great
 :)

 -- Edvin

 Edvin Syse skrev:

  Sure I could, but since the StringRequestTarget constructor takes a
 content-type argument, I find it strange that this isn't sent to the
 browser. Sure enough, StringRequestTarget#respond, creates as
 StringBufferResourcesStream with the contentType field set correctly, but
 then it just copies the stream, and doesn't set any headers.

 Maybe this will work?

 RequestCycle.get().setRequestTarget(new StringRequestTarget(text/html,
 body) {
public void respond(RequestCycle requestCycle) {
requestCycle.getResponse().setContentType(text/html);
super.respond(requestCycle);
}
 });

 -- Edvin

 richardwilko skrev:

 You could implement your own dynamic web resource.  eg for a kml page on
 our
 site:


 public class KMLResource extends DynamicWebResource
 {

Document kml;
public KMLResource(Document kml)
{
this.kml = kml;
}
@Override
protected ResourceState getResourceState()
{
final XMLOutputter out = new XMLOutputter();
  KMLResourceState kmlResourceState = new KMLResourceState();
try
{
ByteArrayOutputStream byteout = new ByteArrayOutputStream();
out.output(kml, byteout);
kmlResourceState.setData(byteout.toByteArray());
byteout.close();
}
catch (IOException e)
{
e.printStackTrace();
}
return kmlResourceState;
}

class KMLResourceState extends ResourceState
{
@Override
public String getContentType()
{
return application/vnd.google-earth.kml+xml;
}

private byte[] data = new byte[0];
@Override
public byte[] getData()
{
return data;
}
public void setData(byte[] data)
{
this.data = data;
}
  @Override
public int getLength()
{
return data.length;
}
}
 }

 then use it like this in your page

 final KMLResource kmlResource = new KMLResource(kml);
  getRequestCycle().setRequestTarget(new IRequestTarget() {

public void detach(RequestCycle requestCycle) {
  }
public void respond(RequestCycle requestCycle) {
  ResourceStreamRequestTarget target = new
 ResourceStreamRequestTarget(kmlResource.getResourceStream());
target.setFileName(name);

getRequestCycle().setRequestTarget(target); }
});

 just alter it for text rather than a Document


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

refreshingview with textfield items that use validatior

2008-05-22 Thread i ii


how can use refreshingview with textfield items that use validatior? when i use 
and validator fails all textfield values reset. i want reset every request, but 
not when validator fails.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Testing using WicketTester

2008-05-22 Thread Eyal Golan

Hi,
I want to create a small UnitTest for my login page:
public void testLoginPageRender() {
tester.startPage(Login.class);
// Just to ensure that the request has not been
// intercepted or redirected
tester.assertRenderedPage(Login.class);
// A page might render with an error message.
// If the Login page does have an associated error message, the
// following
// method will result in a failed assertion.
tester.assertNoErrorMessage();
}

I get a ClassCastException:
java.lang.ClassCastException: org.apache.wicket.protocol.http.WebSession
at com.eurekify.web.Login.init(Login.java:101)

And this is of course because I have this in my Login page:
if(((PortalSession)getSession()).isUserLoggedIn()){
PageParameters pageParameters = new PageParameters();
pageParameters.put(pageId, );
PortalWebPage page = new PortalWebPage(pageParameters);
setRedirect( true );
setResponsePage(page);
}

My question is, how do I set the WebSession in a testing environment?

Thanks
-- 
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/

Re: Testing using WicketTester

2008-05-22 Thread richardwilko


WicketTester tester = new WicketTester(new MyApplication());

should do it




Eyal Golan wrote:
 
 Hi,
 I want to create a small UnitTest for my login page:
 public void testLoginPageRender() {
 tester.startPage(Login.class);
 // Just to ensure that the request has not been
 // intercepted or redirected
 tester.assertRenderedPage(Login.class);
 // A page might render with an error message.
 // If the Login page does have an associated error message, the
 // following
 // method will result in a failed assertion.
 tester.assertNoErrorMessage();
 }
 
 I get a ClassCastException:
 java.lang.ClassCastException: org.apache.wicket.protocol.http.WebSession
 at com.eurekify.web.Login.init(Login.java:101)
 
 And this is of course because I have this in my Login page:
 if(((PortalSession)getSession()).isUserLoggedIn()){
 PageParameters pageParameters = new PageParameters();
 pageParameters.put(pageId, );
 PortalWebPage page = new PortalWebPage(pageParameters);
 setRedirect( true );
 setResponsePage(page);
 }
 
 My question is, how do I set the WebSession in a testing environment?
 
 Thanks
 -- 
 Eyal Golan
 [EMAIL PROTECTED]
 
 Visit: http://jvdrums.sourceforge.net/
 
 

-- 
View this message in context: 
http://www.nabble.com/Testing-using-WicketTester-tp17403637p17403686.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

RE: Providing IModel to Validators

2008-05-22 Thread Hoover, William

done: https://issues.apache.org/jira/browse/WICKET-1654 

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 21, 2008 8:10 PM
To: users@wicket.apache.org
Subject: Re: Providing IModel to Validators

ah, i see. so the model for the validator overrides the message
completely?

i have already built in a support for this into the core api via
IValidationError. the problem is that our validator implementations are
based around resource keys, and changing that will probably entail api
breakages which we cannot have in a 1.3 release.

enter an rfe and we can refactor this stuff for 1.4/1.5

-igor

On Wed, May 21, 2008 at 5:00 PM, Hoover, William [EMAIL PROTECTED]
wrote:
 A column attribute, or any other attribute for that matter, would 
 not make a difference because if would all be encapsulated within the 
 model set on the validator (use case 6 below). Providing models to the

 validators would make it a lot easier to override validation messages 
 because all the developer would have to do is set the model on it (vs 
 looking up the resource key and add it to the components properties 
 file). I can see that this is receiving some strong resistance so I 
 wont push the issue any further :o)

 ==

 Use Case 6:

 StringResourceModel srm =  new
 StringResourceModel(CustomStringValidator.minimum, null, null, new 
 Object[]{ rowIndex, columnIndex });

 add(new textfield(fname).setlabel(new model(first 
 name)).add(stringvalidator.minimum(5, srm));

 results in- 'first name' with value 'abc' at row 10, column 3 is 
 shorter than the minimum of 5 characters.

 ==

 -Original Message-
 From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, May 21, 2008 3:07 PM
 To: users@wicket.apache.org
 Subject: Re: Providing IModel to Validators

 and what happens when someone wants ${label} at row {0} column {1} is 
 required? do we start passing in arrays, lists, or maps for imodels to

 validators?

 why not just do

 textfield.setlabel(new model(first name at row +row));

 -igor

 On Wed, May 21, 2008 at 4:52 AM, Hoover, William [EMAIL PROTECTED]
 wrote:
 What I'm proposing would not require the same first name model on 
 both validators. I might not have been clear enough in my
 explanation...

 StringValidator.minimum='${label}' with value '${input}' is shorter 
 than the minimum of ${minimum} characters.

 CustomStringValidator.minimum='${label}' with value '${input}' at row

 {0} is shorter than the minimum of ${minimum} characters.

 MyUsernameValidator.unique='${label}' with value '${input}' at row 
 {0}

 is not unique.

 ==

 Use Case 1:

 add(new textfield(fname).add(stringvalidator.minimum(5));

 results in- 'fNameId' with value 'abc' is shorter than the minimum of
 5 characters.

 ==

 Use Case 2:

 add(new textfield(fname).setlabel(new model(first 
 name)).add(stringvalidator.minimum(5));

 results in- 'first name' with value 'abc' is shorter than the minimum

 of
 5 characters.

 ==

 Use Case 3:

 StringResourceModel srm =  new
 StringResourceModel(CustomStringValidator.minimum, null, null, new 
 Object[]{ rowIndex });

 add(new textfield(fname).add(stringvalidator.minimum(5, srm));

 results in- 'fNameId' with value 'abc' at row 10 is shorter than the 
 minimum of 5 characters.

 ==

 Use Case 4:

 StringResourceModel srm =  new
 StringResourceModel(CustomStringValidator.minimum, null, null, new 
 Object[]{ rowIndex });

 add(new textfield(fname).setlabel(new model(first 
 name)).add(stringvalidator.minimum(5, srm));

 results in- 'first name' with value 'abc' at row 10 is shorter than 
 the minimum of 5 characters.

 ==

 Use Case 5:

 StringResourceModel srm =  new
 StringResourceModel(CustomStringValidator.minimum, null, null, new 
 Object[]{ rowIndex });

 add(new textfield(fname).setlabel(new model(first 
 name)).add(stringvalidator.minimum(5, srm)).add(new 
 MyUsernameValidator());

 results in- 'first name' with value 'abc' at row 10 is shorter than 
 the minimum of 5 characters.

 results in- 'first name' with value 'abc' at row 10 is not unique.

 ==

 -Original Message-
 From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, May 20, 2008 8:41 PM
 To: users@wicket.apache.org
 Subject: Re: Providing IModel to Validators

 On Tue, May 20, 2008 at 3:39 PM, Hoover, William 
 [EMAIL PROTECTED]
 wrote:
 sure, if you know to override NumberValidator.minimum with:

 label.myminimum=My Object at row: {0} with value 
 NumberValidator.minimum=${label} '${input}' must be smaller than 
 ${minimum}

 It seems odd because:
 1) NumberValidator.minimum (or any other entry in
 Application.properties) does not use ${label} by default

 i have argued for this, but ive been met with resistance. reasoning 
 was that not everyone

Re: Testing using WicketTester

2008-05-22 Thread Eyal Golan

Thanks.
I actually tried but got an error that it could not find the application
context (we use Spring).

java.lang.IllegalStateException: No WebApplicationContext found: no
ContextLoaderListener registered?

Instead this is what I did:
tester = new WicketTester(new WebApplication() {
@Override
public Session newSession(Request request, Response response) {
return new PortalSession(request);
}

@Override
public Class getHomePage() {
// TODO Auto-generated method stub
return null;
}

});

What do you think?

On Thu, May 22, 2008 at 3:56 PM, richardwilko 
[EMAIL PROTECTED] wrote:


 WicketTester tester = new WicketTester(new MyApplication());

 should do it




 Eyal Golan wrote:
 
  Hi,
  I want to create a small UnitTest for my login page:
  public void testLoginPageRender() {
  tester.startPage(Login.class);
  // Just to ensure that the request has not been
  // intercepted or redirected
  tester.assertRenderedPage(Login.class);
  // A page might render with an error message.
  // If the Login page does have an associated error message, the
  // following
  // method will result in a failed assertion.
  tester.assertNoErrorMessage();
  }
 
  I get a ClassCastException:
  java.lang.ClassCastException: org.apache.wicket.protocol.http.WebSession
  at com.eurekify.web.Login.init(Login.java:101)
 
  And this is of course because I have this in my Login page:
  if(((PortalSession)getSession()).isUserLoggedIn()){
  PageParameters pageParameters = new PageParameters();
  pageParameters.put(pageId, );
  PortalWebPage page = new PortalWebPage(pageParameters);
  setRedirect( true );
  setResponsePage(page);
  }
 
  My question is, how do I set the WebSession in a testing environment?
 
  Thanks
  --
  Eyal Golan
  [EMAIL PROTECTED]
 
  Visit: http://jvdrums.sourceforge.net/
 
 

 --
 View this message in context:
 http://www.nabble.com/Testing-using-WicketTester-tp17403637p17403686.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]




-- 
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/

How can i load Image??

2008-05-22 Thread Fabien D.


Hi everybody,

In my web application, I want to display a Image.

I try to use Image and ResourceReference but I have some problemes

My image is in a folder stock in my context of my web aplication :

/stock/domaine/sdoimaine/projet/logo. I try to load it with the real path,
or the context path...

String name_upload = GestionProperties.getProperty(uploadRealdir);
String chemin =
name_upload+File.separator+model_domaine.getObject()+File.separator+model_sous_domaine.getObject()+File.separator+model_nom.getObject()+File.separator+model_logo.getObject();
ResourceReference ref = new ResourceReference(chemin);
Image logoProjet = new Image(logoimg, ref );  

And the result is :
http://localhost:8080/appWicket-1.0/resources/org.apache.wicket.Application/stock...

How can I place my RessourceReference in the context?

Thank you in adance 
-- 
View this message in context: 
http://www.nabble.com/How-can-i-load-Image---tp17403872p17403872.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: filter for data in security layer

2008-05-22 Thread Andrea Jahn



 

Hi,

thanks a lot for the detailed explanation, it works 

I needed some time for the implementation, because I'm a wicket beginner and 
had first to find out, how a DropDownChoice works (not so easy to understand 
that model concept at the first time :))

Only one point regarding to the policy file is open:

If I use the name of the DataPermission defined in the Model (like in the 
Getting started with Swarm example), it works. 
This makes sense in the case of my Location DropDownChoice, because this is 
created within the SecureBasePage, which is extended by each page.
One user has always the same permissions for the locations on each page (all 
locations or only certain locations). 
So I have to define the permission only once for the Model (per principal), but 
not for every page. 


public class LocationListModel extends LoadableDetachableModel implements 
SwarmModel {
...
 public String getSecurityId(Component component) {
 return LocationListModel; // name of the DataPermission
 }
...
}

permission ${DataPermission} LocationListModel, global;

--

I tried to set the permissions like in the explanation below, but that didn't 
work:

// Welcome page
permission ${ComponentPermission} ${front}.Welcome, inherit, render, global;
permission ${ComponentPermission} ${front}.Welcome, enable, global;

Debug logging:
2008-05-22 14:47:57,515 DEBUG 
org.apache.wicket.security.hive.BasicHive.addPrincipal(BasicHive.java:111) - 
Adding 
org.apache.wicket.security.hive.authorization.permissions.ComponentPermission 
xxx.yyy.zzz.front.Welcome access, render, enable, location, global to 
everybody
2008-05-22 14:47:57,515 DEBUG 
org.apache.wicket.security.hive.BasicHive.addPrincipal(BasicHive.java:111) - 
Adding 
org.apache.wicket.security.hive.authorization.permissions.ComponentPermission 
xxx.yyy.zzz.front.Welcome access, inherit, render, location, global to 
everybody

2008-05-22 14:48:13,046 DEBUG 
org.apache.wicket.Component.render(Component.java:2284) - Begin render 
[MarkupContainer [Component id = selectLocation, page = 
xxx.yyy.zzz.front.Welcome, path = 1:formLocation:selectLocation.DropDownChoice, 
isVisible = true, isVersioned = false]]
2008-05-22 14:48:13,046 DEBUG 
org.apache.wicket.security.hive.BasicHive.hasPermission(BasicHive.java:224) - 
Subjects[HashKey: -1185945692, sortOrder 0 = [EMAIL PROTECTED] [mailto:[EMAIL 
PROTECTED] does not have or implies 
org.apache.wicket.security.hive.authorization.permissions.DataPermission 
LocationListModel global

Andrea

-
On Sun, May 18, 2008 at 7:26 PM, Igor Vaynberg [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] wrote:
 something like this should probably be filter inside the database not
 by some external filter which forces you to load the entire dataset.

No that would be foolish, but that wasn't suggested.


 -igor

 On Sun, May 18, 2008 at 9:39 AM, Andrea Jahn [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] wrote:




 Hi,

 in our application locations are administered. A user has only rights on 
 some of the locations, e.g. Munich, Berlin. He should be able to select one 
 of the allowed locations in a selection box. Then on the different pages all 
 data are depending on the actually selected location. For example a DataView 
 shows only the items, which belong to this location.

 Could Swarm support data filtering ?

Yes, especially in 1.3.1 this is a bit cleaner dependency wise. But
there is no out of the box solution as there are lots of framework
combinations possible. So get ready for some heavy duty programming :)


 I found the following related message.

 http://markmail.org/message/hb42u5xj7xlvumm7 
 [http://markmail.org/message/hb42u5xj7xlvumm7] 
 [http://markmail.org/message/hb42u5xj7xlvumm7] (subsection4)

 I like the idea, that the dataproviders get some filters (only the data 
 which are needed should be read from the database), but where should I store 
 the filters for the actual selected location in the security layer ?

 Perhaps does someone know examples for that issue (using Wicket, Spring and 
 Hibernate) ?

Not aware of any examples out there, but here is what we did,
customized to your situation for as far as i understand it :)
Suppose we have a searchpage with some filter criteria including a
dropdown for the location. The data in this dropdown is filtered by
the permissions the user has for this page. If he has global
permissions the dropdown contains all locations. otherwise it only
contains locations assigned to this user. The user is not required to
select a location, if he does that location will be used but if he
clears the selection the search will be over all allowed locations.
clicking a row in the search results will bring him to a another page
from where he can navigate to other pages to see different data. These
pages can have different permissions as the search page. for example a
user has global search and report permissions but only location
permissions for administrative tasks.

Note that if all

Re: Wicket and inline JavaScript

2008-05-22 Thread Ned Collyer


Hi Edvin,

I am an advocate of JQuery :).  I even won their icon design contest, and
I've been using it for years!  I think it should be used in all projects
that require effects or cool DOM manipulation.

I love the unobtrusive way and xhtml strict!

That being said, when it comes to wicket AJAX - just use the wicket ajax and
be done with it.  No point mucking with something thats already excellent. 
It works and its easy.  Why reimplement that bit - and potentially open up
bugs that you need to go debug.

For effects and DOM manipulation, you can use JQuery by adding header
contributors.  It is cleaner.. and in many instances easier to debug.  It
makes development quick and painless.

If it wasn't wicket - id suggest using JQuery for ajax.


Edvin Syse wrote:
 
 Hi,
 
 I have a webdesigner who keeps harassing me with the way Wicket does 
 JavaScript, attaching behaviour to onclick events etc. instead of doing 
 it the jquery way of picking up the components and attaching the 
 events afterwards, thus keeping all the nasty bits away from the actual 
 markup.
 
 Ofcourse the code looks a lot cleaner the jquery way, and he tells me 
 that debugging and working with the code is also much easier. Personally 
 I don't know enough about html/javascript to decide what's the better 
 approach, but I just wanted to know if there are any plans to rework 
 this in Wicket, or if the current approach is just as good?
 
 -- Edvin
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-and-inline-JavaScript-tp17402101p17404025.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Testing using WicketTester

2008-05-22 Thread Ned Collyer


See the testing section here
http://cwiki.apache.org/WICKET/spring.html#Spring-UnitTestingtheProxyApproach

For testing spring.

Basically you make a context, and add it to the app.  You can load it up
with whatever real/mock beans you need.

Rgds

Ned



Eyal Golan wrote:
 
 Thanks.
 I actually tried but got an error that it could not find the application
 context (we use Spring).
 
 java.lang.IllegalStateException: No WebApplicationContext found: no
 ContextLoaderListener registered?
 
 Instead this is what I did:
 tester = new WicketTester(new WebApplication() {
 @Override
 public Session newSession(Request request, Response response)
 {
 return new PortalSession(request);
 }
 
 @Override
 public Class getHomePage() {
 // TODO Auto-generated method stub
 return null;
 }
 
 });
 
 What do you think?
 

-- 
View this message in context: 
http://www.nabble.com/Testing-using-WicketTester-tp17403637p17404126.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

RE: How can i load Image??

2008-05-22 Thread Hoover, William

Why not do:

final Image logoImg = new Image(logoimg);
logoImg.add(new SimpleAttributeModifier(src, chemin));

or:

final Image logoImg = new Image(logoimg);
logoImg.add(new AttributeModifier(src, true, new
AbstractReadOnlyModel() {
public final Object getObject() {
// TODO : get the image source that will be updated
dynamically
return chemin;
}
}));

-Original Message-
From: Fabien D. [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 22, 2008 9:08 AM
To: users@wicket.apache.org
Subject: How can i load Image??


Hi everybody,

In my web application, I want to display a Image.

I try to use Image and ResourceReference but I have some problemes

My image is in a folder stock in my context of my web aplication :

/stock/domaine/sdoimaine/projet/logo. I try to load it with the real
path, or the context path...

String name_upload = GestionProperties.getProperty(uploadRealdir);
String chemin =
name_upload+File.separator+model_domaine.getObject()+File.separator+mode
l_sous_domaine.getObject()+File.separator+model_nom.getObject()+File.sep
arator+model_logo.getObject();
ResourceReference ref = new ResourceReference(chemin);
Image logoProjet = new Image(logoimg, ref );  

And the result is :
http://localhost:8080/appWicket-1.0/resources/org.apache.wicket.Applicat
ion/stock...

How can I place my RessourceReference in the context?

Thank you in adance
--
View this message in context:
http://www.nabble.com/How-can-i-load-Image---tp17403872p17403872.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

Re: Wicket and inline JavaScript


Hi Ned,

thanks for your reply. I agree with your point of view. Today, however, 
we got bitten because the designer wanted to change all buttons by 
hiding them with jquery, and adding an anchor right after it in the 
dom-tree, so he could style them the way he wanted it (not possible with 
buttons he tells me).


You can see his lovely button on this page:

http://sd.tornado.no/domorder/search/query/testdomain

The way he then triggered the submit buttons is with the following 
Jquery code:


$('.btn.submit').click(function(){
$(this).prev().click();
});

This works most of the times, but sometimes, when the wicket ajax stuff 
includes references to 'this', the approach doesn't work, and wicket 
tells me that the ajax request was stopped 'because of precondition'.


That's when he started bitching about the Wicket way of inlining 
JavaScript, so I thought I'd be nice to hear some opinions :))


-- Edvin

Ned Collyer skrev:

Hi Edvin,

I am an advocate of JQuery :).  I even won their icon design contest, and
I've been using it for years!  I think it should be used in all projects
that require effects or cool DOM manipulation.

I love the unobtrusive way and xhtml strict!

That being said, when it comes to wicket AJAX - just use the wicket ajax and
be done with it.  No point mucking with something thats already excellent. 
It works and its easy.  Why reimplement that bit - and potentially open up

bugs that you need to go debug.

For effects and DOM manipulation, you can use JQuery by adding header
contributors.  It is cleaner.. and in many instances easier to debug.  It
makes development quick and painless.

If it wasn't wicket - id suggest using JQuery for ajax.


Edvin Syse wrote:

Hi,

I have a webdesigner who keeps harassing me with the way Wicket does 
JavaScript, attaching behaviour to onclick events etc. instead of doing 
it the jquery way of picking up the components and attaching the 
events afterwards, thus keeping all the nasty bits away from the actual 
markup.


Ofcourse the code looks a lot cleaner the jquery way, and he tells me 
that debugging and working with the code is also much easier. Personally 
I don't know enough about html/javascript to decide what's the better 
approach, but I just wanted to know if there are any plans to rework 
this in Wicket, or if the current approach is just as good?


-- Edvin





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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Jeremy Thomerson

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.

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

On Thu, May 22, 2008 at 6:23 AM, Jan Kriesten [EMAIL PROTECTED]
wrote:


 hi sebastiaan,

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


 i'm all in when you're talking about type safety. having compile-time
 checks on the types is a time-saver during development.

 with wicket generics it's just that the time-saver get's in it's own way,
 i.e. bringing in so much boilerplate, that coding is getting harder to do
 right (besides from source readability).


 regards, --- jan.

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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Jeremy Thomerson

I forgot to mention... when I said code self-documentation, I meant that
there are places where I have a component or page that takes two models.
Which is which?  I document it by the parameter name (i.e.
MyComponent(IModel fooModel, IModel barModel), but it is much better (and
the compiler checks it for me) having MyComponent(IModelFoo fooModel,
IModelBar barModel).

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

On Thu, May 22, 2008 at 8:32 AM, Jeremy Thomerson [EMAIL PROTECTED]
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.

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

 On Thu, May 22, 2008 at 6:23 AM, Jan Kriesten [EMAIL PROTECTED]
 wrote:


 hi sebastiaan,

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


 i'm all in when you're talking about type safety. having compile-time
 checks on the types is a time-saver during development.

 with wicket generics it's just that the time-saver get's in it's own way,
 i.e. bringing in so much boilerplate, that coding is getting harder to do
 right (besides from source readability).


 regards, --- jan.

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

Data Access Design for Pagination

2008-05-22 Thread wfroud


Hi,

I've been using the DefaultDataTable component in Wicket which allow me to
paginate through a few pages worth of multi column data.

I believe the general approach is to load all data from the database into
the session first (as a List of Domain Objects ?), then as navigation links
are clicked show subsets of this list?

I'm using Spring Beans Injection to inject the Data Access Object into a
subclass of SortableDataProvider (called QueryDataProvider).

Then within the QueryDataProviders constructor I'm calling a method in the
DataAccessObject to create the List of Data Objects. 

The DataProvider's iterator method then calls a subset of the List stored in
the DataAccessObject.  

I'm pretty sure this is an awful way of designing my data access, if I click
the nav links just a bit too fast I get the following error:

WicketMessage: After 1 minute the Pagemap null is still locked by:
Thread[http-8080-1,5,main], giving up trying to get the page for path:
16:entries:topToolbars:1:toolbar:span:navigator:navigation:1:pageLink

How should I be doing things differently? 

Thanks for any help, much appreciated.

Will
-- 
View this message in context: 
http://www.nabble.com/Data-Access-Design-for-Pagination-tp17404681p17404681.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: (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: How can i load Image??

2008-05-22 Thread Michael Sparer


I hope I'm getting your point right ...

I think the solution for your problem is to mount the resource. E.g. in your
application class (if it's a logo that's reused often in the app ... and
also comes with the app)

final String name = foo.jpg;
getSharedResources().add(name, PackageResource.get(YourClassScope.class,
name));
mountSharedResource(/img/ + name, new ResourceReference(name)
.getSharedResourceKey());

then you can access it with /img/foo.jpg in your html or in your
StaticImages and so on ... again, hope I got your point :-)



Fabien D. wrote:
 
 Hi everybody,
 
 In my web application, I want to display a Image.
 
 I try to use Image and ResourceReference but I have some problemes
 
 My image is in a folder stock in my context of my web aplication :
 
 /stock/domaine/sdoimaine/projet/logo. I try to load it with the real path,
 or the context path...
 
 String name_upload = GestionProperties.getProperty(uploadRealdir);
   String chemin =
 name_upload+File.separator+model_domaine.getObject()+File.separator+model_sous_domaine.getObject()+File.separator+model_nom.getObject()+File.separator+model_logo.getObject();
   ResourceReference ref = new ResourceReference(chemin);
   Image logoProjet = new Image(logoimg, ref );  
 
 And the result is :
 http://localhost:8080/appWicket-1.0/resources/org.apache.wicket.Application/stock...
 
 How can I place my RessourceReference in the context?
 
 Thank you in adance 
 


-
Michael Sparer
http://talk-on-tech.blogspot.com
-- 
View this message in context: 
http://www.nabble.com/How-can-i-load-Image---tp17403872p17405297.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: Formatting a DatePickerSettings

2008-05-22 Thread Beyonder Unknown


Hi Nate, I think you have to create/override the factor method in DateTextField 
and set it from there:


 protected DateTextField newDateTextField(String id, PropertyModel 
dateFieldModel)
{
return new DateTextField(id, dateFieldModel, new 
StyleDateConverter(false)).forDatePattern(id,dateFieldModel, MM/ddyy);
}

Hope this helps!

Regards,
Wen Tong--
The only constant in life is change.


- Original Message 
From: nate roe [EMAIL PROTECTED]
To: users@wicket.apache.org
Sent: Wednesday, May 21, 2008 3:38:00 PM
Subject: Formatting a DatePickerSettings

I'm using Wicket 1.2, and WicketExtensions 1.2.

I have a DateTextField that is formatted with the String, MM/dd/yy  This
field has a corresponding DatePickerSettings, but the DatePickerSettings
doesn't follow this format (it adds dates with four-digit years,
MM/dd/.)

How can I change this?

Thanks,
Nate



  

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

Re: Data Access Design for Pagination

Why can't you just query for the objects that should be on the page?

On Thu, May 22, 2008 at 9:51 AM, wfroud [EMAIL PROTECTED] wrote:

 Hi,

 I've been using the DefaultDataTable component in Wicket which allow me to
 paginate through a few pages worth of multi column data.

 I believe the general approach is to load all data from the database into
 the session first (as a List of Domain Objects ?), then as navigation links
 are clicked show subsets of this list?

 I'm using Spring Beans Injection to inject the Data Access Object into a
 subclass of SortableDataProvider (called QueryDataProvider).

 Then within the QueryDataProviders constructor I'm calling a method in the
 DataAccessObject to create the List of Data Objects.

 The DataProvider's iterator method then calls a subset of the List stored in
 the DataAccessObject.

 I'm pretty sure this is an awful way of designing my data access, if I click
 the nav links just a bit too fast I get the following error:

 WicketMessage: After 1 minute the Pagemap null is still locked by:
 Thread[http-8080-1,5,main], giving up trying to get the page for path:
 16:entries:topToolbars:1:toolbar:span:navigator:navigation:1:pageLink

 How should I be doing things differently?

 Thanks for any help, much appreciated.

 Will
 --
 View this message in context: 
 http://www.nabble.com/Data-Access-Design-for-Pagination-tp17404681p17404681.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

Re: (Class? extends Page?) casting troubles

Well, perhaps if we documented our specific usecases, it might help
the case for change (that's assuming there aren't already a million
other people doing the same thing ;).  I think creating the Wiki is a
good idea.  It will help us identify the growing pains we're facing
and perhaps let folks propose solutions.  Or, if the growing pains are
too numerous (which could very well be the case), we may decide that
it's just not worth it.


On Thu, May 22, 2008 at 10:42 AM, Jonathan Locke
[EMAIL PROTECTED] wrote:

 Yes. I think trying to fix this problem is really trying to fix Java, which
 is pretty far outside our scope. Sun Microsystems should be trying to fix
 such use cases not us. If people are leaving the Java platform because of
 verbosity my guess is such people left when they saw their first anonymous
 class, but that's just my opinion.

 In the case at hand, if we're doing generics where it's an unreasonable use
 case, that's one thing. We can fix that. But I think a class like component
 is almost certainly a reasonable use case and if we can't come to an
 agreement to make that generic, there's something more deeply wrong with
 Java generics which we can't fix and so the only reasonable course of action
 at that point is to scrap generics entirely  for now and wait for Sun
 Microsystems to fix it (which is the reason I asked if we could not create a
 version with the generics removed). Personally, I don't see this use of Void
 as something even remotely close to a reason to scrap it. I would happily
 use that construct every day. But that's just me.


 Sebastiaan van Erk wrote:

 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]





 --
 View this message in context: 
 http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17405816.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]

unit testing setRenderResponse(new Page()) without instantiation of Page


I am looking to unit test the following:

form.add(new AjaxSubmitLink(submitLink){
private static final long serialVersionUID = 
3239568065916265026L;

@Override
protected void onSubmit(AjaxRequestTarget target, Form 
form){
setResponsePage(new ScheduleEvent(event, 
resources));
}

Calling
tester.clickLink(submitLink, true);

instantiates the ScheduleEvent class. I want to avoid this as it forces me
to mock appropriate parameters for ScheduleEvent. All I want to do is check
that the rendered page is of type ScheduleEvent. ScheduleEvent class will
have it's own unit tests where I want to address issues concerning it. Has
anyone done this??
-- 
View this message in context: 
http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: unit testing setRenderResponse(new Page()) without instantiation of Page

You could use the bookmarkable version of setResponsePage().  That
just says what type of page to instantiate.


On Thu, May 22, 2008 at 10:51 AM, nitinkc [EMAIL PROTECTED] wrote:

 I am looking to unit test the following:

form.add(new AjaxSubmitLink(submitLink){
private static final long serialVersionUID = 
 3239568065916265026L;

@Override
protected void onSubmit(AjaxRequestTarget target, Form 
 form){
setResponsePage(new ScheduleEvent(event, 
 resources));
}

 Calling
 tester.clickLink(submitLink, true);

 instantiates the ScheduleEvent class. I want to avoid this as it forces me
 to mock appropriate parameters for ScheduleEvent. All I want to do is check
 that the rendered page is of type ScheduleEvent. ScheduleEvent class will
 have it's own unit tests where I want to address issues concerning it. Has
 anyone done this??
 --
 View this message in context: 
 http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Jonathan Locke

Yes. I think trying to fix this problem is really trying to fix Java, which
is pretty far outside our scope. Sun Microsystems should be trying to fix
such use cases not us. If people are leaving the Java platform because of
verbosity my guess is such people left when they saw their first anonymous
class, but that's just my opinion.

In the case at hand, if we're doing generics where it's an unreasonable use
case, that's one thing. We can fix that. But I think a class like component
is almost certainly a reasonable use case and if we can't come to an
agreement to make that generic, there's something more deeply wrong with
Java generics which we can't fix and so the only reasonable course of action
at that point is to scrap generics entirely for now and wait for Sun
Microsystems to fix it (which is the reason I asked if we could not create a
version with the generics removed). Personally, I don't see this use of Void
as something even remotely close to a reason to scrap it. I would happily
use that construct every day. But that's just me.

Sebastiaan van Erk wrote:

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]

--
View this message in context:
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17405816.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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

Re: How can i load Image??

2008-05-22 Thread Fabien D.


Thank you for your help, I will try your solution :)
-- 
View this message in context: 
http://www.nabble.com/How-can-i-load-Image---tp17403872p17406121.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: (Class? extends Page?) casting troubles

2008-05-22 Thread Doug Donohoe


I'll chime in again.  I really like generics.   When I first upgraded to 1.4,
I did a bit of grumbling, but I came to realize some great benefits,
especially with components.  I'd hate to lose that (almost as much as I'd
hate to go through my whole code base and remove that work).

I did a couple of things that made things easier.  First, all my pages
subclassed from a common ancestor which I just changed to 'extends
WebPageVoid'.  Second, I created some utility classes such as

   VoidContainer extends WebMarkupContainerVoid
   StringLabel extends LabelString

and so on.  I don't feel that having to create these utility classes is a
hassle or is a mark against the API.  Rather, it helps me understand how and
where I use certain types of components.  It also helps with refactoring.  

There is one place that it is ugly, but it is an edge case in a logout link. 
I just used @SuppressWarnings to deal with it.

@SuppressWarnings({unchecked})
@Override
public void onClick()
{
getSession().invalidate();
// need to use class so page is created new
setResponsePage((Classlt;? extends Pagelt;?)
getPage().getClass()));
}

The bottom line was that the work didn't take that long and in the end I
feel my code is more readable and type-safe.

-Doug


Jeremy Thomerson-5 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.
 
 -- 
 Jeremy Thomerson
 http://www.wickettraining.com
 
 On Thu, May 22, 2008 at 6:23 AM, Jan Kriesten [EMAIL PROTECTED]
 wrote:
 

 hi sebastiaan,

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


 i'm all in when you're talking about type safety. having compile-time
 checks on the types is a time-saver during development.

 with wicket generics it's just that the time-saver get's in it's own way,
 i.e. bringing in so much boilerplate, that coding is getting harder to do
 right (besides from source readability).


 regards, --- jan.

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


 
 

-- 
View this message in context: 
http://www.nabble.com/%28Class%3C--extends-Page%3C-%3E%3E%29--casting-troubles-tp17355847p17406422.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: refreshingview with textfield items that use validatior

see setitemreusestrategy, there is also an example in
wicketstuff.org/wicket13/repeater

-igor


On Thu, May 22, 2008 at 5:43 AM, i ii [EMAIL PROTECTED] wrote:

 how can use refreshingview with textfield items that use validatior? when i 
 use and validator fails all textfield values reset. i want reset every 
 request, but not when validator fails.
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



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

Re: unit testing setRenderResponse(new Page()) without instantiation of Page


That won't work for me b'cos I am also passing constructor arguments to the
response Page.
So new Page() is actually new Page(x,y).


jwcarman wrote:
 
 You could use the bookmarkable version of setResponsePage().  That
 just says what type of page to instantiate.
 
 
 On Thu, May 22, 2008 at 10:51 AM, nitinkc [EMAIL PROTECTED] wrote:

 I am looking to unit test the following:

form.add(new AjaxSubmitLink(submitLink){
private static final long serialVersionUID =
 3239568065916265026L;

@Override
protected void onSubmit(AjaxRequestTarget target,
 Form form){
setResponsePage(new ScheduleEvent(event,
 resources));
}

 Calling
 tester.clickLink(submitLink, true);

 instantiates the ScheduleEvent class. I want to avoid this as it forces
 me
 to mock appropriate parameters for ScheduleEvent. All I want to do is
 check
 that the rendered page is of type ScheduleEvent. ScheduleEvent class will
 have it's own unit tests where I want to address issues concerning it.
 Has
 anyone done this??
 --
 View this message in context:
 http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17406699.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: unit testing setRenderResponse(new Page()) without instantiation of Page

Can those arguments be put into PageParameters?

On Thu, May 22, 2008 at 11:24 AM, nitinkc [EMAIL PROTECTED] wrote:

 That won't work for me b'cos I am also passing constructor arguments to the
 response Page.
 So new Page() is actually new Page(x,y).


 jwcarman wrote:

 You could use the bookmarkable version of setResponsePage().  That
 just says what type of page to instantiate.


 On Thu, May 22, 2008 at 10:51 AM, nitinkc [EMAIL PROTECTED] wrote:

 I am looking to unit test the following:

form.add(new AjaxSubmitLink(submitLink){
private static final long serialVersionUID =
 3239568065916265026L;

@Override
protected void onSubmit(AjaxRequestTarget target,
 Form form){
setResponsePage(new ScheduleEvent(event,
 resources));
}

 Calling
 tester.clickLink(submitLink, true);

 instantiates the ScheduleEvent class. I want to avoid this as it forces
 me
 to mock appropriate parameters for ScheduleEvent. All I want to do is
 check
 that the rendered page is of type ScheduleEvent. ScheduleEvent class will
 have it's own unit tests where I want to address issues concerning it.
 Has
 anyone done this??
 --
 View this message in context:
 http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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]




 --
 View this message in context: 
 http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17406699.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

Re: (Class? extends Page?) casting troubles

actually, if implemented properly EditPage should take IModelPerson
and not Person itself. so unless you typed Link you have IModel?
that you have to cast to IModelPerson

-igor

On Thu, May 22, 2008 at 2:45 AM, Jan Kriesten [EMAIL PROTECTED] wrote:

 Hi Johan,

 I thing that the example below is exactly the thing that generics are
 pretty
 good:

 populateItem(ListItemPerson item) {
   add(new LinkPerson(edit, item.getModel()) {
   public void onClick() {
   setResponsePage(new EditPage(getModelObject()));
   }
   });

 (and EditPage is by itself already generified to Person)

 well, just that the LinkPerson is IMHO redundant and unnecessary(just
 dropped a note to Martijn, but since you brought that up...)

 populateItem(final ListItemPerson item) {
item.add(new Link(edit) {
public void onClick() {
setResponsePage(new EditPage(item.getModelObject()));
}
});

 So, it might have sense with ListItem, but not necissarily with Link...

 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]

Focus not getting set after an ajax call

2008-05-22 Thread hillj2


I have an issue with DropDownChoice components with an attached
AjaxFormComponentUpdatingBehavior.  After the ajax is processed the focus
doesn't properly get reset so when the user tabs, the focus jumps back to
the top of the page.  It doesn't happen all the time, but most of the time
(the issue seems somewhat inconsistent and seems to happen more frequently
for different fields).  When the problem occurs, the ajax debug outputs
last focus id was not set.  So apparently, for some reason, the focus id
is not set on the ajax call, so it can't be reset properly after the call
completes.

Any reason why this is occurring and how to fix it?  I was originally using
wicket 1.3.1, but tried upgrading to 1.3.3, but this did not fix the issue.

Thanks.

Joel
-- 
View this message in context: 
http://www.nabble.com/Focus-not-getting-set-after-an-ajax-call-tp17407105p17407105.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: unit testing setRenderResponse(new Page()) without instantiation of Page


I am not sure, but would rather not. I believe this is a standard way to
create pages in Wicket(passing required arguments in constructors) and there
should be a mechanism to test this. 

On a side note, when I change my code to:
form.add(new AjaxSubmitLink(submitLink){
private static final long serialVersionUID = 
3239568065916265026L;

@Override
protected void onSubmit(AjaxRequestTarget target, Form 
form){
//setResponsePage(new ScheduleEvent(event, 
resources));
setResponsePage(ScheduleEvent.class);
}   
});

the following fails

tester.clickLink(eventDetailsGroupBox:eventDetailsForm:submitLink,
false);
tester.assertRenderedPage(ScheduleEvent.class);

junit.framework.AssertionFailedError: expected:ScheduleEvent but
was:EventDetails
at
org.apache.wicket.util.tester.WicketTester.assertResult(WicketTester.java:575)
at
org.apache.wicket.util.tester.WicketTester.assertRenderedPage(WicketTester.java:522)
at 



I have verified that 
onSubmit(AjaxRequestTarget target, Form form) 
is infact getting called. Any ideas?


jwcarman wrote:
 
 Can those arguments be put into PageParameters?
 
 On Thu, May 22, 2008 at 11:24 AM, nitinkc [EMAIL PROTECTED] wrote:

 That won't work for me b'cos I am also passing constructor arguments to
 the
 response Page.
 So new Page() is actually new Page(x,y).


 jwcarman wrote:

 You could use the bookmarkable version of setResponsePage().  That
 just says what type of page to instantiate.


 On Thu, May 22, 2008 at 10:51 AM, nitinkc [EMAIL PROTECTED]
 wrote:

 I am looking to unit test the following:

form.add(new AjaxSubmitLink(submitLink){
private static final long serialVersionUID =
 3239568065916265026L;

@Override
protected void onSubmit(AjaxRequestTarget
 target,
 Form form){
setResponsePage(new ScheduleEvent(event,
 resources));
}

 Calling
 tester.clickLink(submitLink, true);

 instantiates the ScheduleEvent class. I want to avoid this as it forces
 me
 to mock appropriate parameters for ScheduleEvent. All I want to do is
 check
 that the rendered page is of type ScheduleEvent. ScheduleEvent class
 will
 have it's own unit tests where I want to address issues concerning it.
 Has
 anyone done this??
 --
 View this message in context:
 http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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]




 --
 View this message in context:
 http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17406699.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]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17407117.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]

Possible BUG - discrepancy in component.onBeforeRender and IBehavior.beforeRender.

2008-05-22 Thread gumnaam23


The  following statement 

if (!component.isAuto()  getFlag(FLAG_RENDERING)) 

in Component- checkHierarchyChange()

returns false when a Behavior is added to the Component.onBeforeRender()
phase, but returns true if
a Behavior is added by another Behavior as part of it's beforeRender()
phase. 

So 
new Component () {
  onBeforeRender() {
add(some behavior);
}

Works.

but 
new Component().add(new AbstractBehavior() {
 
   beforeRender(Component c) {
 c.addBehavior(some behavior);
  }

}

doesn't work, as the getFlag(FLAG_RENDERING) returns false in the first case
and true in the next case.
So in the second case, I get an Exception.

Is this an expected behavior or a possible bug ?


  

-- 
View this message in context: 
http://www.nabble.com/Possible-BUG---discrepancy-in-component.onBeforeRender-and-IBehavior.beforeRender.-tp17407123p17407123.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

RE: refreshingview with textfield items that use validatior

2008-05-22 Thread i ii

thank you for help, but all i find is 
org.apache.wicket.markup.repeater.ReuseIfModelsEqualStrategy and 
org.apache.wicket.markup.repeater.DefaultItemReuseStrategy. neither work, need 
to implement org.apache.wicket.markup.repeater.IItemReuseStrategy?

 Date: Thu, 22 May 2008 08:22:41 -0700
 From: [EMAIL PROTECTED]
 To: users@wicket.apache.org
 Subject: Re: refreshingview with textfield items that use validatior

 see setitemreusestrategy, there is also an example in
 wicketstuff.org/wicket13/repeater

 -igor

 On Thu, May 22, 2008 at 5:43 AM, i ii [EMAIL PROTECTED] wrote:

  how can use refreshingview with textfield items that use validatior? when i 
  use and validator fails all textfield values reset. i want reset every 
  request, but not when validator fails.
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: (Class? extends Page?) casting troubles



Hi Doug,

 The bottom line was that the work didn't take that long and in the end I
 feel my code is more readable and type-safe.

I have tried 4 times to convert my 1.3 codebase to 1.4 - and failed 4 times. All 
in all I spent 3 days and just reverted it.


There are API changes thru generics, which just break the way my app works.

Trying to code tables with PropertyColumns and IColumns just isn't readable any 
more due to having to cast (which before wasn't necessary)...


And the many Void aren't making it any better of course!


Best regards, --- Jan.

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

Re: Using the WicketTester WITHOUT rendering a response on submit


Timo,
I am trying to achieve something similar. How did you manage to assign the
TestingWebApplication  to your WicketTester?? Thanks!


mclev wrote:
 
 
 
 mclev wrote:
 
 4. Can I test that the response page is what I expect when when I first
 render and when i submit my form
 
 So, call me crazy, but it occurs to me that it would be nice if I could
 unit test just my page, verifying that when the code in my page
 finishes executing everything is what I expect. I don't really care if
 the response page renders properly (I'll test that in a unit test for
 that page), I just want to know that the logic in my page in sending off
 to the new page.
 
 
 
 So I figured out a way to do this by extending the
 WebRequestCycleProcessor.respond methods. :
 
 public class TestingWebRequestCycleProcessor extends
 WebRequestCycleProcessor {
   
   private boolean respondingSuspended = false;
   
   public TestingWebRequestCycleProcessor(){
   super();
   }
 
   public boolean isRespondingSuspended() {
   return respondingSuspended;
   }
 
   public void setRespondingSuspended(boolean respondingSuspended) {
   this.respondingSuspended = respondingSuspended;
   }
   
   @Override
   public void respond(RequestCycle requestCycle)
   {
   if (isRespondingSuspended()){
   return;
   }
   
   super.respond(requestCycle);
   }
   
   @Override
   public void respond(RuntimeException e, RequestCycle requestCycle)
   {
   if (isRespondingSuspended()){
   return;
   }
   
   super.respond(e, requestCycle);
   }
 }
 
 then overriding the WicketTester.DummyApplication:
 
 public class TestingWebApplication  extends
 WicketTester.DummyWebApplication{
   
   private TestingWebRequestCycleProcessor requestProcessor;
   
   @Override
   protected IRequestCycleProcessor newRequestCycleProcessor()
   {
   requestProcessor =  new TestingWebRequestCycleProcessor();
   return requestProcessor;
   }
   
   public void suspendResponding(){
   requestProcessor.setRespondingSuspended(true);
   }
   
   public void unsuspendResponding(){
   requestProcessor.setRespondingSuspended(false); 
   }
 }
 
 
 now my test looks like this:
 
   @Test
   public void testSubmitExistingPart(){
   // setup for modifying a part (part has an id -- found by dao)
   setUp();
   final Part part = new MockPart(10);
   final PartDAO mockDAO = module.getmock();
   mockery.checking(new Expectations(){{
   one(mockDAO).findPart(part.getId()); 
 will(returnValue(part));
   one(mockDAO).save(with(same(part)));
   }});
   PageParameters params = new PageParameters(id=+ part.getId());
   Page page = new PartDetailPage(params); 
   tester.startPage(page);
   
   // simulate entry of part data
   FormTester formTester = tester.newFormTester(inputForm);
   String barcode = 123;
   String name = ABC;
   String description = XYZ;
   enterFormData(formTester, barcode, name, description);
   
   testApp.suspendResponding(); // so response won't be rendered
   formTester.submit();
   
   // verify values set properly in model;
   assertModelUpdated(part, barcode, name, description);
   
   // verify that response page is correct
 // this now works -- even though the page isn't really
 renderd
   tester.assertRenderedPage(PartListPage.class);
   }
 
 I'm still new to wicket so if anybody thinks this is this is crazy please
 let me know.
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Using-the-WicketTester-WITHOUT-rendering-a-response-on-submit-tp13737447p17407457.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: unit testing setRenderResponse(new Page()) without instantiation of Page


Seems like bookmarkable setResponsePage will not work either. Check:
http://www.nabble.com/How-to-test-setResponsePage-td16802302.html


nitinkc wrote:
 
 I am not sure, but would rather not. I believe this is a standard way to
 create pages in Wicket(passing required arguments in constructors) and
 there should be a mechanism to test this. 
 
 On a side note, when I change my code to:
   form.add(new AjaxSubmitLink(submitLink){
   private static final long serialVersionUID = 
 3239568065916265026L;
 
   @Override
   protected void onSubmit(AjaxRequestTarget target, Form 
 form){
   //setResponsePage(new ScheduleEvent(event, 
 resources));
   setResponsePage(ScheduleEvent.class);
   }   
   });
 
 the following fails
   
 tester.clickLink(eventDetailsGroupBox:eventDetailsForm:submitLink,
 false);
   tester.assertRenderedPage(ScheduleEvent.class);
 
 junit.framework.AssertionFailedError: expected:ScheduleEvent but
 was:EventDetails
   at
 org.apache.wicket.util.tester.WicketTester.assertResult(WicketTester.java:575)
   at
 org.apache.wicket.util.tester.WicketTester.assertRenderedPage(WicketTester.java:522)
   at 
 
 
 
 I have verified that 
 onSubmit(AjaxRequestTarget target, Form form) 
 is infact getting called. Any ideas?
 
 
 jwcarman wrote:
 
 Can those arguments be put into PageParameters?
 
 On Thu, May 22, 2008 at 11:24 AM, nitinkc [EMAIL PROTECTED]
 wrote:

 That won't work for me b'cos I am also passing constructor arguments to
 the
 response Page.
 So new Page() is actually new Page(x,y).


 jwcarman wrote:

 You could use the bookmarkable version of setResponsePage().  That
 just says what type of page to instantiate.


 On Thu, May 22, 2008 at 10:51 AM, nitinkc [EMAIL PROTECTED]
 wrote:

 I am looking to unit test the following:

form.add(new AjaxSubmitLink(submitLink){
private static final long serialVersionUID =
 3239568065916265026L;

@Override
protected void onSubmit(AjaxRequestTarget
 target,
 Form form){
setResponsePage(new
 ScheduleEvent(event,
 resources));
}

 Calling
 tester.clickLink(submitLink, true);

 instantiates the ScheduleEvent class. I want to avoid this as it
 forces
 me
 to mock appropriate parameters for ScheduleEvent. All I want to do is
 check
 that the rendered page is of type ScheduleEvent. ScheduleEvent class
 will
 have it's own unit tests where I want to address issues concerning it.
 Has
 anyone done this??
 --
 View this message in context:
 http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17405981.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]




 --
 View this message in context:
 http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17406699.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]
 
 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/unit-testing-setRenderResponse%28new-Page%28%29%29-without-instantiation-of-Page-tp17405981p17407666.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]

Can't see progress in progressBar from Safari

2008-05-22 Thread Steamus


I use standard Wicket ajax progress bar. The Wicket version is 1.3.3.
It works excellent with IE6/7, Fox, Opera (little conflict with Date
picker), but doesn’t work with Safari (3.1.1). I can see title ‘upload
starting…’ only. No bar from left to right, no percentage...

I checked the example
(http://www.wicket-library.com/wicket-examples/upload/single). It does not
work with Safari too… :-(

Anybody won this problem?

-- 
View this message in context: 
http://www.nabble.com/Can%27t-see-progress-in-progressBar-from-Safari-tp17407714p17407714.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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

Re: (Class? extends Page?) casting troubles

Since I like to have the last word in all discussions, let's close
this one down and move it to our development list. I have started a
[discuss] thread over there with an outline of a process. See you
there!

Martijn

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

Re: Can't see progress in progressBar from Safari

I ran into the same problem:
http://www.nabble.com/UploadProgress-in-1.3.3---does-it-work--to17372890.html

Martijn

On Thu, May 22, 2008 at 6:11 PM, Steamus [EMAIL PROTECTED] wrote:

 I use standard Wicket ajax progress bar. The Wicket version is 1.3.3.
 It works excellent with IE6/7, Fox, Opera (little conflict with Date
 picker), but doesn't work with Safari (3.1.1). I can see title 'upload
 starting…' only. No bar from left to right, no percentage...

 I checked the example
 (http://www.wicket-library.com/wicket-examples/upload/single). It does not
 work with Safari too… :-(

 Anybody won this problem?

 --
 View this message in context: 
 http://www.nabble.com/Can%27t-see-progress-in-progressBar-from-Safari-tp17407714p17407714.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.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

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

Re: [PROPOSAL] wicketstuff SVN reorganization...

2008-05-22 Thread Eelco Hillenius

 p.s. Sorry to be such a stickler, but I'm one of those folks who has
 to have order.  I can't work until I clean my desk up first! :)

Haha. You must be popular with girls (at least the ones I know would
love a guy like that)! ;-)

+1 for doing a vote.

Eelco

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

Re: [PROPOSAL] wicketstuff SVN reorganization...

Please keep these types of discussion on the dev@ list. It is hardly a
user question (perhaps the confusing bit)

So if you go for a vote, do it on dev@

Martijn

PS. My boss would *love* you... my desk is a huge pile of paper,
cables, cd's, used mugs and cans.

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

Re: Data Access Design for Pagination

you should be performing the query inside iterator() and size()
methods. that way you only retrieve the data you are going to display.

-igor

On Thu, May 22, 2008 at 6:51 AM, wfroud [EMAIL PROTECTED] wrote:

 Hi,

 I've been using the DefaultDataTable component in Wicket which allow me to
 paginate through a few pages worth of multi column data.

 I believe the general approach is to load all data from the database into
 the session first (as a List of Domain Objects ?), then as navigation links
 are clicked show subsets of this list?

 I'm using Spring Beans Injection to inject the Data Access Object into a
 subclass of SortableDataProvider (called QueryDataProvider).

 Then within the QueryDataProviders constructor I'm calling a method in the
 DataAccessObject to create the List of Data Objects.

 The DataProvider's iterator method then calls a subset of the List stored in
 the DataAccessObject.

 I'm pretty sure this is an awful way of designing my data access, if I click
 the nav links just a bit too fast I get the following error:

 WicketMessage: After 1 minute the Pagemap null is still locked by:
 Thread[http-8080-1,5,main], giving up trying to get the page for path:
 16:entries:topToolbars:1:toolbar:span:navigator:navigation:1:pageLink

 How should I be doing things differently?

 Thanks for any help, much appreciated.

 Will
 --
 View this message in context: 
 http://www.nabble.com/Data-Access-Design-for-Pagination-tp17404681p17404681.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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



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

RE: refreshingview with textfield items that use validatior

2008-05-22 Thread i ii

i cannot get to work :(

 From: [EMAIL PROTECTED]
 To: users@wicket.apache.org
 Subject: RE: refreshingview with textfield items that use validatior
 Date: Thu, 22 May 2008 15:47:52 +

 thank you for help, but all i find is 
 org.apache.wicket.markup.repeater.ReuseIfModelsEqualStrategy and 
 org.apache.wicket.markup.repeater.DefaultItemReuseStrategy. neither work, 
 need to implement org.apache.wicket.markup.repeater.IItemReuseStrategy?

  Date: Thu, 22 May 2008 08:22:41 -0700
  From: [EMAIL PROTECTED]
  To: users@wicket.apache.org
  Subject: Re: refreshingview with textfield items that use validatior

  see setitemreusestrategy, there is also an example in
  wicketstuff.org/wicket13/repeater

  -igor

  On Thu, May 22, 2008 at 5:43 AM, i ii [EMAIL PROTECTED] wrote:

   how can use refreshingview with textfield items that use validatior? when 
   i use and validator fails all textfield values reset. i want reset every 
   request, but not when validator fails.
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: refreshingview with textfield items that use validatior

if you use reuseifmodelequalsstrategy then you need to implement
equals/hashcode on the models you give to refreshingview

-igor

On Thu, May 22, 2008 at 11:40 AM, i ii [EMAIL PROTECTED] wrote:

 i cannot get to work :(

 From: [EMAIL PROTECTED]
 To: users@wicket.apache.org
 Subject: RE: refreshingview with textfield items that use validatior
 Date: Thu, 22 May 2008 15:47:52 +


 thank you for help, but all i find is 
 org.apache.wicket.markup.repeater.ReuseIfModelsEqualStrategy and 
 org.apache.wicket.markup.repeater.DefaultItemReuseStrategy. neither work, 
 need to implement org.apache.wicket.markup.repeater.IItemReuseStrategy?

  Date: Thu, 22 May 2008 08:22:41 -0700
  From: [EMAIL PROTECTED]
  To: users@wicket.apache.org
  Subject: Re: refreshingview with textfield items that use validatior
 
  see setitemreusestrategy, there is also an example in
  wicketstuff.org/wicket13/repeater
 
  -igor
 
 
  On Thu, May 22, 2008 at 5:43 AM, i ii [EMAIL PROTECTED] wrote:
  
   how can use refreshingview with textfield items that use validatior? 
   when i use and validator fails all textfield values reset. i want reset 
   every request, but not when validator fails.
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 


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

Re: filter for data in security layer

2008-05-22 Thread Maurice Marrink

I am not sure i follow you.

According to the log the user does not have the datapermission for the dropdown.

 I tried to set the permissions like in the explanation below, but that didn't 
 work:

 // Welcome page
 permission ${ComponentPermission} ${front}.Welcome, inherit, render, 
 global;
 permission ${ComponentPermission} ${front}.Welcome, enable, global;

What is not working?


In general adding custom actions to your pages is only useful if the
page has a securitycheck that actually checks for those actions. In
the case of a welcome page that is probably overkill but for a page
showing for example customer info it would be very useful to check if
the user has global permissions and thus can see any user or local
permissions and this only is the customer is affiliated with one of
his locations. Such a check could be implemented like this.
public boolean isActionAuthorized(WaspAction action)
{
WaspAction combined = null;
WaspAction additional;
ActionFactory factory = getActionFactory();
additional = factory.getAction(Global.class);
combined = action.add(additional);
//wrapped is another isecuritycheck like a component- or 
classsecuritycheck
if (wrapped.isActionAuthorized(combined))
return true; //global so everything is allowed
additional = factory.getAction(Location.class);
combined = action.add(additional);
if (wrapped.isActionAuthorized(combined))
return 
verifyCustomerLocationMatchesUserLocations(someCustomer, theUser);
return false;
}
The custom security check in the examples simply overrides an existing
check where this check could extend AbstractSecurityCheck but the
principal is the same. You need to check your custom actions yourself.

Not sure if that at all answers your question.

Maurice


 Debug logging:
 2008-05-22 14:47:57,515 DEBUG 
 org.apache.wicket.security.hive.BasicHive.addPrincipal(BasicHive.java:111) - 
 Adding 
 org.apache.wicket.security.hive.authorization.permissions.ComponentPermission 
 xxx.yyy.zzz.front.Welcome access, render, enable, location, global to 
 everybody
 2008-05-22 14:47:57,515 DEBUG 
 org.apache.wicket.security.hive.BasicHive.addPrincipal(BasicHive.java:111) - 
 Adding 
 org.apache.wicket.security.hive.authorization.permissions.ComponentPermission 
 xxx.yyy.zzz.front.Welcome access, inherit, render, location, global to 
 everybody

 2008-05-22 14:48:13,046 DEBUG 
 org.apache.wicket.Component.render(Component.java:2284) - Begin render 
 [MarkupContainer [Component id = selectLocation, page = 
 xxx.yyy.zzz.front.Welcome, path = 
 1:formLocation:selectLocation.DropDownChoice, isVisible = true, isVersioned = 
 false]]
 2008-05-22 14:48:13,046 DEBUG 
 org.apache.wicket.security.hive.BasicHive.hasPermission(BasicHive.java:224) - 
 Subjects[HashKey: -1185945692, sortOrder 0 = [EMAIL PROTECTED] [mailto:[EMAIL 
 PROTECTED] does not have or implies 
 org.apache.wicket.security.hive.authorization.permissions.DataPermission 
 LocationListModel global

 Andrea

 -
 On Sun, May 18, 2008 at 7:26 PM, Igor Vaynberg [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] wrote:
 something like this should probably be filter inside the database not
 by some external filter which forces you to load the entire dataset.

 No that would be foolish, but that wasn't suggested.


 -igor

 On Sun, May 18, 2008 at 9:39 AM, Andrea Jahn [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] wrote:




 Hi,

 in our application locations are administered. A user has only rights on 
 some of the locations, e.g. Munich, Berlin. He should be able to select one 
 of the allowed locations in a selection box. Then on the different pages 
 all data are depending on the actually selected location. For example a 
 DataView shows only the items, which belong to this location.

 Could Swarm support data filtering ?

 Yes, especially in 1.3.1 this is a bit cleaner dependency wise. But
 there is no out of the box solution as there are lots of framework
 combinations possible. So get ready for some heavy duty programming :)


 I found the following related message.

 http://markmail.org/message/hb42u5xj7xlvumm7 
 [http://markmail.org/message/hb42u5xj7xlvumm7] 
 [http://markmail.org/message/hb42u5xj7xlvumm7] (subsection4)

 I like the idea, that the dataproviders get some filters (only the data 
 which are needed should be read from the database), but where should I 
 store the filters for the actual selected location in the security layer ?

 Perhaps does someone know examples for that issue (using Wicket, Spring and 
 Hibernate) ?

 Not aware of any examples out there, but here is what we did,
 customized to your situation for as far as i understand it :)
 Suppose we have a searchpage with some filter criteria including a
 dropdown for the location. The data in this

missing something: getting AjaxCheckBox to recheck value from model as its redrawn?

2008-05-22 Thread Kirk Israel

Short version of my question:
Why wouldn't redrawing a surrounding span for an AjaxCheckBox (all
embedded inside a ListView) be enough to get it to check its
underlying PropertyModel, and then reflect that new value?
(and is it broken for an underlying PropertyModel's hashmap to return
null for that key?)

Background:
So I'm tearing my hair out over this, because I've (somewhat) deeply
researched what's going on our code side, but might be dumbly missing
something basic on the Wicket side.

We have a list view that iterates over manufacturers, and each
manufacturer has a pallet control of devices
(two list boxes w/ move selection to right list, move selection to
left list buttons between) along with a all for manufacturer
checkbox

(the checkbox is a bit tricky, because it's also saying this is true
for this manufacturer even if it's not a device we recognize)

When you click the select all checkbox, it calls the function that
moves everything into the right hand select list, great.

What I'd like to have happen is moving an item from the right hand
list back to the left also unchecks the select box.

I cannot get this checkbox to update for anything!

Another developer has the underlying model contain a
HashMapString,Boolean of manufacturers, so the code is like

final AjaxCheckBox selectAllCheckbox = new
AjaxCheckBox(manufacturerCheckbox, new
PropertyModel(mTargetModel.getManufacturersAsMap(), manufacturerName))
{

then, when the remove from right list button is hit, it removes the
manufacturer value from the list (originally it just set it to false;
is it ok to have the Property return null for a checkbox value, to
mean false?) and then adds the checkbox to the AjaxRequestTarget ;
actually it adds a containing span, which also (for now) has a label
w/ a timestamp, so I can see that the whole span containing the
checkbox is being redrawn.

I also updated the Target Model's getManufacturersAsMap() function, so
that it logs when it's called. Oddly (to me, again I might be missing
something here) the getManufacturersAsMap() is called when the page is
constructed and when the checkbox is clicked but NOT when the span
including the checkbox is being redrawn.

Just out of curiosity I've tried this with and without the ListView
setReuseItems set to true. I've made sure that appropriate
setOutputMarkupIds are set (it seems some of the rules for making sure
your nesting wicket:id hierarchy are relaxed in the case of ListViews,
though of course I try to be as faithful as always, still that doesn't
seem to be the problem)

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

RE: AjaxLink not clickable in IE

2008-05-22 Thread Michael Mehrle

LOL - sorry - I saw tons of messages regarding generics and wanted to
make sure it didn't fall through the cracks. 

Yes, you spoil us! :-P

M.

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 21, 2008 6:50 PM
To: users@wicket.apache.org
Subject: Re: AjaxLink not clickable in IE

wow. we spoil our users too much when they complain about not getting
a response after 3 hours...

-igor

On Wed, May 21, 2008 at 5:24 PM, Michael Mehrle [EMAIL PROTECTED]
wrote:
 Anyone? Or are we only talking generics today? ;-)

 Seriously, could use a 2nd pair of eyes on this one... any input
 appreciated.

 -Original Message-
 From: Michael Mehrle [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, May 21, 2008 2:31 PM
 To: users@wicket.apache.org
 Subject: AjaxLink not clickable in IE

 I've got this AjaxLink:



 fooLink = new AjaxLink(fooLink) {

@Override

public void
 onClick(AjaxRequestTarget target) {

Boolean
 selected = (Boolean) fooCheckBox.getModelObject();

if
 (!selected) {


 fooCheckBox.setModelObject((new Boolean(true)));

}


 target.addComponent(fooCheckBox);

// pop up
 the modal


 showRecurringFooModal(recurringFooModalWindow, target);

}

};



 a href= wicket:id= fooLink  class=textlinkwicket:message
 key=fooLabel //a



 Works fine in Safari and Firefox but in IE it's not clickable - looks
 like a link but the mouse pointer doesn't change and nothing happens
 when clicking. No error message either in IE's JS console or in AJAX.
 Any idea what I'm doing wrong here?



 Michael


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



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


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

RE: AjaxLink not clickable in IE

2008-05-22 Thread Michael Mehrle

Nothing happens in the AJAX debug - checked that first thing. It just
behaves as if the link doesn't exist.

Michael

-Original Message-
From: richardwilko [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 22, 2008 1:54 AM
To: users@wicket.apache.org
Subject: Re: AjaxLink not clickable in IE

I have found ie to be rubbish it comes to javascript, any error in any
file
can stop all the javascript on the page working.  make sure you dont
have
other javascript on the page which causes problems.

Also open up the wicket ajax debug window and see you anything happens
in
there when you click on the link.

richard

igor.vaynberg wrote:

 wow. we spoil our users too much when they complain about not getting
 a response after 3 hours...

 -igor

 On Wed, May 21, 2008 at 5:24 PM, Michael Mehrle
[EMAIL PROTECTED]
 wrote:
 Anyone? Or are we only talking generics today? ;-)

 Seriously, could use a 2nd pair of eyes on this one... any input
 appreciated.

 -Original Message-
 From: Michael Mehrle [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, May 21, 2008 2:31 PM
 To: users@wicket.apache.org
 Subject: AjaxLink not clickable in IE

 I've got this AjaxLink:

 fooLink = new AjaxLink(fooLink) {

@Override

public void
 onClick(AjaxRequestTarget target) {

Boolean
 selected = (Boolean) fooCheckBox.getModelObject();

if
 (!selected) {

 fooCheckBox.setModelObject((new Boolean(true)));

}

 target.addComponent(fooCheckBox);

// pop up
 the modal

 showRecurringFooModal(recurringFooModalWindow, target);

}

};

   wicket:message
 key=fooLabel / 

 Works fine in Safari and Firefox but in IE it's not clickable - looks
 like a link but the mouse pointer doesn't change and nothing happens
 when clicking. No error message either in IE's JS console or in AJAX.
 Any idea what I'm doing wrong here?

 Michael

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

-- 
View this message in context:
http://www.nabble.com/AjaxLink-not-clickable-in-IE-tp17379705p17399591.h
tml
Sent from the Wicket - User mailing list archive at Nabble.com.

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

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

Re: AjaxLink not clickable in IE