cool. --- Arron Bates <[EMAIL PROTECTED]> wrote: > > 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]> >
__________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
