Thanks for replying, the problem is that I am upgrading from 0.8.5 and I have quite a few decorators.
I removed the "static" initializer, recompiled and it works fine but there is no more caching. I understand the motivation behind the "static" being placed there and it's perfectly logical since once it has been established that a particular subclass of the Decorator implements an accessor, there is no reason to re-compute it again. The cache instead of being keyed by property name should be keyed by the composition of the subclass of Decorator's name and by the property being accessed. I am sure there are better alternative solutions, may the community speak.
Best Regards, Thomas
On Friday, Oct 31, 2003, at 15:29 Canada/Eastern, John York wrote:
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
------------------------------------------------------- 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
