using i18n.DataAnnotations . How exactly does it work? - asp.net-mvc-3

I am implementing a multilingual site with asp.net mvc 3.
A friend suggested me this project https://github.com/danielcrenna/i18n
Until now i have succeded to make it work in controllers and views (razor) but not in data annotation.
For example
public class LogOnModel
{
[i18n.DataAnnotations.Email]
[Required(ErrorMessage = "Required Field")]
[i18n.DataAnnotations.DataType(DataType.EmailAddress)]
public string Email { get; set; }
[i18n.DataAnnotations.Required(ErrorMessage = "Required Field")]
[DataType(DataType.Password)]
[i18n.DataAnnotations.Display(Name = "Password")]
public string Password { get; set; }
[i18n.DataAnnotations.Display(Name = "Remember me?")]
public bool RememberMe { get; set; }
}
The above piece of code should produce new entries in .po files , whenever the build is successful. But nothing happens whatsoever.
Is there anybody that has knowledge of this?
Thanks in advance!

I can't comment on the i18n framework you're using from GitHub, but if it helps, there is something similar in .NET. The way you do this in .NET isn't based on .po but on resources compiled into satellite assemblies.
For MVC you can use the DisplayAttribute to specify the type which contains the resource string you wish to use. There are equivalent attributes for validation messages.

It seems that with i18n v1 is not possible to make working i18n.DataAnnotations, I asked as issue at github https://github.com/turquoiseowl/i18n/issues/104

Related

Property marked with JsonIgnore is still shown in Swagger UI documentation for Web API

I'm using Swashbuckle package which integrates swagger with Web API project. I want to hide the property marked as Ignored in the documentation. I tried to use different ways such as IgnoreDataMember, DataContract & DataMember, JsonIgnore or XmlIgnore but nothing seems to work with swagger ui.
However, in default API documentation it works as expected. This is how my model looks like:
public partial class Model : BaseSettingsModel
{
public string ReceiptTitle { get; set; }
[IgnoreDataMember]
public FieldsEnum Fields { get; set; }
public string DisplayFields { get; set; }
}
Moving from version 1.3.0 to 1.3.6 will solve this for you. At least #JsonIgnore and #XmlTransient are being respected.
For JsonIgnore you need to pull in the JSON.net NuGet package.

Create custom login system with FormsAuthentication and more in ASP.NET MVC 3 Razor?

Sorry for the big title.
So I've been doing some research for making login systems. I've already made my own, but discovered a more secure way to do it.
As far as I know, the four basic components of this login system are:
FormsAuthentication
MembershipProvider
RoleProvider
Principal
I have this as my basic user model:
public class User
{
public int ID { get; set; }
public string Name { get; set; }
public string Password { get; set; }
public string PictureUrl { get; set; }
public string Role { get; set; }
public string AccessToken { get; set; }
}
This is just for retaining the data from the database.
I still want to use this model with the components listed above.
Does anyone know a good and thorough tutorial that explains how to create a custom login system using the above components in MVC 3 Razor?
Thanks in advance.
You can build a custom 'login system' by implementing a custom version of MembershipProvider and RoleProvider that uses your own database. Then you can re-use all the rest of the built in authentication and authorization stuff.
MSDN has some details on how to build a MembershipProvider here and details on a custom RoleProvider here. Samples implementations are included.
You can use this open source project :
https://github.com/TroyGoode/MembershipStarterKit

In ASP.NET MVC3 how do you stay DRY with very similar but slightly different viewmodels?

In building an app, we created a generic object model to store some values, the viewmodel looks a bit like this at the moment:
public class FooViewModel {
public int ID { get; set; }
public byte FooType { get; set; }
[Required]
[Display(Name = "Bar Name")]
public string Name { get; set; }
[Required]
public string Email { get; set; }
//etc, etc
}
The problem is: depending on the FooType, we want to have the Display Name to be different and the Email is not required for type 1 and 2, but is required for type 3 and 4.
We tried seperating out the properties that differ per type in to classes that inherit from this one, but the validation does a fallback on what is specified in the base type, so that didn't work.
Currently, the only option seems to be to create a viewmodel for each FooType (and also seperate controllers and view), which leads to a lot of code duplication.
What are other ways to keep this DRY?
To benefit a validation context (e.g. validating objects in different contexts), I strongly recommend using FluentValidation library.
You could implement a custom RequiredIf validation attribute, or you could implement IValidatableObject.

POCO - if POCO means pure .net class with only properties, where i can write validations in MVC

Very new to POCO, find some google links but found many different stories.
Some connected with Entity framework, lazy loading etc. Some says its a pure .det class.
Atleast MSDN.
LINK FOR DEFINE POCO FROM MSDN:
msdn.microsoft.com/en-us/library/dd456872.aspx
I trust MSDN(a simple defination), and assume that it is a pure .NET Class.
Now let me come to the point.
IF it is pure .net class with only properties inside it than it is equilateral to "MODEL" in MVC.
example.
[Required(ErrorMessage = "Full Name required.")]
[StringLength(20, ErrorMessage = "Username must be under 20 chars.")]
public string UserName { get; set; }
[Required(ErrorMessage = "Email required.")]
[RegularExpression(".+#.+\\..+", ErrorMessage = "Email not valid.")]
public string Email { get; set; }
[Required(ErrorMessage = "PassWord required.")]
[StringLength(20, ErrorMessage = "Maximum 20 chars. allow")]
[DataType(DataType.Password)]
public string Password { get; set; }
Upto this level it is clear to me. Now if i want to write my own validation (conditional) in MODEL
using
ValidationAttribute
or
IValidatableObject
this will be not pure .net class if i am not wrong.
example.... (Something like below)
public class Wizard : ValidationAttribute,IValidatableObject
{
public override bool IsValid(object value)
{
return base.IsValid(value);
}
public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
throw new NotImplementedException();
}
[Required(ErrorMessage = "Full Name required.")]
[StringLength(20, ErrorMessage = "Username must be under 20 chars.")]
public string UserName { get; set; }
[Required(ErrorMessage = "Email required.")]
[RegularExpression(".+#.+\\..+", ErrorMessage = "Email not valid.")]
public string Email { get; set; }
[Required(ErrorMessage = "PassWord required.")]
[StringLength(20, ErrorMessage = "Maximum 20 chars. allow")]
[DataType(DataType.Password)]
public string Password { get; set; }
}
Is this the POCO still?
If yes, how can it contains methods.(opposite to MSDN link)
IF NO, where should i write down my validation code (of course conditional validation in MVC).
Looking for a really great answer with an example.
POCOs mean you do not have to inherit from some framework defined base class in order to implement functionality. Basically you are free to design your class hierarchy.
You can add your own methods be it validation or some business logic.
A counter example would be to inherit from EntityObject class for entities in Entity Framework.
The linked article doesn't say that POCO mustn't have methods. Clear description what POCO is can be found on Wikipedia:
... the term is used to contrast a simple object with one that is
designed to be used with a complicated, special object frameworks such
as an ORM component. Another way to put it is that POCOs are objects
unencumbered with inheritance or attributes needed for specific
frameworks.
POCO can have all methods or logic you need. The difference between POCO and non-POCO is that POCO is class you can use always even if you don't use specific framework (EF) but non-POCO can be used only when specific framework is linked or even worse initialized and used.
For purists data annotations violates POCO as well because they also demand specific API but in pragmatic approach data annotations are OK (except special annotations used in EF Code first to define mapping) because they bring dependency only to the way how entity is validated but not the dependency to the way how entity is persisted (non-POCO EF object). Dependency on persistence can demand reference to EF in assemblies where you never expect to use EF - for example presentation layer like MVC application.
Personally I like to make my POCOs partial classes with the basic properties needed to define that model and then put and validation logic in a separate class. e.g:
public partial class Wizard
{
public string UserName { get; set; }
public string EmailAddress { get; set; }
}
and then if I wanted to add validation to UserName:
public partial class Wizard
{
[Required]
[StringLength(20)]
public string UserName { get; set; }
}
I know the complier just amalgamates the two classes anyway and you may be repeating properties but I think its the cleanest approach.
Another option is to use the MetadataType attribute.

Decorating serializable class with extra properties

I'm building a Windows Phone 7 application and I'm trying to decorate a generated class with an additional property to bind against, but I'm a bit puzzled on how to solve this architecturally. What I currently have is this class, which is generated with the xsd.exe tool from an XML file:
[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "4.0.30319.1")]
[System.Diagnostics.DebuggerStepThroughAttribute]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType = true)]
public class Session
{
[System.Xml.Serialization.XmlElementAttribute(Form = System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string Abstract { get; set; }
[System.Xml.Serialization.XmlElementAttribute(Form = System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string Speaker { get; set; }
[System.Xml.Serialization.XmlAttributeAttribute]
public string TimeslotBegin { get; set; }
[System.Xml.Serialization.XmlAttributeAttribute]
public string Location { get; set; }
[System.Xml.Serialization.XmlAttributeAttribute]
public string TimeslotEnd { get; set; }
[System.Xml.Serialization.XmlAttributeAttribute]
public string Title { get; set; }
}
I am fetching the XML from the web and deserializing this with a XmlSerializer, but I want to add an additional property to allow the user to "flag" items in the UI. I want to be able to bind to this property, so it should notify the UI thread when changed.
Any ideas on how to solve this?
For this situation, I'd recommend you separate your Model from your ViewModel.
The ViewModel is a data representation (including bindable properties) specifically designed for your UI.
The Model is the "pure" data representation, specifically designed for modelling your domain and for persistance (either directly to IsolatedStorage or perhaps persisted via a web service)
So, my recommendation is that you build some ViewModel classes for your UI to bind to - and then work out how these ViewModels interact with the Model.
As an aside, I'd also be cautious about using the XSD generated classes within Windows Phone 7 - WP7 seems to prefer the XDocument Linq XML classes, rather than the XmlDocument XML classes (but I may have this wrong!)

Resources