One thing you can do is use the servlet session since values stored
their should be accessible by your portlets in the
PortletSession.APPLICATION_SCOPE.

Keep in mind though that there are things you can only accomplish in
processAction like window and mode changes as well as setting render
parameters etc.

Up to now, I have mainly been using AJAX to minimize the number of
page loads needed by fetching data for dynamic selects or data lookups
as the result of some user selection.

I have been doing some thinking about this since we will soon want to
make our portlet apps rarely require page loads by using more AJAX
calls to invoke the business logic.

The latest Jetspeed provides an AJAX API for invoking render and
action requests via javascript.  Jetspeed also provides a pipeline so
that one can access a portlet directly via some URL rather than by a
portal page.

While these functions are proprietary, I would bet that at some point,
all J2EE portal vendors will have to provide similar functionality.

My plan is to create a simple adapter interface and an implementation
for Jetspeed that will compartmentalize all of these proprietary
portal functions and then when/if I ever need to move portals, then
I'd look at implementing a new adapter for the target portal.  I'm
going to try to get away from using helper servlets as much as
possible in favour of this new strategy.

That being said, if platform neutrality and adhering strictly to the
spec is very important to you, then you'll want to explore other
alternatives.

I have not read the Portlet Spec 2.0, but their may also be hints
there as to what strategy to adopt.

-aaron

On 11/12/06, Team Vit <[EMAIL PROTECTED]> wrote:
thank you very much Mr Donaghy and Mr Evans, for your quick response.
I am trying out the methods you sugested and it seems to works.

As you seem to have worked on AJAX portlets before using the same concept of
portlet+ Servlet.

How do you manage a change of state of the portlet??

Basically what i mean to say is that i am not using the processaction Method
at all.
instead using the DoView and DoEdit methods just to send in the baseline JSP
and then delegate all the business logic to the servlet.
So in short the protlet acctually act like just a container for my servlet
with
no state being managed by it.

Is this the right method or is there something more elegant

Thanks,
Team Vit

On 11/12/06, Aaron Evans <[EMAIL PROTECTED]> wrote:
>
> Yeah, I was about to say, use tomcat SSO and then the getUserPrincipal
> and isUserInRole servlet API calls will work.
>
> I use this technique extensively for retrieving data and content via
> AJAX for my portlets.
>
>
>
>
> On 11/12/06, Philip Mark Donaghy <[EMAIL PROTECTED]> wrote:
> > Hi Team,
> >
> > On 11/12/06, Team Vit <[EMAIL PROTECTED]> wrote:
> > > Hi everybody,
> > >
> > > I have a question... If i wanted to make a "pure JSR 168 portlet" and
> use
> > > ajax within it
> > > then is it true that the only option i have is to make the ajax calls
> to a
> > > servlet ???
> >
> > I guess this would be a standard j2ee solution. Though you'll probably
> > have different security configurations for each j2ee vendors. This
> > post from Aaron explains how to set up a shared tomcat realm to
> > validate users across webapp contexts running on on the same tomcat
> > server.
> >
> >
> http://www.mail-archive.com/[email protected]/msg04829.html
> >
> > >
> > > if that is the case , how would i validate the user making the
> > > calll..whether he has logged in to the portal
> > > and what role he is in ...etc..basically all related information to
> the
> > > user.
> >
> > Just add a security-constraint to the web.xml and specify the jetspeed
> > role required to access the servlet.
> >
> >           <security-constraint>
> >             <web-resource-collection>
> >               <web-resource-name>NOC</web-resource-name>
> >               <url-pattern>/*</url-pattern>
> >             </web-resource-collection>
> >             <auth-constraint>
> >               <!-- NOTE:  This role is not present in the default
> > users file -->              <role-name>operations</role-name>
> >             </auth-constraint>
> >           </security-constraint>
> >
> >           <!-- Define the Login Configuration for this Application -->
> >           <login-config>
> >             <auth-method>BASIC</auth-method>
> >             <realm-name>Jetspeed</realm-name>
> >           </login-config>
> >
> >           <!-- Security roles referenced by this web application -->
> >           <security-role>
> >             <description>
> >               The role that is required to log in to the Manager
> Application
> >             </description>
> >             <role-name>manager</role-name>
> >           </security-role>
> >
> > Using tomcat-sso users with the j2 role manager (or whatever you
> > specify) will be able to access the servlet or any resource(see
> > role-name tag) in the web app. The /* means everything in the web app.
> > The realm name Jetspeed needs to be specified in the server.xml as
> > described in the other thread.
> >
> > Phil
> >
> > >
> > > as of now i am setting using the portlet session to pass info between
> the
> > > servlet n portlet..is there a more elegant solution?
> > >
> > > I am really new to J2EE  so please excuse me if this a really stupid
> > > question....and point me to the right documentation..
> > >
> > > thanks
> > >
> > > Team VIT
> > >
> > >
> >
> >
> > --
> > Philip Donaghy
> > donaghy.blogspot.com del.icio.us/donaghy/philip
> > Skype: philipmarkdonaghy
> > Office: +33 5 56 60 88 02
> > Mobile: +33 6 20 83 22 62
> >
> > ---------------------------------------------------------------------
> > 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]

Reply via email to