I recently ran into an issue where I noticed that a custom type converter was being called when parameters were being applied to a model object but not when that model was being rendered out to a result via the s:select tag. The issue is probably summed up by Jasper Rosenberg's previous bug report WW-2047 (https://issues.apache.org/struts/browse/WW-2047). After reading that report I have the following question/observation:
Since XWork's type conversion capabilities are among the best features of the framework, why are they being subverted by hard-coding the tags so that they only call toString, even in the presence of a custom type converter. The response in the Jira issue was to make sure toString returned what we wanted. The trouble with that is now the web framework is dictating how the model classes are designed... and wasn't getting away from that kind of problem one of the major benefits of moving to s2? The type converters are there explicitly to provide flexibility to the framework so that the framework designer's assumptions don't end up hamstringing the applications being written on top of the framework. Just how difficult would it be for the tags to look for a type converter first (since the appropriate call in this circumstance would be returning a string) and then fail back to toString if one was not found? Wouldn't that approach be more in keeping with the spirit of the framework? -- View this message in context: http://www.nabble.com/Struts-framework-design-question%3A-Type-Converters-and-Tags-tp15019888p15019888.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
