[#DISPL-268] Add two classes to project to support JSR168 based portlets - jira.codehaus.org

DisplayTag

Add two classes to project to support JSR168 based portlets

Created: 15/Dec/05 04:24 PM Updated: 03/Jan/06 08:28 PM Resolved: 29/Dec/05 09:42 AM

Return to search

Component/s:

Container Compability

Affects Version/s:

None

Fix Version/s:

1.1

Time Tracking:

Issue & Sub-Tasks

Issue Only

Not Specified

File Attachments:

displaytag-portlet.zip (351 kB)
2.

displaytag_portlet.patch (53 kB)
3.

displaytag_portlet.patch (31 kB)
4.

PortletRequestHelper.java (5 kB)
5.

PortletRequestHelperFactory.java (1 kB)

Application server:

Jetspeedd 2.0

Sub-Tasks:
All
Open

display-portlet code cleanup

Closed

Description

« Hide

I'll include the two classes necessary to make this work. There are no changes necessary to other source code. Minor changes will be needed to make this build.

I've got no easy test cases at this time. I'll see if I can get one to you before too long.

Finally, there should probably be a minor doc update so folks know how to set this up.
( change to display.properties )
factory.requestHelper=org.displaytag.util.PortletRequestHelperFactory

Sort Order:

[ Permalink | « Hide ]

Eric Dalquist added a comment - 20/Dec/05 03:26 PM

The above fix does not work in all JSR-168 portlet containers. I'm working on a fix which involves some slight changes to the way the library generates URLs but will work for servlets and portlets in all containers. I should have the complete code ready to go by 12/21/2005

[ Permalink | « Hide ]

Eric Dalquist added a comment - 20/Dec/05 04:04 PM

Patch against CVS HEAD as of 2005-12-20 14:03 Pacific Standard Time

[ Permalink | « Hide ]

Eric Dalquist added a comment - 20/Dec/05 04:09 PM

The patch I've attached provides full JSR-168 compatibility for the displaytag library. The code should work on any JSR-168 compliant container.

I made the following changes to achieve the support.

-Changed the Href class to an interface, moved the existing implementation to a class named DefaultHref.
-Removed the DefaultHref(Href) constructor, changed all use of the copy constructor to use the Href.clone() method, allowing Hrefs to be cloned regardless of the implementation.
-Added the PortletRequestHelperFactory, PortletRequestHelper and PortletHref classes. Using these via the 'factory.requestHelper=org.displaytag.util.PortletRequestHelperFactory' property results in portlet URLs being generated for paging.

Direct links still work (falls back on DefaultHref) if the href or url tag property is specified.

The portlet API artifact dependency is not included in the patch I attached. A dependence on the http://www.ibiblio.org/maven/javax.portlet/poms/portlet-api-1.0.pom is required for compiling the Portlet* classes. It is not required at run time if these classes are not used.

[ Permalink | « Hide ]

Eric Dalquist added a comment - 22/Dec/05 08:11 PM

The portlet classes have been moved into their own module which is in the zip file. The patch contains just the code modifications that need to be made to the core codebase for the portlet support to work.

[ Permalink | « Hide ]

fabrizio giustina added a comment - 29/Dec/05 09:42 AM

The displaytag-portlet module has been committed to CVS, included in multiproject builds and documentation has been integrated.
Many thanks for this contribution Eric, it looks really good.
It will be released along with displaytag 1.1, please give a look at snapshot builds to see if everything is ok.
http://displaytag.sourceforge.net/m2repo/displaytag/displaytag-portlet/1.1-SNAPSHOT/

[ Permalink | « Hide ]

Eric Dalquist added a comment - 03/Jan/06 08:28 PM

I'm glad the code is in there and already getting use. The fix for the bug Eric Borisow ran into is in ~~DISPL-272~~ and there are some minor changes which I would be greatfull if you could do in ~~DISPL-273~~. Thanks for being so helpful Fabrizio