Bugzilla – Full Text Bug Listing
| Summary: | cannot do global replacement in validation properties | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Rafael Chaves <eclipse> |
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 1.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Rafael Chaves
(hit this trying to plug into the orion.navigate.command service) Rafael, have you tried using the "replacements" property? http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Plugging_into_Orion_pages#Validation_Properties Yup, my point is that AFAIK you can't use that to replace a string multiple times.
replacements: [{pattern: "/", replacement: "-"}]
That will work only for the first occurrence of '/'.
If I were going to instantiate a RegExp to perform that substitution as many times as there are slashes in the string, I'd need to use: new RegExp("/", "g"), the default behavior (without the "g" modifier) matches only the first occurrence.
Or am I missing something obvious?
(In reply to comment #3) > Yup, my point is that AFAIK you can't use that to replace a string multiple > times. > > replacements: [{pattern: "/", replacement: "-"}] > > That will work only for the first occurrence of '/'. > > If I were going to instantiate a RegExp to perform that substitution as many > times as there are slashes in the string, I'd need to use: new RegExp("/", > "g"), the default behavior (without the "g" modifier) matches only the first > occurrence. > > Or am I missing something obvious? No, it just sounds like a bug in our implementation. The intention was to have a global replace. I think we just need to modify line 169 of extension commands to include the "g". We must have simple single replacements in our plugins or we would have caught this by now. Can you verify that if you use this line of code you get the behavior you want? If so, I may be able to get this fix into 1.0. validator[validationProperty.variableName] = validator[validationProperty.variableName].replace(new RegExp(from,"g"), to); Won't that break people that would want only the first match to be replaced? Maybe take a third option, "modifiers"? I don't have an actual use case for that myself, the changes you propsed will make my use case work. But I just wonder why the declarative validationProperties mechanism replaced the previous one that existed before 0.5 and supported computing a URL with code. Right now, for a navigator command, the user has two options: the declarative approach, or if that doesn't work, the DIY approach, with a run function. But then the user loses the ability of have using browser links - which means you cannot take the user to another page. (In reply to comment #5) > Won't that break people that would want only the first match to be replaced? > Maybe take a third option, "modifiers"? The spec is pretty fuzzy here, it nearly implies that you would do complete replacement, so now (1.0) would be the time to decide on the expected behavior. But I agree that specifying the modifiers is probably a better choice, especially for "i" which you can't really argue a clear default for. Also, if not specified, we can default to the old behavior. > But I just wonder why the declarative validationProperties mechanism > replaced the previous one that existed before 0.5 and supported computing a > URL with code. The prior approach required the plugin to load to compute the link. That meant that the navigator, for example, was actually loading all plugins that declared links just to build the the links, even if the user never bothered to click on the link. The declarative approach means we can compute all links from service properties, and don't need to load the plugin unless something is actually clicked to do some work. > Right now, for a navigator command, the user has two options: > the declarative approach, or if that doesn't work, the DIY approach, with a > run function. But then the user loses the ability of have using browser > links - which means you cannot take the user to another page. This was the tradeoff. I'm going to propose a fix for RC2 for this (exposing the regexp modifiers)... Rafael, is this important for you for 1.0? Not really, Susan, thanks for checking. I am working around this by passing the original location paths and doing the mapping server side right now. ok, great. Since this will be an "API" addition that won't hurt existing adopters, I'll take a look when 1.0 ships. Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |