-
1. Re: rich:messages enhancement
nbelaevski Feb 25, 2009 10:26 AM (in response to hanafey)Hello,
I've filed RFC on that: https://jira.jboss.org/jira/browse/RF-6436 -
2. Re: rich:messages enhancement
hotngui May 13, 2010 6:18 PM (in response to nbelaevski)I'll throw in my two cents here...
What I would find very useful is that the "for=" attribute could take wildcards, something akin to "MyFom:MyTable:*"
I have the situation a lot where I have tables containing input fields that have validators. There is never room in the cells for the various error messages, so I would to put them in a place close to the table. The clincher is that I often have multiple tables on a page - and I want to keep the messages for a table close to that specific table (hence catching global messages in a common place not viable).
Joey
-
3. Re: rich:messages enhancement
ilya_shaikovsky May 14, 2010 2:46 AM (in response to hanafey)I'm not aginst the proposal and agree with Nick's issue risen.. but in general globalOnly attribute could do the work for you. message pointed to component with for - will show concrete components messages and rich:messages with globalOnly set will show the global ones.
-
4. Re: rich:messages enhancement
hotngui May 14, 2010 4:09 PM (in response to ilya_shaikovsky)Hi Ilya,
Hopefully the image below (I also attached the image file in case) clarifies what my needs are and why the current "for=" functionality is insufficient. The image is hacked up from a page that shows more input fields, but I had to hide some information that was propierty to our customer.
You can see I have several tables on the page, each one contains multiple input fields, any of which could cause validation errors. The only two options now is to use rich:messages with globalOnly=true or rich:messages with for=somecomponent. Neither of these is sufficient because globalOnly=true would cause the messages to be show above all the tables, and for= does not work because I can point at coding time to the complete list of input field IDs since the data is dynamically populated.
That is why I think expanded for= to accept wildcards, or at least parent component specifiers are necessary. So I can have:
rich:messages for="SoftIPTable:*"
rich:messages for="HardIPTable:*"
rich:messages for="ERAMTable:*"
to localize the destination of messages originating from fields in each of the individual tables.
Keep in mind, I am far from being an expert with JSF or RichFaces.
-
screenshot2.jpg 955.2 KB
-