I added Tim's patch to the displaytag2 source tree today. I believe
that none of my changes will cause any problems with the existing tag,
so I'm going to go ahead and commit it. Here's what I did.
1. Added a tags.el package with Tim's 3 files (ColumnTag, TableTag and
ExpressionEvaluator).
2. Added jstl and standard as dependencies in project.xml.
3. Modified the ColumnTag that Tim submitted so a JSTL resource bundle
could be recognized from a <context-param> in web.xml:
<!-- Define the basename for a resource bundle for I18N -->
<context-param>
<param-name>javax.servlet.jsp.jstl.fmt.localizationContext</param-name>
<param-value>ApplicationResources</param-value>
</context-param>
4. Duplicated the displaytag-12.tld and renamed it displaytag-el-12.tld
and renamed the "table" and "column" tags to refer to the classes in the
.tags.el package. Changed the URI to be
http://jakarta.apache.org/taglibs/display-el. Modified maven.xml
appropriately to include this in the final jar.
5. Added an additional "url" attribute that is the same thing as
"href", but pre-prends the contextPath. I only added this to the
el.tld.
These changes should allow a user to use the existing display URI or
display-el URI and choose the tag they want to use. I believe this
should work. I integrated this into my AppFuse project and was able to
eliminate all the scriplets in my JSP. Here's a before and after:
Before:
<%@ page import="org.apache.struts.util.MessageResources,
org.apache.struts.Globals"%>
<%
MessageResources resources =
(MessageResources) request.getAttribute(Globals.MESSAGES_KEY);
%>
<%-- For linking to edit screen --%>
<bean:struts id="editURL" forward="editProfile"/>
<%-- URL to this screen --%>
<bean:struts id="thisURL" forward="viewUsers"/>
<display:table name="userList" cellspacing="0" cellpadding="0"
requestURI="<%=request.getContextPath()+thisURL.getPath()%>"
scope="request" pagesize="25" styleClass="list userList"
export="true">
<%-- Table columns --%>
<display:column property="username" sort="true"
headerClass="sortable" width="17%"
href='<%=request.getContextPath()+editURL.getPath()+"&from=list"%>'
paramId="username" paramProperty="username"
title='<%=resources.getMessage("userFormEx.username")%>'/>
<display:column property="firstName" sort="true"
headerClass="sortable" width="20%"
title='<%=resources.getMessage("userFormEx.firstName")%>' />
<display:column property="lastName" sort="true"
headerClass="sortable" width="13%"
title='<%=resources.getMessage("userFormEx.lastName")%>' />
<display:column property="email" sort="true" headerClass="sortable"
width="26%" autolink="true"
title='<%=resources.getMessage("userFormEx.email")%>' />
<display:setProperty name="paging.banner.item_name" value="User" />
<display:setProperty name="paging.banner.items_name" value="Users"
/>
</display:table>
After:
<%-- For linking to edit screen --%>
<bean:struts id="editURL" forward="editProfile"/>
<%-- URL to this screen --%>
<bean:struts id="thisURL" forward="viewUsers"/>
<display:table name="userList" cellspacing="0" cellpadding="0"
requestURI="${request.contextPath}" defaultsort="1"
scope="request" pagesize="25" styleClass="list userList"
export="true">
<%-- Table columns --%>
<display:column property="username" sort="true"
headerClass="sortable" width="17%"
url="${editURL.path}&from=list"
paramId="username" paramProperty="username"
titleKey="userFormEx.username"/>
<display:column property="firstName" sort="true"
headerClass="sortable" width="20%"
titleKey="userFormEx.firstName" />
<display:column property="lastName" sort="true"
headerClass="sortable" width="13%"
titleKey="userFormEx.lastName"/>
<display:column property="email" sort="true" headerClass="sortable"
width="26%" autolink="true"
titleKey="userFormEx.email" />
<display:setProperty name="paging.banner.item_name" value="User" />
<display:setProperty name="paging.banner.items_name" value="Users"
/>
</display:table>
One thing I found that is quite strange is that using
requestURI="${request.contextPath}" renders the correct URL! When using
the scriplet, I had to use
requestURI="<%=request.getContextPath()+thisURL.getPath()%>".
Comments? Questions?
Matt
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Matt Raible
> Sent: Saturday, December 20, 2003 4:19 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [displaytag-devel] Fwd: [displaytag-user] Expression support
>
>
> Very nice Tim. Looking through your code, this looks like a sweet
> addition. Here's my +1. Does the EL support require a JSP 1.2
> container or can commons-el be used? The reason I ask is I
> believe the
> displaytag will run on a servlet 2.2/jsp 1.1 container (though I
> wouldn't mind making it require 2.3/1.2).
>
> I've cc'd the developers list we can see what others think and
> hopefully commit this. You might also want to submit this as a patch
> to SourceForge so it doesn't get lost in e-mails and folks
> that want it
> can easily download it and use it.
>
> Thanks!
>
> Matt
>
> Begin forwarded message:
>
> > From: Tim McCune <[EMAIL PROTECTED]>
> > Date: December 19, 2003 12:20:16 PM MST
> > To: [EMAIL PROTECTED]
> > Subject: [displaytag-user] Expression support
> > Reply-To: [EMAIL PROTECTED]
> >
> > I sent mail to displaytag-devel a few days ago asking if anyone was
> > working on expression support for displaytag. Since nobody
> replied, I
> > went ahead and implemented it. I'm attaching the source.
> Instead of
> > patching displaytag, I just subclassed a couple things, but these
> > changes could easily go back into the main source if
> someone feels so
> > inclined. Enjoy.
> >
> > --Tim
>
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
displaytag-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
