jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: EL in String Taglib 1.0
Date Fri, 01 Nov 2002 23:05:01 GMT


Okay. I've got EL working in String Taglib quite happily. The changes I've
made are, to StringTagSupport [my abstract class]:

    public int doEndTag() throws JspException {

        ....

        if(StringTagSupport.jstlExists()) {
            evaluateExpressions();
        }

        ....
    }

    // expected to be extended
    protected void evaluateExpressions() throws JspException {
    }

    protected final String evaluateExpression(String name, String value) throws JspException
{
            return (String)org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.evaluate(
                name,
                value,
                String.class,
                this,
                pageContext);
    }

    static private Boolean JSTL = null;
    static private boolean jstlExists() {
        if(JSTL == null) {
          try {
            Class.forName("org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager");
            JSTL = Boolean.TRUE;
          } catch(ClassNotFoundException cnfe) {
            JSTL = Boolean.FALSE;
          }
        }
        return JSTL.booleanValue();
    }

and then in a particular tag I have:

    protected void evaluateExpressions() throws JspException {
        this.replace = evaluateExpression("replace", this.replace);
        this.with = evaluateExpression("with", this.with);
        if(this.count != null) {
            this.count = evaluateExpression("count", this.count);
        }
        if(this.newlineToken != null) {
            this.newlineToken = evaluateExpression("newlineToken", this.newlineToken);
        }
    }

I have to make minor changes, for example this.count was an int, but now
has to be stored as a String and turned to an int at the last second.

With the standard.jar there, 'str:replace with' can happily take an EL,
and if I remove standard.jar [and remove the jstl parts form the jsp], the
str:replace happily works.

I'm aiming to add a el="false" option to all tags which will allow people
to turn off EL if they have the JSTL installed and don't want
with="${foo}" to be done.

Apart from that, are there any issues with this approach?

David, you mentioned issues with moving to JSP 2.0, can you see this
approach hitting a problem when it heads in that direction?

I know I'm not following either David or Glenn's suggestions, but am
hoping to find something sweet and nice hidden away. What worries me is
that I'm making an assumption somehow about the way all servers work [as I
just use Tomcat for testing], or that JSP 2.0 is going to bite me.

Thanks for the time,

Hen

On Fri, 1 Nov 2002, Henri Yandell wrote:

>
> [Moving to Developers]
>
> That's pretty much a decision that String Taglib for 1.1 is frozen and
> development only continues on 1.2. Basically I'm wanting all the cake and
> to eat it.
>
> A 1.1 taglib which will happily go into 1.2/EL or then 2.0 mode without
> changing the jar. I can see there is a need for a separate TLD though, as
> JSTL has two tlds, one for EL and one for rtexpr. So 1.1 would effectively
> be rtexpr and there would be an el taglib that could be used. [the inverse
> of the jstl tlds, would be string.tld and string-el.tld].
>
> I want to avoid the management of a branch or new project, but also to
> maintain a 1.1 workable version. If it's possible to set a system up that
> fills those needs, then it could be something that we fit onto all the
> projects [and retrofit cache].
>
> Am I chasing something that better minds have tried and decided is
> impossible?
>
> Hen
>
> On Fri, 1 Nov 2002, Glenn Nielsen wrote:
>
> > I would recommend creating the EL enabled version as a 2.0 release.
> > Enabling EL in an older non EL taglib can allow you to restructure
> > how your tags work.  Some tags or tag attributes may no longer be
> > necessary when the EL is available.  Plus doesn't the EL require JSP 1.2?
> > And the current taglib is compatible with JSP 1.1?
> >
> > Adding the EL is enough of a change to warrant a 2.0 release IMHO.
> > Perhaps not from the developer viewpoint, but definitely from the
> > user viewpoint.
> >
> > Regards,
> >
> > Glenn
> >
> > Henri Yandell wrote:
> > > There is that, but in terms of project management for the Jakarta Taglibs,
> > > it'll turn each ELized version into a new project, or a branch or
> > > somewhat. Unless we declare org.apache.taglibs.<name>.el to be special
> > > perhaps, and output two jars, one with and one without the el sub-package.
> > >
> > > Will ask Glenn.
> > >
> > > Hen
> > >
> > > On Fri, 1 Nov 2002, Karr, David wrote:
> > >
> > >
> > >>My goal is to not change the existing library at all, either at the
> > >>source level or the deployment level.  If you put the new classes in the
> > >>old jar, then people deploying the old taglib will get those extra
> > >>classes.  Those shouldn't cause any conflicts, but I don't like to
> > >>introduce changes that "very likely" won't have any effect.
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: Henri Yandell [mailto:bayard@generationjava.com]
> > >>>Sent: Friday, November 01, 2002 12:31 PM
> > >>>
> > >>>On Fri, 1 Nov 2002, Karr, David wrote:
> > >>>
> > >>>
> > >>>>All the tag classes in the Struts-EL tag library are
> > >>>
> > >>>subclasses of the
> > >>>
> > >>>>corresponding class in the Struts tag library, and all of them look
> > >>>>almost identical.  In each one, the "doStartTag()" method
> > >>>
> > >>>calls a method
> > >>>
> > >>>>called "evaluateExpressions()", which just has one block of almost
> > >>>>identical code for each property of the tag, which just passes the
> > >>>>current value of the property through the EL parser and into the
> > >>>>"setter" method for the property.  The only exception to
> > >>>
> > >>>this relatively
> > >>>
> > >>>Okay. I'm convinced :) Will work on getting a 1.1 release out
> > >>>which has an
> > >>>EL'd component. Any reason it has to be a different jar? Or
> > >>>just one jar
> > >>>with them all and a different tld?
> > >>
> > >>--
> > >>To unsubscribe, e-mail:   <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
> > >>For additional commands, e-mail: <mailto:taglibs-user-help@jakarta.apache.org>
> > >>
> > >>
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:   <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail: <mailto:taglibs-user-help@jakarta.apache.org>
> >
> >
> > --
> > ----------------------------------------------------------------------
> > Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
> > MOREnet System Programming               |  * if iz ina coment.      |
> > Missouri Research and Education Network  |  */                       |
> > ----------------------------------------------------------------------
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:taglibs-user-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>
>
>


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


Mime
View raw message