jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric W Hauser <ehau...@indiana.edu>
Subject Re: Plugging in Implicit Objects
Date Wed, 21 Jan 2004 23:44:18 GMT
If you use a <portlet:defineObjects/> tag, basically what you are doing is
telling the container to make those objects available to the page context
of the page.  This solves the problem of having to find exactly where
those objects are being stored.  For instance, the HttpServletRequest
could be holding the RenderRequests for multiple portlets.  The
implementation of that tag is container specific.  However, this still
doesn't solve the problem of making these attributes available to EL.  To
access the attributes of these objects using EL, you still need to make a
object available that stores the attributes in a Collection.  

If a <tag:defineObjects/> is the best way to do this, than that is the
way I'll go.  However, I still have concerns about using this approach.
If I use a custom tag to define this objects, then I may be creating a lot
of objects that never get used.  Say my tag creates three Map's 
(e.g portletRequest, portletSession, and portletApplication) that contain
all the attributes stored in this objects.  I would then be able to easily
access them using EL.  So, I every JSP page I would use
<tag:defineObjects/> to create these maps.  If I only use portletSession,
then I basically created two other Map's for no reason. I can't remember
the exact class off the top of my head but when I was looking at the
standard source yesterday, it seemed like these Map's were only being
created when an expression was being evaluated.  That approach seemed to
not create any unnecessary objects.  That was why I was trying to decide
whether or not to package my own version of the standard tag libraries
that created the extra implicit objects.  Thanks for the input.

On Wed, 21 Jan 2004, Kris Schneider wrote:

> Back to the tag approach for a second. It looks like the Portlet Spec mandates
> the existence of the "portlet tag library". If you do something like:
> <%@ taglib prefix="portlet" uri="http://java.sun.com/portlet" %>
> <portlet:defineObjects/>
> Then you get:
> renderRequest:  RenderRequest (extends PortletRequest)
> renderResponse: RenderResponse (extends PortletResponse)
> portletConfig:  PortletConfig
> Does that help any? BTW, the <taglib:defineObjects/> action is the recommended
> style for defining new implicit objects.
> Quoting Kris Schneider <kris@dotech.com>:
> > I'm not that familiar with the portlet spec, but I assume a filter could also
> > be
> > used to create your attribute maps. No tags needed and the filter can apply
> > to
> > every request so it's not tied to JSP.
> > 
> > Quoting Eric W Hauser <ehauser@indiana.edu>:
> > 
> > > I've got some portlet projects coming up, and the one thing the bothers
> > me
> > > is that fact that EL expressions in JSPs are not easy to use.  A quick
> > > background of the problem: Each portlet has its own PortletRequest,
> > > PortletSession, and PortletContext objects which are just extensions of
> > > HttpServletRequest, HttpSession, and ServletContext objects.  Accessing 
> > > these objects from a JSP using requires a container specific tag that
> > > makes them available in the page context.  I would like to be able to
> > > access them using EL expressions.
> > > 
> > > I've been trying to come up with a workaround and came up with a couple
> > of
> > > solutions.  First, I could just define a tag (i.e.
> > > <p:initPortletObjects/>) that would just make the attributes of these
> > > objects available in a Map that is stored in the PageContext.  Then, they
> > > called be accessed by ${pageScope.portletRequest.attribute}.  However,
> > the
> > > downside to doing this is that I would have to run this tag on every page
> > > and it would be creating objects that may not get used.  My other option
> > > was to build my own version of the tag libraries and add these as
> > > implicit objects so that they could be resolved by the expression
> > > evaluator.  
> > > 
> > > I was thinking that there should be an easier way to accomplish this, but
> > > the spec doesn't define a way to plugin implicit objects.  I'm
> > > sure there would be other instances were this could be useful.  Just
> > > wondering if any had any thoughts/suggestions.
> > > 
> > > -------------------
> > > Eric Hauser
> > > ehauser@indiana.edu
> > 
> > -- 
> > Kris Schneider <mailto:kris@dotech.com>
> > D.O.Tech       <http://www.dotech.com/>
> -- 
> Kris Schneider <mailto:kris@dotech.com>
> D.O.Tech       <http://www.dotech.com/>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org

Eric Hauser
(317) 679-4766

To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org

View raw message