Spam detection software, running on the system "azul3.aguilardelgado.com", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  Hi Rob, Yep, of course is more beautiful!!! :D But I did not
   know that you can cast a PortletResponse to an action response... [...] 

Content analysis details:   (5.5 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.5 RCVD_IN_PBL            RBL: Received via a relay in Spamhaus PBL
                            [87.223.212.129 listed in zen.spamhaus.org]
 1.6 RCVD_IN_SORBS_DUL      RBL: SORBS: sent directly from dynamic IP address
                            [87.223.212.129 listed in dnsbl.sorbs.net]
 1.0 EXTRA_MPART_TYPE       Header has extraneous Content-type:...type= entry
 2.3 DATE_IN_PAST_96_XX     Date: is 96 hours or more before Received: date
 0.0 HTML_MESSAGE           BODY: HTML included in message
 0.1 RDNS_DYNAMIC           Delivered to trusted network by host with
                            dynamic-looking rDNS
 0.0 DYN_RDNS_AND_INLINE_IMAGE Contains image, and was sent by dynamic
                            rDNS

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.

--- Begin Message ---
Hi Rob, 

Yep, of course is more beautiful!!! :D

But I did not know that you can cast a PortletResponse to an action
response...

It should not be the same. I'm a little bit confused about  the big
number of XXXResponse object going around...

Thank you for the suggestion. I will change my code...

:D




El vie, 14-08-2009 a las 07:13 +0200, Rob Sonke escribió:

> It's up to you but I think there is a more beautiful/easier way. Just 
> configure the public render params the same in the portlet.xml. Use this 
> to set params in e.g. an onClick:
> 
> ActionResponse actionResponse = (ActionResponse) 
> ((PortletRequestContext)PortletRequestContext.get()).getPortletResponse();
> actionResponse.setRenderParameter(name.getValue(), value);
> 
> And this to retrieve a parameter anywhere:
> PortletRequestContext prc = (PortletRequestContext)RequestContext.get();
> Map<String, String[]> map = prc.getPortletRequest().getPublicParameterMap();
> map.get(name.getValue());
> 
> But that's up to you :)
> 
> Rob
> 
> On 8/14/09 1:50 AM, Gonzalo Aguilar Delgado wrote:
> > Hi all!
> >
> > I managed to do it with wicket 1.4. This is how:
> >
> > Define it in portlet.xml
> >
> > <portlet-app>
> > ...
> > <public-render-parameter>
> >          <identifier>crmportal:userId</identifier>
> >          <qname
> > xmlns:x="http://www.level2crm.com/params";>x:userId</qname>
> > </public-render-parameter>
> > </portlet-app>
> >
> > Every portlet that will use it must also be configured with:
> > <portlet>
> > ...
> > <supported-public-render-parameter>crmportal:userId</supported-public-render-parameter>
> > </portlet>
> >
> > After doing this the portlet must have access to this parameter. But as
> > I have not access from Page processing to the
> > Wicket Portlet class I should hold the variable in session for a while:
> >
> >                                  Link link = new Link("id", new
> > PropertyModel<String>(userObject, "uuid.uuid"))
> >                             {
> >                                     @Override
> >                                     public void onClick()
> >                                     {
> >                                     
> >                                             UUID uuid =  (UUID) 
> > this.getModelObject();
> >                                             
> >                                             PortletSession session =
> > ((PortletRequestContext)RequestContext.get()).getPortletRequest()
> >                                                     .getPortletSession();
> >                                             
> > session.setAttribute(CustomerListPortlet.CURRENT_UUID,
> > uuid.toString());
> >                                     }
> >                             };
> >
> >
> > And after in the function processActionResponseState we can set the
> > public parameter after we recover it from session.
> >
> >     @Override
> >     protected void processActionResponseState(String wicketURL,
> >                     String wicketFilterPath, String wicketFilterQuery,
> >                     PortletRequest request, ActionResponse response,
> >                     WicketResponseState responseState) throws 
> > PortletException,
> >                     IOException {
> >             
> >             PortletSession session = request.getPortletSession();
> >             String uuid = (String)session.getAttribute(CURRENT_UUID);
> >             if(uuid!=null)
> >             {
> >                     response.setRenderParameter("crmportal:userId", uuid);
> >             }
> >             
> >             // TODO Auto-generated method stub
> >             super.processActionResponseState(wicketURL, wicketFilterPath,
> >                             wicketFilterQuery, request, response, 
> > responseState);
> >     }
> >
> >
> >
> > The other portlets will see this public render parameter as normal
> > parameter (NOTE: I don't know why not differentiate from the rest of
> > parameters. Can it have security considerations?).
> >
> > This is accessible directly in the page (This is other portlet and other
> > application inside the portal):
> >     IModel loadableUserModel = new LoadableDetachableModel() {
> >             
> >             @Override
> >             protected Object load(){
> >                     User selectedUser = null;
> >                     String value =
> > ((PortletRequestContext)RequestContext.get()).getPortletRequest().getParameter("crmportal:userId");
> >                     if(value!=null)
> >                     {
> >                             UuidUserType uuid = 
> > UuidUserType.fromString(value);
> >                             selectedUser = userDAO.find(uuid);
> >                             
> >                             if(!userDAO.isAttached(selectedUser))
> >                             {
> >                                     userDAO.save(selectedUser); //Attach it
> >                             }
> >                             
> >                             Set<ContactBasicDetail>  setDetails =
> > selectedUser.getContactBasicDetails();
> >                             setDetails.isEmpty();
> >                             
> >                             return setDetails.toArray();
> >                     }
> >                     return null;
> >             }
> >             
> >             
> >     };
> >
> >
> > It seems to work right.
> >
> > But means are subject of discussion...
> >
> > Tnx
> >
> >
> > El jue, 13-08-2009 a las 13:43 +0200, Gonzalo Aguilar Delgado escribió:
> >
> >    
> >> Hi all!,
> >>
> >> I have some questions about parameter passing in portal environment. I
> >> saw that WebPage class can have access to the Application class
> >> but not the portlet class. This makes a little tricky to handle requests
> >> because:
> >>
> >> We can set session paramaters. And can call functions inside Application
> >> (WicketExamplesMenuApplication.getExamples()).
> >>
> >> @Override
> >> public void onClick()
> >> {
> >>    int index = ((LoopItem)getParent()).getIteration();
> >>    ExampleApplication ea =
> >> WicketExamplesMenuApplication.getExamples().get(
> >>            index + 1);
> >>    PortletSession session =
> >> ((PortletRequestContext)RequestContext.get()).getPortletRequest()
> >>            .getPortletSession();
> >>
> >> session.setAttribute(WicketExamplesMenuPortlet.EXAMPLE_APPLICATION_ATTR,
> >> ea);
> >> }
> >>
> >> But it will be the portlet class the responsible for handling
> >> processing. So the only way to pass information from the onClick
> >> function to the
> >> portlet application for rendering (for example) is using the portlet
> >> session.
> >>
> >> But I suppose that's not the preferred way.
> >>
> >>
> >> What's the best way to pass information to the portlet class? Is there
> >> any way to use the portlet class like we use the application class
> >> (WicketExamplesMenuApplication.getExamples() ->
> >> WicketExamplesMenuPortlet.getExamples())
> >>
> >>
> >> I also saw that in the portlet example, the examples structure is
> >> initialized by the WicketExamplesMenuPortlet and sent to the
> >> WicketExamplesMenuApplication using the servlet context. But this will
> >> overbloat the servlet attributes storage space. Also this should be
> >> solved if webpages could access to the portlet class directly.
> >>
> >> Why to do this way?
> >>
> >>
> >>
> >> I want to know all this because I want to use shared render parameters
> >> (I put there a user id and all the portlets update accordingly). To do
> >> this I will do:
> >>
> >>
> >>
> >>          1.- Onclick: Put the Id on the session like above.
> >>          2.- Portlet.DoView: Recover id from session and store it in
> >>          shared render params.
> >>          3.- Delete it from session.
> >>
> >>
> >> Is this the correct way to do it?
> >>
> >>
> >> Thank you very much in advance...
> >>
> >>
> >>      
> >    
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org

<<attachment: face-smile-big.png>>


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

Reply via email to