Re: Nested Messages Errors tags applicability...
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. 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'. David --- Arron Bates [EMAIL PROTECTED] wrote: That all seems cool, and if the test works, all the better :) To confirm what's happening there... It's fetching the nameList.value property off the same bean as the text fields. To read the markup, the messages and errors would then be calling on the same property. 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?... Arron. On Fri, 2002-06-21 at 05:45, David Winterfeldt wrote: I'm not 100% I'm sure I'm following what the problem is (probably missed some other e-mails). I was going to talk to you Aaron when I went to do these, but it seemed very simple so I went ahead and made them. I just wanted the nested messages and errors tags to be able to get the property name of the bean so you could display messages and errors next to a field from a list. These tags don't really need any other feature the nested tags provid. Currently the validator can handle lists, but not custom messages for each field. It does correctly create the full property as the error key though so you can display the error next to the field. Here is the example from web/validator/type.jsp where I tested this. nested:iterate property=nameList tr th align=left nbsp; /th td align=left nested:messagesPresent property=value br ul nested:messages id=error property=value libean:write name=error//li /nested:messages /ul /nested:messagesPresent nested:text property=value size=15 maxlength=15/ /td /tr /nested:iterate Let me know what you think. David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Nested Messages Errors tags applicability...
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]
Nested Messages Errors tags applicability...
Just curious as to the applicability of the Errors an Messages tags in the nested context... Because the nested tags use the one bean reference, I'm finding it hard to visualise using these tags within context. In the original tags, everything was an island, so it was all fine, but nesting against the one bean makes it a little fuzzy. Referencing the different bean means implanting a new root tag, which would mean you'd have to nest the tags all over again to get to the same point. It would be easier to go the route of the original errors/messages tags. I realise that it'd be really handy to be able to get at the same property that a text box is working off of, but the separate bean issue meant that I basically put it down to being out of context and as a result I didn't include them in the tags when I first wrote them. One way I can see it working is to make a small departure from the way the rest of the nested tags work, and allow the referencing of a different bean. This then raises the problem that if you do it for one, you should possibly allow the others. Not impossible. Just a check in the tags to see if there's a supplied bean name reference, if there is, allow it to go through. Up to this point I kept it as a best practice to leave the naming of any bean up to the root tag (well, it enforced it really). Means that the requirement of the root tag should probably be loosened up if a bean is explicitly provided. There will possibly be an ambiguity as to how far back the property will be calculated, and the definition of the nested tags being properly marked up. But I'm probably over-thinking the issue. Any other thoughts?... any other committers actually using the nested tags?... :) Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Nested Messages Errors tags applicability...
I'm not 100% I'm sure I'm following what the problem is (probably missed some other e-mails). I was going to talk to you Aaron when I went to do these, but it seemed very simple so I went ahead and made them. I just wanted the nested messages and errors tags to be able to get the property name of the bean so you could display messages and errors next to a field from a list. These tags don't really need any other feature the nested tags provid. Currently the validator can handle lists, but not custom messages for each field. It does correctly create the full property as the error key though so you can display the error next to the field. Here is the example from web/validator/type.jsp where I tested this. nested:iterate property=nameList tr th align=left nbsp; /th td align=left nested:messagesPresent property=value br ul nested:messages id=error property=value libean:write name=error//li /nested:messages /ul /nested:messagesPresent nested:text property=value size=15 maxlength=15/ /td /tr /nested:iterate Let me know what you think. David --- Arron Bates [EMAIL PROTECTED] wrote: Just curious as to the applicability of the Errors an Messages tags in the nested context... Because the nested tags use the one bean reference, I'm finding it hard to visualise using these tags within context. In the original tags, everything was an island, so it was all fine, but nesting against the one bean makes it a little fuzzy. Referencing the different bean means implanting a new root tag, which would mean you'd have to nest the tags all over again to get to the same point. It would be easier to go the route of the original errors/messages tags. I realise that it'd be really handy to be able to get at the same property that a text box is working off of, but the separate bean issue meant that I basically put it down to being out of context and as a result I didn't include them in the tags when I first wrote them. One way I can see it working is to make a small departure from the way the rest of the nested tags work, and allow the referencing of a different bean. This then raises the problem that if you do it for one, you should possibly allow the others. Not impossible. Just a check in the tags to see if there's a supplied bean name reference, if there is, allow it to go through. Up to this point I kept it as a best practice to leave the naming of any bean up to the root tag (well, it enforced it really). Means that the requirement of the root tag should probably be loosened up if a bean is explicitly provided. There will possibly be an ambiguity as to how far back the property will be calculated, and the definition of the nested tags being properly marked up. But I'm probably over-thinking the issue. Any other thoughts?... any other committers actually using the nested tags?... :) 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]
Re: Nested Messages Errors tags applicability...
That all seems cool, and if the test works, all the better :) To confirm what's happening there... It's fetching the nameList.value property off the same bean as the text fields. To read the markup, the messages and errors would then be calling on the same property. 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?... Arron. On Fri, 2002-06-21 at 05:45, David Winterfeldt wrote: I'm not 100% I'm sure I'm following what the problem is (probably missed some other e-mails). I was going to talk to you Aaron when I went to do these, but it seemed very simple so I went ahead and made them. I just wanted the nested messages and errors tags to be able to get the property name of the bean so you could display messages and errors next to a field from a list. These tags don't really need any other feature the nested tags provid. Currently the validator can handle lists, but not custom messages for each field. It does correctly create the full property as the error key though so you can display the error next to the field. Here is the example from web/validator/type.jsp where I tested this. nested:iterate property=nameList tr th align=left nbsp; /th td align=left nested:messagesPresent property=value br ul nested:messages id=error property=value libean:write name=error//li /nested:messages /ul /nested:messagesPresent nested:text property=value size=15 maxlength=15/ /td /tr /nested:iterate Let me know what you think. David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
