jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: LDAP taglib proposal
Date Tue, 10 Sep 2002 02:49:23 GMT

I agree with much of these suggestions. I think the appropriate strategy 
would be one of Picking up the current JNDI taglib and moving it forward 
by adding the freatures represented in other libraries through 
"re-factorings" to bring it upto par with volunteered code. I like the 
idea of getting it functional with JSTL and EL. I noticed a discussion 
awhile back about JSTL/EL best practices.

Pierre Delisle wrote:

>I've had a look at your LDAP taglib submission.
>Looks good, but I do have the following concerns:
>1. Duplication of functionality
>  As we all know, we already have a JNDI taglib offering.
>  Unfortunately, its original developer is no longer
>  active in our community, and it has not been "growing"
>  much over time.
>  However, before we accept another "competing" proposal, 
>  I think we ought to have compelling reasons to choose that
>  path, rather than work on evolving the current one.
>  So, it would be great to have these reasons clearly exposed
>  to the list.
>2. JNDI vs LDAP
>  It would also be important to build the case for LDAP
>  as opposed to a more generic JNDI taglib.
>  [Would be great if you could address the questions that
>   were sent by Henri Yandell]
>3. Design Patterns
>  JSTL has introduced many patterns for the design
>  of tag libraries. It would be great if new taglibs
>  tried to adopt these design patterns whenever possible.
>  [I see a lot of similarities between the JSTL <sql:*> tags
>  and the JNDI/LDAP tags (configuration, 
>  connect-query-access-update)]

With most of my taglibs, I've been using Forte as a development 
platform, it has very excellent examples of making sure that the objects 
being handed are of the right classes. However, I do notice that the 
Handlers on many of the jakarta taglibs are a bit "smaller" than those 
Forte autogenerates.

With EL being part of JSP 1.3 I think that its not a matter of 
integrating the EL Enterpreter as much as designing the Taglibs to take 
the Objects handed to it by RT/EL gracefully (Like Shawn recommends). 
Doing things like <pre:tag 
attribute='<%=session.getAttribute("foobar")%>'/> are pretty simple.

Best practices are stuff like this:

<tag:setSomeObject var="foobar" scope="session"/>
<tag:doSomethingWithObject value='<%=session.getAttribute("foobar")%>'/>

this gracefully leads the way for

<tag:getObject value='${sessionScope.foobar}'/>

as a "No Brainer" in JSP 1.3.

In terms of design patterns for JNDI, I think paralleling the JNDI 
library is pretty much the best model, for instance the read/write 
DirCintext Taglib might look somewhat like this:

<jndi:dirContext var="ctx" scope="session">
    <jndi:addToEnv  name="..." value="..."/>
    <jndi:removeFromEnv  name="..."/>

    <jndi:search name="..." filter="..." searchScope="...">
        <jndi:searchResult var="sr">
             <jndi:attribute name="..."/>
             <jndi:attributeValues name="...">

    <jndi:attributes name="...">
        <jndi:attribute name="..."/>
        <jndi:attributeValues name="...">

    <jndi:destroy name="..." with-children="true|false"/>

    <jndi:create name="...">
        <jndi:attribute name="..." value="..."/>
        <jndi:attribute name="...">
            <jndi:set value="..."/>
            <jndi:set value="..."/>

    <jndi:modify name="..." operation="...">
        <jndi:attribute name="..." value="..."/>
        <jndi:attribute name="...">
            <jndi:set value="..."/>
            <jndi:set value="..."/>


my 2 cents,

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

View raw message