-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Added new Converters. #462
Conversation
…meToResourceStringConverter.
Hi @TommasoScalici, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution! TTYL, DNFBOT; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I agree with these converters being sealed either.
@@ -0,0 +1,62 @@ | |||
// ****************************************************************** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I see the point of this converter. Why not just do the formatting in the viewmodel, that's what it's for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, actually I usually use this to comply the absence of the StringFormat Markup Extension. Usually in WPF you format data in XAML binding in that way, and honestly, I always thought that formatting data is something more related to the View than the ViewModel, since it deals with how you present data and not how you stored it.
By the way this can be more useful if generalized to be used with any data type.
But I can also remove it if anyone doesn't feel the need of a StringFormat substitute.
I agree with you on classes not to be sealed, so I removed the sealed modifier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The good thing about binding is that view just consumes what viewmodel exposes. yes often it is painful.. we have come a long way from WPF (in ways).. XAML is somewhat different plus default patterns is MVVM which tends to take a lot of load off the Views.
Since data is being bound to controls, i'd imagine most work is being done on UI thread. You dont really need StringFormat to run on UI thread.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find converters like this super useful. It seems silly to me to put all of these formatted strings into my ViewModel code. The ViewModel holds the absolute data, and then the View decides "Oh hey, this number will only have 2 decimal points of precision" or "this date will just say Mon rather than Monday"
My apps have always had converters like this. So I'm throwing my vote in for including this converter! But if this is actually a bad pattern and those conversions are actually supposed to happen in the ViewModel (despite how unintuitive that seems to me), maybe I'm wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the ViewModel is supposed to be where what controls how the data is presented to the view.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Scott but I do not want the toolkit to be MVVM only or whatever. So for people not using MVVM or not wanting to do conversion in the ViewModel I'm also voting to add these converters to the toolkit
But you will need to update the doc to get the final validation :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all your opinions, I updated the docs, tell me if there's something else I'm missing.
Also, after this discussion and what @Anbare said, I thought it would have more sense to have a converter that can format any kind of type, not only DateTime/DateTimeOffset. So I came up with this: FormatStringConverter.
using Windows.ApplicationModel.Resources; | ||
using Windows.UI.Xaml.Data; | ||
|
||
namespace TommasoScalici.UWPConvertersAndUtilities |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Namespace needs correcting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Namespace corrected.
/// </summary> | ||
public sealed class ResourceNameToResourceStringConverter : IValueConverter | ||
{ | ||
private readonly ResourceLoader resourceLoader = ResourceLoader.GetForViewIndependentUse(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
private fields should begin with a _
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added underscore.
/// <returns>The string corresponding to the resource name.</returns> | ||
public object Convert(object value, Type targetType, object parameter, string language) | ||
{ | ||
return resourceLoader.GetString(value?.ToString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is GetString safe to pass null into it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not safe at all since the method will throw an exception if null is passed. I'll add a null check.
@TommasoScalici, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR. |
Like the FormatStringConverter.. |
return value; | ||
} | ||
|
||
return formattableValue.ToString(parameter as string, null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If parameter is null or not a string, will this explode? If so, we should probably either return the value if parameter isn't a string, or have it throw an ArgumentException... I'd vote for returning the value (same as if formattableValue == null).
if (formattableValue == null || !(parameter is string))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, didn't think of this possibility. I'd also vote to return the value.
Besides formattableValue, create If format is null, return original value Cast using as save check for null is somewhat better than |
I agree, this is usually the way I do. |
Hi, I just noticed that the new converters are nice and all but they're not built :). |
they are not linked.. they are excluded but in folder |
Woot..This is a big miss |
We need to do a PR to merge them back |
okay on it |
Missing converters from PR #462
good spot @JulienTheron these are now include.. you could get a myget build soon with these inside |
Nice! Thanks. |
Added BoolNegationConverter, DateTimeToStringConverter and ResourceNameToResourceStringConverter.
I use very often these converters during my UWA development, so I though that may be useful to have them in the community toolkit.
Names and XML summaries should be enough self-explainatory on what they do.
Let me know what do you think.