I'm curious as to what it is you are trying to accomplish. It's been my experience that you might be able to do without the decorators altogether. If you've got something simple to decorate, it's much easier to just use the body of the column tag:
<table:column ...>Handle decoration here</table:column> I know we have a few things that only work using decorators, but I hope we'll be in the process of making them work without forcing the extra complexity of decorators on our users. That being said, is there any reason why Decorator.java needs to make this value static? Won't you always reference a specific decorator object from within your tables? If we remove the 'static', will it just work? John On Fri, 31 Oct 2003, Thomas Gourgon wrote: > Hi Matt and others, > I am having a problem with the use of a static variable in > org.displaytag.decorator.Decorator where it's caching the presence of > property accessors: > > private static HashMap lPropertyMap = new HashMap();. > > > The problem is that the static variable is shared across all the > extensions org.displaytag.decorator.Decorator which means that if any > Decorator implements an accessor for a property A then every request to > a property of that name will be performed on the Decorator regardless > of it's type. > > An example for clarity: Let's say two TableDecorators Td1 decorating > Obj1 and Td2 decorating Obj2 where Td1 and Obj2 implement getProp1. Now > when Td1 is ask if it implements an accessor for prop1 it caches the > results in lPropertyMap then when Td2 is asked for pro1 it resolves out > of the same cache to true because of Td1. This generates an exception > since Td2 does not implements getPlrop1. > > A solution to this problem would be to add the decorator's class name > to the hash key to create some kind of name space for each extension of > Decorator. On the other hand this may be a bit hard to implement > without changing the interface since the class name would have to be > passed up to the parent Decorator class. I volunteer to implement > whatever solution is accepted. > > Regards, > > Thomas Gourgon > > Tritus Consultant Group Inc. > www.tritus.ca > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > displaytag-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/displaytag-devel > -- John York Software Engineer CareerSite Corporation ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ displaytag-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/displaytag-devel
