Yeah, JSR-301 is really the first spec to consider JSF and Portlet in
detail. It, of course, is dependent on JSF 1.2 (for a bunch of
reasons). Still, this is not really a JSF issue I don't think (unless
the 1.1 MyFaces bridge has a bug somewhere, but I'm skeptical).
I'm not familiar with JBoss Portal's header framework, but I can only
assume that it's a way to put a portlet somewhere in the portal's header
rather then in the main content region. The issue here is that any
ActionUrl you create will reference the header instance unless they also
provide you some mechanism for a specific portlet instance.
If they do have the latter mechanism, you basically need to either
"post" to the portlet you want to reflect your results (meaning it
needs to be on the current page already, or you will have to create a
new ActionUrl which references your portlet instance, append your
parameters to that which you need the portlet to recieve, and then do a
redirect with that URL. Does this make sense?
Scott
souravm wrote:
Thanks Scott for your suggestion.
I know I'm struggling to find a solution which involves 2 specs JSF and Portlet
(most probably the 2 most complicated one today in J2EE world).
Let me explain you a bit on the origin of this requirements.
The Portal application we are developing needs to have a search box in header.
That Search box needs to appear in every page at the top right corner where
user will enter a search criterion. And the result of the search needs to be
displayed in the main content window of the Portal
Now creating this Search Box using a Portlet does not make sense as that will
make the portal layout very complicated. So we use the Jboss Portal's header
framework to create this search box. And as a submission of the search request
we try to initiate a portlet.
So that's being the case -
1. The JSF Portlet being still called within the Portal Framework with encoded
URL.
2. The request is still a Post request (form submit happens from the Search Box
form).
Considering this situation any further suggestion is really appreciated.
Regards,
Sourav
-----Original Message-----
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 8:48 AM
To: MyFaces Discussion
Subject: Re: Calling a Myfaces Portlet from a non-JSF request ..
One more thing, this has nothing to do with JSF. It's has to do with
trying to call a portlet from outside of a Portal. :) It is possible the
JBOSS portal has an off-spec proprietary way to pass parameters into a
portlet, but you'll have to take it up with them.
souravm wrote:
Hi All,
I've a MyFaces (1.1.4) Portlet deployed in jboss portal server.
First time I need to access this portlet from a non-JSF (jsp) page
which sends a http post request with some request parameters.
The solution does not work when the request does not have any request
parameter (works fine when accessed by a request with no request
parameter).
When I try to read the request parameter(s) in the constructor of the
managed bean they come as null.
I tried extending the processAction() method of MyFacesGenericPortlet.
I read the request parameters from the ActionRequest and set them in
RenderRequest using setRenderParameter (This anyway one has to do for
a jsp based portlet implementation). With this approach I can read the
request parameters in the constructor of the managed bean.
I would like to validate whether this is a known limitation of
MyFacesGenericPortlet and the solution approach mentioned above is
right one (or any other approach is recommended) ?
Any help in this regard would be highly appreciated.
Sourav
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
solely for the use of the addressee(s). If you are not the intended
recipient, please notify the sender by e-mail and delete the original
message. Further, you are not to copy, disclose, or distribute this
e-mail or its contents to any other person and any such actions are
unlawful. This e-mail may contain viruses. Infosys has taken every
reasonable precaution to minimize this risk, but is not liable for any
damage you may sustain as a result of any virus in this e-mail. You
should carry out your own virus checks before opening the e-mail or
attachment. Infosys reserves the right to monitor and review the
content of all messages sent to or from this e-mail address. Messages
sent to or from this e-mail address may be stored on the Infosys
e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
