DisplayTag

Add two classes to project to support JSR168 based portlets

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.1
  • Component/s: Container Compability
  • Labels:
    None
  • Application server:
    Jetspeedd 2.0

Description

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

Activity

Hide
Eric Dalquist added a comment -
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
Show
Eric Dalquist added a comment - 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
Hide
Eric Dalquist added a comment -
Patch against CVS HEAD as of 2005-12-20 14:03 Pacific Standard Time
Show
Eric Dalquist added a comment - Patch against CVS HEAD as of 2005-12-20 14:03 Pacific Standard Time
Hide
Eric Dalquist added a comment -
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.
Show
Eric Dalquist added a comment - 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.
Hide
Eric Dalquist added a comment -
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.
Show
Eric Dalquist added a comment - 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.
Hide
fabrizio giustina added a comment -
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/
Show
fabrizio giustina added a comment - 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/
Hide
Eric Dalquist added a comment -
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
Show
Eric Dalquist added a comment - 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

People

  • Reporter:
    Anonymous
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: