> > I don't like the performance impact of creating a new wrapper instance > > on > > every call to getMap(), however -- that can happen lots of times in a > > page. It's probably possible to create the wrapper once and then cache > > it > > (to reduce the impact somewhat), but it is still a spurious object > > creation. > > I considered caching as well but thought the implementation might get a > bit ugly. It also doesn't help the form.map.prop issue.
I have an idea that avoids caching and spurious object creation, but does not fix the form.map.prop issue. The idea is to create a new FixedKeyMap class which delegates all methods and constructors to the HashMap class with the following exceptions: - put(), putAll(), remove(), and clear() throw UnsupportedOperationException - a new set method with the same signature as the put method is created, but it can only be used to override values of existing keys. So the end effect is that when the map is created the key set is fixed forever by the constructor. The map's values can change, but its keys cannot. It's ugly for a Java or JSP developer to change the bean's properties using the Map instead of the methods in the DynaActionForm class, but at least it shouldn't cause any strange exceptions to occur. I'm just throwing this idea out there... actually I prefer having DynaActionForm implement Map directly. Matt --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
