I agree with Christian. From a developer perspective you will just use some
abstract "{PAGEX_USER_NOT_ALLOWED}" and define the parameters. The developer
usually doesn't care about the exact wording anyway ;)
For the 3.) I think you should just use 2 different message template
identifiers.
LieGrue,
strub
----- Original Message -----
> From: Christian Kaltepoth <[email protected]>
> To: [email protected]
> Cc: Mark Struberg <[email protected]>
> Sent: Saturday, October 6, 2012 11:42 AM
> Subject: Re: proposal for JSF Messages
>
> Hey Bernard,
>
> I think the user shouldn't actually care about 1) and 2). IMHO the main
> point is to hide these details from the actual business code. In your code
> you just say "send message X to the user". If summary and details are
> the
> same or not shouldn't be relevant at this point.
>
> Just my feelings regarding this. :)
>
> Christian
>
>
> 2012/10/6 Bernard Łabno <[email protected]>
>
>> Mark,
>>
>> As I've cited
>> hello_you = Hello You
>> hello_you.detail = Good evening Ladies and Gentlemen!
>>
>> Imagine i'm user. Now i have such questions:
>> 1) Does msg.addError().userNotAllowed(loggedInUser) set summary or details?
>> 2) Hm i've set summary, how do I set details? The API doesn't tell
> me this,
>> I have to reference some manuals to learn how to set details.
>> 3) What if (in one case in entire app) I want to set summary with key
>> {hello_you} and details from {goodbye_you}? In the rest of app I could use
>> approach as you've proposed, but this once i want to do custom?
>>
>> Please, do not take this as criticism, it's just my gut feeling.
>>
>> 2012/10/6 Mark Struberg <[email protected]>
>>
>> > Hi Bernard!
>> >
>> > which part of it do you consider as magic?
>> >
>> > I think the Message.getCategory(String) is fine (feel free to suggest
> a
>> > better name for the method)
>> > A category is just a different resource pattern for the same
> parameters.
>> > Like short text and long text of the same message.
>> >
>> > Imagine a user makes
>> >
>> > @Inject JsfMessage<MyCheckMessages> msg;
>> >
>> >
>> > msg.addError().userNotAllowed(loggedInUser);
>> >
>> > which would automatically use the property without as fallback and the
>> > categories 'summary' and 'detail' for creating the
> FacesMessage.
>> > Those 2 categories are of course a contract of the JsfMessage
>> > implementation.
>> >
>> >
>> > But even for non JSF messages it would make sense.
>> >
>> > @Inject MyCheckMessages msg;
>> >
>> > msg.userNotAllowed(loggedInUser).getCategory('shortText');
>> >
>> > The category String should be a well documented final static String
>> > somewhere of course.
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> >
>> >
>> > >________________________________
>> > > From: Bernard Łabno <[email protected]>
>> > >To: [email protected]; Mark Struberg <
>> [email protected]
>> > >
>> > >Sent: Saturday, October 6, 2012 8:49 AM
>> > >Subject: Re: proposal for JSF Messages
>> > >
>> > >
>> > >Mark,
>> > >
>> > >Most of ideas are great, but I think that following will be
> considered
>> as
>> > "magic" (too magic) by users.
>> > >
>> > >
>> > >for a "{hello_you}" you can have entries in your
> properties file
>> > >>
>> > >>hello_you = Hello You
>> > >>hello_you.detail = Good evening Ladies and Gentlemen!
>> > >>
>> > >
>> > >
>> > >2012/10/5 Mark Struberg <[email protected]>
>> > >
>> > >Yes, that was the final idea.
>> > >>
>> > >>I originally thought about extending the @MessageBundle and
> let the
>> > interface optionally return a String[]. But I think this is too
> complex
>> to
>> > get right
>> > >>
>> > >>Instead I'd rather introduce a
>> > >>Message#toString(String category); and
>> > >>
>> > >>Message#toString(MessageContext context, String category);
>> > >>
>> > >>for a "{hello_you}" you can have entries in your
> properties file
>> > >>
>> > >>hello_you = Hello You
>> > >>hello_you.detail = Good evening Ladies and Gentlemen!
>> > >>
>> > >>
>> > >>If a user just returns a String in his interface, then both
> detail and
>> > summary will be set with the same text
>> > >>If a user returns a Message, then we can look deeper.
>> > >>
>> > >>LieGrue,
>> > >>strub
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>----- Original Message -----
>> > >>> From: Gerhard Petracek <[email protected]>
>> > >>> To: [email protected]
>> > >>> Cc:
>> > >>> Sent: Friday, October 5, 2012 9:57 PM
>> > >>> Subject: Re: proposal for JSF Messages
>> > >>>
>> > >>>t he example provided by mark could add a global message
> with the same
>> > >>
>> > >>> summary- and detail-message.
>> > >>> -> we just need those methods with additional
> parameters.
>> > >>>
>> > >>> regards,
>> > >>> gerhard
>> > >>>
>> > >>>
>> > >>>
>> > >>> 2012/10/5 Ken Finnigan <[email protected]>
>> > >>>
>> > >>>> Some additional plans for messages that may be
> relevant to JSF have
>> > been
>> > >>>> documented in [1].
>> > >>>>
>> > >>>> In Seam 3 International we had some ideas around
> targeting a
>> message
>> > at a
>> > >>>> specific component which are noted here [2].
>> > >>>>
>> > >>>> Ken
>> > >>>>
>> > >>>> [1]
>> > >>>>
>> > >>>>
>> > >>>
>> >
>>
> https://cwiki.apache.org/confluence/display/DeltaSpike/Message+Module+Drafts
>> > >>>> [2]
>> > >>>>
>> > >>>>
>> > >>>
>> >
>>
> https://issues.jboss.org/browse/SEAMINTL-7?focusedCommentId=12562378&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12562378
>> > >>>>
>> > >>>> On Fri, Oct 5, 2012 at 3:18 PM, Gerhard Petracek
> <
>> > >>>> [email protected]
>> > >>>> > wrote:
>> > >>>>
>> > >>>> > hi jason,
>> > >>>> >
>> > >>>> > that's for sure just a first idea.
>> > >>>> > e.g. we also need the possibility to add
> messages for a specific
>> > >>>> component.
>> > >>>> >
>> > >>>> > regards,
>> > >>>> > gerhard
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> > 2012/10/5 Jason Porter
> <[email protected]>
>> > >>>> >
>> > >>>> > > On Fri, Oct 5, 2012 at 11:24 AM, Mark
> Struberg
>> > >>> <[email protected]>
>> > >>>> > wrote:
>> > >>>> > >
>> > >>>> > > > Hi folks!
>> > >>>> > > >
>> > >>>> > > > I thought quite some time about how
> we could do the typesafe
>> > >>> messging
>> > >>>> > for
>> > >>>> > > > JSF. Today I had the following idea.
>> > >>>> > > >
>> > >>>> > > >
>> > >>>> > > > Imagine a typesafe message
>> > >>>> > > >
>> > >>>> > > > @MessageBundle
>> > >>>> > > > public interface SimpleMessage
>> > >>>> > > > {
>> > >>>> > > > @MessageTemplate("Welcome to
> %s")
>> > >>>> > > > Message welcomeTo(String name);
>> > >>>> > > > }
>> > >>>> > > >
>> > >>>> > > > This is nice but it's hard to use
> it for creating
>> > >>> FacesMessages that
>> > >>>> > way.
>> > >>>> > > >
>> > >>>> > > > Now imagine the following
>> > >>>> > > >
>> > >>>> > > > @Inject
>> > >>>> > > > JsfMessage<SimpleMessge>
> message;
>> > >>>> > > >
>> > >>>> > > > ...
>> > >>>> > > >
>> > >>>> > > >
> message.addInfo().welcomeTo("DeltaSpike);
>> > >>>> > > >
>> > >>>> > > >
>> > >>>> > > >
>> > >>>> > > > public interface JsfMessage<T>
> {
>> > >>>> > > > T addInfo();
>> > >>>> > > > T addWarning();
>> > >>>> > > > T addError();
>> > >>>> > > > void clear();
>> > >>>> > > > }
>> > >>>> > > >
>> > >>>> > > >
>> > >>>> > > > I think it is possible to implement
> this, right?
>> > >>>> > > >
>> > >>>> > > > Wdyt from a users perspective?
>> > >>>> > > >
>> > >>>> > > > LieGrue,
>> > >>>> > > > strub
>> > >>>> > > >
>> > >>>> > > >
>> > >>>> > > This looks like a great start. In IRC we
> discovered we need to
>> > >>>> determine
>> > >>>> > if
>> > >>>> > > the text goes to the summary or detail. We
> already have the
>> > >>> severity
>> > >>>> with
>> > >>>> > > the methods. I'd suggest having each
> of those methods take an
>> > >>> enum
>> > >>>> > (DETAIL,
>> > >>>> > > SUMMARY, BOTH or similar). One drawback I
> see about this is you
>> > >>> can't
>> > >>>> > > define a different message for the detail
> and the summary on
>> one
>> > >>> line,
>> > >>>> > but
>> > >>>> > > that may not be the end of the world.
>> > >>>> > >
>> > >>>> > > --
>> > >>>> > > Jason Porter
>> > >>>> > > http://lightguard-jp.blogspot.com
>> > >>>> > > http://twitter.com/lightguardjp
>> > >>>> > >
>> > >>>> > > Software Engineer
>> > >>>> > > Open Source Advocate
>> > >>>> > > Author of Seam Catch - Next Generation
> Java Exception Handling
>> > >>>> > >
>> > >>>> > > PGP key id: 926CCFF5
>> > >>>> > > PGP key available at: keyserver.net,
> pgp.mit.edu
>> > >>>> > >
>> > >>>> >
>> > >>>>
>> > >>>
>> > >>
>> > >
>> > >
>> > >
>> >
>>
>
>
>
> --
> Christian Kaltepoth
> Blog: http://chkal.blogspot.com/
> Twitter: http://twitter.com/chkal
>
