that's why i said: "i would skip the #getCategory part for now." regards, gerhard
2012/10/7 Mark Struberg <[email protected]> > The default categories in JsfMessage will be constants. > This is the most flexible and least restricting way. > > We could introduce an own Category interface. That would work as well, but > then we wont be able to easily implement dynamic categories. > Also the mapping is a String inside the property file or database anyway. > You would then need to define another mapping to a String in any case. > Imo this is not worth all the effort. But I'd be happy for a review and of > getting more pros and cons. > We should just try to avoid overcomplicating it. If people think there is > a good reason for an own Interface than it's easy to add it. I'm just not > sure about the value it brings. > > > LieGrue, > strub > > > > ----- Original Message ----- > > From: Gerhard Petracek <[email protected]> > > To: [email protected] > > Cc: > > Sent: Sunday, October 7, 2012 1:01 PM > > Subject: Re: proposal for JSF Messages > > > > @ "We already found an easy solution.": > > > > can't be, because this discussion wasn't even near to be finished. > > > > @"This part is already implemented.": > > > > i saw it - to say it differently: -1 to category as a string > > (back then that was also part of the discussion about the bv constraint > > payload.) > > > > regards, > > gerhard > > > > > > > > 2012/10/7 Mark Struberg <[email protected]> > > > >> 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 > >> >> > > >> >> > >> > > >> > > >
