You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by manunabble <ma...@gmail.com> on 2007/06/21 17:46:46 UTC
IRequestCycleProcessor on PortletRequestCycle implementation
Hi,
I am on testing my recently-"old"-webapp, now migrated
without-code-compilation-errors to a portlet-application, and my
custom-session implementation forces me to implement
new-PortletRequestCycle, and its IRequestCycleProcessor-abstract-method.
My code-snippet, inside my PortletApplication-extension is this:
...
protected IRequestCycleFactory getDefaultRequestCycleFactory() {
return new IRequestCycleFactory() {
private static final long serialVersionUID = 1L;
public RequestCycle newRequestCycle(Session session, Request request,
Response response) {
return new PortletRequestCycle((WicketPortletSession) session,
(WicketPortletRequest) request, response) {
public Page onRuntimeException(Page page, RuntimeException e) {
...
}
public IRequestCycleProcessor getProcessor() {
// TODO Auto-generated method stub
return null;
}
};
}
};
...
What should I do at the TODO, instead of returning null?
Thank you ;)
Cheers
--
View this message in context: http://www.nabble.com/IRequestCycleProcessor-on-PortletRequestCycle-implementation-tf3959585.html#a11235892
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: IRequestCycleProcessor on PortletRequestCycle implementation
Posted by Eelco Hillenius <ee...@gmail.com>.
Janne, are you reading with us?
Eelco
On 6/21/07, manunabble <ma...@gmail.com> wrote:
>
> Hi,
>
> I am on testing my recently-"old"-webapp, now migrated
> without-code-compilation-errors to a portlet-application, and my
> custom-session implementation forces me to implement
> new-PortletRequestCycle, and its IRequestCycleProcessor-abstract-method.
>
> My code-snippet, inside my PortletApplication-extension is this:
>
> ...
> protected IRequestCycleFactory getDefaultRequestCycleFactory() {
> return new IRequestCycleFactory() {
> private static final long serialVersionUID = 1L;
> public RequestCycle newRequestCycle(Session session, Request request,
> Response response) {
> return new PortletRequestCycle((WicketPortletSession) session,
> (WicketPortletRequest) request, response) {
> public Page onRuntimeException(Page page, RuntimeException e) {
> ...
> }
> public IRequestCycleProcessor getProcessor() {
> // TODO Auto-generated method stub
> return null;
> }
> };
> }
> };
> ...
>
> What should I do at the TODO, instead of returning null?
>
> Thank you ;)
>
> Cheers
>
> --
> View this message in context: http://www.nabble.com/IRequestCycleProcessor-on-PortletRequestCycle-implementation-tf3959585.html#a11235892
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: IRequestCycleProcessor on PortletRequestCycle implementation
Posted by manunabble <ma...@gmail.com>.
> protected IRequestCycleFactory getDefaultRequestCycleFactory() {
> ...
> public Page onRuntimeException(Page page, RuntimeException e) {
> if (e instanceof NTWebException) {
> return new ErrorPage((NTWebException) e);
> }
> return new ErrorPage(new NTWebException(new NTWebError(new
> String[] {
> ErrorConst.ERR$EXC }), e));
> }
> ...
> }
> Are you sure that is going to work on your portlet container?
Of course I am not sure, I have to achieve running the portlet in the
portlet-container first. That code worked fine as a WebApp, so it's just
inherited in this portlet after the webapp-2-portlet-transformation, which
consists, in most cases, swapping from WebPage to PortletPage and
refactoring some code fragment (You and me had a conversation about this
various month ago, remember?).
So, you are the expert in wicket-vs-portlet, you might tell why are you
doubting that code snippet might not work!?
> Yeah, Wicket 1.3 is in beta and it's portlet support is experimental,
but the portlet support of 1.2 is as much experimental: http://
svn.apache.org/viewvc/incubator/wicket/branches/wicket-1.2.x/wicket/
src/main/java/wicket/protocol/http/portlet/WARNING.README?view=co .
If I would have to do some portlet stuff now, I would choose Wicket 1.3.
Well, so you suggesting me to migrate the application to 1.3... should I
guess that portlet-support for wicket is only continued in 1.3, but not in
1.2 anymore?
Appart from this, I am wondering: if wicket-portlet-api is experimental,
both 1.2 and 1.3, why was it distributed and released as
non-explicitly-expermintal some month ago at wicket's site? I began testing
wicket because of its apparent stable release and support on portlets when
deciding which web-front-tech to use in this project. This is not complaint,
it's an obvious question, but with not an obvious answer, I am afraid.
--
View this message in context: http://www.nabble.com/IRequestCycleProcessor-on-PortletRequestCycle-implementation-tf3959585.html#a11286139
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: IRequestCycleProcessor on PortletRequestCycle implementation
Posted by Janne Hietamäki <ja...@apache.org>.
On 22.6.2007, at 16.53, manunabble wrote:
>
>> Why you have to implement a new PortletRequestCycle?
>
> Because I do a custom-error-handling, as you can see in the following
> fragment of the already-posted-snippet (onRuntimeException):
>
> protected IRequestCycleFactory getDefaultRequestCycleFactory() {
> ...
> public Page onRuntimeException(Page page, RuntimeException e) {
> if (e instanceof NTWebException) {
> return new ErrorPage((NTWebException) e);
> }
> return new ErrorPage(new NTWebException(new NTWebError(new
> String[] {
> ErrorConst.ERR$EXC }), e));
> }
> ...
> }
>
Are you sure that is going to work on your portlet container?
>> Maybe you should check out the new portlet support from http://
> svn.apache.org/viewvc/incubator/wicket/branches/wicket-1.3-portlet-
> support/ ?
>
> Hmmm... I was recommended not to use wicket-1.3, as it's still
> experimental;
> I am working on wicket-1.2.6.
Yeah, Wicket 1.3 is in beta and it's portlet support is experimental,
but the portlet support of 1.2 is as much experimental: http://
svn.apache.org/viewvc/incubator/wicket/branches/wicket-1.2.x/wicket/
src/main/java/wicket/protocol/http/portlet/WARNING.README?view=co .
If I would have to do some portlet stuff now, I would choose Wicket 1.3.
Janne
Re: IRequestCycleProcessor on PortletRequestCycle implementation
Posted by manunabble <ma...@gmail.com>.
> Why you have to implement a new PortletRequestCycle?
Because I do a custom-error-handling, as you can see in the following
fragment of the already-posted-snippet (onRuntimeException):
protected IRequestCycleFactory getDefaultRequestCycleFactory() {
...
public Page onRuntimeException(Page page, RuntimeException e) {
if (e instanceof NTWebException) {
return new ErrorPage((NTWebException) e);
}
return new ErrorPage(new NTWebException(new NTWebError(new String[] {
ErrorConst.ERR$EXC }), e));
}
...
}
> Maybe you should check out the new portlet support from http://
svn.apache.org/viewvc/incubator/wicket/branches/wicket-1.3-portlet-
support/ ?
Hmmm... I was recommended not to use wicket-1.3, as it's still experimental;
I am working on wicket-1.2.6.
--
View this message in context: http://www.nabble.com/IRequestCycleProcessor-on-PortletRequestCycle-implementation-tf3959585.html#a11252715
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: IRequestCycleProcessor on PortletRequestCycle implementation
Posted by Janne Hietamäki <ja...@apache.org>.
Hi,
Why you have to implement a new PortletRequestCycle? Take a look at
PortletActionRequestCycle and PortletRenderRequestCycle, and the
default getDefaultRequestCycleFactory method from
PortletApplication. As you can access all the original portlet
Action/Render Request/Responses from the default implementations,
there should not really be any reason to re-implement these.
Maybe you should check out the new portlet support from http://
svn.apache.org/viewvc/incubator/wicket/branches/wicket-1.3-portlet-
support/ ?
Janne
On 21.6.2007, at 18.46, manunabble wrote:
>
> Hi,
>
> I am on testing my recently-"old"-webapp, now migrated
> without-code-compilation-errors to a portlet-application, and my
> custom-session implementation forces me to implement
> new-PortletRequestCycle, and its IRequestCycleProcessor-abstract-
> method.
>
> My code-snippet, inside my PortletApplication-extension is this:
>
> ...
> protected IRequestCycleFactory getDefaultRequestCycleFactory() {
> return new IRequestCycleFactory() {
> private static final long serialVersionUID = 1L;
> public RequestCycle newRequestCycle(Session session, Request request,
> Response response) {
> return new PortletRequestCycle((WicketPortletSession) session,
> (WicketPortletRequest) request, response) {
> public Page onRuntimeException(Page page, RuntimeException e) {
> ...
> }
> public IRequestCycleProcessor getProcessor() {
> // TODO Auto-generated method stub
> return null;
> }
> };
> }
> };
> ...
>
> What should I do at the TODO, instead of returning null?
>
> Thank you ;)
>
> Cheers
>
> --
> View this message in context: http://www.nabble.com/
> IRequestCycleProcessor-on-PortletRequestCycle-implementation-
> tf3959585.html#a11235892
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>