double EL evaluating
i've searched the archives, but have been unable to find an answer to this, other than a question shawn made about wanting a real-world case for it. i think i might have one, and i'm not sure how to proceed, so i'll see what y'all think.
the situation is that i have an 'imported' page that displays a menu, but the options in the menu change depending on what page imports it. i achieve this by sending different parameters to the imported page, and then the imported page goes from there. one of the parameters passed in are parent_objectName, which, for example, can contain 'Product' or 'Service'. what i want to do is this:
c:if test${not empty param.typeID}
c:set var=${param.parent_objectName}_typeID value=${param.typeID}/
/c:if
then later:
c:out value=${${parent_objectName}_typeID}/
this would store an attribute named either Product_typeID or Service_typeID that could then be used elsewhere in the page.
unfortunately, the problems are plenty. it seems c:set.var isn't EL enabled (there is nothing set by the name of Service_typeID for example) and one can't 'double evaluate' in the c:out.value attribute.
the only way i can see of doing this now, is to create a custom tag that performs the magic, which might make sense for me in this case anyway, but i'd thought i'd throw this into the pit to be picked apart.
cheers,
--
CraigL-Thx();
Be Developer ID: 5852
signature.asc
Description: This is a digitally signed message part
different EVAL_BODY_XXX return types
i having some complicated problems in the doEndTag() processing that are primarily related to the bodyContent member. according to the javadocs, if EVAL_BODY_INCLUDE is returned, setBodyContent() and doInitBody() are not invoked. the upshot of this is that the bodyContent member variable is potentially not configured for each tag invocation. the place that this seems to hurt me, is when i'm using a tag that can return different responses to the doStartTag() method, sometimes i want to have it simply processed 'inline' with INCLUDE, sometimes i need to buffer it and process it differently at the end. the reason i'm doing this, is i assume it is more efficient to simply have the contents processed with EVAL_BODY_INCLUDE. i think it is streamed back to the client as available, right? if its buffered, then nothing can go back until the entire tag is finished (because it isn't available until the doEndTag() writes it out). the problem i was having, now that i've figured it out, is that the bodyContent member was not being set if the EVAL_BODY_INCLUDE value was used. normally, this is ok, i check for bodyContent==null in doEndTag(). but sometimes the tag appeared twice in one page, and it was returning EVAL_BODY_BUFFERED the first time, then EVAL_BODY_INCLUDE the second time, and then the bodyContent was not reset, which was causing problems (duplicate output, the contents of the first tag body would be written again). question time... 1) is this resetting of bodyContent the responsibility of the implementing tag? seeing as the return from doStartTag() doesn't seem to be included in the AttrSet that decides if a tag can be reused or not, i guess it is? (the BodyTagSupport.doStartTag(), but it returns EVAL_BODY_BUFFERED by default so it can assume that setBodyContent() is called) 2) is the goal of using EVAL_BODY_INCLUDE when possible an admirable one? considering that the included body _might_ be very big, i think it is, but i'd like confirmation. 3) is returning different values from doStartTag() a stupid/dangerous/illegal thing to do? this seems awfully confusing now that i read it over, hopefully it is manageable, if i need to clarify anything just lemme know. -- CraigL-Thx(); Be Developer ID: 5852 signature.asc Description: This is a digitally signed message part
Re: c:import
On Tue, 2002-09-17 at 20:52, Shawn Bayern wrote:
On 17 Sep 2002, Craig Longman wrote:
when you include a file via c:insert that actually maps to another
servlet, it appears that the request object (in tomcat 4.1.10 at
least) doesn't reflect any of the actual request being delivered.
i'm a little confused as to what i can do now.
Unless I'm misunderstanding your question, this sounds like the right
behavior. The relevant specification is actually the Servlet
specification (section SRV.8.2), though see JSTL 1.0 section 7.4 for the
specification of c:import.
hm. i only had the jstl and jsp specs. thanks, i'll try and find the
servlet spec.
however, when this url is invoked via a c:import url=/mapper/file,
all of the information retrievable via the request object refer to the
'wrapping' request, to the jsp page contains the c:import. the
parameters passed are available, but don't show up in the query string
(because the query string is for the containing jsp page).
I don't see any query string in the example; did you mean to write
/mapper?file-to-get? I'm not sure, from your description, what is being
lost.
If you need to pass parameters directly, you can use the c:param tag as
a subtag of c:import. Otherwise, I think I'd need a little more
information to help.
the parameters i refer to are, in fact, passed via c:param. so, the
relevant jsp file portion looks like:
c:import url=/mapper/testfile
c:param name=name1 value=${lookup1}/
/c:import
in the mapper servlet, i can do a request.getParameter( name1 ) and
get whatever value lookup1 contained. but if i do a
request.getQueryString(), it returns blank. also, i have no way of
extracting the 'testfile' information, it is simply lost; a call to
request.getRequestURI(), .getRequestURL() and .getServletPath() will
return references to the calling page (debug.jsp in this case). i guess
i could just turn the filename into a parameter also.
it just a bit disconcerting, i'm going to have to be very careful about
calling existing servlets as they will quite possibly break as well as
handling (possibly special handling) of cases where a servlet is called
either directly or imported. this might not be the case with a
cross-context servlet, and probably not the case with an absolute url,
i'll have to test. but then there is extra overhead in using those
types of connections also.
thanks.
--
CraigL-Thx();
Be Developer ID: 5852
signature.asc
Description: This is a digitally signed message part
TagSupport.xxxValue()
i'm confused about something, and no amount of searching has been able to help me, and the javadocs are a bit vague. the set/get/removeValue() methods in the TagSupport class. what are they setting, getting and removing? not the actual properties (as handled by the getXXX()/setXXX() methods), right? this is just some map of key/values for something else? if so, then what were the intentions for this, somewhere to store stuff between invocations? the methods are marked public, so it seems like they have an external purpose, but i'm just not seeing it. thanks! -- CraigL-Thx(); Be Developer ID: 5852 signature.asc Description: This is a digitally signed message part
Re: flow control and conditional logic
On Fri, 2002-09-13 at 04:38, Xavier Prélat wrote:
Hi,
I want to create a dynamic select box using JSTL core and xml tags.
// setting a variable called 'selector'
c:set var=selector%= strAction %/c:set
// displaying select box...all html tags are not represented...it's not my
mistake ;-)
x:forEach select=$xmlMenu/modules/module var=mod
x:if select=$mod/module-load-status = '${selector}'
x:if select=$mod/module-load-status == '${selector}'
notice the '==' as equality check, not '=' as assignment. i'm pretty
sure that a (at least one) problem.
option value=x:out select=$mod/@id/nbsp;x:out
select=$mod/@name//option
/x:when
/x:forEach
This problem is that I can't get a value for ${selector} in the line :
x:if select=$mod/module-load-status = '${selector}'
Any ideasI am getting a bit confused about the way to access variables
from these tags!
Xavier
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
CraigL-Thx();
Be Developer ID: 5852
signature.asc
Description: This is a digitally signed message part
incorporating EL support
hi there,
i'm just starting out with jsp/taglibs, and have decided to focus on
using the jstl as the basis for my efforts. it seems to provide exactly
what i needed, some basic, compatible tags to get started.
it is clear, however, that i'm going to have to write my own tags to get
any serious work done.
my question is this, i figure that if i'm going to standardize on the
jstl, then it only makes sense to standardize on the EL stuff also, i
prefer its style to the scriplet thingies, and its less typing. but,
i'm wondering what the preferred/recommended method is for doing this.
i see in the src dist for the reference jstl that there are a couple of
classes that look promising to use. one is an interface
(ExpressionEvaluator) and then an implementing class
(ExpressionEvaluatorManager). using it appears to be as simple as this
(from tag/el/core/ForEachTag.java):
if( begin_ != null )
{
Object r = ExpressionEvaluatorManager.evaluate(
begin, begin_, Integer.class, this, pageContext );
if (r == null)
{
throw new NullAttributeException(forEach, begin);
}
begin = ((Integer) r).intValue();
validateBegin();
}
it is acceptable to utilize this class in this manner for custom tags?
or is there a better/standard way. i have been unable to find any docs
that talk about using the standard EL in your own tags, but if anyone
has any pointers, i would greatly appreciate it.
thanks,
--
CraigL-Thx();
Be Developer ID: 5852
signature.asc
Description: This is a digitally signed message part
RE: PageContext is always null with taglibs
On Thu, 2002-09-12 at 19:59, Byrne Reese wrote:
So I actually only enclosed a code snippet... I did several variations
while unit testing - and even tried to implement a simple HelloWorld
TagSupport class... but with no luck. :(
one other thing that might cause this, is if you override the existing
setPageContext() method, and forget to call super.setPageContext() from
there, then the protected pageContext member won't be set. sounds like
you did a simple servlet though and are still seeing this.
if you haven't done this yet, try _overriding_ the setPageContext() and
see if/when you're called. you can do this by:
public void setPageContext( PageContext pageContext )
{
super.setPageContext( pageContext );
pageContext.getServletContext().log( pageContext: + pageContest );
}
i don't think that anything configuration wise could have changed this,
but at least then you'd know wether or not setPageContext() was being
called which might help...
cheers,
--
CraigL-Thx();
Be Developer ID: 5852
signature.asc
Description: This is a digitally signed message part
