Showing an IBAN number grouped just with the format property

[Bernd.N]

I would like to store an IBAN properly, i.e. without any blanks, like DE21301204000000015228
The display of the IBAN in the UI should show grouped, like DE21 3012 0400 0000 0152 28

And I would not mind if the input format would also be in groups, as long as the blanks are not stored,
and provided I could still past a full IBAN from clipboard.

Is that possible just with the format property of a TEXT_FIELD?
For number fields, the format property shows both display format and edit format.
But for string fields, the format property shows just the display format, so there is no different edit format.

If it is not possible with the native format property, which method do you suggest to do the grouping in the UI?
Currently I plan to work with two different fields, one edit field and one UI-display-field, the toggle each other’s visibility, plus a function that converts the IBAN-string to a IBAN-grouped-string.

[ROCLASI]

Hi Bernd,

Just use 1 column and use your functions on a column converter. See the column converter properties in the table settings.

Hope this helps.

[Bernd.N]

Thanks for the hint, Robert. When I understand the UI converter concept right, you need two functions which switch values back and forth.

I choosed now to spend a second field that shows the IBAN grouped, so that a user can check the IBAN better, and used a function for converting.
That way a user can take over an ungrouped IBAN with clipboard and have the grouped layout additionally.

/**
 * Returns a string with blanks after each four letters
 * 
 * @author Bernd Korthaus
 * @param {String} string
 * @properties={typeid:24,uuid:"5F11CC03-1D7B-42BB-9B5F-1EA816CC4D94"}
 */
function string_groupByFour(string) {

	// stringTrim is necessary to take away the trailing blank in case the string has x*4 letters,
	// it is used to make it more readable, instead of a second regular expression
	return (string)  ?  utils.stringTrim( string.replace(/(\w{4})/g, '$1 ') )  :  null;
}

[deezzub]

I think that is a good example for bad user interface design.

I have build an IBAN “class” with useful functions for doing things like that.

/**
 * Convert IBAN with spaces to IBAN without spaces.
 * 
 * @param {String} iban
 */
function ibanSeparatedToIban( iban ) {
	return new Iban( iban ).getIBAN( );
}

/**
 * Convert IBAN without spaces to IBAN with spaces
 * 
 * @param {String} iban
 */
function ibanToIbanSeparated( iban ) {
	return new Iban( iban ).getIBANSeparated( );
}

On the field on the form you can use something like the following in the format property.:

{"converter":{"name":"GlobalMethodConverter","properties":{"fromObjectMethodName":"scopes.bossGlobals_finance.ibanSeparatedToIban","toObjectMethodName":"scopes.bossGlobals_finance.ibanToIbanSeparated","type":"TEXT"}}}

[Bernd.N]

Yes I know it’s not the best solution so far.

I would like an input mask like AAAA AAAA AAAA … where the user sees the grouping already while typing the numbers, without having to type the blanks.
Additionally it should be possible to paste in an ungrouped IBAN from clipboard,
and to be perfect it should even handle a grouped IBAN from clipboard and take out the spaces itself.

Seems it is easy to spend half a day on that.

[deezzub]

Bernd.N:
I would like an input mask like AAAA AAAA AAAA … where the user sees the grouping already while typing the numbers, without having to type the blanks.

Yes, it should be possible to define that in the format property. Maybe it is possible, I don’t know. If not, it would be a good feature request.

Bernd.N:
Additionally it should be possible to paste in an ungrouped IBAN from clipboard,
and to be perfect it should even handle a grouped IBAN from clipboard and take out the spaces itself.

If you mean ungrouped like without spaces / grouped like with spaces, then it should work, because in the contructor function of the Iban all spaces are removed.

Bernd.N:
Seems it is easy to spend half a day on that.

Seems so.

[Bernd.N]

I like the solution with showing the IBAN both ungrouped and grouped, because it provides the opportunity to copy each format to clipboard.
There are cases where you need both versions.

My current version is now first taking away any spaces a user typed in to store the IBAN properly, and then showing the grouped version as second field below:

function onDataChangeIBAN(oldValue, newValue, event) {

	persons_to_employees.e_iban = utils.stringReplace(newValue, ' ', '');
	refreshUI();
	return true;
}

function refreshUI() {
	
	_e_iban_grouped = (persons_to_employees.e_iban)  ?  scopes.utils.string_groupByFour(persons_to_employees.e_iban)  :  null;
}

[sbutler]

In your example, your displaying an editable IBAN number without spaces. Then a non-editable IBAN number in grouped format.

It appears that your using a form variable for the non-editable IBAN number in grouped format. I’d suggest using a calculation instead. So, on your employees table, you would have a calc, something like: calc_e_iban_grouped with the calc value of:

return e_iban ? scopes.utils.string_groupByFour(e_iban) : null;

The reasoning here is if you have multiple places in your UI where you will display this value, you can reference the calculation so its only defined once. You also don’t need the onDataChange events triggering the refresh.

If you use the form variable approach, you’ll need to have a form variable on every UI, along with the events triggering the refresh.

Another alternative if you don’t like using calculations is to move some of your logic into the entity scope (which still could call your scopes.utils.string_groupByFour). Essentially, you want to avoid having to declare new methods on every form and new form variables just to display 1 value in a special format.

[Bernd.N]

Good point, Scott, I will switch to a calculation for the grouped IBAN. I actually like them and prefer stored calculations in most cases.
Name would be e_iban_grouped_clcs, but that’s a matter of taste.

The refreshUI()-method was even not correct completely, as it created an error for persons that are not employees and do not have a linked employee-record.
This would have been the correct version:

	if (utils.hasRecords(persons_to_employees)) {
		
		_e_iban_grouped = (persons_to_employees.e_iban)  ?  scopes.utils.string_groupByFour(persons_to_employees.e_iban)  :  null;
	}
	else
	{
		_e_iban_grouped = null;
	}

[sbutler]

Bernd.N:
I actually like them and prefer stored calculations in most cases.

No man should ever speak those words Stored calcs are the devil. There are no good circumstances in which I would suggest that you use them. As you add complexity, they become unreliable and don’t update as often as you want.

[ptalbot]

goldcougar:

Bernd.N:
I actually like them and prefer stored calculations in most cases.

No man should ever speak those words Stored calcs are the devil. There are no good circumstances in which I would suggest that you use them. As you add complexity, they become unreliable and don’t update as often as you want.

I agree. Avoid at all cost!

[david]

goldcougar:
Stored calcs are the devil. There are no good circumstances in which I would suggest that you use them. As you add complexity, they become unreliable and don’t update as often as you want.

Hey! That’s my line

[ROCLASI]

goldcougar:

Bernd.N:
I actually like them and prefer stored calculations in most cases.

No man should ever speak those words Stored calcs are the devil. There are no good circumstances in which I would suggest that you use them. As you add complexity, they become unreliable and don’t update as often as you want.

+1 (x any large number)

[Bernd.N]

However for prototyping stored calcs are great to show fast results to end users, much like Excel, that’s for sure a good application area.

[david]

Bernd.N:
However for prototyping stored calcs are great to show fast results to end users, much like Excel, that’s for sure a good application area.

Unstored calcs is what you should be using for simple fast display of scalar data combinations. If the reason you’re using stored calcs is to arrive at some collection stats, then you should do this with code instead of stored calcs. Stored calcs really are just plain bad practice.

Edit: only semi-decent example of stored calc usage is being able to sort on a calc. For prototyping only or for tables you know are limited in size. We let pass on some of our application meta tables.