HTML Data Table with cell-level inline messages?

Question

Hi all.
I'm not suprised by this, but I am wondering if anyone has figured out a slick/elegant way around the "problem"
Basically, the problem I want to solve is:
how to get corresponding validation error messages to show up in the data table cell that contains the (editiable) ui component representing the "offending" value?
The naive first approach would be simply to place an inline message component just before or after the corresponding data table column's row value presentation component.
But obviously, this won't work, primarily because the inline message component id will not be unique (does not pick up the currentRow to make it unique) asd well as due to the issue of binding the inlineMessage component's "for" attribute to the correct row (as well as column).
So, the naive first approach results in a thrown exception:
javax.servlet.ServletException: Duplicate component id: 'form1:personDataTable:firstNameValidationInlineMessage'
Now, I know I could add "virtual" columns to my data table to hold validation errors so that they correspond to the correct row/columns and I know I can bind the rendered attribute, style etc, for corresponding presentation elements, but then I've basically side-stepped the whole faces message functionality built into the JSF framework.
Also, if I have to use "virtual" columns, then I've complicated life for myself, since I ordinarily want to bind the data table to a list of bean instances (i.e. we are using hibernate persistence) or even a row set (difficulty setting a column value that is not updateable in data source, i.e. corresponds to no table/column and maybe involves dynamically adding "virtual" column to data cache?).
Now, I know I can place a message list on the page instead (this is currently what I am doing), and I know I can change the application so that I provide a separate *single row" edit page, both of which provide a semi-adequate alternative.
I like the first alternative (the one I'm using), because in-place editing of data table rows is so much more compact and elegant, both in terms of presentation and coding.
Using this first alternative, I am currently adding to the validation error messages the currentRow attrubute so that users can see it an trace back to the corresponding row in the data table to correct the data entry.
However, everyone, users, project drivers and developers (including myself), are grumbling a bit over such a "hackish" approach.
Any thoughts? Am I missing something obvious?

Answer 1

Well I'll be damned!
What's done in the sample app is, of course, the intuitively obvious choice and is exactly what I started out trying to do the first time round.
But as I mentioned before, when I first tried it (yes: I'm pretty sure I set the "for" attribute on the inlineMessage components), I got the non-unique component id exception for the inlineMessage component(s) after adding the second (but not the first) row to the page.
Anyway, after dragging my inlineMessages to the exact same position as those in the AppModel example, now things work fine (except I think I'd like a line break before the message and to change the row/column styles so the values and messages line up properly...the look is rather ugly in the AppModel example when there are validation messages displayed).
Not sure, but I'm thinking maybe there was an issue with where the inline message markup was placed, my first time through, relative to the data table value bound component and the column header facet?
I was using the application view drag 'n drop feature the first time round and dragged the inlineMessage component to the spot just below the data table value bound component and hence just above the column header facet. In the AppModel example, OTOH, the inline messages are placed just after the column header facet.
Of course, I will now try to duplicate the original exception.
If I can (and it is an issue with placement), I will post back some sort of bug report or RFE. Otherwise, I'll post back declaring what a bone head I've been...;-)
Anyway, thanks for the quick response, v.
Campbell