Hi Gerhard! We already found an easy solution.
I removed the restriction that @MessageBundles are only allowed to return a Message if they have a MessageContext parameter. I found no reason to restrict that. If a user returns a Message intead of a String then we will use the categories 'summary' and 'detail' for creating the FacesMessage. Both fall back to the default value in their property files if they don't have a .summary or .detail entry in that language. If a String is being returned we use it for both summary and detail Strings. This part is already implemented. I'm currently working on the Proxy for creating the JsfMessage<YourMessage> part. LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <[email protected]> > To: [email protected] > Cc: > Sent: Sunday, October 7, 2012 12:37 PM > Subject: Re: proposal for JSF Messages > > i would skip the #getCategory part for now. it's very similar to the > type-safe message-payload used in codi and those parts are quite special > already. > > regards, > gerhard > > > > 2012/10/6 Mark Struberg <[email protected]> > >> 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 >> > >> >
