small fix on NewTools-Spotter-Processors -> stQuery >> updatefromContext

[SebastianLorenzano]

sometimes, aSpotterContext search can give back a Text object insteaad of a string, which doesn't understand the substrings: message, so I'm making sure that in textParts he always uses texts asString to make sure it doesn't happen :)

[Ducasse]

Ok could you chase why we get a Text instead of String?
You can put a self haltIf: [ x class = Text] this break point will only stop on demand.

[SebastianLorenzano]

@Ducasse For what I've seen, it has to do with the styles it has attached: When you are writing on the playground, it uses a text to be able to carry the style of the string (for eg. when it doesn't find a selector and it paints itself red). So, when you insert the selection, it actually gets a Text instead of a String. It is not a case that happens always but it does happen in those cases, which was throwing me an exception before the change

[Ducasse]

Now I do not get because trimBoth is not defined on Text so it should break here.

[Ducasse]

@SebastianLorenzano
could you do the following:

introduce trimBoth, and friends (trimLeft trimRight I checked) there is trim in Text) to the class Text) with tests?

This way we will have Text and String polymorphic and then we could check all the trim users and get rid of the conversion?
@jecisc What do you think cyril.
We got several bugs because of this.
The trim API was introduced but only in String it was clearly an error.

S.

[jecisc]

I think it makes sense to have trimming in Text. But probably not for spotter. In spotter I'd use an "asString" when we set the value of the field to be sure to manipulate a string everywhere in spotter model. I don't see why Spotter would need the styling

[Ducasse]

Ok I will integrate it.
I did a PR for improving the text API.