Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make StringFormatter trim value #3

Closed
wants to merge 1 commit into from
Closed

Make StringFormatter trim value #3

wants to merge 1 commit into from

Conversation

addshore
Copy link
Contributor

No description provided.

@@ -30,7 +30,7 @@ public function format( $dataValue ) {
throw new InvalidArgumentException( 'DataValue is not a StringValue.' );
}

return $dataValue->getValue();
return trim( $dataValue->getValue() );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: Can't be null, no check needed.

@JeroenDeDauw
Copy link
Member

-2. Absolutely not. You cannot simply change the contract of a class used by other components like this. I'm also somewhat dubious on doing trimming like this in a formatter - though am not going to object against strongly against having one that does that in Wikibase.

@thiemowmde
Copy link
Contributor

I think this is a misunderstanding. Compare to the other ValueFormatterBase based classes. They return formatted dates and such. What do you expect from a formated generic string? Trimming sounds very reasonable to me. If this class does nothing what's the reason to have it in the first place?

One thing confuses me, though: The format() calls in other ValueFormatterBase based classes return HTML. Shouldn't this return htmlspecialchars( trim( ... ) )?

@thiemowmde thiemowmde reopened this Mar 4, 2014
@JeroenDeDauw
Copy link
Member

It is a misunderstanding yes, though not from my side.

Compare to the other ValueFormatterBase based classes. They return formatted dates and such.

Indeed.

What do you expect from a formated generic string?

This class is essentially an adepter.

Trimming sounds very reasonable to me.

It is, and creating a formatter that does it is reasonable as well.

The problem with this change is that it changes the default behaviour of the class. That change makes sense for the use we currently make of this class in our project. It does not automatically make sense for all users though. (And we are already no longer the only user of this code.) If this went in like this, you'd have a breaking change which is not documented, which is quite subtle and can cause data loss in applications making use of this component.

One thus needs to avoid changing the default behaviour, which can be done by creating a new class or by adding options. (The former option probably being the better.)

@JeroenDeDauw
Copy link
Member

I am also curious: why are we putting trimming in a formatter to begin with? If we have a string in our db with a space, then why would we not want to show it? It seems to me that if we would not want to show it, we'd not want to have it in the db to begin with.

@addshore
Copy link
Contributor Author

addshore commented Mar 4, 2014

These are the things I raised when wikimedia/data-values-value-view#20 was initially proposed.
I think we should just get rid of the trimming all together.
' ' is a valid value for a string >.> if we have spaces in the DB we should show them rather than hiding them!

@JeroenDeDauw
Copy link
Member

Ok, closing again since it looks like both implementation and the concept are flawed. Only reopen if you provide a reason why the concept is not flawed, and intend to fix the implementation issues

@Ladsgroup Ladsgroup deleted the stringTrim branch July 24, 2017 06:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants