Re: Stream/download files through portlet

2009-05-08 Thread Bruno Ledesma

Hello All!

Im facing problems trying to  Stream/download files through portlet. I also
used DynamicWebResource and a Resource link to serve the Resource Data. On a
simple Wicket application everything works fine, but when my war is deployed
as a portlet into a Liferay 5 instance, it doesnt work. 

The browser response is :  The requested resource
(/wick-portlet-0.0.1-SNAPSHOT/wick-portlet/) is not available.

Does anyone have some idea,or know any issue about this kind of feature?

thanks!

Bruno Ledesma


Rob Sonke wrote:
 
 Thijs and I debugged the code together this morning because when he read 
 this thread he was sure that both options (overriding setheaders and 
 onclick) should work. After some debugging we found a bug in Liferay 
 which could be easily fixed in our used version. The current (5.1.2) 
 version has a lot of changes around these properties, we will recheck 
 that once we're able to upgrade.
 
 Thanks for your help.
 
 Serkan Camurcuoglu wrote:
 In the PLT.12.1.1 section of jsr 286 it says:

 Response properties can be viewed as header values set for the portal
 application. If these header values are intended to be transmitted to the
 client they should be set before the response is committed. When setting
 headers in the render lifecycle phase portlets should set the header in
 the
 render headers part or simply override the GenericPortlet.doHeaders
 method
 (see PLT.11.1.1.4.3).

 I think you may try:

 PortletRequestContext ctx = (PortletRequestContext) RequestContext.get();
 PortletResponse presp = ctx.getPortletResponse();
 presp.addProperty(header, value);

 this is kind of a hack but it might work..




 Rob Sonke wrote:
   
 No, too bad. The headers aren't picked up.


 Serkan Camurcuoglu wrote:
 
 For the DynamicWebResource case, doesn't overriding setHeaders() in
 DynamicWebResource and adding your http header in this method work?

 By the way, which portlet container are you working with?




 Rob Sonke wrote:
   
   
 Hi,

 We're using wicket for our portlets now for almost 3/4 year and it's 
 great. We're following/try to help with the full implementation of jsr 
 286 in wicket too (Thijs and me, see other threads). But I'm having a 
 problem now with offering files through a portlet. There are actually 
 two options, use the resource phase of jsr286 or use a separate
 download 
 servlet. First option rocks, second option not (if option 1 won't
 work, 
 I'll have to deal with it but I prefer not).

 So I'm trying to serve a file through the portlet based on a wicket 
 link. A normal link would end up in a actionResponse which will not 
 allow you to touch the resourcestream (returning null as the portlet 
 specs describe). An ajax link (which uses the resource phase) will end 
 up with a lot of binary code in the ajax xml output which will, of 
 course, not work.

 I tried also adding a DynamicWebResource to a wicket ResourceLink,
 which 
 works actually pretty good except that he's not communicating the 
 filename to the brower by setting a header. I tried adding a header to 
 the ResourceResponse but that one was not passed to the client too 
 (maybe I did that wrong).

 Could anyone point me in the right direction or could tell me what I'm 
 doing wrong over here?

 Regards,
 Rob

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



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



 

   
 
 

-- 
View this message in context: 
http://www.nabble.com/Stream-download-files-through-portlet-tp19980617p23452007.html
Sent from the Wicket - User mailing list archive at Nabble.com.


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



Re: Stream/download files through portlet

2009-05-08 Thread Bruno Ledesma
Solved.

Its a Liferay issue.
http://issues.liferay.com/browse/LPS-1911

I was using portlet names and  filter-mapping with a - char.

 I have to use the same string value for the portlet name and the
filter-mapping stuff... without the - char, cause liferay (i dont have
idea why) removes this char, causing the problem.

sorry for the inconvenient question...

Bruno

2009/5/8 Bruno Ledesma led.br...@gmail.com


 Hello All!

 Im facing problems trying to  Stream/download files through portlet. I also
 used DynamicWebResource and a Resource link to serve the Resource Data. On
 a
 simple Wicket application everything works fine, but when my war is
 deployed
 as a portlet into a Liferay 5 instance, it doesnt work.

 The browser response is :  The requested resource
 (/wick-portlet-0.0.1-SNAPSHOT/wick-portlet/) is not available.

 Does anyone have some idea,or know any issue about this kind of feature?

 thanks!

 Bruno Ledesma


 Rob Sonke wrote:
 
  Thijs and I debugged the code together this morning because when he read
  this thread he was sure that both options (overriding setheaders and
  onclick) should work. After some debugging we found a bug in Liferay
  which could be easily fixed in our used version. The current (5.1.2)
  version has a lot of changes around these properties, we will recheck
  that once we're able to upgrade.
 
  Thanks for your help.
 
  Serkan Camurcuoglu wrote:
  In the PLT.12.1.1 section of jsr 286 it says:
 
  Response properties can be viewed as header values set for the portal
  application. If these header values are intended to be transmitted to
 the
  client they should be set before the response is committed. When setting
  headers in the render lifecycle phase portlets should set the header in
  the
  render headers part or simply override the GenericPortlet.doHeaders
  method
  (see PLT.11.1.1.4.3).
 
  I think you may try:
 
  PortletRequestContext ctx = (PortletRequestContext)
 RequestContext.get();
  PortletResponse presp = ctx.getPortletResponse();
  presp.addProperty(header, value);
 
  this is kind of a hack but it might work..
 
 
 
 
  Rob Sonke wrote:
 
  No, too bad. The headers aren't picked up.
 
 
  Serkan Camurcuoglu wrote:
 
  For the DynamicWebResource case, doesn't overriding setHeaders() in
  DynamicWebResource and adding your http header in this method work?
 
  By the way, which portlet container are you working with?
 
 
 
 
  Rob Sonke wrote:
 
 
  Hi,
 
  We're using wicket for our portlets now for almost 3/4 year and it's
  great. We're following/try to help with the full implementation of
 jsr
  286 in wicket too (Thijs and me, see other threads). But I'm having a
  problem now with offering files through a portlet. There are actually
  two options, use the resource phase of jsr286 or use a separate
  download
  servlet. First option rocks, second option not (if option 1 won't
  work,
  I'll have to deal with it but I prefer not).
 
  So I'm trying to serve a file through the portlet based on a wicket
  link. A normal link would end up in a actionResponse which will not
  allow you to touch the resourcestream (returning null as the portlet
  specs describe). An ajax link (which uses the resource phase) will
 end
  up with a lot of binary code in the ajax xml output which will, of
  course, not work.
 
  I tried also adding a DynamicWebResource to a wicket ResourceLink,
  which
  works actually pretty good except that he's not communicating the
  filename to the brower by setting a header. I tried adding a header
 to
  the ResourceResponse but that one was not passed to the client too
  (maybe I did that wrong).
 
  Could anyone point me in the right direction or could tell me what
 I'm
  doing wrong over here?
 
  Regards,
  Rob
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/Stream-download-files-through-portlet-tp19980617p23452007.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


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




Re: Stream/download files through portlet

2008-10-15 Thread Rob Sonke
Thijs and I debugged the code together this morning because when he read 
this thread he was sure that both options (overriding setheaders and 
onclick) should work. After some debugging we found a bug in Liferay 
which could be easily fixed in our used version. The current (5.1.2) 
version has a lot of changes around these properties, we will recheck 
that once we're able to upgrade.


Thanks for your help.

Serkan Camurcuoglu wrote:

In the PLT.12.1.1 section of jsr 286 it says:

Response properties can be viewed as header values set for the portal
application. If these header values are intended to be transmitted to the
client they should be set before the response is committed. When setting
headers in the render lifecycle phase portlets should set the header in the
render headers part or simply override the GenericPortlet.doHeaders method
(see PLT.11.1.1.4.3).

I think you may try:

PortletRequestContext ctx = (PortletRequestContext) RequestContext.get();
PortletResponse presp = ctx.getPortletResponse();
presp.addProperty(header, value);

this is kind of a hack but it might work..




Rob Sonke wrote:
  

No, too bad. The headers aren't picked up.


Serkan Camurcuoglu wrote:


For the DynamicWebResource case, doesn't overriding setHeaders() in
DynamicWebResource and adding your http header in this method work?

By the way, which portlet container are you working with?




Rob Sonke wrote:
  
  

Hi,

We're using wicket for our portlets now for almost 3/4 year and it's 
great. We're following/try to help with the full implementation of jsr 
286 in wicket too (Thijs and me, see other threads). But I'm having a 
problem now with offering files through a portlet. There are actually 
two options, use the resource phase of jsr286 or use a separate download 
servlet. First option rocks, second option not (if option 1 won't work, 
I'll have to deal with it but I prefer not).


So I'm trying to serve a file through the portlet based on a wicket 
link. A normal link would end up in a actionResponse which will not 
allow you to touch the resourcestream (returning null as the portlet 
specs describe). An ajax link (which uses the resource phase) will end 
up with a lot of binary code in the ajax xml output which will, of 
course, not work.


I tried also adding a DynamicWebResource to a wicket ResourceLink, which 
works actually pretty good except that he's not communicating the 
filename to the brower by setting a header. I tried adding a header to 
the ResourceResponse but that one was not passed to the client too 
(maybe I did that wrong).


Could anyone point me in the right direction or could tell me what I'm 
doing wrong over here?


Regards,
Rob

-
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: Stream/download files through portlet

2008-10-14 Thread Serkan Camurcuoglu

For the DynamicWebResource case, doesn't overriding setHeaders() in
DynamicWebResource and adding your http header in this method work?

By the way, which portlet container are you working with?




Rob Sonke wrote:
 
 Hi,
 
 We're using wicket for our portlets now for almost 3/4 year and it's 
 great. We're following/try to help with the full implementation of jsr 
 286 in wicket too (Thijs and me, see other threads). But I'm having a 
 problem now with offering files through a portlet. There are actually 
 two options, use the resource phase of jsr286 or use a separate download 
 servlet. First option rocks, second option not (if option 1 won't work, 
 I'll have to deal with it but I prefer not).
 
 So I'm trying to serve a file through the portlet based on a wicket 
 link. A normal link would end up in a actionResponse which will not 
 allow you to touch the resourcestream (returning null as the portlet 
 specs describe). An ajax link (which uses the resource phase) will end 
 up with a lot of binary code in the ajax xml output which will, of 
 course, not work.
 
 I tried also adding a DynamicWebResource to a wicket ResourceLink, which 
 works actually pretty good except that he's not communicating the 
 filename to the brower by setting a header. I tried adding a header to 
 the ResourceResponse but that one was not passed to the client too 
 (maybe I did that wrong).
 
 Could anyone point me in the right direction or could tell me what I'm 
 doing wrong over here?
 
 Regards,
 Rob
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Stream-download-files-through-portlet-tp19980617p19981070.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: Stream/download files through portlet

2008-10-14 Thread Rob Sonke
Thanks for your answer. I think overriding the setHeaders will end up 
with the same result as with adding the filename through the constructor 
of DynamicWebResource but I'll try it in some minutes.


We're using Liferay as the portal.

Rob


Serkan Camurcuoglu wrote:

For the DynamicWebResource case, doesn't overriding setHeaders() in
DynamicWebResource and adding your http header in this method work?

By the way, which portlet container are you working with?




Rob Sonke wrote:
  

Hi,

We're using wicket for our portlets now for almost 3/4 year and it's 
great. We're following/try to help with the full implementation of jsr 
286 in wicket too (Thijs and me, see other threads). But I'm having a 
problem now with offering files through a portlet. There are actually 
two options, use the resource phase of jsr286 or use a separate download 
servlet. First option rocks, second option not (if option 1 won't work, 
I'll have to deal with it but I prefer not).


So I'm trying to serve a file through the portlet based on a wicket 
link. A normal link would end up in a actionResponse which will not 
allow you to touch the resourcestream (returning null as the portlet 
specs describe). An ajax link (which uses the resource phase) will end 
up with a lot of binary code in the ajax xml output which will, of 
course, not work.


I tried also adding a DynamicWebResource to a wicket ResourceLink, which 
works actually pretty good except that he's not communicating the 
filename to the brower by setting a header. I tried adding a header to 
the ResourceResponse but that one was not passed to the client too 
(maybe I did that wrong).


Could anyone point me in the right direction or could tell me what I'm 
doing wrong over here?


Regards,
Rob

-
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: Stream/download files through portlet

2008-10-14 Thread Rob Sonke

No, too bad. The headers aren't picked up.


Serkan Camurcuoglu wrote:

For the DynamicWebResource case, doesn't overriding setHeaders() in
DynamicWebResource and adding your http header in this method work?

By the way, which portlet container are you working with?




Rob Sonke wrote:
  

Hi,

We're using wicket for our portlets now for almost 3/4 year and it's 
great. We're following/try to help with the full implementation of jsr 
286 in wicket too (Thijs and me, see other threads). But I'm having a 
problem now with offering files through a portlet. There are actually 
two options, use the resource phase of jsr286 or use a separate download 
servlet. First option rocks, second option not (if option 1 won't work, 
I'll have to deal with it but I prefer not).


So I'm trying to serve a file through the portlet based on a wicket 
link. A normal link would end up in a actionResponse which will not 
allow you to touch the resourcestream (returning null as the portlet 
specs describe). An ajax link (which uses the resource phase) will end 
up with a lot of binary code in the ajax xml output which will, of 
course, not work.


I tried also adding a DynamicWebResource to a wicket ResourceLink, which 
works actually pretty good except that he's not communicating the 
filename to the brower by setting a header. I tried adding a header to 
the ResourceResponse but that one was not passed to the client too 
(maybe I did that wrong).


Could anyone point me in the right direction or could tell me what I'm 
doing wrong over here?


Regards,
Rob

-
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: Stream/download files through portlet

2008-10-14 Thread Serkan Camurcuoglu

In the PLT.12.1.1 section of jsr 286 it says:

Response properties can be viewed as header values set for the portal
application. If these header values are intended to be transmitted to the
client they should be set before the response is committed. When setting
headers in the render lifecycle phase portlets should set the header in the
render headers part or simply override the GenericPortlet.doHeaders method
(see PLT.11.1.1.4.3).

I think you may try:

PortletRequestContext ctx = (PortletRequestContext) RequestContext.get();
PortletResponse presp = ctx.getPortletResponse();
presp.addProperty(header, value);

this is kind of a hack but it might work..




Rob Sonke wrote:
 
 No, too bad. The headers aren't picked up.
 
 
 Serkan Camurcuoglu wrote:
 For the DynamicWebResource case, doesn't overriding setHeaders() in
 DynamicWebResource and adding your http header in this method work?

 By the way, which portlet container are you working with?




 Rob Sonke wrote:
   
 Hi,

 We're using wicket for our portlets now for almost 3/4 year and it's 
 great. We're following/try to help with the full implementation of jsr 
 286 in wicket too (Thijs and me, see other threads). But I'm having a 
 problem now with offering files through a portlet. There are actually 
 two options, use the resource phase of jsr286 or use a separate download 
 servlet. First option rocks, second option not (if option 1 won't work, 
 I'll have to deal with it but I prefer not).

 So I'm trying to serve a file through the portlet based on a wicket 
 link. A normal link would end up in a actionResponse which will not 
 allow you to touch the resourcestream (returning null as the portlet 
 specs describe). An ajax link (which uses the resource phase) will end 
 up with a lot of binary code in the ajax xml output which will, of 
 course, not work.

 I tried also adding a DynamicWebResource to a wicket ResourceLink, which 
 works actually pretty good except that he's not communicating the 
 filename to the brower by setting a header. I tried adding a header to 
 the ResourceResponse but that one was not passed to the client too 
 (maybe I did that wrong).

 Could anyone point me in the right direction or could tell me what I'm 
 doing wrong over here?

 Regards,
 Rob

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



 

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

-- 
View this message in context: 
http://www.nabble.com/Stream-download-files-through-portlet-tp19980617p19981860.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: Stream/download files through portlet

2008-10-14 Thread Rob Sonke
Awesome! I was pretty sure that I tried that too but probably not in 
combination with other changes. I have overridden the onclick like this:


ResourceLink link = new ResourceLink(downloadLink, resource)
   {
 /* (non-Javadoc)
  * @see org.apache.wicket.markup.html.link.ResourceLink#onClick()
  */
 @Override
 public void onClick()
 {
   super.onClick();
   PortletRequestContext ctx = (PortletRequestContext) 
RequestContext.get();

   PortletResponse presp = ctx.getPortletResponse();
   presp.addProperty(Content-Disposition, 
String.format(attachment; filename=\%s\, boe.doc));

 }
   };

Thanks, that made my day :)

Rob


Serkan Camurcuoglu wrote:

In the PLT.12.1.1 section of jsr 286 it says:

Response properties can be viewed as header values set for the portal
application. If these header values are intended to be transmitted to the
client they should be set before the response is committed. When setting
headers in the render lifecycle phase portlets should set the header in the
render headers part or simply override the GenericPortlet.doHeaders method
(see PLT.11.1.1.4.3).

I think you may try:

PortletRequestContext ctx = (PortletRequestContext) RequestContext.get();
PortletResponse presp = ctx.getPortletResponse();
presp.addProperty(header, value);

this is kind of a hack but it might work..




Rob Sonke wrote:
  

No, too bad. The headers aren't picked up.


Serkan Camurcuoglu wrote:


For the DynamicWebResource case, doesn't overriding setHeaders() in
DynamicWebResource and adding your http header in this method work?

By the way, which portlet container are you working with?




Rob Sonke wrote:
  
  

Hi,

We're using wicket for our portlets now for almost 3/4 year and it's 
great. We're following/try to help with the full implementation of jsr 
286 in wicket too (Thijs and me, see other threads). But I'm having a 
problem now with offering files through a portlet. There are actually 
two options, use the resource phase of jsr286 or use a separate download 
servlet. First option rocks, second option not (if option 1 won't work, 
I'll have to deal with it but I prefer not).


So I'm trying to serve a file through the portlet based on a wicket 
link. A normal link would end up in a actionResponse which will not 
allow you to touch the resourcestream (returning null as the portlet 
specs describe). An ajax link (which uses the resource phase) will end 
up with a lot of binary code in the ajax xml output which will, of 
course, not work.


I tried also adding a DynamicWebResource to a wicket ResourceLink, which 
works actually pretty good except that he's not communicating the 
filename to the brower by setting a header. I tried adding a header to 
the ResourceResponse but that one was not passed to the client too 
(maybe I did that wrong).


Could anyone point me in the right direction or could tell me what I'm 
doing wrong over here?


Regards,
Rob

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



Stream/download files through portlet

2008-10-14 Thread Rob Sonke

Hi,

We're using wicket for our portlets now for almost 3/4 year and it's 
great. We're following/try to help with the full implementation of jsr 
286 in wicket too (Thijs and me, see other threads). But I'm having a 
problem now with offering files through a portlet. There are actually 
two options, use the resource phase of jsr286 or use a separate download 
servlet. First option rocks, second option not (if option 1 won't work, 
I'll have to deal with it but I prefer not).


So I'm trying to serve a file through the portlet based on a wicket 
link. A normal link would end up in a actionResponse which will not 
allow you to touch the resourcestream (returning null as the portlet 
specs describe). An ajax link (which uses the resource phase) will end 
up with a lot of binary code in the ajax xml output which will, of 
course, not work.


I tried also adding a DynamicWebResource to a wicket ResourceLink, which 
works actually pretty good except that he's not communicating the 
filename to the brower by setting a header. I tried adding a header to 
the ResourceResponse but that one was not passed to the client too 
(maybe I did that wrong).


Could anyone point me in the right direction or could tell me what I'm 
doing wrong over here?


Regards,
Rob

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