[
https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s...
]
Dan Allen edited comment on SEAMINTL-7 at 11/11/10 2:23 PM:
------------------------------------------------------------
Here's an example of how it might look (revised from Pete's slides)
@StatusReporter
public interface BookingStatusReporter
{
@ReportStatusMessage(level = INFO, defaultText = "You are booked to stay at the
{0} on {1,date}", during = TransactionPhase.AFTER_SUCCESS)
void bookingConfirmed(Hotel hotel, Date date);
}
@Inject BookingStatusReporter status;
...
status.bookingConfirmed(booking.getHotel(), booking.getCheckinDate());
@StatusReporter specializes the functionality of @MessageBundle by stating the intent to
register a status message rather than return a string. It's like @MessageLogger from
weld extensions.
If we want to reuse the @Message annotation from JBoss Logging, then the message method
would instead be:
@Message(level = INFO, value = "You are booked to stay at the {0} on {1,date}")
@ReportStatus(during = TransactionPhase.AFTER_SUCCESS)
void bookingConfirmed(Hotel hotel, Date date);
In the second case, the @ReportStatus a) makes it a status message, b) has some additional
settings (such as when to add the message)
(btw, INFO is the default level, it's just shown for completeness)
I'd really like to see EL evaluation supported in the message string to make it
possible to reference property values. As you can see the above example assumes that
Hotel#toString() returns the name of the hotel. Instead we might do:
@Message(level = INFO, value = "You are booked to stay at the #{argv[1].name} on
{1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS)
void bookingConfirmed(Hotel hotel, Date date);
I use the index of 1 for the first argument because I'm thinking argv[0] can hold the
name of the message key (i.e., method)
As an alternative, we could allow named arguments by annotating the method parameters.
@MessageParam assigns the method argument to the variable specified in the
annotation's value. Then you can reference it in the message string.
@Message(level = INFO, value = "You are booked to stay at the #{hotel.name} on
{1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS)
void bookingConfirmed(@MessageParam("hotel") Hotel hotel, Date date);
The @MessageParam stuff should probably go into JBoss Logging.
was (Author: dan.j.allen):
Here's an example of how it might look (revised from Pete's slides)
@StatusReporter
public interface BookingStatusReporter
{
@ReportStatusMessage(level = INFO, defaultText = "You are booked to stay at the
{0} on {1,date}", during = TransactionPhase.AFTER_SUCCESS)
void bookingConfirmed(Hotel hotel, Date date);
}
@Inject @StatusReporter BookingStatusReporter status;
...
status.bookingConfirmed(booking.getHotel(), booking.getCheckinDate());
@StatusReporter specializes the functionality of @MessageBundle by stating the intent to
register a status message rather than return a string. It's like @MessageLogger from
weld extensions.
If we want to reuse the @Message annotation from JBoss Logging, then the message method
would instead be:
@Message(level = INFO, value = "You are booked to stay at the {0} on {1,date}")
@ReportStatus(during = TransactionPhase.AFTER_SUCCESS)
void bookingConfirmed(Hotel hotel, Date date);
In the second case, the @ReportStatus a) makes it a status message, b) has some additional
settings (such as when to add the message)
(btw, INFO is the default level, it's just shown for completeness)
I'd really like to see EL evaluation supported in the message string to make it
possible to reference property values. As you can see the above example assumes that
Hotel#toString() returns the name of the hotel. Instead we might do:
@Message(level = INFO, value = "You are booked to stay at the #{argv[1].name} on
{1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS)
void bookingConfirmed(Hotel hotel, Date date);
I use the index of 1 for the first argument because I'm thinking argv[0] can hold the
name of the message key (i.e., method)
As an alternative, we could allow named arguments by annotating the method parameters.
@MessageParam assigns the method argument to the variable specified in the
annotation's value. Then you can reference it in the message string.
@Message(level = INFO, value = "You are booked to stay at the #{hotel.name} on
{1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS)
void bookingConfirmed(@MessageParam("hotel") Hotel hotel, Date date);
The @MessageParam stuff should probably go into JBoss Logging.
Rewrite Messages API along the lines of JBoss Logging 3
-------------------------------------------------------
Key: SEAMINTL-7
URL:
https://jira.jboss.org/browse/SEAMINTL-7
Project: Seam i18n
Issue Type: Feature Request
Components: Messages
Affects Versions: 3.0.0.Alpha1
Reporter: Ken Finnigan
Assignee: Pete Muir
Fix For: 3.0.0.Beta1
Rewrite messages API along the lines of JBoss Logging 3 to be consistent with the logging
approach once the switch from slf4j is made to JBoss Logging 3.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira