TextResource vs Constant

[Lars]

I have a UiBinder file with a button. I want to change the text on the button pro programmatically.

This begs for TextResource, right?

However, do I need to have a .txt file for each string of text that I'll use for the button? e.g.

@Source("MyButtonUp.txt")
TextResources buttonUp();

and

@Source("MyButtonDown.txt")
TextResources buttonDown();

Is there no way to put the strings in the same file (like you can put multiple css rules in one css file by extending CssResource and declaring methods that match up to the style selectors?

Is the solution the 'Constant' interface? (i'm not sure if these can be accessed in the UiBinder.ui.xml template though.

My ideal is a ClientBundle containing something like:
@Source("ButtonStrings.txt")
ButtonText buttonText();
 
 public interface ButtonText extends TextResource {
   String up();
   String down();
}

and the "ButtonStrings.txt" would be something like:
up=i am up
down=i am down

But alas, this does not work. This has gotta be pretty common, no? What's the standard solution here? A txt file for every string?

Thanks in advance,
Lars

[Thomas Broyer]

I'd definitely go for a Constants or Messages interface.

In UiBinder, it works exacltty like an external ClientBundle: <ui:with/> to instantiate (through GWT.create) the interface, and then {theField.theMethod} to access values in attributes (and <ui:text from="{theField.theMethod}"/> otherwise).

[Joseph Lust]

Lars,

Depending how large the text is, the i18n UiBinder tools should work easily for you here. You said the text was for a button, so clearly a large text file is a bit of overkill.

Use the i18n messages interface file. Create a simple properties file such as buttonNames_en.properties, and put all your strings in there. Then just make a matching messages interface. Since you are using the UiBinder, the easiest way to set the values is the <ui:text> and <ui:with> tags (below).

<ui:with field='msg' type='com.project.i18n.ButtonMessages'/> 
	<g:HTMLPanel>
		<ui:text from="{msg.getString}"/>
	<g:HTMLPanel>

Once the code is in the i18n messages file, you can also access it programmatically when you like, such as the following:

private static final ButtonMessages messages = ButtonMessages.Default.getInstance();

public void someMethod() {
	// set string programmatically
	someElement.setInnerText(messages.getString());
}

While this may seem like Java overkill in itself, it is a great thing to have no string literals at all in your project's Java/UiBinder files and will make you happy in the future if you ever need to support other languages.

Sincerely,

Joseph

[Joseph Lust]

To give credit where it's due, TB pointed this out first. I'd scribed the response and then headed home for the evening and then posted. No offense TB.

[Lars]

Excellent advice... Thanks Thomas & Joseph.

I'm assuming when it comes down to deciding b/w using the Constants or Messages interfaces, the decision is based upon whether you need the substitution features available by using messages?

Thanks again,
Lars

[3xM]

you can also access it programmatically like this:

@UiField ButtonMessages msg;

public void someMethod() {
	// set string programmatically

	someElement.setInnerText(msg.getString());
}

[Thomas Broyer]

On Thursday, July 19, 2012 7:12:06 PM UTC+2, Lars wrote:

Excellent advice... Thanks Thomas & Joseph.

I'm assuming when it comes down to deciding b/w using the Constants or Messages interfaces, the decision is based upon whether you need the substitution features available by using messages?

I'd rather base my choice on the type of values: Messages can only have String and SafeHtml, whereas Constants can have numbers and booleans (and lists or maps of them).

If you have only Strings and no parameter, then Constants or Messages will lead to the exact same code. 

[Joseph Lust]

You can mix and match too, as I've see properties files being used to fill Maps the messages interfaces too.

One note however, is that if you place to internationalize a bunch of strings, then you just need to have a .properties file translated and add the language permutation to your module. So, if you go the properites file route, you are i18n ready.

Sincerely,

Joseph