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_st
rings.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: interface-discuss-unsubscribe openoffice.org
For additional commands, e-mail: interface-discuss-helpopenoffice.org
|