[seam-dev] Messages API in i18n

[Lincoln Baxter, III]

Hi Ken, no worries. It took a while to get the API's worked out ;) See my
responses inline.

On Fri, May 28, 2010 at 3:11 AM, Ken Finnigan <ken.finnigan at sorstech.com>wrote:

> Hi Lincoln,
>
> Sorry for taking so long to respond to your email!
>
> I've taken a look at the Messages code you committed the other day and I
> had a few questions about some areas that I didn't quite understand in
> reading the code:
>
>
>    1. I noticed that Bundles contained @Named and was wondering what your
>    thoughts were about the bundles being directly EL accessible?
>
> This is to provide i18n support directly in EL-like use-cases, such as
Facelets:

<h1>#{bundles.headers.loginHeader}</h1> -- Dan could highlight that use case
a bit more. Dan?


>
>    1. With BundleMessage I wasn't sure if it was purely the Builder
>    pattern that dictated that the BundleKey was set through a method call as
>    opposed to on the constructor or whether there was another reason?
>
>
Yeah, since we're using the Builder pattern, everything gets set through a
setter. It makes the usage consistent, otherwise you'd have 50 constructors
;) I went with the builder pattern because I didn't want method explosion.


>
>    1. What are the benefits to MessageFactory returning concrete
>    implementations as opposed to the MessageBuilder interface?
>
> Well, MessageBuilder interface only defines the "public Message build()"
method, which is how builders actually produce the Message to be stored - so
in order to expose the APIs for building a TemplateMessage or a
BundleTemplateMessage, the actual Impls needed to be returned. Now.. one
option is to convert TemplateMessage and BundleTemplateMessage into
interfaces, and move the Impls to the impl module. That's not a bad idea,
actually. Then we wouldn't need to use Class.forName() in order to get the
MessageImpl.


>
>    1. What are the benefits to Messages containing the same methods as
>    MessageFactory, without them saving the result in the Messages map?
>
> Just to avoid confusion, but this API has actually changed slightly so that
the messages are indeed added :)

messages.info("This message gets added now!").targets("someComponent");


>    1. Should Messages be @ConversationScoped to support parallel requests
>    from the UI?
>
> Actually, I think @RequestScoped is the best option. It should be up to the
consumer of the Messages to make sure that they are propagated to whatever
framework is necessary. That's an interesting question though... since
@ConversationScoped is @RequestScoped unless marked as long running. It
could provide an interesting feature, but perhaps one that is confusing. I'm
open to discussion on the use-cases... but at the moment,
@ConversationScoped only works in JSF, so I think @RequestScoped is the
right choice.

I just wrote a new JSF scope that lasts "Until the next Render", so the
MessagesAdapter in the Faces Module would be responsible for transferring
messages into that scope. Several potential names for this scope:
@FlashScoped, @InteractionScoped, @LogicalRequestScoped.


>
>    1. If I've understood the code any message bundles that contain
>    properties need to be specified as strings in code.  Was there any thought
>    of using XML Config to read them in, as this was something Dan and I had
>    discussed in the past?
>
> I'm not sure I'm following you here. Could you explain? I don't think I've
heard this :)


> If I understood the usage scenarios correctly they would include:
>
> Messages.add(MessageFactory.info(new BundleKey("bundle", "key"),
> 2).build());
>

Now:
Messages.info(new BundleKey("bundle", "key"), 2);


> OR
>
> Messages.add( <http://MessageFactory.info/>MessageFactory.info(new
> BundleKey("bundle", "key"), 2));
>
> OR
>
> Creating an instance of MessageImpl directly and set the values before
> passing it to Messages.add();
>
> Could just be me, but these seem quite wordy just to add a message to the
> UI?
>

Still wordy? :)


>
> What I am planning is to prototype what I have been thinking of doing,
> using what you've already done as inspiration.
>
> What are your thoughts on other features that should be in an Alpha 1 of
> i18n?  I've got no problem with releasing Alpha 1 with the Messages API you
> and Dan came up with to give me more time to think of possible alternatives.
>

I think we're ready for an Alpha after a little housekeeping. We just need
the documentation / reference guide. We can steal the Faces Reference guide
as a starting point.

>
> Ken
>
> Sent from my iPhone
>



-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100528/b5765cad/attachment-0001.html