My initial thoughts:
* Agree with Ken, don't see why Bundles needs a @Named
* Bundles is hard to understand, split out forwarding/delegating operations from real
operations (see Google Collections for good examples of this)
* trvially, keySet() will cause a stack overflow right now
* get() will cause a datarace
* BundleTemplateMessage.setLevel should be level()
* weird package structure - crosslinking between status.builder and builder
* possibility to retrieve a templated message direct from EL?
* how do you add a message from any relevant resource bundle?
On 28 May 2010, at 08:11, Ken Finnigan 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:
• I noticed that Bundles contained @Named and was wondering what your thoughts were
about the bundles being directly EL accessible?
• 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?
• What are the benefits to MessageFactory returning concrete implementations as opposed
to the MessageBuilder interface?
• What are the benefits to Messages containing the same methods as MessageFactory,
without them saving the result in the Messages map?
• Should Messages be @ConversationScoped to support parallel requests from the UI?
Yes, interested to hear why this is RequestScoped
• 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?
Ken can you explain more?
If I understood the usage scenarios correctly they would include:
Messages.add(MessageFactory.info(new BundleKey("bundle", "key"),
2).build());
OR
Messages.add(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?
Yes, I think Lincoln has fixed this now.
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.
Ken
Sent from my iPhone
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev