Re: Making Wicket Fully Compatible with Google App Engine
On Mon, Sep 20, 2010 at 1:18 PM, tetsuo wrote: > An auto-detected GAE-specific mode in Wicket core? I don't think this is a > good idea... > I agree that this shouldn't go in core, but I think if someone like Clint has the motivation to do so, I'd love to see a project that provides out-of-the-box GAE support. This might make it easier for newbs to get something deployed to play with. This could potentially be done as a standalone project that provides subclasses to WebApplication, etc, with the default implementations switched out to GAE-compatible classes, configured correctly, etc. Or, it could be a git clone of 1.4 and 1.5 (trunk) that keeps current with the "vendor" (us, official Wicket), but adds in their custom changes to make it GAE compatible. Why not use Jira sub tasks? I think this is the way to go - create a master "make GAE compatible version" task and subtasks for each individual thing. There should be a differentiation made between ones that can be accepted in core and those that can't. For example, we (probably) won't be accepting a WebApplication subclass specific to GAE. But, we could accept some changes that need to be made to make it compatible with, or easier to make compatible with, GAE. For example, I'd love to see a task for "kill the use of stupid TreeModel in 1.5" (and, really, any java.awt / javax.swing usage in core). But, this would be better discussed as a separate thread. -- Jeremy Thomerson http://www.wickettraining.com
Re: Making Wicket Fully Compatible with Google App Engine
An auto-detected GAE-specific mode in Wicket core? I don't think this is a good idea... On Mon, Sep 20, 2010 at 3:07 PM, Erik van Oosten wrote: > > ...and those shouldn't change, since the defaults shoud target... >> ...I think nothing one could do would change the classification from >> semi-compatible to compatible... >> > > Sure you can, the defaults could change automatically by detecting that GAE > is the container. > > Regards, >Erik. > > > > Op 20-09-10 15:05, tetsuo wrote: > >> I think Wicket is listed as semi-compatible because it requires some >> customization (override some methods, change some configuration) to make >> it >> work, not because its internals are inherently incompatible to GAE, or >> because it has some incompatible visual components. >> >> Such customization are simply disabling resource polling, enabling >> sessions >> and persisting the session store in the HttpSession, and those shouldn't >> change, since the defaults shoud target to the plain-old Java web >> application, not GAE. >> >> Some things could be done to improve GAE support, such as eliminating >> javax.swing dependencies (from the Tree component), but I think nothing >> one >> could do would change the classification from semi-compatible to >> compatible >> in that listing. Unless, of course, GAE turns to be the main target for >> Wicket (which I don't think is the case). >> >> my 2c, >> >> Tetsuo >> >> >> > -- > Sent from my SMTP compliant software > Erik van Oosten > http://day-to-day-stuff.blogspot.com/ > > >
Re: Making Wicket Fully Compatible with Google App Engine
...and those shouldn't change, since the defaults shoud target... ...I think nothing one could do would change the classification from semi-compatible to compatible... Sure you can, the defaults could change automatically by detecting that GAE is the container. Regards, Erik. Op 20-09-10 15:05, tetsuo wrote: I think Wicket is listed as semi-compatible because it requires some customization (override some methods, change some configuration) to make it work, not because its internals are inherently incompatible to GAE, or because it has some incompatible visual components. Such customization are simply disabling resource polling, enabling sessions and persisting the session store in the HttpSession, and those shouldn't change, since the defaults shoud target to the plain-old Java web application, not GAE. Some things could be done to improve GAE support, such as eliminating javax.swing dependencies (from the Tree component), but I think nothing one could do would change the classification from semi-compatible to compatible in that listing. Unless, of course, GAE turns to be the main target for Wicket (which I don't think is the case). my 2c, Tetsuo -- Sent from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: Making Wicket Fully Compatible with Google App Engine
I think Wicket is listed as semi-compatible because it requires some customization (override some methods, change some configuration) to make it work, not because its internals are inherently incompatible to GAE, or because it has some incompatible visual components. Such customization are simply disabling resource polling, enabling sessions and persisting the session store in the HttpSession, and those shouldn't change, since the defaults shoud target to the plain-old Java web application, not GAE. Some things could be done to improve GAE support, such as eliminating javax.swing dependencies (from the Tree component), but I think nothing one could do would change the classification from semi-compatible to compatible in that listing. Unless, of course, GAE turns to be the main target for Wicket (which I don't think is the case). my 2c, Tetsuo On Mon, Sep 20, 2010 at 9:52 AM, Peter Ertl wrote: > Why not prefix all issue titles with something like > > [GAE] problem description > > ? > > This should be easy to filter or lookup > > Am 20.09.2010 um 14:43 schrieb Clint Checketts: > > > There is a 'Will it play in app engine' page that tracks libraries that > are > > compatible with Google App Engine (aka GAE): > > > http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 > > > > Correctly, Wicket is listed as Semi-Compatible. > > > > As a project I've been looking through the Wicket codebase locating the > > pieces that need to change to make it fully compatible. Does it make > sense > > to have a master Jira that tracks the overall 'compatible with GAE' state > > while making individual issues for the specific changes that reference > back > > to the master issue? > > > > Thanks, > > > > -Clint Checketts > >
Re: Making Wicket Fully Compatible with Google App Engine
Jira supports tags right? On Sep 20, 2010 8:55 AM, "Clint Checketts" wrote: > Sure I could take whichever approach the core team prefers. A bonus of > having a master issue is once it gets resolved that the release notes will > specifically mark that it is compatible with GAE. > > On Mon, Sep 20, 2010 at 7:52 AM, Peter Ertl wrote: > >> Why not prefix all issue titles with something like >> >> [GAE] problem description >> >> ? >> >> This should be easy to filter or lookup >> >> Am 20.09.2010 um 14:43 schrieb Clint Checketts: >> >> > There is a 'Will it play in app engine' page that tracks libraries that >> are >> > compatible with Google App Engine (aka GAE): >> > >> http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 >> > >> > Correctly, Wicket is listed as Semi-Compatible. >> > >> > As a project I've been looking through the Wicket codebase locating the >> > pieces that need to change to make it fully compatible. Does it make >> sense >> > to have a master Jira that tracks the overall 'compatible with GAE' state >> > while making individual issues for the specific changes that reference >> back >> > to the master issue? >> > >> > Thanks, >> > >> > -Clint Checketts >> >>
Re: Making Wicket Fully Compatible with Google App Engine
On 20/09/2010 09:52, Peter Ertl wrote: Why not prefix all issue titles with something like [GAE] problem description ? This should be easy to filter or lookup Why not use Jira sub tasks? Adriano
Re: Making Wicket Fully Compatible with Google App Engine
Sure I could take whichever approach the core team prefers. A bonus of having a master issue is once it gets resolved that the release notes will specifically mark that it is compatible with GAE. On Mon, Sep 20, 2010 at 7:52 AM, Peter Ertl wrote: > Why not prefix all issue titles with something like > > [GAE] problem description > > ? > > This should be easy to filter or lookup > > Am 20.09.2010 um 14:43 schrieb Clint Checketts: > > > There is a 'Will it play in app engine' page that tracks libraries that > are > > compatible with Google App Engine (aka GAE): > > > http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 > > > > Correctly, Wicket is listed as Semi-Compatible. > > > > As a project I've been looking through the Wicket codebase locating the > > pieces that need to change to make it fully compatible. Does it make > sense > > to have a master Jira that tracks the overall 'compatible with GAE' state > > while making individual issues for the specific changes that reference > back > > to the master issue? > > > > Thanks, > > > > -Clint Checketts > >
Re: Making Wicket Fully Compatible with Google App Engine
Why not prefix all issue titles with something like [GAE] problem description ? This should be easy to filter or lookup Am 20.09.2010 um 14:43 schrieb Clint Checketts: > There is a 'Will it play in app engine' page that tracks libraries that are > compatible with Google App Engine (aka GAE): > http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 > > Correctly, Wicket is listed as Semi-Compatible. > > As a project I've been looking through the Wicket codebase locating the > pieces that need to change to make it fully compatible. Does it make sense > to have a master Jira that tracks the overall 'compatible with GAE' state > while making individual issues for the specific changes that reference back > to the master issue? > > Thanks, > > -Clint Checketts
Making Wicket Fully Compatible with Google App Engine
There is a 'Will it play in app engine' page that tracks libraries that are compatible with Google App Engine (aka GAE): http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 Correctly, Wicket is listed as Semi-Compatible. As a project I've been looking through the Wicket codebase locating the pieces that need to change to make it fully compatible. Does it make sense to have a master Jira that tracks the overall 'compatible with GAE' state while making individual issues for the specific changes that reference back to the master issue? Thanks, -Clint Checketts
Re: svn commit: r997528 - in /wicket/trunk: wicket-request/src/main/java/org/apache/wicket/request/http/ wicket/src/main/java/org/apache/wicket/protocol/http/servlet/
Am 20.09.2010 um 13:03 schrieb Martin Grigorov: > I chose "WebResponse" as type because this is in *Web*Application. Isn't it even a "ServletWebApplication" ? :-)
Re: svn commit: r997528 - in /wicket/trunk: wicket-request/src/main/java/org/apache/wicket/request/http/ wicket/src/main/java/org/apache/wicket/protocol/http/servlet/
These are just the default implementations of these two methods. If you change #newWebRequest() to return something else, e.g. PortletWebRequest, then you will have to override #newWebResponse() as well (e.g PortletWebResponse). Until this change ServletWebResponse was working directly with HttpServletRequest, now it has "wider knowledge" thru ServletWebRequest. Maybe we can change #newWebResponse() to receive "Response" instead of "WebResponse", but the cast will be still needed for this _default_ implementation. I chose "WebResponse" as type because this is in *Web*Application. On Mon, Sep 20, 2010 at 12:03 PM, Peter Ertl wrote: > I don't know if the cast to (ServletWebRequest) in webapplicat...@383 is > safe? > >return new HeaderBufferingWebResponse(new > ServletWebResponse((ServletWebRequest)webRequest, > > If it is safe then why not change > >protected WebResponse newWebResponse(final WebRequest webRequest, > final HttpServletResponse httpServletResponse) > > to > >protected WebResponse newWebResponse(final ServletWebRequest > webRequest, final HttpServletResponse httpServletResponse) > > ? > > That's exactly the location in code I did not know how to proceed. > > Igor mentioned that abstract WebRequest does not necessarily have to be > ServletWebRequest when running in different containers. > > @dev: any opinions on that? > > > Am 20.09.2010 um 10:30 schrieb Martin Grigorov: > > > Please review r998677. > > I implemented the logic we discussed in IRC with you before your change. > > > > On Mon, Sep 20, 2010 at 10:24 AM, Peter Ertl wrote: > > > >> Hi Martin, > >> > >> I am aware of that uglyness but I could not figure out a clean way to > get > >> around it. > >> > >> When fixing WICKET-3048 I needed a way to detect if the current request > is > >> of type 'ajax'. > >> > >> However the ctor from ServletWebResponse is > >> > >> public ServletWebResponse(HttpServletRequest httpServletRequest, > >> HttpServletResponse httpServletResponse) > >> > >> To change it to > >> > >> public ServletWebResponse(ServletWebRequest servletWebRequest, > >> HttpServletResponse httpServletResponse) > >> > >> you would need to instantiate > >> > >> public ServletWebRequest(HttpServletRequest httpServletRequest, > >> String filterPrefix) > >> > >> However there's no easy way to get 'filterPrefix' in the relevant places > so > >> I was kind of stuck there. > >> > >> Note my TODO in ServletWebRequest line 389 :-( > >> > >> If you can figure out a clean way to get this done I will appreciate > that > >> :-) > >> > >> > >> > >> > >> > >> > >> Am 19.09.2010 um 16:22 schrieb Martin Grigorov: > >> > >>> Hi Peter, > >>> > >>> On Thu, Sep 16, 2010 at 12:40 AM, wrote: > >>> > Author: pete > Date: Wed Sep 15 22:39:59 2010 > New Revision: 997528 > > URL: http://svn.apache.org/viewvc?rev=997528&view=rev > Log: > fixed non-working ajax redirects: WICKET-3048 > > Modified: > > > >> > wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java > > > >> > wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java > > > >> > wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java > > Modified: > > >> > wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java > URL: > > >> > http://svn.apache.org/viewvc/wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java?rev=997528&r1=997527&r2=997528&view=diff > > > >> > == > --- > > >> > wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java > (original) > +++ > > >> > wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java > Wed Sep 15 22:39:59 2010 > @@ -104,8 +104,8 @@ public abstract class WebRequest extends > /** > * Marker parameter for AjaxRequest. > */ > - private static final String PARAM_AJAX = "wicket:ajax"; > - private static final String HEADER_AJAX = "Wicket-Ajax"; > + protected static final String PARAM_AJAX = "wicket:ajax"; > + protected static final String HEADER_AJAX = "Wicket-Ajax"; > > /** > * Returns whether this request is an Ajax request. This > implementation only checks for value of > > Modified: > > >> > wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java > URL: > > >> > http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java?rev=997528&r1=997527&r2=997528&view=diff > > > >> > ==
Re: svn commit: r997528 - in /wicket/trunk: wicket-request/src/main/java/org/apache/wicket/request/http/ wicket/src/main/java/org/apache/wicket/protocol/http/servlet/
I don't know if the cast to (ServletWebRequest) in webapplicat...@383 is safe?
return new HeaderBufferingWebResponse(new
ServletWebResponse((ServletWebRequest)webRequest,
If it is safe then why not change
protected WebResponse newWebResponse(final WebRequest webRequest, final
HttpServletResponse httpServletResponse)
to
protected WebResponse newWebResponse(final ServletWebRequest
webRequest, final HttpServletResponse httpServletResponse)
?
That's exactly the location in code I did not know how to proceed.
Igor mentioned that abstract WebRequest does not necessarily have to be
ServletWebRequest when running in different containers.
@dev: any opinions on that?
Am 20.09.2010 um 10:30 schrieb Martin Grigorov:
> Please review r998677.
> I implemented the logic we discussed in IRC with you before your change.
>
> On Mon, Sep 20, 2010 at 10:24 AM, Peter Ertl wrote:
>
>> Hi Martin,
>>
>> I am aware of that uglyness but I could not figure out a clean way to get
>> around it.
>>
>> When fixing WICKET-3048 I needed a way to detect if the current request is
>> of type 'ajax'.
>>
>> However the ctor from ServletWebResponse is
>>
>> public ServletWebResponse(HttpServletRequest httpServletRequest,
>> HttpServletResponse httpServletResponse)
>>
>> To change it to
>>
>> public ServletWebResponse(ServletWebRequest servletWebRequest,
>> HttpServletResponse httpServletResponse)
>>
>> you would need to instantiate
>>
>> public ServletWebRequest(HttpServletRequest httpServletRequest,
>> String filterPrefix)
>>
>> However there's no easy way to get 'filterPrefix' in the relevant places so
>> I was kind of stuck there.
>>
>> Note my TODO in ServletWebRequest line 389 :-(
>>
>> If you can figure out a clean way to get this done I will appreciate that
>> :-)
>>
>>
>>
>>
>>
>>
>> Am 19.09.2010 um 16:22 schrieb Martin Grigorov:
>>
>>> Hi Peter,
>>>
>>> On Thu, Sep 16, 2010 at 12:40 AM, wrote:
>>>
Author: pete
Date: Wed Sep 15 22:39:59 2010
New Revision: 997528
URL: http://svn.apache.org/viewvc?rev=997528&view=rev
Log:
fixed non-working ajax redirects: WICKET-3048
Modified:
>> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java
Modified:
>> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
URL:
>> http://svn.apache.org/viewvc/wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java?rev=997528&r1=997527&r2=997528&view=diff
>> ==
---
>> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
(original)
+++
>> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
Wed Sep 15 22:39:59 2010
@@ -104,8 +104,8 @@ public abstract class WebRequest extends
/**
* Marker parameter for AjaxRequest.
*/
- private static final String PARAM_AJAX = "wicket:ajax";
- private static final String HEADER_AJAX = "Wicket-Ajax";
+ protected static final String PARAM_AJAX = "wicket:ajax";
+ protected static final String HEADER_AJAX = "Wicket-Ajax";
/**
* Returns whether this request is an Ajax request. This
implementation only checks for value of
Modified:
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
URL:
>> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java?rev=997528&r1=997527&r2=997528&view=diff
>> ==
---
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
(original)
+++
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
Wed Sep 15 22:39:59 2010
@@ -371,4 +371,23 @@ public class ServletWebRequest extends W
{
return RequestUtils.getCharset(httpServletRequest);
}
+
+ @Override
+ public boolean isAjax()
+ {
+ return isAjax(httpServletRequest);
+ }
+
+ /**
+* check if random http servlet request is an ajax request
+*
+* @param httpServletRequest web request
+* @return true if ajax, false if
>> regul
Re: svn commit: r997528 - in /wicket/trunk: wicket-request/src/main/java/org/apache/wicket/request/http/ wicket/src/main/java/org/apache/wicket/protocol/http/servlet/
Please review r998677.
I implemented the logic we discussed in IRC with you before your change.
On Mon, Sep 20, 2010 at 10:24 AM, Peter Ertl wrote:
> Hi Martin,
>
> I am aware of that uglyness but I could not figure out a clean way to get
> around it.
>
> When fixing WICKET-3048 I needed a way to detect if the current request is
> of type 'ajax'.
>
> However the ctor from ServletWebResponse is
>
>public ServletWebResponse(HttpServletRequest httpServletRequest,
>HttpServletResponse httpServletResponse)
>
> To change it to
>
>public ServletWebResponse(ServletWebRequest servletWebRequest,
>HttpServletResponse httpServletResponse)
>
> you would need to instantiate
>
>public ServletWebRequest(HttpServletRequest httpServletRequest,
> String filterPrefix)
>
> However there's no easy way to get 'filterPrefix' in the relevant places so
> I was kind of stuck there.
>
> Note my TODO in ServletWebRequest line 389 :-(
>
> If you can figure out a clean way to get this done I will appreciate that
> :-)
>
>
>
>
>
>
> Am 19.09.2010 um 16:22 schrieb Martin Grigorov:
>
> > Hi Peter,
> >
> > On Thu, Sep 16, 2010 at 12:40 AM, wrote:
> >
> >> Author: pete
> >> Date: Wed Sep 15 22:39:59 2010
> >> New Revision: 997528
> >>
> >> URL: http://svn.apache.org/viewvc?rev=997528&view=rev
> >> Log:
> >> fixed non-working ajax redirects: WICKET-3048
> >>
> >> Modified:
> >>
> >>
> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
> >>
> >>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
> >>
> >>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java
> >>
> >> Modified:
> >>
> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java?rev=997528&r1=997527&r2=997528&view=diff
> >>
> >>
> ==
> >> ---
> >>
> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
> >> (original)
> >> +++
> >>
> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
> >> Wed Sep 15 22:39:59 2010
> >> @@ -104,8 +104,8 @@ public abstract class WebRequest extends
> >> /**
> >>* Marker parameter for AjaxRequest.
> >>*/
> >> - private static final String PARAM_AJAX = "wicket:ajax";
> >> - private static final String HEADER_AJAX = "Wicket-Ajax";
> >> + protected static final String PARAM_AJAX = "wicket:ajax";
> >> + protected static final String HEADER_AJAX = "Wicket-Ajax";
> >>
> >> /**
> >>* Returns whether this request is an Ajax request. This
> >> implementation only checks for value of
> >>
> >> Modified:
> >>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java?rev=997528&r1=997527&r2=997528&view=diff
> >>
> >>
> ==
> >> ---
> >>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
> >> (original)
> >> +++
> >>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
> >> Wed Sep 15 22:39:59 2010
> >> @@ -371,4 +371,23 @@ public class ServletWebRequest extends W
> >> {
> >> return RequestUtils.getCharset(httpServletRequest);
> >> }
> >> +
> >> + @Override
> >> + public boolean isAjax()
> >> + {
> >> + return isAjax(httpServletRequest);
> >> + }
> >> +
> >> + /**
> >> +* check if random http servlet request is an ajax request
> >> +*
> >> +* @param httpServletRequest web request
> >> +* @return true if ajax, false if
> regular
> >> request
> >> +*/
> >> + public static boolean isAjax(HttpServletRequest
> httpServletRequest)
> >> + {
> >> + // TODO there is some redundancy in this method and
> >> WebRequest#isAjax - can this be eliminated?
> >> + return
> >> Strings.isTrue(httpServletRequest.getHeader(HEADER_AJAX)) ||
> >> +
> >> Strings.isTrue(httpServletRequest.getParameter(PARAM_AJAX));
> >> + }
> >>
> > What is the reason to add this method at all ?
> > Why not use WebRequest#isAjax() ?
> >
> > Why 'static' ? ServletWebRequest has a reference to its
> HttpServletRequest.
> > Why do you want to check some other HttpServletRequest ?!
> >
> >> }
> >>
> >> Modified:
> >>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java
> >> URL:
> >>
> http://svn.apache.org/vi
Re: svn commit: r997528 - in /wicket/trunk: wicket-request/src/main/java/org/apache/wicket/request/http/ wicket/src/main/java/org/apache/wicket/protocol/http/servlet/
Hi Martin,
I am aware of that uglyness but I could not figure out a clean way to get
around it.
When fixing WICKET-3048 I needed a way to detect if the current request is of
type 'ajax'.
However the ctor from ServletWebResponse is
public ServletWebResponse(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse)
To change it to
public ServletWebResponse(ServletWebRequest servletWebRequest,
HttpServletResponse httpServletResponse)
you would need to instantiate
public ServletWebRequest(HttpServletRequest httpServletRequest, String
filterPrefix)
However there's no easy way to get 'filterPrefix' in the relevant places so I
was kind of stuck there.
Note my TODO in ServletWebRequest line 389 :-(
If you can figure out a clean way to get this done I will appreciate that :-)
Am 19.09.2010 um 16:22 schrieb Martin Grigorov:
> Hi Peter,
>
> On Thu, Sep 16, 2010 at 12:40 AM, wrote:
>
>> Author: pete
>> Date: Wed Sep 15 22:39:59 2010
>> New Revision: 997528
>>
>> URL: http://svn.apache.org/viewvc?rev=997528&view=rev
>> Log:
>> fixed non-working ajax redirects: WICKET-3048
>>
>> Modified:
>>
>> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
>>
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
>>
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java
>>
>> Modified:
>> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
>> URL:
>> http://svn.apache.org/viewvc/wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java?rev=997528&r1=997527&r2=997528&view=diff
>>
>> ==
>> ---
>> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
>> (original)
>> +++
>> wicket/trunk/wicket-request/src/main/java/org/apache/wicket/request/http/WebRequest.java
>> Wed Sep 15 22:39:59 2010
>> @@ -104,8 +104,8 @@ public abstract class WebRequest extends
>> /**
>>* Marker parameter for AjaxRequest.
>>*/
>> - private static final String PARAM_AJAX = "wicket:ajax";
>> - private static final String HEADER_AJAX = "Wicket-Ajax";
>> + protected static final String PARAM_AJAX = "wicket:ajax";
>> + protected static final String HEADER_AJAX = "Wicket-Ajax";
>>
>> /**
>>* Returns whether this request is an Ajax request. This
>> implementation only checks for value of
>>
>> Modified:
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
>> URL:
>> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java?rev=997528&r1=997527&r2=997528&view=diff
>>
>> ==
>> ---
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
>> (original)
>> +++
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebRequest.java
>> Wed Sep 15 22:39:59 2010
>> @@ -371,4 +371,23 @@ public class ServletWebRequest extends W
>> {
>> return RequestUtils.getCharset(httpServletRequest);
>> }
>> +
>> + @Override
>> + public boolean isAjax()
>> + {
>> + return isAjax(httpServletRequest);
>> + }
>> +
>> + /**
>> +* check if random http servlet request is an ajax request
>> +*
>> +* @param httpServletRequest web request
>> +* @return true if ajax, false if regular
>> request
>> +*/
>> + public static boolean isAjax(HttpServletRequest httpServletRequest)
>> + {
>> + // TODO there is some redundancy in this method and
>> WebRequest#isAjax - can this be eliminated?
>> + return
>> Strings.isTrue(httpServletRequest.getHeader(HEADER_AJAX)) ||
>> +
>> Strings.isTrue(httpServletRequest.getParameter(PARAM_AJAX));
>> + }
>>
> What is the reason to add this method at all ?
> Why not use WebRequest#isAjax() ?
>
> Why 'static' ? ServletWebRequest has a reference to its HttpServletRequest.
> Why do you want to check some other HttpServletRequest ?!
>
>> }
>>
>> Modified:
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java
>> URL:
>> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java?rev=997528&r1=997527&r2=997528&view=diff
>>
>> ==
>> ---
>> wicket/trunk/wicket/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java
>> (original)
>> +++
>> wicket/trunk/wicket/src/main/java/org/apache/wicket
