Community
Participate
Working Groups
The requested signature of API should address following use cases: 1. Concatenations displayText = someStr1 + someStr2 + someStr3 + ... + someStrN 2. Templated messages - load a message template based on message ID (i.e. "{0} file does not exist") - replace the placeholders (i.e. {0}) with actual data (i.e. c:\file.txt) - create result display string Please observe that Concatenation is a particular case of templated messages, since every concatenation can be represented by template like: {0}{1}{2}{3}...{n} In all those cases it might be important (depending on actual text / data) to enforce text direction or order of tokens for either placeholder or/and entire message. Suggested signature is: applyBidiProcessing(String messageID, String[] placeholdersData, String[] bidiHandlingType) For covering concatenated scenario (#1 above) we will call: applyBidiProcessing(null, placeholdersData, bidiHandlingType) For covering templated message scenario (#2 above) we will call: applyBidiProcessing("ID123456", placeholdersData, bidiHandlingType) Internally API will take into account the information about locale / language since this will affect several aspects of handling (i.e. general direction of the message). Obviously this API is not supposed to be used in EVERY SINGLE context in which message is created. It is very much depends on the type of message and type of data replacing the placeholders. For example: 1. "{0} users are currently logged in" - it is expected that place holder will be replaced with number. Most probably this message should not be processed in any special way. 2. "User {0} deleted file {1}" - when placeholders are replaced we can get something like: "User moshe deleted file c:\file.txt". In this case we most probably would like to enforce text direction for text replacing placeholder {0} and apply structured text handling for data replacing placeholder {1} 3. <name of user> + "-" + "<file path> - in this case we would like to: - enforce text direction for <name of user> - apply Bidi handling for <file path> - assure that for English UI we see: <name of user> - <file path> - assure that for Arabic / Hebrew UI we see: <file path> - <name of user>
Each separate placeholder (as well as the entire message as whole if necessary) can be processed using API described in bug 465495
Which BidiUtils class are you referring to? I suspect this bug does not belong in the framework.
org.eclipse.jface.util.BidiUtils
JFace is Platform/UI. Moved the bug. Bug 465880 is also about combining multiple bidi-processed strings, but in a slightly different setup. Maybe there's some code-sharing opportunity between the two bugs.
(In reply to Markus Keller from comment #4) > JFace is Platform/UI. Moved the bug. > > Bug 465880 is also about combining multiple bidi-processed strings, but in a > slightly different setup. Maybe there's some code-sharing opportunity > between the two bugs. The bug 465880 is about editable control context. API in this bug is working on the string level. Thus there is no any relation besides the fact that Bidi is being handled in both. The only common functionality is usage of low level API injecting UCC into strings. This defect is about handling finite well defined (from programmer perspective) string. Bug 465880 is about potentially infinite sequence of tokens not known to developer in advance. I will add more comments on bug 465880 in the bug thread itself.
Most probably the suggested signature will change based on the widely used coding pattern for handling message formatting. For example: MessageFormat.format("Exception in {0}.performCopy(): {1}", new Object[] { getClass().getName(), e.getTargetException() }) Observe that second argument passed to format function is simply an array of objects which hold values to replace placeholders in the message. Thus previously suggested pattern: applyBidiProcessing( String messageID, String[] placeholdersData, String[] bidiHandlingType); will change to: Object[] applyBidiProcessing ( String typeOfContext, Object ...args); - typeOfContext - is used to distinguish between use cases: message with placeholders vs. concatenations. - Object ... args - unlimited number of arguments associated with either placeholders or concatenated strings. It is always even number since for each placeholder / piece of text, we need to specify which type of handling is required (i.e. text direction enforcement, structured text, no handling). 1. Message with placeholders ----------------------------- Sample call: applyBidiProcessing ( BIDITYPE_MESSAGEWITHPLACEHOLDERS, placeholderData_1, BTD_LTR, placeholderData_2, NULL // for numbers placeholderData_3, STT_FILEPATH); 2. Concatenation of strings ---------------------------- Sample call: applyBidiProcessing ( BIDITYPE_CONCATENATION, firstPieceOfText, BTD_LTR, secondPieceOfText, NULL // for numbers thirdPieceOfText, STT_FILEPATH); The main difference is in the type of result returned by the function. In case of messages it is just array of objects, while in case of concatenations it is array of objects with just one object - String. Taking typical example of message formatting from above: MessageFormat.format("Exception in {0}.performCopy(): {1}", new Object[] { getClass().getName(), e.getTargetException() }) to allow proper Bidi processing in this context we will suggest to change it (for relevant context / messages) as follows: MessageFormat.format("Exception in {0}.performCopy(): {1}", applyBidiProcessing( BIDITYPE_MESSAGEWITHPLACEHOLDERS, getClass().getName(),STT_FILEPATH e.getTargetException(),BTD_DEFAULT)) In case of concatenation, we will need to retrieve first object from the result array which will hold the result String. PS. Important observation, number of arguments to be passed to new function will be always odd and will be at least 3. Each placeholder or piece of concatenated string comes with its type.
Created attachment 253623 [details] new API applyBidiProcessing for formatting messages Hello Markus, Could you please review this patch ? Actually this patch is for both Bug 465495 and Bug 466345. I think it would be much easier for you to review both defects at the same time. Thank you for your review
Created attachment 253627 [details] new API applyBidiProcessing for formatting messages
Dear @markus, any review comments ?
Created attachment 259850 [details] Unit tests for applyBidiProcessing formatting messages API Hello @markus, ' I've created these unit tests to facilitate your review Please let me know if you need anything else Thank you very much for your review
Sorry, I didn't get to this in time for M6, but I'll have a look in M7 and ask for PMC approval for the late API addition.
Thanks Markus ! Appreciate it very much in advance.
Sorry, I have to move this out, just due to lack of time and other higher-priority items.
