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

2008-06-01 Thread Jeremy Thomerson
Weird indeed.  Do this... capture the return of your ((ConverterLocator)
getConverterLocator()).set(...) call.  In that method, it is returning the
result of a Map.put(Timestamp.class, your-converter).  Therefore, the result
should be non-null, as you should be overriding the default implementation
that was already put in the map.

Something like:

IConverter ic = ((ConverterLocator)
getConverterLocator()).set(Timestamp.class, new IConverterTimestamp() {

private static final long serialVersionUID = 1L;

public Timestamp convertToObject(String value, Locale
locale) {
if (value == null) {
return null;
}
if (locale == null) {
locale = Locale.getDefault();
}
DateFormat format =
DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
try {
Date date = format.parse(value);
return new Timestamp(date.getTime());
} catch (ParseException e) {
throw new ConversionException(Cannot parse '
+ value + ' using format  + format)
.setSourceValue(value).setTargetType(
Timestamp.class).setConverter(this)
.setLocale(locale);
}
}

public String convertToString(final Timestamp value, Locale
locale) {
if (value == null) {
return null;
}
if (locale == null) {
locale = Locale.getDefault();
}
DateFormat format =
DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
return format.format(value);
}

});
System.out.println(I OVERRODE THIS CONVERTER: + ic);

Also - what version are you running?


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

On Sun, Jun 1, 2008 at 1:05 AM, Michael Mehrle [EMAIL PROTECTED]
wrote:

 Yes, exactly the way you're doing it - didn't change anything except for
 removing the generic def in the IConverter interface (not using generics
 yet in my current project).

 And yes, I also set my breakpoint but it's never being called. The field
 simply grabs the time value and no conversion seems to be happening.

 BTW, very elegant fix - just hope I can make this work (driving me crazy
 this issue).

 Michael

 -Original Message-
 From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
 Sent: Saturday, May 31, 2008 7:14 PM
 To: users@wicket.apache.org
 Subject: RE: Timestamp - java.util.Date convertion in Wicket

 Did you make sure to use the code exactly (it calls SET on the concrete
 implementation rather than the standard way of just adding a converter
 to the interface)?

 Which version are you using?  This problem appeared in 1.3, and I have
 tested my fix in all versions of of 1.3 and 1.4-m1 and m2.

 You can set a breakpoint in your implementation and in the default with
 Wicket to see which is getting called.  Let me know what you find.

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


 -Original Message-
 From: Michael Mehrle [EMAIL PROTECTED]
 Sent: Saturday, May 31, 2008 8:57 PM
 To: users@wicket.apache.org
 Subject: RE: Timestamp - java.util.Date convertion in Wicket

 Hello Jeremy:

 I added the converter to my apps init() method per your example but the
 problem persists. I keep seeing 12:00am instead of the date. Any
 suggestions?

 Michael

 -Original Message-
 From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
 Sent: Friday, May 30, 2008 7:35 PM
 To: users@wicket.apache.org
 Subject: RE: Timestamp - java.util.Date convertion in Wicket

 Found a link:

 http://markmail.org/message/m5cyca4vsrrvcrid

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


 -Original Message-
 From: Michael Mehrle [EMAIL PROTECTED]
 Sent: Friday, May 30, 2008 8:55 PM
 To: users@wicket.apache.org
 Subject: Timestamp - java.util.Date convertion in Wicket

 I am persisting java.util.Date objects to the DB but am getting
 Timestamp objects back (no surprise there since the hibernate type is
 set to 'timestamp'). Wicket converts the Timestamp and populates my
 field without complaining but all I'm getting is the time (12:00am - the
 default start time since it wasn't set due to it originating as a Date).
 Is there some sort of default converter? I assume this is a common
 scenario.



 Thanks,



 Michael



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


 -
 To unsubscribe, 

Wicket in Action PDF - font size

2008-06-01 Thread Eyal Golan
Hi,

I plan to buy this book but not sure if to buy only the ebook or also the
paper version as well.
I prefer just the e-book so I won't waist another tree :)

I downloaded the free first chapter of WIA.
It seems to me that the font is a bit small.
even when I fit width it is still too small.
I needed to zoom in more.
I could see that there's a big area in the left of the page that is not
used.

Is the final version of the e-book going to have bigger font?

It may seem a stupid question here in the users group, but it's important
for me.

thanks
-- 
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74


Re: Changing Link string conditionally?

2008-06-01 Thread Erik van Oosten

The idea is to put a span inside the a, and then attach a Label to the span.

Is that something you can work with?

Regards,
   Erik.


Michael Mehrle wrote:

Okay, this seems so easy, but I'm somehow stuck. How do I change the
string of a Link based on some condition? Do I simply provide a
terminated tag and set the model (i.e. the visible string) in my code?

  



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



Re: tabbed pages not panels

2008-06-01 Thread Erik van Oosten
Tabbed pages are easy to create yourself (a lot easier then tabbed 
panels). Just create a list (ol) with elements (li) with in each a link 
(a). Now attach a Link component to the latter (any link type, but you 
probably are looking for a BookmarkableLink).
Put this all in a Panel you can reuse over different pages. In the 
constructor you accept an argument that will make the panel add a class 
attribute (class=selected) to one of the links.

Add some css and you're done.

Regards,
   Erik.


nazeem wrote:

Does wicket have inbuilt support for tabbed pages ? not tabbed panels. Please
point me to if available
  



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



Re: tabbed pages not panels

2008-06-01 Thread Maurice Marrink
Just add your custom tabbar and a panel to your page. and let the
tabbar know which panel it should update.
Note that in the case of panels you should use Link in your tabbar component.

Maurice


On Sun, Jun 1, 2008 at 12:01 PM, cresc [EMAIL PROTECTED] wrote:

 Thanks Erik.. I understand ur suggestion. But I do have an other problem
 where I need to split the navigation panel  the panel content. Any idea how
 to achieve this?

 http://www.nabble.com/split-tabpanel-navigation-and-panel-content-tt17583663.html

 -  nazeem


 Erik van Oosten wrote:

 Tabbed pages are easy to create yourself (a lot easier then tabbed
 panels). Just create a list (ol) with elements (li) with in each a link
 (a). Now attach a Link component to the latter (any link type, but you
 probably are looking for a BookmarkableLink).
 Put this all in a Panel you can reuse over different pages. In the
 constructor you accept an argument that will make the panel add a class
 attribute (class=selected) to one of the links.
 Add some css and you're done.

 Regards,
 Erik.


 nazeem wrote:
 Does wicket have inbuilt support for tabbed pages ? not tabbed panels.
 Please
 point me to if available



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




 --
 View this message in context: 
 http://www.nabble.com/tabbed-pages-not-panels-tp17582637p17584051.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 in Action PDF - font size

2008-06-01 Thread Martijn Dashorst
All Manning e-books use the same font and layout between the PDF and
printed versions. I don't know if our sample chapter will be updated
(I certainly hope so!) but the final PDF will look like all the other
Manning PDF ebooks, for example:

http://www.manning.com/gallo/sample-ch2.pdf

Martijn

On Sun, Jun 1, 2008 at 9:18 AM, Eyal Golan [EMAIL PROTECTED] wrote:
 Hi,

 I plan to buy this book but not sure if to buy only the ebook or also the
 paper version as well.
 I prefer just the e-book so I won't waist another tree :)

 I downloaded the free first chapter of WIA.
 It seems to me that the font is a bit small.
 even when I fit width it is still too small.
 I needed to zoom in more.
 I could see that there's a big area in the left of the page that is not
 used.

 Is the final version of the e-book going to have bigger font?

 It may seem a stupid question here in the users group, but it's important
 for me.

 thanks
 --
 Eyal Golan
 [EMAIL PROTECTED]

 Visit: http://jvdrums.sourceforge.net/
 LinkedIn: http://www.linkedin.com/in/egolan74




-- 
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: Wicket in Action PDF - font size

2008-06-01 Thread Eyal Golan
cool thanks

On Sun, Jun 1, 2008 at 12:51 PM, Martijn Dashorst 
[EMAIL PROTECTED] wrote:

 All Manning e-books use the same font and layout between the PDF and
 printed versions. I don't know if our sample chapter will be updated
 (I certainly hope so!) but the final PDF will look like all the other
 Manning PDF ebooks, for example:

 http://www.manning.com/gallo/sample-ch2.pdf

 Martijn

 On Sun, Jun 1, 2008 at 9:18 AM, Eyal Golan [EMAIL PROTECTED] wrote:
  Hi,
 
  I plan to buy this book but not sure if to buy only the ebook or also the
  paper version as well.
  I prefer just the e-book so I won't waist another tree :)
 
  I downloaded the free first chapter of WIA.
  It seems to me that the font is a bit small.
  even when I fit width it is still too small.
  I needed to zoom in more.
  I could see that there's a big area in the left of the page that is not
  used.
 
  Is the final version of the e-book going to have bigger font?
 
  It may seem a stupid question here in the users group, but it's
 important
  for me.
 
  thanks
  --
  Eyal Golan
  [EMAIL PROTECTED]
 
  Visit: http://jvdrums.sourceforge.net/
  LinkedIn: http://www.linkedin.com/in/egolan74
 



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




-- 
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74


Re: tabbed pages not panels

2008-06-01 Thread cresc

Thanks Erik.. I understand ur suggestion. But I do have an other problem
where I need to split the navigation panel  the panel content. Any idea how
to achieve this?

http://www.nabble.com/split-tabpanel-navigation-and-panel-content-tt17583663.html

-  nazeem


Erik van Oosten wrote:
 
 Tabbed pages are easy to create yourself (a lot easier then tabbed 
 panels). Just create a list (ol) with elements (li) with in each a link 
 (a). Now attach a Link component to the latter (any link type, but you 
 probably are looking for a BookmarkableLink).
 Put this all in a Panel you can reuse over different pages. In the 
 constructor you accept an argument that will make the panel add a class 
 attribute (class=selected) to one of the links.
 Add some css and you're done.
 
 Regards,
 Erik.
 
 
 nazeem wrote:
 Does wicket have inbuilt support for tabbed pages ? not tabbed panels.
 Please
 point me to if available
   
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/tabbed-pages-not-panels-tp17582637p17584051.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]



split tabpanel navigation and panel content

2008-06-01 Thread cresc

When using wickets tabbed panel can I split the navigation and the panel
contents to diff blocks. The use cases I require is use a vertical tab
(sidebar) as tab and display the contents in RHS side.

Please suggest any workaround to achieve this.

Thank u.
-- 
View this message in context: 
http://www.nabble.com/split-tabpanel-navigation-and-panel-content-tp17583663p17583663.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: split tabpanel navigation and panel content

2008-06-01 Thread Maurice Marrink
Well if you are talking about having other html elements between the
tab bar and the content itself, then no you would have to write your
own components. but using some css or overriding the default markup
for the tabbedpanel you might be able to achieve the same visual
effect.

Maurice

On Sun, Jun 1, 2008 at 11:22 AM, cresc [EMAIL PROTECTED] wrote:

 When using wickets tabbed panel can I split the navigation and the panel
 contents to diff blocks. The use cases I require is use a vertical tab
 (sidebar) as tab and display the contents in RHS side.

 Please suggest any workaround to achieve this.

 Thank u.
 --
 View this message in context: 
 http://www.nabble.com/split-tabpanel-navigation-and-panel-content-tp17583663p17583663.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]



Weird exceptions. Has anyone seen any exceptions like these

2008-06-01 Thread atul singh
Hi,
As a result of code integration from various teams we have introduced
some change which is causing problems...
but the sad part is that we do not know what is happening--
I will loove to know if someone else has seen similar exceptions and
how they solved if they were able to::
Also what do these exceptions mean--i mean situation they might happen in??

1.
java.lang.IllegalStateException: No Page found for component
[MarkupContainer [Component id = panel, page = No Page, path =
 at org.apache.wicket.Component.getPage(Component.java:1658)
 at 
org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689)
 at 
org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605)
 at 
org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520)
 at 
org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104)
 at 
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172)

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



fieldlabel Component

2008-06-01 Thread Jürgen Lind

Hi,

I am looking for the solution for a quite common problem: I want the label
of a form element to change its color if the input is invalid. Searching the
web I found some very old postings of Igor and Jonathan discussing this matter;
however, I have not found any links to the final solution. Can someone help
me and point me to a solution for this problem?

Regards,

J.

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


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



Re: fieldlabel Component

2008-06-01 Thread Jürgen Lind

Thx,

J.

Martijn Dashorst wrote:

label.add(new AttributeModifier(class, true, new Model() { public
Object getObject() { return formcomponent.isValid() ?  : error;
}});


On Sun, Jun 1, 2008 at 8:05 PM, Jürgen Lind [EMAIL PROTECTED] wrote:

Hi,

I am looking for the solution for a quite common problem: I want the label
of a form element to change its color if the input is invalid. Searching the
web I found some very old postings of Igor and Jonathan discussing this
matter;
however, I have not found any links to the final solution. Can someone help
me and point me to a solution for this problem?

Regards,

J.

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


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








--
Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


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



Re: Weird exceptions. Has anyone seen any exceptions like these

2008-06-01 Thread Maurice Marrink
Are you by any chance replacing components? This could happen if you
let the ajax render a component that has been removed from the page.

Maurice

On Sun, Jun 1, 2008 at 7:32 PM, atul singh [EMAIL PROTECTED] wrote:
 Hi,
 As a result of code integration from various teams we have introduced
 some change which is causing problems...
 but the sad part is that we do not know what is happening--
 I will loove to know if someone else has seen similar exceptions and
 how they solved if they were able to::
 Also what do these exceptions mean--i mean situation they might happen in??

 1.
 java.lang.IllegalStateException: No Page found for component
 [MarkupContainer [Component id = panel, page = No Page, path =
  at org.apache.wicket.Component.getPage(Component.java:1658)
 at 
 org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689)
 at 
 org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605)
 at 
 org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520)
 at 
 org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104)
 at 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172)

 -
 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: fieldlabel Component

2008-06-01 Thread Martijn Dashorst
label.add(new AttributeModifier(class, true, new Model() { public
Object getObject() { return formcomponent.isValid() ?  : error;
}});


On Sun, Jun 1, 2008 at 8:05 PM, Jürgen Lind [EMAIL PROTECTED] wrote:
 Hi,

 I am looking for the solution for a quite common problem: I want the label
 of a form element to change its color if the input is invalid. Searching the
 web I found some very old postings of Igor and Jonathan discussing this
 matter;
 however, I have not found any links to the final solution. Can someone help
 me and point me to a solution for this problem?

 Regards,

 J.

 --
 Dr. Jürgen Lind
 iteratec GmbHFon: +49 (0)89 614551-44
 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
 82008 Unterhaching   Web: www.iteratec.de

 Sitz und Registergericht der iteratec GmbH: München HRB 113 519
 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel


 -
 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: Changing Link string conditionally?

2008-06-01 Thread Michael Mehrle
Okay, so I need to treat the link text as a separate entity - makes
sense. Thanks a lot - can't believe I didn't think of that...

Michael

-Original Message-
From: Erik van Oosten [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 01, 2008 2:00 AM
To: users@wicket.apache.org
Subject: Re: Changing Link string conditionally?

The idea is to put a span inside the a, and then attach a Label to the
span.

Is that something you can work with?

Regards,
Erik.


Michael Mehrle wrote:
 Okay, this seems so easy, but I'm somehow stuck. How do I change the
 string of a Link based on some condition? Do I simply provide a
 terminated tag and set the model (i.e. the visible string) in my code?

   


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



AjaxFallbackLink to Show/Hide a checkGroup problem...

2008-06-01 Thread smallufo
Hi
I want to use an AjaxFallbackLink  to show/hide a checkGroup , but I can
only hide it , cannot re-show it...
I did checkGroup.setRenderBodyOnly(false);
and listView.setReuseItems(true);
But still can still only hide the checkGroup , cannot make it re-appear...

Can somebody help me checking the code , thanks a lot.


ListPlanet list = Arrays.asList(Planet.values);
final CheckGroup checkGroup = new CheckGroup(checkGroup , list);
checkGroup.setRenderBodyOnly(false);
checkGroup.setOutputMarkupId(true);
add(checkGroup);

ListView listView = new ListView(list, list )
{
  @Override
  protected void populateItem(ListItem item)
  {
Planet planet = (Planet) item.getModelObject();
item.add(new PointShownCheckBox(check , displayables , planet));
item.add(new Label(name , planet.getName()));
  }
};
listView.setReuseItems(true);
checkGroup.add(listView);


collapseExpandStarsLink = new
AjaxFallbackLink(collapseExpandStarsLink)
{
  @Override
  public void onClick(AjaxRequestTarget target)
  {
if(checkGroup.isVisible())
  target.addComponent(checkGroup.setVisible(false));
else
  target.addComponent(checkGroup.setVisible(true));
  }
};
add(collapseExpandStarsLink);


RE: AjaxFallbackLink to Show/Hide a checkGroup problem...

2008-06-01 Thread Jeremy Thomerson
There's another boolean on component that you should set to true.  It will 
output a container where the component should be, even if the component is 
invisible.  Unfortunately, I'm not at my computer, and I can't remember the 
name.  Look for set*(boolean), and it may have the word container in it.  It's 
baffling me that I can't remember it.

Hope this helps...

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


-Original Message-
From: smallufo [EMAIL PROTECTED]
Sent: Sunday, June 01, 2008 3:04 PM
To: users@wicket.apache.org
Subject: AjaxFallbackLink to Show/Hide a checkGroup problem...

Hi
I want to use an AjaxFallbackLink  to show/hide a checkGroup , but I can
only hide it , cannot re-show it...
I did checkGroup.setRenderBodyOnly(false);
and listView.setReuseItems(true);
But still can still only hide the checkGroup , cannot make it re-appear...

Can somebody help me checking the code , thanks a lot.


ListPlanet list = Arrays.asList(Planet.values);
final CheckGroup checkGroup = new CheckGroup(checkGroup , list);
checkGroup.setRenderBodyOnly(false);
checkGroup.setOutputMarkupId(true);
add(checkGroup);

ListView listView = new ListView(list, list )
{
  @Override
  protected void populateItem(ListItem item)
  {
Planet planet = (Planet) item.getModelObject();
item.add(new PointShownCheckBox(check , displayables , planet));
item.add(new Label(name , planet.getName()));
  }
};
listView.setReuseItems(true);
checkGroup.add(listView);


collapseExpandStarsLink = new
AjaxFallbackLink(collapseExpandStarsLink)
{
  @Override
  public void onClick(AjaxRequestTarget target)
  {
if(checkGroup.isVisible())
  target.addComponent(checkGroup.setVisible(false));
else
  target.addComponent(checkGroup.setVisible(true));
  }
};
add(collapseExpandStarsLink);


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



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

2008-06-01 Thread Eelco Hillenius
Hi all,

We have had several threads in this and the dev list, and some
discussions in the public on how to incorporate generics in Wicket.

I'd like to use this thread to gather the opinions of as many regular
Wicket users as we can. Please help us get an impression of what our
users think about the issue by completing this simple survey. Note
that it is not a vote; we only want to get an idea of what you think.

1) Generifying* Wicket
   [ ] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.
   [ ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
   [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
in your opinion here).
   [ ]  (anything other than these choices?)

2) How strongly do you feel about your choice above?
   [ ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
   [ ] I might rethink upgrading if my choice doesn't win.
   [ ] I definitively won't be using 1.4. if Wicket doesn't go for my
preference.

Thanks in advance for everyone participating, and pls feel free to
explain yourself further beyond just answering these questions!

Eelco

p.s. I suggest that the core devs and most active participants and
previous discussions wait a few days before giving their opinions so
that we don't flood the thread right from the start.

* Parameterizing would probably be the better word to use, but
generifying seems to be the word that many people use.

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



What is Wicket? from WIA

2008-06-01 Thread Eyal Golan
Hi,
I read chapter 1 in Wicket in Action and I have a question.
in section 1.2.1 it says:
You can get rid of all of these problems  by using Wicket.  It  is  a
stateful framework,  so you
don't have  to follow  the REST  (though you can,  but we will  talk about
that  later  in this  book)
approach. The main idea behind REST is scalability. Fine. But let me make a
bold statement here:
Very often, REST is premature optimization.

Wicket is my first Web Framework and I was wondering if someone can explain
why Wicket solves the REST problem (which I understood the problem itself).
Is it because in Wicket we don;t need to pass parameters in the request? And
instead we create pages with the necessary information? (or something like
that)

Thank

-- 
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74


Re: AjaxFallbackLink to Show/Hide a checkGroup problem...

2008-06-01 Thread Igor Vaynberg
setoutputmarkupplaceholdertag(true)

-igor

On Sun, Jun 1, 2008 at 1:39 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
 There's another boolean on component that you should set to true.  It will 
 output a container where the component should be, even if the component is 
 invisible.  Unfortunately, I'm not at my computer, and I can't remember the 
 name.  Look for set*(boolean), and it may have the word container in it.  
 It's baffling me that I can't remember it.

 Hope this helps...

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


 -Original Message-
 From: smallufo [EMAIL PROTECTED]
 Sent: Sunday, June 01, 2008 3:04 PM
 To: users@wicket.apache.org
 Subject: AjaxFallbackLink to Show/Hide a checkGroup problem...

 Hi
 I want to use an AjaxFallbackLink  to show/hide a checkGroup , but I can
 only hide it , cannot re-show it...
 I did checkGroup.setRenderBodyOnly(false);
 and listView.setReuseItems(true);
 But still can still only hide the checkGroup , cannot make it re-appear...

 Can somebody help me checking the code , thanks a lot.


ListPlanet list = Arrays.asList(Planet.values);
final CheckGroup checkGroup = new CheckGroup(checkGroup , list);
checkGroup.setRenderBodyOnly(false);
checkGroup.setOutputMarkupId(true);
add(checkGroup);

ListView listView = new ListView(list, list )
{
  @Override
  protected void populateItem(ListItem item)
  {
Planet planet = (Planet) item.getModelObject();
item.add(new PointShownCheckBox(check , displayables , planet));
item.add(new Label(name , planet.getName()));
  }
};
listView.setReuseItems(true);
checkGroup.add(listView);


collapseExpandStarsLink = new
 AjaxFallbackLink(collapseExpandStarsLink)
{
  @Override
  public void onClick(AjaxRequestTarget target)
  {
if(checkGroup.isVisible())
  target.addComponent(checkGroup.setVisible(false));
else
  target.addComponent(checkGroup.setVisible(true));
  }
};
add(collapseExpandStarsLink);


 -
 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: AjaxFallbackLink to Show/Hide a checkGroup problem...

2008-06-01 Thread Jeremy Thomerson
Found the method:

 public final ComponentT setOutputMarkupPlaceholderTag(final boolean 
outputTag)

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


-Original Message-
From: smallufo [EMAIL PROTECTED]
Sent: Sunday, June 01, 2008 3:04 PM
To: users@wicket.apache.org
Subject: AjaxFallbackLink to Show/Hide a checkGroup problem...

Hi
I want to use an AjaxFallbackLink  to show/hide a checkGroup , but I can
only hide it , cannot re-show it...
I did checkGroup.setRenderBodyOnly(false);
and listView.setReuseItems(true);
But still can still only hide the checkGroup , cannot make it re-appear...

Can somebody help me checking the code , thanks a lot.


ListPlanet list = Arrays.asList(Planet.values);
final CheckGroup checkGroup = new CheckGroup(checkGroup , list);
checkGroup.setRenderBodyOnly(false);
checkGroup.setOutputMarkupId(true);
add(checkGroup);

ListView listView = new ListView(list, list )
{
  @Override
  protected void populateItem(ListItem item)
  {
Planet planet = (Planet) item.getModelObject();
item.add(new PointShownCheckBox(check , displayables , planet));
item.add(new Label(name , planet.getName()));
  }
};
listView.setReuseItems(true);
checkGroup.add(listView);


collapseExpandStarsLink = new
AjaxFallbackLink(collapseExpandStarsLink)
{
  @Override
  public void onClick(AjaxRequestTarget target)
  {
if(checkGroup.isVisible())
  target.addComponent(checkGroup.setVisible(false));
else
  target.addComponent(checkGroup.setVisible(true));
  }
};
add(collapseExpandStarsLink);


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



Re: What is Wicket? from WIA

2008-06-01 Thread Eelco Hillenius
Wicket supports private state for individual components, whereas the
traditional (REST) pattern assumes to take the state out (to string
based request parameters) and up to the request level. The big
difference is that without using a framework like Wicket, you can't
really create self contained components. You have to ensure that state
gets passed in any URL that is generated on a page, ensure the
parameters are properly scoped, have to worry about how to serialize
and de-serialize (from regular objects to strings and vice versa),
etc.

You can test this by creating a Struts app where you create a pageable
list. You'd append parameters for e.g. the page number and query to
every URL that passes back to the page, even if the link you are
constructing has nothing to do with the pageable list. Just the fact
that it is on the page means you have to pass the parameter. That by
itself is doable - though destroys encapsulation -; the problems
really start when you decide to move/ reuse the 'component' to/ in
another page, and when e.g. you add more things to the pass that need
to pass state like for instance tabs.

Eelco

On Sun, Jun 1, 2008 at 1:53 PM, Eyal Golan [EMAIL PROTECTED] wrote:
 Hi,
 I read chapter 1 in Wicket in Action and I have a question.
 in section 1.2.1 it says:
 You can get rid of all of these problems  by using Wicket.  It  is  a
 stateful framework,  so you
 don't have  to follow  the REST  (though you can,  but we will  talk about
 that  later  in this  book)
 approach. The main idea behind REST is scalability. Fine. But let me make a
 bold statement here:
 Very often, REST is premature optimization.

 Wicket is my first Web Framework and I was wondering if someone can explain
 why Wicket solves the REST problem (which I understood the problem itself).
 Is it because in Wicket we don;t need to pass parameters in the request? And
 instead we create pages with the necessary information? (or something like
 that)

 Thank

 --
 Eyal Golan
 [EMAIL PROTECTED]

 Visit: http://jvdrums.sourceforge.net/
 LinkedIn: http://www.linkedin.com/in/egolan74


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



Re: Weird exceptions. Has anyone seen any exceptions like these

2008-06-01 Thread atul singh
Thanks,
But i am sure, that is not happening ..I looked at all that code..
Any other suggestions/guesses??

On Mon, Jun 2, 2008 at 12:09 AM, Maurice Marrink [EMAIL PROTECTED] wrote:
 Are you by any chance replacing components? This could happen if you
 let the ajax render a component that has been removed from the page.

 Maurice

 On Sun, Jun 1, 2008 at 7:32 PM, atul singh [EMAIL PROTECTED] wrote:
 Hi,
 As a result of code integration from various teams we have introduced
 some change which is causing problems...
 but the sad part is that we do not know what is happening--
 I will loove to know if someone else has seen similar exceptions and
 how they solved if they were able to::
 Also what do these exceptions mean--i mean situation they might happen in??

 1.
 java.lang.IllegalStateException: No Page found for component
 [MarkupContainer [Component id = panel, page = No Page, path =
  at org.apache.wicket.Component.getPage(Component.java:1658)
 at 
 org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689)
 at 
 org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605)
 at 
 org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520)
 at 
 org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104)
 at 
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172)

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



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



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



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

2008-06-01 Thread atul singh
1)
 [ X] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
*Reason::* I think generifying data-structure/models is what is sustainable.
Components can become too complicated when gentrified..and who know how far
wicket wants to go!!

2)
[X] I definitively won't be using 1.4. if Wicket doesn't go for my
preference.



On Mon, Jun 2, 2008 at 2:14 AM, Eelco Hillenius [EMAIL PROTECTED]
wrote:
 Hi all,

 We have had several threads in this and the dev list, and some
 discussions in the public on how to incorporate generics in Wicket.

 I'd like to use this thread to gather the opinions of as many regular
 Wicket users as we can. Please help us get an impression of what our
 users think about the issue by completing this simple survey. Note
 that it is not a vote; we only want to get an idea of what you think.

 1) Generifying* Wicket
   [ ] Can best be done like currently in the 1.4 branch, where models
 and components are both generified. I care most about the improved
 static type checking generified models and components give Wicket.
   [ ] Can best be done in a limited fashion, where we only generify
 IModel but not components. I care more about what generifying can do
 for API clarity (declaring a component to only accept certain models
 for instance) than static type checking.
   [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
 in your opinion here).
   [ ]  (anything other than these choices?)

 2) How strongly do you feel about your choice above?
   [ ] Whatever choice ultimately made, I'll happily convert/ start
 using 1.4 and up.
   [ ] I might rethink upgrading if my choice doesn't win.
   [ ] I definitively won't be using 1.4. if Wicket doesn't go for my
 preference.

 Thanks in advance for everyone participating, and pls feel free to
 explain yourself further beyond just answering these questions!

 Eelco

 p.s. I suggest that the core devs and most active participants and
 previous discussions wait a few days before giving their opinions so
 that we don't flood the thread right from the start.

 * Parameterizing would probably be the better word to use, but
 generifying seems to be the word that many people use.

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




Re: What is Wicket? from WIA

2008-06-01 Thread Eyal Golan
wow.
thanks.
That was very helpful :)

Eyal

On Mon, Jun 2, 2008 at 12:08 AM, Eelco Hillenius [EMAIL PROTECTED]
wrote:

 Wicket supports private state for individual components, whereas the
 traditional (REST) pattern assumes to take the state out (to string
 based request parameters) and up to the request level. The big
 difference is that without using a framework like Wicket, you can't
 really create self contained components. You have to ensure that state
 gets passed in any URL that is generated on a page, ensure the
 parameters are properly scoped, have to worry about how to serialize
 and de-serialize (from regular objects to strings and vice versa),
 etc.

 You can test this by creating a Struts app where you create a pageable
 list. You'd append parameters for e.g. the page number and query to
 every URL that passes back to the page, even if the link you are
 constructing has nothing to do with the pageable list. Just the fact
 that it is on the page means you have to pass the parameter. That by
 itself is doable - though destroys encapsulation -; the problems
 really start when you decide to move/ reuse the 'component' to/ in
 another page, and when e.g. you add more things to the pass that need
 to pass state like for instance tabs.

 Eelco

 On Sun, Jun 1, 2008 at 1:53 PM, Eyal Golan [EMAIL PROTECTED] wrote:
  Hi,
  I read chapter 1 in Wicket in Action and I have a question.
  in section 1.2.1 it says:
  You can get rid of all of these problems  by using Wicket.  It  is  a
  stateful framework,  so you
  don't have  to follow  the REST  (though you can,  but we will  talk
 about
  that  later  in this  book)
  approach. The main idea behind REST is scalability. Fine. But let me make
 a
  bold statement here:
  Very often, REST is premature optimization.
 
  Wicket is my first Web Framework and I was wondering if someone can
 explain
  why Wicket solves the REST problem (which I understood the problem
 itself).
  Is it because in Wicket we don;t need to pass parameters in the request?
 And
  instead we create pages with the necessary information? (or something
 like
  that)
 
  Thank
 
  --
  Eyal Golan
  [EMAIL PROTECTED]
 
  Visit: http://jvdrums.sourceforge.net/
  LinkedIn: http://www.linkedin.com/in/egolan74
 

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




-- 
Eyal Golan
[EMAIL PROTECTED]

Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74


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

2008-06-01 Thread Ayodeji Aladejebi
scan this user forum, you will realize that there is no high demand for
generics in wicket from users. I am yet to see one user or thread here of
wicket users screeming out for generics addition. I think users has been
doing just fine without it at least speaking for myself.

Anything more than IModel, I wont upgrade to 1.4 as well

+1 for IModels only

as for as I am concerned, annotations are better 1.5 additions than
generics. generics is just awful


On 6/1/08, atul singh [EMAIL PROTECTED] wrote:

 1)
   [ X] Can best be done in a limited fashion, where we only generify

 IModel but not components. I care more about what generifying can do
 for API clarity (declaring a component to only accept certain models
 for instance) than static type checking.

 *Reason::* I think generifying data-structure/models is what is
 sustainable.
 Components can become too complicated when gentrified..and who know how far
 wicket wants to go!!

 2)
 [X] I definitively won't be using 1.4. if Wicket doesn't go for my
 preference.



 On Mon, Jun 2, 2008 at 2:14 AM, Eelco Hillenius [EMAIL PROTECTED]
 
 wrote:

  Hi all,
 
  We have had several threads in this and the dev list, and some
  discussions in the public on how to incorporate generics in Wicket.
 
  I'd like to use this thread to gather the opinions of as many regular
  Wicket users as we can. Please help us get an impression of what our
  users think about the issue by completing this simple survey. Note
  that it is not a vote; we only want to get an idea of what you think.
 
  1) Generifying* Wicket
[ ] Can best be done like currently in the 1.4 branch, where models
  and components are both generified. I care most about the improved
  static type checking generified models and components give Wicket.
[ ] Can best be done in a limited fashion, where we only generify
  IModel but not components. I care more about what generifying can do
  for API clarity (declaring a component to only accept certain models
  for instance) than static type checking.
[ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
  in your opinion here).
[ ]  (anything other than these choices?)
 
  2) How strongly do you feel about your choice above?
[ ] Whatever choice ultimately made, I'll happily convert/ start
  using 1.4 and up.
[ ] I might rethink upgrading if my choice doesn't win.
[ ] I definitively won't be using 1.4. if Wicket doesn't go for my
  preference.
 
  Thanks in advance for everyone participating, and pls feel free to
  explain yourself further beyond just answering these questions!
 
  Eelco
 
  p.s. I suggest that the core devs and most active participants and
  previous discussions wait a few days before giving their opinions so
  that we don't flood the thread right from the start.
 
  * Parameterizing would probably be the better word to use, but
  generifying seems to be the word that many people use.
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



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

2008-06-01 Thread Ayodeji Aladejebi
  [X ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
[ X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.

On 6/1/08, Eelco Hillenius [EMAIL PROTECTED] wrote:

 Hi all,

 We have had several threads in this and the dev list, and some
 discussions in the public on how to incorporate generics in Wicket.

 I'd like to use this thread to gather the opinions of as many regular
 Wicket users as we can. Please help us get an impression of what our
 users think about the issue by completing this simple survey. Note
 that it is not a vote; we only want to get an idea of what you think.

 1) Generifying* Wicket
[ ] Can best be done like currently in the 1.4 branch, where models
 and components are both generified. I care most about the improved
 static type checking generified models and components give Wicket.
[ ] Can best be done in a limited fashion, where we only generify
 IModel but not components. I care more about what generifying can do
 for API clarity (declaring a component to only accept certain models
 for instance) than static type checking.
[ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
 in your opinion here).
[ ]  (anything other than these choices?)

 2) How strongly do you feel about your choice above?
[ ] Whatever choice ultimately made, I'll happily convert/ start
 using 1.4 and up.
[ ] I might rethink upgrading if my choice doesn't win.
[ ] I definitively won't be using 1.4. if Wicket doesn't go for my
 preference.

 Thanks in advance for everyone participating, and pls feel free to
 explain yourself further beyond just answering these questions!

 Eelco

 p.s. I suggest that the core devs and most active participants and
 previous discussions wait a few days before giving their opinions so
 that we don't flood the thread right from the start.

 * Parameterizing would probably be the better word to use, but
 generifying seems to be the word that many people use.

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




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

2008-06-01 Thread Michael Mehrle
Okay, this is what I'm getting:

[DEBUG EviteApplication] I OVERRODE THIS CONVERTER: null

Strange - isn't it? The only thing I changed was to remove Timestamp
from your IConverter definition. I'm using Wicket 1.3.4.

Thoughts?

Michael

-Original Message-
From: Jeremy Thomerson [mailto:[EMAIL PROTECTED] 
Sent: Saturday, May 31, 2008 11:18 PM
To: users@wicket.apache.org
Subject: Re: Timestamp - java.util.Date convertion in Wicket

Weird indeed.  Do this... capture the return of your ((ConverterLocator)
getConverterLocator()).set(...) call.  In that method, it is returning
the
result of a Map.put(Timestamp.class, your-converter).  Therefore, the
result
should be non-null, as you should be overriding the default
implementation
that was already put in the map.

Something like:

IConverter ic = ((ConverterLocator)
getConverterLocator()).set(Timestamp.class, new IConverterTimestamp()
{

private static final long serialVersionUID = 1L;

public Timestamp convertToObject(String value, Locale
locale) {
if (value == null) {
return null;
}
if (locale == null) {
locale = Locale.getDefault();
}
DateFormat format =
DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
try {
Date date = format.parse(value);
return new Timestamp(date.getTime());
} catch (ParseException e) {
throw new ConversionException(Cannot parse '
+ value + ' using format  + format)
.setSourceValue(value).setTargetType(
 
Timestamp.class).setConverter(this)
.setLocale(locale);
}
}

public String convertToString(final Timestamp value,
Locale
locale) {
if (value == null) {
return null;
}
if (locale == null) {
locale = Locale.getDefault();
}
DateFormat format =
DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT);
return format.format(value);
}

});
System.out.println(I OVERRODE THIS CONVERTER: + ic);

Also - what version are you running?


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

On Sun, Jun 1, 2008 at 1:05 AM, Michael Mehrle [EMAIL PROTECTED]
wrote:

 Yes, exactly the way you're doing it - didn't change anything except
for
 removing the generic def in the IConverter interface (not using
generics
 yet in my current project).

 And yes, I also set my breakpoint but it's never being called. The
field
 simply grabs the time value and no conversion seems to be happening.

 BTW, very elegant fix - just hope I can make this work (driving me
crazy
 this issue).

 Michael

 -Original Message-
 From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
 Sent: Saturday, May 31, 2008 7:14 PM
 To: users@wicket.apache.org
 Subject: RE: Timestamp - java.util.Date convertion in Wicket

 Did you make sure to use the code exactly (it calls SET on the
concrete
 implementation rather than the standard way of just adding a converter
 to the interface)?

 Which version are you using?  This problem appeared in 1.3, and I have
 tested my fix in all versions of of 1.3 and 1.4-m1 and m2.

 You can set a breakpoint in your implementation and in the default
with
 Wicket to see which is getting called.  Let me know what you find.

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


 -Original Message-
 From: Michael Mehrle [EMAIL PROTECTED]
 Sent: Saturday, May 31, 2008 8:57 PM
 To: users@wicket.apache.org
 Subject: RE: Timestamp - java.util.Date convertion in Wicket

 Hello Jeremy:

 I added the converter to my apps init() method per your example but
the
 problem persists. I keep seeing 12:00am instead of the date. Any
 suggestions?

 Michael

 -Original Message-
 From: Jeremy Thomerson [mailto:[EMAIL PROTECTED]
 Sent: Friday, May 30, 2008 7:35 PM
 To: users@wicket.apache.org
 Subject: RE: Timestamp - java.util.Date convertion in Wicket

 Found a link:

 http://markmail.org/message/m5cyca4vsrrvcrid

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


 -Original Message-
 From: Michael Mehrle [EMAIL PROTECTED]
 Sent: Friday, May 30, 2008 8:55 PM
 To: users@wicket.apache.org
 Subject: Timestamp - java.util.Date convertion in Wicket

 I am persisting java.util.Date objects to the DB but am getting
 Timestamp objects back (no surprise there since the hibernate type is
 set to 'timestamp'). Wicket converts the Timestamp and populates my
 field without complaining but all I'm getting is the time (12:00am -
the
 default start time since it 

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

2008-06-01 Thread Eelco Hillenius
On Sun, Jun 1, 2008 at 2:46 PM, Ayodeji Aladejebi [EMAIL PROTECTED] wrote:
 scan this user forum, you will realize that there is no high demand for
 generics in wicket from users. I am yet to see one user or thread here of
 wicket users screeming out for generics addition. I think users has been
 doing just fine without it at least speaking for myself.

Well, there are at least a couple of long-time users that have been
waiting around for more than a year for us to implement (or
re-implement since it was in 2.0) this. But let's see what opinions
this threads show us.

 Anything more than IModel, I wont upgrade to 1.4 as well

 +1 for IModels only

Thanks for giving your opinion.

Eelco

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



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

2008-06-01 Thread Eyal Golan
 [X] *Can best be done in a limited fashion*, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
*Reason* - Well, I haven't started working hard on 4.1
Were we work we still with the 1.3.3 mostly because they're afraid of the
migration.
When I changed to 1.4 in my personal try-out project, I got really confused
and annoyed with the need to add generics to my page, panel etc.
I think that the Model should be generified. It seems logical to me to force
the user to use specific types in the model.

[X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
*Reason* - I usually prefer to work with the latest version.


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

2008-06-01 Thread Peter Ertl

1) Generifying* Wicket
  [X ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.

2) How strongly do you feel about your choice above?
  [X ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.


Cheers
Peter


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



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

2008-06-01 Thread Nick Heudecker
 1) Generifying* Wicket
   [X] Can best be done in a limited fashion, where we only generify
 IModel but not components. I care more about what generifying can do
 for API clarity (declaring a component to only accept certain models
 for instance) than static type checking.


 2) How strongly do you feel about your choice above?
   [X] I might rethink upgrading if my choice doesn't win.


I'm content with the way things work now, but adding generics to models
would be helpful.  It's unclear if adding generics to components would be
worth the complexity.


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

2008-06-01 Thread Advanced Technology®
1)   [ X] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.

2)   [ X] I might rethink upgrading if my choice doesn't win.



AT


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

2008-06-01 Thread James Carman
On Sun, Jun 1, 2008 at 4:44 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
 1) Generifying* Wicket
   [ ] Can best be done like currently in the 1.4 branch, where models
 and components are both generified. I care most about the improved
 static type checking generified models and components give Wicket.

+1 - Although I agree this needs to be done in a way that makes sense.
 If the code gets too crazy, folks will be turned off.


 2) How strongly do you feel about your choice above?
   [ ] Whatever choice ultimately made, I'll happily convert/ start
 using 1.4 and up.

+1

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



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

2008-06-01 Thread Ricky
[X ] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.

I think generifying Components give more clarity (Don't blame Wicket for
Messed up Generic Notation, lots of things can and i suppose will be
improved as we move on) to thinking; IMHO generifying components like pages
and panels makes for cleaner code (in that you see clearly that this panel
/ page or whatever is tied to this model etc.)

I don't know ... I am kinda in between 1  2 (adding generics to components
or just in limited fashion). But I'll think most people would want to go for
number 2. (adding generics in limited fashion). I would still upgrade to 1.4

Regards
Vyas, Anirudh


How to access properties files outside of Wicket components?

2008-06-01 Thread Michael Mehrle
I just refactored one of my pages and externalized an inner class into
an outer class that however still needs access to that page's property
stings. Can I just treat that page's properties file as a resource
bundle and retrieve the strings the old fashioned way? Or will there be
problems?

 

Thanks,

 

Michael



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

2008-06-01 Thread Matthew Young
  [X] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.

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

On Sun, Jun 1, 2008 at 1:44 PM, Eelco Hillenius [EMAIL PROTECTED]
wrote:

 Hi all,

 We have had several threads in this and the dev list, and some
 discussions in the public on how to incorporate generics in Wicket.

 I'd like to use this thread to gather the opinions of as many regular
 Wicket users as we can. Please help us get an impression of what our
 users think about the issue by completing this simple survey. Note
 that it is not a vote; we only want to get an idea of what you think.

 1) Generifying* Wicket
   [ ] Can best be done like currently in the 1.4 branch, where models
 and components are both generified. I care most about the improved
 static type checking generified models and components give Wicket.
   [ ] Can best be done in a limited fashion, where we only generify
 IModel but not components. I care more about what generifying can do
 for API clarity (declaring a component to only accept certain models
 for instance) than static type checking.
   [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
 in your opinion here).
   [ ]  (anything other than these choices?)

 2) How strongly do you feel about your choice above?
   [ ] Whatever choice ultimately made, I'll happily convert/ start
 using 1.4 and up.
   [ ] I might rethink upgrading if my choice doesn't win.
   [ ] I definitively won't be using 1.4. if Wicket doesn't go for my
 preference.

 Thanks in advance for everyone participating, and pls feel free to
 explain yourself further beyond just answering these questions!

 Eelco

 p.s. I suggest that the core devs and most active participants and
 previous discussions wait a few days before giving their opinions so
 that we don't flood the thread right from the start.

 * Parameterizing would probably be the better word to use, but
 generifying seems to be the word that many people use.

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




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

2008-06-01 Thread Ricky
wow this has a pattern for sure doesn't it ? ;)

Rick

On Sun, Jun 1, 2008 at 7:25 PM, Matthew Young [EMAIL PROTECTED] wrote:

  [X] Can best be done in a limited fashion, where we only generify
 IModel but not components. I care more about what generifying can do
 for API clarity (declaring a component to only accept certain models
 for instance) than static type checking.

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

 On Sun, Jun 1, 2008 at 1:44 PM, Eelco Hillenius [EMAIL PROTECTED]
 
 wrote:

  Hi all,
 
  We have had several threads in this and the dev list, and some
  discussions in the public on how to incorporate generics in Wicket.
 
  I'd like to use this thread to gather the opinions of as many regular
  Wicket users as we can. Please help us get an impression of what our
  users think about the issue by completing this simple survey. Note
  that it is not a vote; we only want to get an idea of what you think.
 
  1) Generifying* Wicket
[ ] Can best be done like currently in the 1.4 branch, where models
  and components are both generified. I care most about the improved
  static type checking generified models and components give Wicket.
[ ] Can best be done in a limited fashion, where we only generify
  IModel but not components. I care more about what generifying can do
  for API clarity (declaring a component to only accept certain models
  for instance) than static type checking.
[ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
  in your opinion here).
[ ]  (anything other than these choices?)
 
  2) How strongly do you feel about your choice above?
[ ] Whatever choice ultimately made, I'll happily convert/ start
  using 1.4 and up.
[ ] I might rethink upgrading if my choice doesn't win.
[ ] I definitively won't be using 1.4. if Wicket doesn't go for my
  preference.
 
  Thanks in advance for everyone participating, and pls feel free to
  explain yourself further beyond just answering these questions!
 
  Eelco
 
  p.s. I suggest that the core devs and most active participants and
  previous discussions wait a few days before giving their opinions so
  that we don't flood the thread right from the start.
 
  * Parameterizing would probably be the better word to use, but
  generifying seems to be the word that many people use.
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



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

2008-06-01 Thread Vit Rozkovec



1) Generifying* Wicket
   [X] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.

2) How strongly do you feel about your choice above?
   [X] I might rethink upgrading if my choice doesn't win.
  

*Reason* for new people who want to start with wicket the way generics are now 
may not be very clear and harder to grasp at the beginning. Most of the people 
here is long time in the business, so it may seem natural to you, but try to 
imagine those just entering.


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



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

2008-06-01 Thread Michael Mehrle
Right now I had to resort to the solution below, but I would very much
like to know the standard way of doing this, as this required me to
place my properties file into the src/main/resources folder:

static {
try {

properties.load(Thread.currentThread().getContextClassLoader().getResour
ceAsStream(
MyComponent.properties));
} catch (Exception e) {
LOG.error(Unable to load file
MyComponent.properties' - error: {}, e.getMessage(), e);
}
}

public static String getProperty(String key) {
return properties.getProperty(key);
}



-Original Message-
From: Michael Mehrle [mailto:[EMAIL PROTECTED] 
Sent: Sunday, June 01, 2008 3:50 PM
To: users@wicket.apache.org
Subject: How to access properties files outside of Wicket components?

I just refactored one of my pages and externalized an inner class into
an outer class that however still needs access to that page's property
stings. Can I just treat that page's properties file as a resource
bundle and retrieve the strings the old fashioned way? Or will there be
problems?

 

Thanks,

 

Michael


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



Re: Wicket in Action PDF - font size

2008-06-01 Thread dtoffe

You can also try changing fit width to fit visible, in the example
pdf provided before the zoom went from 137% to 171%

Daniel



Eyal Golan wrote:
 
 
  I downloaded the free first chapter of WIA.
  It seems to me that the font is a bit small.
  even when I fit width it is still too small.
  I needed to zoom in more.
  I could see that there's a big area in the left of the page that is not
  used.
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Wicket-in-Action-PDF---font-size-tp17583011p17592425.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: Weird exceptions. Has anyone seen any exceptions like these

2008-06-01 Thread Timo Rantalaiho
On Sun, 01 Jun 2008, atul singh wrote:
 I will loove to know if someone else has seen similar exceptions and
 how they solved if they were able to::
 Also what do these exceptions mean--i mean situation they might happen in??
 
 1.
 java.lang.IllegalStateException: No Page found for component
 [MarkupContainer [Component id = panel, page = No Page, path =
  at org.apache.wicket.Component.getPage(Component.java:1658)
  at 
 org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689)

We have run into this in a situation where you add a component
to AjaxRequestTarget for repainting, even though the component 
gets removed from the current page.

This happens easily when your component is under a repeater
and the whole repeater gets repainted, and it then recreates 
its children. The old children and their descendants then 
become garbage and repainting them produces this exception.

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations OyURL: http://www.ri.fi/ 

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



Re: Changing Link string conditionally?

2008-06-01 Thread Michael Allan
Erik van Oosten wrote:
 The idea is to put a span inside the a, and then attach a Label to the 
 span.

Fearing a span-demic in my code, I came up with this:

  http://zelea.com/project/votorola/g/servlet/BookmarkablePageLinkX.java

  
http://zelea.com/project/votorola/_/javadoc/votorola/g/servlet/BookmarkablePageLinkX.html

There's probably a more elegant way to code it, though.

-- 
Michael Allan

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


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



RE: maven deployment..?

2008-06-01 Thread Brill Pappin
Because deployment happens to a staging or production server, I simply set
the jvm startup params with  -Dwicket.configuration=deployment.

I also have a small block in my Application instance that turns params on
and off depending on the mode as well, so for instance I can have tags
stripped etc. in production.

So, I simply deploy the war as needed and the correct env is set up.

I like this way of doing it because I hate having a *different* deployable
depending on how some filter modified my metadata.

- Brill  

-Original Message-
From: Nino Saturnino Martinez Vazquez Wael [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 30, 2008 10:43 AM
To: users@wicket.apache.org
Subject: maven deployment..?

Hi

I use cargo, to deploy to tomcat and I would really like to automatically
deploy wicket in deploy and not development. So what do you guys do..? Have
different profiles that include different web.xml or?

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


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


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



how to do i18n of javascript file with Wicket?

2008-06-01 Thread Quan Zhou
My application's supposed to support both English,Simpilify
Chinese,Traditional Chinese,and even Vietnamese. The great I18N feature of
Wicket helps me solve many i18n problems.
The only remains is how to do i18n of javascript.
Due to the initial design, we put some of messages in the .js file,like
confirm messages or some other tips. I firstly archieved it with change
different js file including in the html head tag.
as :
put  script language=javascript src=js/area_zh_CN.js/script in
a.zh_CN.html
while
put  script language=javascript src=js/area_zh_TW.js/script in
a.zh_TW.html

you know ,that's really a bad way to do so. Sometimes there's no difference
in those two html files. and the only difference between js files are those
I18N MESSAGE values.

Now I've two ideas to improve my current design.
1) write some js file named string_zh_CN.js or string_zh_TW.js which
contains all the Message content occurr in ALL the js file, and provide a
method call getString(message) that return the correct value in current
LOCALE. Then write a component that can load the specific string.xx_xxx.js
file according to the Server LOCALE and add it in the basic page class which
inherited by all my business page. Finally replace all the Message Value
exists in other js files with getString(xxx)

2) design a component CustomScript for handling all the js file download
request so that I could use wicket to stream js file content. Then, i could
write wicket:message tag in my js file.I suppose those tag would be replace
with the value I put in the Application.properties. Finally ,replace all the
script tag with my custom component.

However I was still searching whether there's any best practice for this
problem?  I would try to implemented both two ideas in the following days.
Is there any attentions I should pay to? and I'm not quite sure about idea 2
would work well.

Any help or advice would be appreicated.
Thanks all.


Re: Feedback message related problem--info,debug etc take string arguments which is not very flexible

2008-06-01 Thread Erik van Oosten

Hi, Atul,

That sounds like a reasonable request to me (I am no core member). Its 
best to open a new issue in Wicket's jira, preferably with a patch attached.


Regards,
   Erik.

atul singh wrote:

Hi,
I see that only error() feedback takes a serializabel message. This allows
me to pass any java object as message and implement custom filtering of
messages by components.
but info,debug etc take a string and so do not help me in that kind of
filtering.
Actually what we have is a TabbedWizard thing, a hybrid of TabbedPanel and
Wizard. We have such a requirement to target feedback messages to very
specific feedback components on any of the tabs. This is also not possible
by implementing this logic based on the reporting component. I wanted the
implementation to be generic , just based on info encapsulated in the
message.
Can anyone suggest an alternative?
Can the info(),debug() etc method signatures be changed to have such
flexibility???
Thanks

  



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



Re: Changing Link string conditionally?

2008-06-01 Thread Erik van Oosten

Michael Allan wrote:

Fearing a span-demic in my code, I came up with this:...
There's probably a more elegant way to code it, though.
  

Neh, that is a very common approach ;)

   Erik.


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



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

2008-06-01 Thread Erik van Oosten

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

Regards,
   Erik.


Michael Mehrle wrote:

Right now I had to resort to the solution below, but I would very much
like to know the standard way of doing this, as this required me to
place my properties file into the src/main/resources folder:

static {
try {

properties.load(Thread.currentThread().getContextClassLoader().getResour
ceAsStream(
MyComponent.properties));
} catch (Exception e) {
LOG.error(Unable to load file
MyComponent.properties' - error: {}, e.getMessage(), e);
}
}

public static String getProperty(String key) {
return properties.getProperty(key);
}
  



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



Re: how to do i18n of javascript file with Wicket?

2008-06-01 Thread Erik van Oosten
We use approach 1. We do not pull messages from Wicket resources, they 
are just static in the file. The link to the correct js file is however 
created by a dynamic component that uses the current Locale.


You could go with approach 2, but to me it  sounds like a lot of work.

Regards,
   Erik.

Quan Zhou wrote:

My application's supposed to support both English,Simpilify
Chinese,Traditional Chinese,and even Vietnamese. The great I18N feature of
Wicket helps me solve many i18n problems.
The only remains is how to do i18n of javascript



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