> The 'nameList.value' is being used to lookup of the > messages/errors that were stored under this in the > ActionMessages. ActionMessages has an internal Map > and uses a key (normally the property name and there > is also GLOBAL_MESSAGE constant) to store > messages/errors associated with that field.
That part's not the problem. > > Internally the name is being set to the > > same as the rest of the tags, is this simply being > > ignored to go fetch > > the messages on a standard name?... > > Could you clarify this part? Or were you asking if > there was a different between passing in > 'nameList.value' or a simple property 'value'. On all the tags which take a name attribute to get at the bean, they extend the NestedNameSupport. So internally they'll get their name attribute set, like it or not even if a name was provided it will be ignored, as they all need to rely on the model the parent tags and such are working off. Reading the messages tag docco, it reads like the name attribute has to be set, so I assumed the NestedNameSupport. Having a closer look through it all, it resolves itself nicely. You've used the NestedPropertySupport which means that the name will not be set, and it will use the default ActionMessages reference. It does reference a different bean, but it's hidden and internal so that's all ok. If people provide the name attribute, it's all going fall over if the nested property isn't there, but that's kind of outside the nested scope and the original tag should be used. My confusion was that it was working off a different bean reference, which kind of impossible with the other nested tags without setting a new root tag. So I was also thinking about allowing people to reference a separate bean as standard functionality, as these message tags would be. I don't think they should, but I can hold off on this choice for now. Result, it's all good. Sorry about any confusions. Arron. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
