Re: [Announce] Wicket Stuff Core 1.5.1 Released

[Bruno Borges]

Excelent work Michael, thanks a lot!


*Bruno Borges*
(21) 7672-7099
*www.brunoborges.com*



On Sat, Oct 8, 2011 at 11:23 PM, Michael O'Cleirigh <
michael.ocleir...@rivulet.ca> wrote:

> Hello,
>
> Following the release of wicket 1.5.1 have cut a matching wicketstuff-core
> release.
>
> The artifacts have been promoted and are now available in maven central.
>
> They can be retrieved like this:
>
> 
> org.wicketstuff
> wicketstuff-**annotation
> 1.5.1
> 
>
> The release tag is here: https://github.com/**wicketstuff/core/tree/**
> wicketstuff-core-1.5.1
>
> Development on the next release takes place on the master branch here:
> https://github.com/**wicketstuff/core
>
> Issues can be reported here: 
> https://github.com/**wicketstuff/core/issues
>
> The Project Wiki is available here: https://github.com/**
> wicketstuff/core/wiki 
>
> Changelog between wicketstuff-core-1.45.0 and this release:
>
> peter (8):
>  [closure-compiler] add project
>  [closure-compiler] add stats, small fixes
>  add [closure-compiler] to core/jdk-1.5-parent/pom.xml
>  [closure-compiler] support different compression levels, add externs
> to su
>  [closure-compiler] fixed externs, better support for customization
>  add artifact jul-to-slf4j (redirect jul over slf4j) to dependency
> manageme
>  [closure-compiler] better logging, better error reporting
>  [closure-compiler] set default compression to 'simple' since
> 'advanced' is
>
> akiraly (5):
>  [closure-compiler] Moved under jdk-1.6-parent as
> googlecode-closure-compil
>  [core] Updated logback and ehcache.
>  [core] Updated clojure. Triggered some changes in [console-engine]
> clojure
>  [inmethod-grid] Cosmetic change to fix a warning.
>  [push] Fix "unload request" check.
>
> Michael O'Cleirigh (1):
>  commit 1.5.1 release pom's
>
> martin-g (1):
>  [inmethod-grid] Change the artifactId of the examples module to be in
> sync
>
>
> (This listing was generated using: git shortlog -n wicketstuff-core-1.5.0..
> **wicketstuff-core-1.5.1).
>
> I will plan to do the next release within one month of today but if you
> commit code and/or need a release cut sooner please file a ticket.
>
> Regards,
>
> Mike
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

[Announce] Wicket Stuff Core 1.5.1 Released

[Michael O'Cleirigh]

Hello,

Following the release of wicket 1.5.1 have cut a matching 
wicketstuff-core release.


The artifacts have been promoted and are now available in maven central.

They can be retrieved like this:


org.wicketstuff
wicketstuff-annotation
1.5.1


The release tag is here: 
https://github.com/wicketstuff/core/tree/wicketstuff-core-1.5.1


Development on the next release takes place on the master branch here: 
https://github.com/wicketstuff/core


Issues can be reported here: https://github.com/wicketstuff/core/issues

The Project Wiki is available here: 
https://github.com/wicketstuff/core/wiki


Changelog between wicketstuff-core-1.45.0 and this release:

peter (8):
  [closure-compiler] add project
  [closure-compiler] add stats, small fixes
  add [closure-compiler] to core/jdk-1.5-parent/pom.xml
  [closure-compiler] support different compression levels, add 
externs to su

  [closure-compiler] fixed externs, better support for customization
  add artifact jul-to-slf4j (redirect jul over slf4j) to dependency 
manageme

  [closure-compiler] better logging, better error reporting
  [closure-compiler] set default compression to 'simple' since 
'advanced' is


akiraly (5):
  [closure-compiler] Moved under jdk-1.6-parent as 
googlecode-closure-compil

  [core] Updated logback and ehcache.
  [core] Updated clojure. Triggered some changes in 
[console-engine] clojure

  [inmethod-grid] Cosmetic change to fix a warning.
  [push] Fix "unload request" check.

Michael O'Cleirigh (1):
  commit 1.5.1 release pom's

martin-g (1):
  [inmethod-grid] Change the artifactId of the examples module to 
be in sync



(This listing was generated using: git shortlog -n 
wicketstuff-core-1.5.0..wicketstuff-core-1.5.1).


I will plan to do the next release within one month of today but if you 
commit code and/or need a release cut sooner please file a ticket.


Regards,

Mike

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

RE: Forwarding in 1.5 not working like in 1.4

[Chris Colman]

Looks like the redirect is due to the PRG strategy implementation so it's set 
to REDIRECT_TO_BUFFER.

(From my, possibly naïve, understanding I thought you only needed PRG when a 
form submission was involved but it looks like it's applied to every page 
request). 

I probably should keep using the redirect strategy option otherwise I will 
encounter the double submit problem with forms.

I just need to know how I can get wicket to allow me to do a forward of 

www.mysite.com

to a URL of the style

www.mysite.com/content/home/o/123

without performing a redirect that changes the user's browser address field.

>-Original Message-
>From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
>Sent: Saturday, 8 October 2011 10:52 PM
>To: users@wicket.apache.org
>Subject: RE: Forwarding in 1.5 not working like in 1.4
>
>Could it be that Wicket sees the original URL as being / (i.e. home page)
>and so performs a redirect to the home page? Possibly it should be looking
>at the 'forward' request URL which is not / but "content/home/o/76429" and
>should be handled directly without a redirect.
>
>>-Original Message-
>>From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
>>Sent: Saturday, 8 October 2011 10:28 PM
>>To: users@wicket.apache.org
>>Subject: RE: Forwarding in 1.5 not working like in 1.4
>>
>>I have found that the method below appears to return the wrong result for
>>relativeUrl:
>>
>>WebPageRender.java
>>
>>protected void redirectTo(Url url, RequestCycle requestCycle)
>>{
>>WebResponse response =
>>(WebResponse)requestCycle.getResponse();
>>String relativeUrl =
>>requestCycle.getUrlRenderer().renderUrl(url);
>>response.sendRedirect(relativeUrl);
>>}
>>
>>On input to the renderUrl method url = "content/home/o/76429?6"
>>
>>On return relativeUrl = "76429?6"
>>
>>Possibly the problem is in UrlRenderer.renderRelativeUrl(Url url)
>>
>>Given that the UrlRender has it's baseUrl as content/home/o/76429 then,
>>according to my naïve understanding of how the Wicket internals work, the
>>relative URL it returns should be
>>
>>?6
>>
>>not
>>
>>"76429?6"
>>
>>Does this make sense?
>>
>>
>>I'm not quite sure why it is appearing to perform a redirect in the first
>>place.
>>
>>If I point the browser to
>>
>>www.mysite.com/content/home/o/76429
>>
>>It works fine but if I point it to
>>
>>www.mysite.com 
>>
>>my separate redirector filter will identify this as a URL that needs
>>forwarding and so it performs a forward via the dispatcher to
>>www.mysite.com/content/home/o/76429.
>>
>>content/home/o/76429 is indeed the servlet path in the request that the
>>Wicket filter receives but yet it feels the need to do a redirect to the
>>incorrect URL it derives above then attempts to service that incorrect
>>redirect request which fails as it is not in the correct format.
>>
>>
>>
>>
>>From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
>>Sent: Friday, 7 October 2011 6:15 PM
>>To: users@wicket.apache.org
>>Subject: Forwarding in 1.5 not working like in 1.4
>>
>>We have a separate filter set up to catch parameter-less domain name
>>requests ( /* ) like:
>>
>>www.myurl.com 
>>
>>and forward them to a bookmarkable home page like:
>>
>>www.myurl.com/content/home/o/123
>>
>>The extra o/123 is an organization discriminator name/value pair and is
>>read in by the home page as a parameter.
>>
>>The use of a forward means that the address in the user's browser remains
>>as www.myurl.com   but the actual page rendered is
>>www.myurl.com/content/home/o/123
>>
>>The page mount looks like:
>>
>>  pageParametersEncoder = new UrlPathPageParametersEncoder();
>>
>>  mount(new MountedMapper("/content/home", HomePage.class,
>>pageParametersEncoder));
>>
>>The code used for the forward inside our separate redirector filter is:
>>
>>  RequestDispatcher rd =
>>req.getRequestDispatcher("/content/home/o/123");
>>  rd.forward(req, res);
>>
>>  This filter then does not chain to the next filter so that the
>>servlet engine can re-request with the forwarded URL.
>>
>>In 1.4 the wicket filter then services this forward request and renders
>the
>>page without a problem.
>>
>>In 1.5 this no longer works and I've tried many different ideas to get it
>>working but it just doesn't seem to want to work properly.
>>
>>Somehow wicket attempts to render a page with a url of:
>>
>>www.myurl.com/123
>>
>>In other words the /content/home/o/ part has been stripped from the
>>"forward to" URL.
>>
>>Debugging shows that the wicket request does indeed have the full uri:
>>
>>/content/home/o/123 
>>
>>
>>Any ideas what might be causing this?
>>
>>
>>Yours sincerely,
>>
>>Chris Colman
>>
>>Pagebloom Team Leader,
>>Step Ahead Software
>>
>>
>>pagebloom - your business

RE: Forwarding in 1.5 not working like in 1.4

[Chris Colman]

Could it be that Wicket sees the original URL as being / (i.e. home page) and 
so performs a redirect to the home page? Possibly it should be looking at the 
'forward' request URL which is not / but "content/home/o/76429" and should be 
handled directly without a redirect.

>-Original Message-
>From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
>Sent: Saturday, 8 October 2011 10:28 PM
>To: users@wicket.apache.org
>Subject: RE: Forwarding in 1.5 not working like in 1.4
>
>I have found that the method below appears to return the wrong result for
>relativeUrl:
>
>WebPageRender.java
>
>protected void redirectTo(Url url, RequestCycle requestCycle)
>{
>WebResponse response =
>(WebResponse)requestCycle.getResponse();
>String relativeUrl =
>requestCycle.getUrlRenderer().renderUrl(url);
>response.sendRedirect(relativeUrl);
>}
>
>On input to the renderUrl method url = "content/home/o/76429?6"
>
>On return relativeUrl = "76429?6"
>
>Possibly the problem is in UrlRenderer.renderRelativeUrl(Url url)
>
>Given that the UrlRender has it's baseUrl as content/home/o/76429 then,
>according to my naïve understanding of how the Wicket internals work, the
>relative URL it returns should be
>
>?6
>
>not
>
>"76429?6"
>
>Does this make sense?
>
>
>I'm not quite sure why it is appearing to perform a redirect in the first
>place.
>
>If I point the browser to
>
>www.mysite.com/content/home/o/76429
>
>It works fine but if I point it to
>
>www.mysite.com 
>
>my separate redirector filter will identify this as a URL that needs
>forwarding and so it performs a forward via the dispatcher to
>www.mysite.com/content/home/o/76429.
>
>content/home/o/76429 is indeed the servlet path in the request that the
>Wicket filter receives but yet it feels the need to do a redirect to the
>incorrect URL it derives above then attempts to service that incorrect
>redirect request which fails as it is not in the correct format.
>
>
>
>
>From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
>Sent: Friday, 7 October 2011 6:15 PM
>To: users@wicket.apache.org
>Subject: Forwarding in 1.5 not working like in 1.4
>
>We have a separate filter set up to catch parameter-less domain name
>requests ( /* ) like:
>
>www.myurl.com 
>
>and forward them to a bookmarkable home page like:
>
>www.myurl.com/content/home/o/123
>
>The extra o/123 is an organization discriminator name/value pair and is
>read in by the home page as a parameter.
>
>The use of a forward means that the address in the user's browser remains
>as www.myurl.com   but the actual page rendered is
>www.myurl.com/content/home/o/123
>
>The page mount looks like:
>
>  pageParametersEncoder = new UrlPathPageParametersEncoder();
>
>  mount(new MountedMapper("/content/home", HomePage.class,
>pageParametersEncoder));
>
>The code used for the forward inside our separate redirector filter is:
>
>  RequestDispatcher rd =
>req.getRequestDispatcher("/content/home/o/123");
>  rd.forward(req, res);
>
>  This filter then does not chain to the next filter so that the
>servlet engine can re-request with the forwarded URL.
>
>In 1.4 the wicket filter then services this forward request and renders the
>page without a problem.
>
>In 1.5 this no longer works and I've tried many different ideas to get it
>working but it just doesn't seem to want to work properly.
>
>Somehow wicket attempts to render a page with a url of:
>
>www.myurl.com/123
>
>In other words the /content/home/o/ part has been stripped from the
>"forward to" URL.
>
>Debugging shows that the wicket request does indeed have the full uri:
>
>/content/home/o/123 
>
>
>Any ideas what might be causing this?
>
>
>Yours sincerely,
>
>Chris Colman
>
>Pagebloom Team Leader,
>Step Ahead Software
>
>
>pagebloom - your business & your website growing together
>
>Sydney:   (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
>Email: chr...@stepahead.com.au 
>Website:
>http://www.pagebloom.com http://www.pagebloom.com/>
>http://develop.stepaheadsoftware.com
>http://develop.stepaheadsoftware.com/>
>
>

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

RE: Forwarding in 1.5 not working like in 1.4

[Chris Colman]

I have found that the method below appears to return the wrong result for 
relativeUrl:
 
WebPageRender.java
 
protected void redirectTo(Url url, RequestCycle requestCycle)
{
WebResponse response = 
(WebResponse)requestCycle.getResponse();
String relativeUrl = 
requestCycle.getUrlRenderer().renderUrl(url);
response.sendRedirect(relativeUrl);
}
 
On input to the renderUrl method url = "content/home/o/76429?6"
 
On return relativeUrl = "76429?6"
 
Possibly the problem is in UrlRenderer.renderRelativeUrl(Url url)
 
Given that the UrlRender has it's baseUrl as content/home/o/76429 then, 
according to my naïve understanding of how the Wicket internals work, the 
relative URL it returns should be
 
?6
 
not 
 
"76429?6"
 
Does this make sense?
 
 
I'm not quite sure why it is appearing to perform a redirect in the first 
place. 
 
If I point the browser to 
 
www.mysite.com/content/home/o/76429
 
It works fine but if I point it to 
 
www.mysite.com  
 
my separate redirector filter will identify this as a URL that needs forwarding 
and so it performs a forward via the dispatcher to 
www.mysite.com/content/home/o/76429.
 
content/home/o/76429 is indeed the servlet path in the request that the Wicket 
filter receives but yet it feels the need to do a redirect to the incorrect URL 
it derives above then attempts to service that incorrect redirect request which 
fails as it is not in the correct format.
 
 


From: Chris Colman [mailto:chr...@stepaheadsoftware.com] 
Sent: Friday, 7 October 2011 6:15 PM
To: users@wicket.apache.org
Subject: Forwarding in 1.5 not working like in 1.4
 
We have a separate filter set up to catch parameter-less domain name requests ( 
/* ) like:
 
www.myurl.com  
 
and forward them to a bookmarkable home page like:
 
www.myurl.com/content/home/o/123
 
The extra o/123 is an organization discriminator name/value pair and is read in 
by the home page as a parameter.
 
The use of a forward means that the address in the user's browser remains as 
www.myurl.com   but the actual page rendered is 
www.myurl.com/content/home/o/123
 
The page mount looks like:
 
  pageParametersEncoder = new UrlPathPageParametersEncoder();
  
  mount(new MountedMapper("/content/home", HomePage.class, 
pageParametersEncoder));
 
The code used for the forward inside our separate redirector filter is:
 
  RequestDispatcher rd = 
req.getRequestDispatcher("/content/home/o/123");
  rd.forward(req, res);
 
  This filter then does not chain to the next filter so that the 
servlet engine can re-request with the forwarded URL.
 
In 1.4 the wicket filter then services this forward request and renders the 
page without a problem.
 
In 1.5 this no longer works and I've tried many different ideas to get it 
working but it just doesn't seem to want to work properly.
 
Somehow wicket attempts to render a page with a url of:
 
www.myurl.com/123
 
In other words the /content/home/o/ part has been stripped from the "forward 
to" URL.
 
Debugging shows that the wicket request does indeed have the full uri:
 
/content/home/o/123  
 
 
Any ideas what might be causing this?
 
 
Yours sincerely,
 
Chris Colman
 
Pagebloom Team Leader,
Step Ahead Software


pagebloom - your business & your website growing together
 
Sydney:   (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 
Email: chr...@stepahead.com.au  
Website:
http://www.pagebloom.com http://www.pagebloom.com/> 
http://develop.stepaheadsoftware.com 
http://develop.stepaheadsoftware.com/> 
 
 

Re: Community tools

[Gaetan Zoritchak]

2011/10/7 Clint Checketts 

> So what is the best way (official? permanent?) to link to a previous
> response?
>
> In 6 months when someone has a similar question, what is the official way
> to
> link to previous answers? Equally, what is the best way to improve those
> answers if the answer 6 months back worked at that time, but now is invalid
> and a 'bad practice' due to wicket improvements?
>
> That is part of the problem. On the wiki, the pages are not tagged
WICKET-1.4 or WICKET-1.5 so you don't know if you can use them.

Is's the same with mail.

The avantage with a Q&A tool is that you tag, rename and edit the question
and the answers. At the end you have a good question with the best answer
and no duplicates. When you search something you just have to look at the
tags to know if you can use the answer.


> Folks so rarely use the mailing list archives (
> http://wicket.apache.org/help/email.html), (not easily searched!) I doubt
> that is the solution.
>
> -Clint
>
> On Fri, Oct 7, 2011 at 7:32 AM, manuelbarzi  wrote:
>
> > it sounds great, but why not fully concentrate on wicket. apache will
> > adopt whatever magic-solution asa it'll be licence compliant, and
> > affordable by resources and directives.
> >
> > for the moment this mailing list has been a very successful machine,
> > and still has much to bring. outside, whatever wrapper (wicket-based
> > or not, may be assembled to pull all posts, order and make them as far
> > confortable-searcheable as low-patience eager-brains demand).
> >
> > as other expressed: markmail and nabble are pretty enough, and
> > managing issues by mail - on smart or not phones - is simply a
> > pleasure.
> > .
> >
>

Re: DateField with String model

[samket]

DateField seems to require a Date model. You can implement a model (a class 
that implements IModel) that transforms between String and Date.


public class DateModel implements IModel {
 private static final long serialVersionUID = 1L;

 private final IModel innerModel;

 public DateModel(IModel innerModel) {
 this.innerModel = innerModel;
 }

 public void detach() {
 innerModel.detach();
 }

 public Date getObject() {
 String value = innerModel.getObject().getDate();
 if (value == null) {
 return null;
 }
 return MyDateConverter.asDate(value);
 }

 public void setObject(Date object) {
 String value;
 if (object != null) {
 value = MyDateConverter.asString(object);
 } else {
 value = null;
 }
 innerModel.getObject().setDate(value);
 }
}


 
  - Original Message -
  From: Pirlouit Le
  Sent: 10/07/11 11:38 AM
  To: users@wicket.apache.org
  Subject: DateField with String model
 
   
Hi wicket community,I'm trying to use a DateField 
(org.apache.wicket.extention.yui.calendar.DateField)with a String in the model, 
is this possible, perhaps can I provide a converter, a smth like this ?
 
Kind Regards, 





Benoît de Biolley   

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