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 Pierre Delisle <pi...@sun.com> on 2002/10/04 02:15:43 UTC
[JNDI/LDAP] back to basics
While we probably all agree that JNDI/LDAP are important technologies,
it is still not clear to me what the exact motivation for a JNDI/LDAP taglib
is because I never had the need to use such tags in a web application.
So, for all who have developed such tablibs and/or used them, what are
the major reasons why people want this taglib? As I mentioned in a
previous email:
- Who's the target audience?
Is this for a developer who simply does not want to do that stuff in the
backend (because it's easier in the JSP page)? Or is this for a page
author that does not know much about JNDI but will gain from this
set of tags? Both?
- What are the main use cases for the taglib?
- Just the basics, without much knowledge of jndi specifics
- Just reading, or is update also important? Why?
I suspect that the motivation for the JNDI taglib is similar to the one
for the SQL tags (which by the way were quite controversial when they
were first introduced in JSTL). But I'd like to hear it loud and
clear from those who really feel these tags are important...
-- Pierre
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JNDI/LDAP] back to basics
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Pierre Delisle wrote:
>While we probably all agree that JNDI/LDAP are important technologies,
>it is still not clear to me what the exact motivation for a JNDI/LDAP taglib
>is because I never had the need to use such tags in a web application.
>
>
...
> - Who's the target audience?
>
> Is this for a developer who simply does not want to do that stuff in the
> backend (because it's easier in the JSP page)? Or is this for a page
> author that does not know much about JNDI but will gain from this
> set of tags? Both?
>
I think you've inherently answered the question yourself. It usefull for
both, one it will make developers job much easier, and two it will
provide an interface to JNDI that a page author could get at without
extensive knowledge of the underlying JNDI implementation issues that
developers have to repeatedly sweat through:
1.) I noticed in trying to work with webapplications and JNDI that
often there becomes to large a "distance" between the Presentation
interface (JSP or sometimes XSLT) when the "buisness logic" is
customized (say, with a Java Bean) and the final service layer is JNDI
based.
JSP (Presentation) --> JavaBean (Buisness Logic) --> JNDI (Service API)
--> LDAP (Service)
It can often become the case that simply modifying the application to be
able to add a new JNDI entry/attribute can get stretched out into a
process of.
a.) Add capabilities for it to the Service Layer: In the case of
LDAP, the Schema. (often requires working with System Admins).
b.) make modifications to the Buisness logic (with diffferent
developers of different logic components this can get time consuming).
c.) make modification at the Presentation level (often the JSP
developer will be different then the Buisness Logic developer).
I've found that it is easier to consolidate the process considerably by
using the JNDI abstraction as the buisness logic.
JSP (Presentation) --> JNDI Taglib (Buisness Logic) --> LDAP (Service)
This provides huge flexability in the logic component and frees the
developer to focus on the Service and Presentation layers. I did this
initially with java scripting tags in JSP. However, with the move in JSP
twards providing more and more interfaces via taglibraries (JSTL,
jakarta-taglibs, custom taglibs) and standard rules for the design of
taglibraries stabalizing (rt/el language integration into JSP) it became
apparent to me that it is unmanageable to have java scriptlets and
custom tags floating around together in a JSP page.
There are certain aspects of Java Scriptlets that defeat the power and
simplification that JSP can provide:
a.) I've often observed lots of replication of code across JSP's
when Java Scriptlets are employed. Taglibraries provide a means of
consolidating repetative code associated with a *service* such as JNDI
into a controlled and simplified interface. JNDI tags help reduce the
amount of scripting required to manage the presentation and manipulation
of content from a source such as LDAP. A JNDI taglibrary also provides a
*concrete* interface that clearly defines where presentation ends and
logic starts.
b.) Java Scriptlets break the current JSTL paradigm of contexts, for
example if I write <%String foo = new String("bar");%> it has NO context
in JSTL/EL (And by association, in JSP 2.0). By using design
requirements of JSTL We will be prepared for JSP 2.0 in the JNDI
Taglibrary. Many of the inherent problems with referencing objects in
scope will be met with JSP 2.0. By building an effective JNDI taglib we
willl will be providing a means of reducing the necessity of Java
Scriptlets embedded in JSP pages to accomplish simple access ing to JNDI
resources.
> - What are the main use cases for the taglib?
> - Just the basics, without much knowledge of jndi specifics
> - Just reading, or is update also important? Why?
>
It is simple to provide both read and write interfaces through the
design of the taglibrary. And using JSTL as well one can produce simple
JSP pages that consolidate all the behavior to complete one process of
updating into one JSP Page for instance look at the following code example:
In JSP 2.0 one would be capable of: doing the following:
<jndi:dir-context name="vdc_ctx" scope="session"/>
<c:choose>
<c:when test=" ${! empty param.submit}">
<jndi:modifyAttributes name='${param.dn}'
mod_op="REPLACE_ATTRIBUTE">
<jndi:setAttributes>
<jndi:setAttribute name="description"
value='${param.description}'/>
<jndi:setAttribute name="name" value='${param.name}'/>
</jndi:setAttributes>
</jndi:modifyAttributes>
<p>The entry was successfully update</p>
</c:when>
<c:otherwise>
<jndi:getAttributes dn="${param.dn}">
<form method=POST>
<input type=hidden name=dn value="${param.dn}"/>
<input type=text size=30 name=name
value="<jndi:getAttribute name="name"/>"/>
<textarea name="description" cols="24"
rows="5"><jndi:getAttribute name="description"/></textarea>
<input type="Submit" value="submit" name="submit">
</form>
</jndi:getAttributes>
</c:otherwise>
</c:choose>
What happens here?
1.) On the first pass to the page the form is shown with the fields
one would want to update in the "dn" of the interested JNDI entry.
2.) On second pass the "sumbit" parameter is present and the the
modify taglib JSP fragment is executed.
Of course this is an overly simplified example as there is no error
catching or support for multivalue attributes going on. But for the most
part we can see that simple solutions can be created to provide
read/write access to JNDI information.
-Mark Diggory
p.s. another implementation idea to throw around would be the idea of
providing EL support for reading information from a JNDI context. Much
the same way that it is provided for Object like HttpServletRequest,
HttpSession and SerfvletContext. Then the following example could be
explored as well.
<jndi:getAttributes dn="${param.dn}" var="foo" scope="page">
<form method=POST>
...
<input type=text size=30 name=name
value="${pageContext.foo.name}"/>
<input type=text size=30 name=name
value="${pageContext.foo.description}"/>
<input type=text size=30 name=name
value="${pageContext.foo.objectClass}"/>
...
</form>
</jndi:getAttributes>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JNDI/LDAP] back to basics
Posted by orhan alkan <or...@sun.com>.
> Hi All,
> It is nice to hear that we passed item 1. I'd like to add a few words
> into movitivation section; more than simya ldap taglib has been
> downloaded more than 1000. We received many good feed back from the
> users. They can be divided into two section;first part are naive
> users, they are intrested/told to develop application that it have to
> talk to LDAP servers somehow. They were happy with our solution
> because it hides to code and simplifies to access LDAP. Second part
> are advance users but they are lasy to reinvent to wheel, they are happy.
> In last 3 years, almost all organization has been implemented
> directories for intranet/extranet purposes. you can't believe how many
> organization developed at least one phone book application using
> either java or microsoft technologies. I also developed a user
> administration solution.
> As a result, every body is looking for the the solution that are
> simple and flexible. I aggree with Tod in this respect.
>
> I prepared a comparision list you'll find in the attachment. The list
> is not complete. It can be extended. It doesn't includes details about
> Authentication features such as SASL, Kerberos and SSL support.
> Generally, solutions can be catagorized into two parts;
> 1- JNDI taglibraries; they are very generall purpose. They only
> provides basic search and lookup features.
> 2- LDAP taglibraries; they are focused on directory operations.
>
Name search/
lookup
delete
modify
add
LDAP/JNDI
Comments
servlersuite
www.servletsuite.com
X
JNDI
They have DSML option. Free
virtues
www.virtues.com
X
X
X
X
LDAP
Commercial.
Sun
www.sun.com
X
X
X
X
LDAP
Design for SuneOne Directory specifically. Comes with directory resource
kit. They provide similiar library with application server. Free.
Simya Consulting
www.simya.net
X
X
X
X
LDAP
works with any directory server. Free.
Macromedia
www.macromedia.com
X
JNDI
formerly known Jrun. Comes with Jrun.
Jakarta Taglibs
jakarta.apache.org
X
Free.
That is obivous (for me) that there is requirement for jndi taglib that
can be used with all SP(s).
Regards
ORhan Alkan
>
> Mark R. Diggory wrote:
>
>> Pierre Delisle wrote:
>>
>>> Todd, Mark,
>>>
>>> Thanks for taking the time to provide sound arguments for the
>>> motivation of a JNDI/LDAP taglib. Step 1 passed with flying colors!
>>>
>>> OK, on to step 2 now...
>>>
>>> Could someone provide us with some analysis of the taglibs that
>>> currently exist out there that tackle the same topic?
>>> What are their strengths, weaknesses, and what impact would they
>>> have on a possible new project here at jakarta-taglibs?
>>>
>>> -- Pierre
>>>
>>>
>>
>> *Read Only Libraries*
>>
>> Apache
>> http://jakarta.apache.org/taglibs/doc/jndi-doc/intro.html
>>
>> Coldbeans software
>> http://www.servletsuite.com/servlets/jnditag.htm
>>
>> Cocoon XSP Logic Sheet:
>> http://opensource.socialchange.net.au/ldaptaglib/docs/
>>
>> ...Please list any more you know here...
>>
>>
>> *Read/Write Libraries*
>>
>> Virtual Data Center Project (My Project:
>> http://sourceforge.net/projects/thedata)
>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/thedata/VDC/src/UIS/Taglib/
>>
>>
>> Strengths:
>> Implements most of the JNDI DirContext methods for accessing
>> LDAP Directory Content.
>> (search, getAttributes, modifyAttributes, createSubcontext,
>> DeleteSubcontext).
>> Environment can be intialized from properties file.
>> Context can be stored at any scope.
>> Developed in Forte, can be easily modified there for my purposes.
>>
>> Weaknesses:
>> Only one developer
>> Doesn't implement other JNDI Context methods for things like
>> object binding capabilities.
>> Long term future uncertain as a grant funded project.
>> Tag libraries built in Forte, lots of generated tld and java
>> code from Forte, may hinder further development in other development
>> platforms.
>> Doesn't meet Jakarta Taglib development guidelines, not JSTL
>> like in design.
>>
>>
>> ...Please list any more libraries you know here...
>>
>>
>>
>> _________________________
>> On a side note, I also developed a Saxon Extension that does some
>> rudimentary DSML generation from JNDI search results. This allows a
>> JNDI source to be queried from inside Saxon's XSLT Transform.
>> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/thedata/VDC/src/UIS/Saxon/
>>
>>
>> -Mark
>>
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>
>
> ------------------------------------------------------------------------
>
> Name search/
> lookup
> delete
> modify
> add
> LDAP/JNDI
> Comments
>
> servlersuite
> www.servletsuite.com
> X
>
>
>
> JNDI
> They have DSML option. Free
>
> virtues
> www.virtues.com
> X
> X
> X
> X
> LDAP
> Commercial.
>
> Sun
> www.sun.com
> X
> X
> X
> X
> LDAP
> Design for SuneOne Directory specifically. Comes with directory
> resource kit. They provide similiar library with application server.
> Free.
>
> Simya Consulting
> www.simya.net
> X
> X
> X
> X
> LDAP
> works with any directory server. Free.
>
> Macromedia
> www.macromedia.com
> X
>
>
>
> JNDI
> formerly known Jrun. Comes with Jrun.
>
> Jakarta Taglibs
> jakarta.apache.org
> X
>
>
>
>
> Free.
>
>
Re: [JNDI/LDAP] back to basics
Posted by orhan alkan <or...@sun.com>.
Hi All,
It is nice to hear that we passed item 1. I'd like to add a few words
into movitivation section; more than simya ldap taglib has been
downloaded more than 1000. We received many good feed back from the
users. They can be divided into two section;first part are naive users,
they are intrested/told to develop application that it have to talk to
LDAP servers somehow. They were happy with our solution because it hides
to code and simplifies to access LDAP. Second part are advance users but
they are lasy to reinvent to wheel, they are happy.
In last 3 years, almost all organization has been implemented
directories for intranet/extranet purposes. you can't believe how many
organization developed at least one phone book application using either
java or microsoft technologies. I also developed a user administration
solution.
As a result, every body is looking for the the solution that are simple
and flexible. I aggree with Tod in this respect.
I prepared a comparision list you'll find in the attachment. The list is
not complete. It can be extended. It doesn't includes details about
Authentication features such as SASL, Kerberos and SSL support.
Generally, solutions can be catagorized into two parts;
1- JNDI taglibraries; they are very generall purpose. They only provides
basic search and lookup features.
2- LDAP taglibraries; they are focused on directory operations.
That is obivous (for me) that there is requirement for jndi taglib that
can be used with all SP(s).
Regards
ORhan Alkan
Mark R. Diggory wrote:
> Pierre Delisle wrote:
>
>> Todd, Mark,
>>
>> Thanks for taking the time to provide sound arguments for the
>> motivation of a JNDI/LDAP taglib. Step 1 passed with flying colors!
>>
>> OK, on to step 2 now...
>>
>> Could someone provide us with some analysis of the taglibs that
>> currently exist out there that tackle the same topic?
>> What are their strengths, weaknesses, and what impact would they have
>> on a possible new project here at jakarta-taglibs?
>>
>> -- Pierre
>>
>>
>
> *Read Only Libraries*
>
> Apache
> http://jakarta.apache.org/taglibs/doc/jndi-doc/intro.html
>
> Coldbeans software
> http://www.servletsuite.com/servlets/jnditag.htm
>
> Cocoon XSP Logic Sheet:
> http://opensource.socialchange.net.au/ldaptaglib/docs/
>
> ...Please list any more you know here...
>
>
> *Read/Write Libraries*
>
> Virtual Data Center Project (My Project:
> http://sourceforge.net/projects/thedata)
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/thedata/VDC/src/UIS/Taglib/
>
>
> Strengths:
> Implements most of the JNDI DirContext methods for accessing
> LDAP Directory Content.
> (search, getAttributes, modifyAttributes, createSubcontext,
> DeleteSubcontext).
> Environment can be intialized from properties file.
> Context can be stored at any scope.
> Developed in Forte, can be easily modified there for my purposes.
>
> Weaknesses:
> Only one developer
> Doesn't implement other JNDI Context methods for things like
> object binding capabilities.
> Long term future uncertain as a grant funded project.
> Tag libraries built in Forte, lots of generated tld and java
> code from Forte, may hinder further development in other development
> platforms.
> Doesn't meet Jakarta Taglib development guidelines, not JSTL
> like in design.
>
>
> ...Please list any more libraries you know here...
>
>
>
> _________________________
> On a side note, I also developed a Saxon Extension that does some
> rudimentary DSML generation from JNDI search results. This allows a
> JNDI source to be queried from inside Saxon's XSLT Transform.
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/thedata/VDC/src/UIS/Saxon/
>
> -Mark
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
Re: [JNDI/LDAP] back to basics
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Pierre Delisle wrote:
>Todd, Mark,
>
>Thanks for taking the time to provide sound arguments for the
>motivation of a JNDI/LDAP taglib. Step 1 passed with flying colors!
>
>OK, on to step 2 now...
>
>Could someone provide us with some analysis of the taglibs
>that currently exist out there that tackle the same topic?
>What are their strengths, weaknesses, and what impact would they
>have on a possible new project here at jakarta-taglibs?
>
> -- Pierre
>
>
*Read Only Libraries*
Apache
http://jakarta.apache.org/taglibs/doc/jndi-doc/intro.html
Coldbeans software
http://www.servletsuite.com/servlets/jnditag.htm
Cocoon XSP Logic Sheet:
http://opensource.socialchange.net.au/ldaptaglib/docs/
...Please list any more you know here...
*Read/Write Libraries*
Virtual Data Center Project (My Project:
http://sourceforge.net/projects/thedata)
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/thedata/VDC/src/UIS/Taglib/
Strengths:
Implements most of the JNDI DirContext methods for accessing
LDAP Directory Content.
(search, getAttributes, modifyAttributes, createSubcontext,
DeleteSubcontext).
Environment can be intialized from properties file.
Context can be stored at any scope.
Developed in Forte, can be easily modified there for my purposes.
Weaknesses:
Only one developer
Doesn't implement other JNDI Context methods for things like
object binding capabilities.
Long term future uncertain as a grant funded project.
Tag libraries built in Forte, lots of generated tld and java
code from Forte, may hinder further development in other development
platforms.
Doesn't meet Jakarta Taglib development guidelines, not JSTL
like in design.
...Please list any more libraries you know here...
_________________________
On a side note, I also developed a Saxon Extension that does some
rudimentary DSML generation from JNDI search results. This allows a JNDI
source to be queried from inside Saxon's XSLT Transform.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/thedata/VDC/src/UIS/Saxon/
-Mark
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JNDI/LDAP] back to basics
Posted by Pierre Delisle <pi...@sun.com>.
Todd, Mark,
Thanks for taking the time to provide sound arguments for the
motivation of a JNDI/LDAP taglib. Step 1 passed with flying colors!
OK, on to step 2 now...
Could someone provide us with some analysis of the taglibs
that currently exist out there that tackle the same topic?
What are their strengths, weaknesses, and what impact would they
have on a possible new project here at jakarta-taglibs?
-- Pierre
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JNDI/LDAP] back to basics
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Pierre Delisle wrote:
>While we probably all agree that JNDI/LDAP are important technologies,
>it is still not clear to me what the exact motivation for a JNDI/LDAP
taglib
>is because I never had the need to use such tags in a web application.
>
>
...
> - Who's the target audience?
>
> Is this for a developer who simply does not want to do that stuff
in the
> backend (because it's easier in the JSP page)? Or is this for a page
> author that does not know much about JNDI but will gain from this
> set of tags? Both?
>
I think you've inherently answered the question yourself. It usefull for
both, one it will make developers job much easier, and two it will
provide an interface to JNDI that a page author could get at without
extensive knowledge of the underlying JNDI implementation issues that
developers have to repeatedly sweat through:
1.) I noticed in trying to work with webapplications and JNDI that
often there becomes to large a "distance" between the Presentation
interface (JSP or sometimes XSLT) when the "buisness logic" is
customized (say, with a Java Bean) and the final service layer is JNDI
based.
JSP (Presentation) --> JavaBean (Buisness Logic) --> JNDI (Service API)
--> LDAP (Service)
It can often become the case that simply modifying the application to be
able to add a new JNDI entry/attribute can get stretched out into a
process of.
a.) Add capabilities for it to the Service Layer: In the case of
LDAP, the Schema. (often requires working with System Admins).
b.) make modifications to the Buisness logic (with diffferent
developers of different logic components this can get time consuming).
c.) make modification at the Presentation level (often the JSP
developer will be different then the Buisness Logic developer).
I've found that it is easier to consolidate the process considerably by
using the JNDI abstraction as the buisness logic.
JSP (Presentation) --> JNDI Taglib (Buisness Logic) --> LDAP (Service)
This provides huge flexability in the logic component and frees the
developer to focus on the Service and Presentation layers. I did this
initially with java scripting tags in JSP. However, with the move in JSP
twards providing more and more interfaces via taglibraries (JSTL,
jakarta-taglibs, custom taglibs) and standard rules for the design of
taglibraries stabalizing (rt/el language integration into JSP) it became
apparent to me that it is unmanageable to have java scriptlets and
custom tags floating around together in a JSP page.
There are certain aspects of Java Scriptlets that defeat the power and
simplification that JSP can provide:
a.) I've often observed lots of replication of code across JSP's
when Java Scriptlets are employed. Taglibraries provide a means of
consolidating repetative code associated with a *service* such as JNDI
into a controlled and simplified interface. JNDI tags help reduce the
amount of scripting required to manage the presentation and manipulation
of content from a source such as LDAP. A JNDI taglibrary also provides a
*concrete* interface that clearly defines where presentation ends and
logic starts.
b.) Java Scriptlets break the current JSTL paradigm of contexts, for
example if I write <%String foo = new String("bar");%> it has NO context
in JSTL/EL (And by association, in JSP 2.0). By using design
requirements of JSTL We will be prepared for JSP 2.0 in the JNDI
Taglibrary. Many of the inherent problems with referencing objects in
scope will be met with JSP 2.0. By building an effective JNDI taglib we
willl will be providing a means of reducing the necessity of Java
Scriptlets embedded in JSP pages to accomplish simple access ing to JNDI
resources.
> - What are the main use cases for the taglib?
> - Just the basics, without much knowledge of jndi specifics
> - Just reading, or is update also important? Why?
>
It is simple to provide both read and write interfaces through the
design of the taglibrary. And using JSTL as well one can produce simple
JSP pages that consolidate all the behavior to complete one process of
updating into one JSP Page for instance look at the following code example:
In JSP 2.0 one would be capable of: doing the following:
<jndi:dir-context name="vdc_ctx" scope="session"/>
<c:choose>
<c:when test=" ${! empty param.submit}">
<jndi:modifyAttributes name='${param.dn}'
mod_op="REPLACE_ATTRIBUTE">
<jndi:setAttributes>
<jndi:setAttribute name="description"
value='${param.description}'/>
<jndi:setAttribute name="name" value='${param.name}'/>
</jndi:setAttributes>
</jndi:modifyAttributes>
<p>The entry was successfully update</p>
</c:when>
<c:otherwise>
<jndi:getAttributes dn="${param.dn}">
<form method=POST>
<input type=hidden name=dn value="${param.dn}"/>
<input type=text size=30 name=name
value="<jndi:getAttribute name="name"/>"/>
<textarea name="description" cols="24"
rows="5"><jndi:getAttribute name="description"/></textarea>
<input type="Submit" value="submit" name="submit">
</form>
</jndi:getAttributes>
</c:otherwise>
</c:choose>
What happens here?
1.) On the first pass to the page the form is shown with the fields
one would want to update in the "dn" of the interested JNDI entry.
2.) On second pass the "sumbit" parameter is present and the the
modify taglib JSP fragment is executed.
Of course this is an overly simplified example as there is no error
catching or support for multivalue attributes going on. But for the most
part we can see that simple solutions can be created to provide
read/write access to JNDI information.
-Mark Diggory
p.s. another implementation idea to throw around would be the idea of
providing EL support for reading information from a JNDI context. Much
the same way that it is provided for Object like HttpServletRequest,
HttpSession and SerfvletContext. Then the following example could be
explored as well.
<jndi:getAttributes dn="${param.dn}" var="foo" scope="page">
<form method=POST>
...
<input type=text size=30 name=name
value="${pageContext.foo.name}"/>
<input type=text size=30 name=name
value="${pageContext.foo.description}"/>
<input type=text size=30 name=name
value="${pageContext.foo.objectClass}"/>
...
</form>
</jndi:getAttributes>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [JNDI/LDAP] back to basics
Posted by Tod Thomas <tt...@chubb.com>.
Pierre Delisle wrote:
>
> While we probably all agree that JNDI/LDAP are important technologies,
> it is still not clear to me what the exact motivation for a JNDI/LDAP taglib
> is because I never had the need to use such tags in a web application.
>
> So, for all who have developed such tablibs and/or used them, what are
> the major reasons why people want this taglib? As I mentioned in a
> previous email:
>
> - Who's the target audience?
>
> Is this for a developer who simply does not want to do that stuff in the
> backend (because it's easier in the JSP page)? Or is this for a page
> author that does not know much about JNDI but will gain from this
> set of tags? Both?
I'm more familiar with LDAP so I'll speak from that perspective.
In my experience developers don't want to embrace new technologies
unless they're given an easy way to 'kick the tires'. Over the years
this has proven to be the hurdle when trying to gain enterprise wide
acceptance of LDAP in the development community. The typical developer
is very busy and just wants to see it work and maybe implement a few
quick hit applications before taking the time to dig into the details -
and that's the inquisitive developers. Couple that with trying it in an
JAVA/XML/XSLT environment and the learning curve gets steeper. For this
reason alone a taglib would prove invaluable.
Imagine the developer with the JNDI (or LDAP) taglib, a couple of
simple, straightforward examples, and the name of his/her local LDAP
directory. It wouldn't take much to quickly churn out a company white
pages, or organizational chart. With a little work user authentication
would be right around the corner. And thats just read access, providing
update would open up an entirely new set of opportunities. Base the
taglib on the published Oasis XML spec. and you can market the new
taglib as adhering to industry standards.
> - What are the main use cases for the taglib?
> - Just the basics, without much knowledge of jndi specifics
> - Just reading, or is update also important? Why?
Again from the LDAP perspective, I expect read would be the easier to
implement initially. Once read is available you implicitly have bound,
albeit anonymously, so update capabilities will be that much easier to
integrate. I think it wise to think seriously about encryption
throughout the development process as user authentication in the clear
is not very secure.
> I suspect that the motivation for the JNDI taglib is similar to the one
> for the SQL tags (which by the way were quite controversial when they
> were first introduced in JSTL). But I'd like to hear it loud and
> clear from those who really feel these tags are important...
>
> -- Pierre
My opinion alone, not my employers.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>