I'm struggling on logic here - can i get some ideas please! :)
basically i have a c# MVC3 application that accepts a huge amount of text (100+ text areas), modifies it, and then outputs it.
i want to check the length of the combined text boxes and have the process fail validation if they are over X length.
the only solution i can think of is by combining all the text into a string server side and get the length. I'm expecting my competitors to fully abuse the system and attempt to overload my servers when i go live, so i want to try and validate on the client side too if possible.
can anyone think of an efficient way to do this (client or server-side if you have a nice idea).
You could use maxlength css property or you could decorate your model with [StringLength] data annotation to check length of the string
Build a custom validator using a technique similar to this answer by Daron Dimitrov. That will do the check on both client and server side and you can use a ViewModel to decorate the attribute to apply to all of the inputs.
Related
My main problem is that i need to be able to have asp.mvc accept the Danish number format (meaning a dot every thousand and a comma seperator). Since i am working on a larger system, I need a more in-depth solution.
The formating problem includes the fact that I need to beable to solve the errorhandling aswell, which does not accept the 0,00 as a number. best case, the solution still maintains the possibility to calculate with the numbers without having to format them each time.
As another point, I need to beable to switch between the English format, meaning (0.00) and the Danish (0,00).
TL;DR
Solve the problem of using a diffrent formatting in mvc asp.net from (en 0.00) to (da 0,00), including errorhandling, still allowing for calculations in jquery or javascript, and the posibility to switch back to the english format (0.00).
What would be the best way to go about this?
Edit: Solved most of it!
To get the View (Jquery validate) to accept comma as a seperator I've inserted "One regexp" from this: http://mfranc.com/javascript/jquery-valdiator-modyfing-decimal-separator/
Adding the custom model binding, provided by #chrispratt solved the problem of the controller receiving the number in the right format.
On top of this I've added code to modify any number entered into an input field into the right format.
Also all numbers and their display formats are checked before being shown. (since some doubles display without ,00)
I think that should be it, now all that remains is to devise some method of switching between languages and formats, which I should beable to manage.
Thanks for the help!
Any help is apprichiated!
Thanks in advance!
I want to compare two date fields that the value in one fields should not be greater than the other. Is there a built-in validator for this? Or if I have to write a custom one could you please guide me to a good article to explain how to write custom validators.
I have never tried it with a date, but the Property Comparison Validator should work for what you are trying to do.
I want to gracefully convert phone number input from my users into a specific phone number format.
I would like convert this with a dataAnnotation, Just as
[dataType(dataType.Date)] displays a dateTime as a string
Ie:
0205938472 into +61205938472
02 0593 8472 into +61205938472
0593 8472 into +61205938472 (I will assume the area code from where
they live or if its a mobile)
02-0593-8472 into +61205938472
Etc, I also want to convert the other direction:
+61205938472 into 02 0593 8472 (Or whatever format i choose)
I want to do this to promote readability for the user but retain a strict data type in the database.
Questions
Is using a dataAnnotation in this manner considered bad practice?
How would I actually write the dataAnnotation( /However you would do it)?
(please include some code)
Edit: to clarify, i do not want someone to write the extension for me, I would just like an example of key pieces of code and implementation.
Please Note
These are Australia, New Zealand and internationally formatted
numbers being stored as internationally formatted numbers.
And International Formatted numbers being converted to Australia, New Zealand or internationally formatted depending on the user's location (which i can determine)
Depending on the UI you're using, you might be able to do this using a:
ASP.NET: Custom binding code (see example)
ASP.NET MVC: ModelBinder
WPF: CustomBinder
Windows Forms: Custom Converters/Editors
As parsing and formatting usually happens in the UI layer, I doubt you will find a solution that works at the data/model layer and which will work universally or which can do more than just validation.
In the data annotations namespace, there is a DataType.PhoneNumber which you can attach to your properties. Though you, yourself, remain responsible to do the parsing and the formatting using the appropriate display technology.
Data annotations and datatype are used for validation, not for converting values. The datatype is mostly used so that the validation knows where to start guessing.
2. That is asking too much for someone to code an extension like that, especially without showing any effort.
You can use DataTypeAttribute like so:
[DataType(DataType.PhoneNumber)]
public string PhoneNumber{get; set;}
say I have a textBox and a property to get and set its value:
public SomeText
{
get { return HttpUtility.HtmlEncode(textBox.Text); }
set { textBox.Text = HttpUtility.HtmlEncode(value); }
}
I have used HtmlEncode to prevent Javascript injection attacks. After thinking about it though I'm thinking I only need the HtmlEncode on the getter. The setter is only used by the system and can not be accessed by an external user.
Is this correct?
A couple points;
First:
You should really only encode values when you display them, and not any other time. By encoding them as you get the value from the box, and also when you paste in, you could end up with a real mess, that will just get worse and worse any time someone edits the values. You should not encode the values (against HTML/Javascript injection - you DO need to protect against SQL injection, of course) upon saving to the database in most cases, especially if that value could later be edited. In such a case, you actually need to decode it upon loading it back... not encode it again. But again; it's much simpler only to encode when displaying it (which includes displaying for editing, btw)
Second:
HtmlEncode protects against injecting HTML - which can include a <script> block which would run Javascript, true. But this also protects against generally malicious HTML that has nothing to do with Javascript. But protecting against Javascript injection is almost a different thing; that is, if you might ever display something entered by the user in, say, a javascript alert('%VARIABLE'); you have to do a totally different kind of encoding there than what you are doing.
Yes. You only need to encode strings that you have accepted from the users and you have to show inside your pages.
I have set the MaxLength property of a textbox in my windows forms application to 10
I am populating the textbox by reading from a file. However if a read string which is more than 10 characters the textbox still gets populated. But when I manually try to enter a string it works fine (that is, it does not allow more than 10 characters to be entered).
Why is there a difference between these two behaviors? How can I populate my textbox from the file and still have the MaxLength property to be working?
Thanks,
Viren
From the TextBoxBase.MaxLengthProperty specs:
In code, you can set the value of the Text property to a value that has a length greater than the value specified by the MaxLength property. This property only affects text entered into the control at run time.
In other words, you must limit the amount of text in code when pulling from a data source.
For Example:
string text = "The quick blue smurf jumped over the brown fox.";
textBox1.Text = text.Substring( 0, textBox1.MaxLength );
It's never wise to rely entirely on instant validation of values - you should always validate the final value as well. For example, i've seen people regularly using KeyUp/KeyDown/KeyPress events to disallow various characters, and then forgetting that people regularly use copy-and-paste (which negates the intended validation).
You'll have to limit it programatically. That's simply the way the browsers treat HTML. Sorry :(
Unfortunately, the HTML spec doesn't offer any guidance on this issue (that I can find) so the browser makers have settled on this behavior.
http://www.w3.org/TR/html401/interact/forms.html#h-17.4
At the very worst, you could try to limit your data to 10 characters when you are binding to the textbox:
txtMyTextbox.Text = Left(myData, 10)