Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Enum TypeConverter
19 views
Skip to first unread message
Shapper
Nov 12, 2012, 3:15:48 PM11/12/12
to
Hello,
I have the following Enum:
public enum FruitsEnum {
[FruitColor("Red")]
Apple = 1,
[FruitColor("Green")]
Kiwi = 2,
[FruitColor("Yellow")]
Pear = 3
};
The FruitColor attribute is as follows:
public sealed class FruitColorAttribute : Attribute {
public String Color { get; set; }
public FruitColorAttribute(String color) {
this.Color = color;
}
}
I would like to localize the enum and if possible also the attributes.
Is it possible to create a custom TypeConverter for this?
In this TypeConverter a service would be called ...
So when I use GetNames or Parse with the custom type converter the service would translate the Enum to String or the String to Enum.
Does this make sense?
Thank You,
Miguel
I have the following Enum:
public enum FruitsEnum {
[FruitColor("Red")]
Apple = 1,
[FruitColor("Green")]
Kiwi = 2,
[FruitColor("Yellow")]
Pear = 3
};
The FruitColor attribute is as follows:
public sealed class FruitColorAttribute : Attribute {
public String Color { get; set; }
public FruitColorAttribute(String color) {
this.Color = color;
}
}
I would like to localize the enum and if possible also the attributes.
Is it possible to create a custom TypeConverter for this?
In this TypeConverter a service would be called ...
So when I use GetNames or Parse with the custom type converter the service would translate the Enum to String or the String to Enum.
Does this make sense?
Thank You,
Miguel
Peter Duniho
Nov 12, 2012, 6:58:24 PM11/12/12
to
On Mon, 12 Nov 2012 12:15:48 -0800 (PST), Shapper wrote:
> [...]
The usual reason to want to convert an enum value to a string and vice a
versa is when serializing or deserializing. In that scenario, localization
is a bad idea.
On the other hand, the usual reason to want localization is when you need
to display a value to the user (very common), or have the user provide a
localized value (less common). In those scenarios, using a type name or
enum value name from your code to interact with the user is a bad idea.
In other words, whatever the motivation for your request, there's something
bad going on in your design. Once you figure out what's motivating your
request, then you can fix the bad part of the design and move on to an
appropriate solution.
Pete
> [...]
> I would like to localize the enum and if possible also the attributes.
>
> Is it possible to create a custom TypeConverter for this?
>
> In this TypeConverter a service would be called ...
>
> So when I use GetNames or Parse with the custom type converter the service would translate the Enum to String or the String to Enum.
>
> Does this make sense?
I guess that depends on how you're going to use the string.
>
> Is it possible to create a custom TypeConverter for this?
>
> In this TypeConverter a service would be called ...
>
> So when I use GetNames or Parse with the custom type converter the service would translate the Enum to String or the String to Enum.
>
> Does this make sense?
The usual reason to want to convert an enum value to a string and vice a
versa is when serializing or deserializing. In that scenario, localization
is a bad idea.
On the other hand, the usual reason to want localization is when you need
to display a value to the user (very common), or have the user provide a
localized value (less common). In those scenarios, using a type name or
enum value name from your code to interact with the user is a bad idea.
In other words, whatever the motivation for your request, there's something
bad going on in your design. Once you figure out what's motivating your
request, then you can fix the bad part of the design and move on to an
appropriate solution.
Pete
Shapper
Nov 12, 2012, 8:33:33 PM11/12/12
to
Let me better explain what I am looking for.
I have a few SQL Lookup tables: Roles, ...
Usually each table has two columns: ID and NAME.
Consider, as an example, the following:
- Table ROLES with columns ID, NAME and PERMISSIONS.
This one has a rare third column. So I would use:
public enum Roles {
[Permissions("WRD"]
Administrator = 1,
[Permissions("WD")]
Collaborator = 2
}
On my application I would use Roles enumeration.
This would help me avoiding typing problems and so on ...
I always need on my application two fields:
The ID and the NAME. So that is quite close to ENUM.
If I have a need for an extra column I add it as an attribute.
Sometimes the application (usually a web site) is localized.
So my SQL Roles table has 2 or more localized version ...
I would like my Enums to have some kind of localization.
For user display but also for the application usage such as:
EN: /posts/list?r=administrator
PT: /posts/list?r=administrador
I have other lookup tables such as Categories, ...
But those one are dynamic. So they values change.
I am using enumerations only on those tables which do not change and which have influence on how the application behaves, looks, ... Like the User Roles.
I am not sure if ENUM is the best option ... What do you think?
And in relation to translation I can use:
_service.Translate(Roles.Administrator.ToString(), PT).
This would translate the Administrator string to portuguese from the default enum language which is english ...
Maybe this is better instead of integrating the translation completely in the TypeConverter ...
Thank You,
Miguel
Arne Vajhøj
Nov 17, 2012, 10:37:16 PM11/17/12
to
And you do not want to either. Many years ago MS tried to localize
VBA and it was a nightmare to work with.
You can obviously localize when formatting and parsing as
part of UI.
But that will require some special code to do that. Trivial
code but still a bit messy.
You can use the TypeConverter framework for that or you can
use something else.
I don't think I would use TypeConverter. It is coupled and
not so readable as something simpler.
Arne
Arne Vajhøj
Nov 17, 2012, 10:46:44 PM11/17/12
to
On 11/12/2012 8:33 PM, Shapper wrote:
> Let me better explain what I am looking for.
>
> I have a few SQL Lookup tables: Roles, ...
> Usually each table has two columns: ID and NAME.
>
> Consider, as an example, the following:
> - Table ROLES with columns ID, NAME and PERMISSIONS.
>
> This one has a rare third column. So I would use:
>
> public enum Roles {
> [Permissions("WRD"]
> Administrator = 1,
> [Permissions("WD")]
> Collaborator = 2
> }
That is a lot different from your first example.
> Let me better explain what I am looking for.
>
> I have a few SQL Lookup tables: Roles, ...
> Usually each table has two columns: ID and NAME.
>
> Consider, as an example, the following:
> - Table ROLES with columns ID, NAME and PERMISSIONS.
>
> This one has a rare third column. So I would use:
>
> public enum Roles {
> [Permissions("WRD"]
> Administrator = 1,
> [Permissions("WD")]
> Collaborator = 2
> }
> On my application I would use Roles enumeration.
> This would help me avoiding typing problems and so on ...
>
> I always need on my application two fields:
> The ID and the NAME. So that is quite close to ENUM.
> If I have a need for an extra column I add it as an attribute.
>
> Sometimes the application (usually a web site) is localized.
>
> So my SQL Roles table has 2 or more localized version ...
> I would like my Enums to have some kind of localization.
>
> For user display but also for the application usage such as:
> EN: /posts/list?r=administrator
> PT: /posts/list?r=administrador
>
> I have other lookup tables such as Categories, ...
> But those one are dynamic. So they values change.
>
> I am using enumerations only on those tables which do not change and which have influence on how the application behaves, looks, ... Like the User Roles.
>
> I am not sure if ENUM is the best option ... What do you think?
You should not have role in an URL at all. That should be in session.
It should not be localized in the the core application logic
and database only in the UI.
Roles-permissions should not be hardcoded but be configurable.
Roles should not be an enum as that does not allow you to add
new roles without changing the code.
> And in relation to translation I can use:
>
> _service.Translate(Roles.Administrator.ToString(), PT).
>
> This would translate the Administrator string to portuguese from the default enum language which is english ...
>
> Maybe this is better instead of integrating the translation completely in the TypeConverter ...
But maybe even better to use standard resources.
Arne
0 new messages