You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Eric W Hauser <eh...@indiana.edu> on 2004/01/21 15:15:26 UTC

Plugging in Implicit Objects

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


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


Re: Plugging in Implicit Objects

Posted by Eric W Hauser <eh...@indiana.edu>.
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 <kr...@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 <eh...@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 <ma...@dotech.com>
> > D.O.Tech       <http://www.dotech.com/>
> 
> -- 
> Kris Schneider <ma...@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
ehauser@indiana.edu
(317) 679-4766


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


Re: Plugging in Implicit Objects

Posted by Kris Schneider <kr...@dotech.com>.
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 <kr...@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 <eh...@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 <ma...@dotech.com>
> D.O.Tech       <http://www.dotech.com/>

-- 
Kris Schneider <ma...@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


Re: Plugging in Implicit Objects

Posted by Kris Schneider <kr...@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 <eh...@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 <ma...@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


Re: Plugging in Implicit Objects

Posted by Peter Lin <tc...@yahoo.com>.
 
before you go any further, you should seriously consider if you want to use tomcat5 or 4. the reason I say this is because tomcat 5 supports the latest spec, which uses commons-el, which is the follow up to the original EL in JSTL.
 
By buidling your tags for tomcat5, you can get EL automatically. You also get new things like file tags and other features.
 
tomcat 5 also has a new jasper plugin feature, which allows you to parse and process a page before jasper compiles it. in essense it allows you to convert tags to pure java, resolve objects or strip extra carriage returns.
 
peter lin


Eric W Hauser <eh...@indiana.edu> wrote:
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.


) 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


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


---------------------------------
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes