Because looks like you're focusing on this class now, may I suggest something? In general, Seam is over verbose in showing default messages to the end user. I mean similarities of "Transaction failed", despite the fact that I actually show perfectly precise and meaningful message to user. Most of these default messages has no real sense and should be rather logged at debug level to the log file. But we are forced to shown these messages if only we put h:message on the page :(. Overriding default messages in resources solves nothing here...
Currently I'm dealing with it by overriding Seam's FacesMessages bean with higher precedence and dropping all Seam internal messages to file. Only messages added by my method addPublicMessage() are actually shown to end user.
This realization is clumsy but it allows me to get rid of this unfortunate Seam's default behavior.
Can I suggest following?
1. Either allow to disable default Seam-internals-originated messages (and simply allow them to be logged). Provide a mean to ensure that only messages explicitly produced by developer are shown to user.
or
2. Cross-redirect message preserving in FacesMessages is cool but these methods are private, make addToTasks*() and getTasks*() overrideable, and keep FacesMessages easy overrideable in general.
Przemyslaw Jaskierski [02/Apr/08 11:33 AM]
Pete,
Because looks like you're focusing on this class now, may I suggest something? In general, Seam is over verbose in showing default messages to the end user. I mean similarities of "Transaction failed", despite the fact that I actually show perfectly precise and meaningful message to user. Most of these default messages has no real sense and should be rather logged at debug level to the log file. But we are forced to shown these messages if only we put h:message on the page :(. Overriding default messages in resources solves nothing here...
Currently I'm dealing with it by overriding Seam's FacesMessages bean with higher precedence and dropping all Seam internal messages to file. Only messages added by my method addPublicMessage() are actually shown to end user.
This realization is clumsy but it allows me to get rid of this unfortunate Seam's default behavior.
Can I suggest following?
1. Either allow to disable default Seam-internals-originated messages (and simply allow them to be logged). Provide a mean to ensure that only messages explicitly produced by developer are shown to user.
or
2. Cross-redirect message preserving in FacesMessages is cool but these methods are private, make addToTasks*() and getTasks*() overrideable, and keep FacesMessages easy overrideable in general.
TIA
Regards,
Przemek.
Przemyslaw, why does overriding the default messages in messages.properties not work?
How about
(3) Add priorities like SEAM_INFO. Then you could filter these messages out in your custom FacesMessages class. Seam would translate these to INFO at the view layer. Or some other flag you can access (to avoid overloading the meaning of priority).
Pete Muir [02/Apr/08 11:41 AM]
Przemyslaw, why does overriding the default messages in messages.properties not work?
How about
(3) Add priorities like SEAM_INFO. Then you could filter these messages out in your custom FacesMessages class. Seam would translate these to INFO at the view layer. Or some other flag you can access (to avoid overloading the meaning of priority).
Pete, I guess overriding works (never used it though). Problem is that it is limited to showing generic messages only which were meant for i.e. log-in event or failed transaction. Generic "failed transaction"-like message has no real value/meaning for end user. And there is no strict control on what is shown to user (all these illegal navigation etc he has no clue about).
Your (3) solution is great and very flexible. Another approach to priorities (in contrary to the JSF model) would be to be consistent to Seam components precedence model, all default Seam messages could have SEAM_BUILT_IN priority (with this as a default value, to make it quick to use). Priorities will allow to have an ability to silence all Seam messages in production but keep them for development/prototyping. Let developer decide what he wants to show.
Przemyslaw Jaskierski [02/Apr/08 01:35 PM]
Pete, I guess overriding works (never used it though). Problem is that it is limited to showing generic messages only which were meant for i.e. log-in event or failed transaction. Generic "failed transaction"-like message has no real value/meaning for end user. And there is no strict control on what is shown to user (all these illegal navigation etc he has no clue about).
Your (3) solution is great and very flexible. Another approach to priorities (in contrary to the JSF model) would be to be consistent to Seam components precedence model, all default Seam messages could have SEAM_BUILT_IN priority (with this as a default value, to make it quick to use). Priorities will allow to have an ability to silence all Seam messages in production but keep them for development/prototyping. Let developer decide what he wants to show.
Pete Muir [02/Apr/08 01:59 PM]
With (3) we could of course provide a simple boolean switch that would cater for the common use case of not wanting these messages displayed.
Feature Request
Closed
Major
Abstraction of FacesMessages
