deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: proposal for JSF Messages
Date Sat, 06 Oct 2012 11:56:56 GMT
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 <christian@kaltepoth.de>
> To: deltaspike-dev@incubator.apache.org
> Cc: Mark Struberg <struberg@yahoo.de>
> 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 <s4237@pjwstk.edu.pl>
> 
>>  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 <struberg@yahoo.de>
>> 
>>  > 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 <s4237@pjwstk.edu.pl>
>>  > >To: deltaspike-dev@incubator.apache.org; Mark Struberg <
>>  struberg@yahoo.de
>>  > >
>>  > >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 <struberg@yahoo.de>
>>  > >
>>  > >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 <gerhard.petracek@gmail.com>
>>  > >>> To: deltaspike-dev@incubator.apache.org
>>  > >>> 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 <ken@kenfinnigan.me>
>>  > >>>
>>  > >>>>  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 
> <
>>  > >>>>  gerhard.petracek@gmail.com
>>  > >>>>  > 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 
> <lightguard.jp@gmail.com>
>>  > >>>>  >
>>  > >>>>  > > On Fri, Oct 5, 2012 at 11:24 AM, Mark 
> Struberg
>>  > >>> <struberg@yahoo.de>
>>  > >>>>  > 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
> 

Mime
View raw message