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">
</th>
<td align="left">
<nested:messagesPresent property="value">
<br>
<ul>
<nested:messages id="error"
property="value">
<li><bean: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]>
