Hi there!
Just two possibly incompatible thoughts on that:
1.) What about using regular expressions like you can do in java or perl
with the search string being a regular expression and the replacement
String having the possibility to contain /$1 /$2 /$3 etc. with the
meaning to replace with the match found for the n-th group surrounded by
brackets inside the regular expression?
The Boost library which AFAIK we already use for something else does
contain support for regular expressions.
Have a look at:
http://www.boost.org/libs/regex/doc/index.html
http://www.boost.org/libs/regex/doc/non_standard_strings.html
2.) What about using arrays of Strings as arguments instead of just
Strings? This would be adding the possiblity to replace multiple
patterns at the same time while eliminating your problem one mentioned
as well. And it will likely be faster than multiple calls to one replace
method with different patterns and replacements.
Kind regards,
Bernd Eilers
Stephan Bergmann wrote:
Bjoern Milcke wrote:
Hi Stephan,
<http://www.openoffice.org/issues/show_bug.cgi?id=66621> is a request
to add searchAndReplace functionality to rtl::OUString, giving the
following use case: "Loading strings from a resource file [...]
often requires to replace certain parts of the loaded string with
runtime-dependent content. For instance, a resource might contain an
error message string 'The object $object$ could not be found.', where
$object$ would be filled in at runtime."
Now, being the pain in the neck that I am, I wonder whether solving
the above via a hypothetic
newStr = oldStr.searchAndReplace("$object$", whatever);
would generally be useful. In general, some searchAndReplace would
not work at least in the following two scenarios:
1 When there is more than one token (e.g., "$object1$",I wouldn't
want to d "$object2$", ...) to replace in oldStr, and the
replacements may contain text that looks like one of the tokens (but
must not be replaced).
2 When there is an escape mechanism so that oldStr can contain text
that looks like a token but is not replaced with a token (e.g.,
"\$object1$" would not expand to "\"+whatever, but to verbatim
"$object1$").
IMO, a well-engineered framework to replace parts of resource strings
with dynamic content would allow for both multiple tokens and an
escape mechanism, so could not use the hypothetic rtl::OUString
searchAndReplace.
+1
So, *is* there need for rtl::OUString searchAndReplace?
IMO, no. Especially as I think we wanted to make the OUString const
anyway? AFAIK, the only method that modifies an OUString is operator+.
We should think about removing that and exploit the fact that
OUStrings can never change.
The hypothetical
newStr = oldStr.searchAndReplace("$object$", whatever);
would leave oldStr unchanged (I did not mention that explicitly).
BTW, replacing strings in resources usually means using the tools
String rather than OUString, anyway. So, this would be another
argument for an external helper function that may be offered for both
string types (calling a single implementation).
Although I would vote for an easy-to-use interface. The typical case
is replacing one substring. For this I would like to write a single
(suitably short ;-) ) line of code.
...which is probably hampered by the fact that there is not a single
(well-engineered, see above) convention for such placeholders in
resource strings, but various different ones.
O overall OOo architecture, where art thou?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
