In struts 1 if you try to bind a html:text field directly to an integer in the ActionForm then there isn't a chance to validate it correctly when the user enters a non-numberic value.
If the user enters a non-numberic value, then the integer value is always parsed as 0 before it reaches the validate method.
Is there any way supported way that struts provides to handle this situation? Or do I need to always bind to a String first and then parse into an integer later on?
If I am not mistaken, any thing that comes from the UI is a string, even though you have the variable defined as an integer in your form.
So my suggestion would be to declare the variable as string and parse it according to your need.
Related
If I ommit an optional input parameter in a CRM action call, will this parameter always be null in the Code Activity?
We have a customer which calls a particular CRM action, lets say an update action. The customer wants to be able to pass input parameters as null if the value in the corresponding field in dynamics must be deleted.
the problem i an facing now is that I cannot detect wether the input variable was effectively passed like "parameter_1 = null" or if the parameter itself was not even passed in the action call. the issue is that I cannot delete the value in crm if the input parameter was just not passed. only if the parameter was passed with the value null, I am allowed to delete the field value in crm.
Am I correct assuming that the value of a optional action input parameter is also null if the parameter is not passed at all?
Is there maybe a workaround which enables me to detect wether the value of the input parameter was passed as null instead of beeing ommitted?
something like "undefined" or similar?
You are correct. Input parameters are always present in the IPluginExecutionContext.InputParameters collection passed to the plugin handling your action.
You would need an extra "MyParameterNameSpecified" so to speak to signal if the parameter null value was actually passed.
Another option could be to use a string parameter holding the value passed in JSON-serialized form.
I have the folowing URL:
http://localhost:7975/test?parameter01=X
In my model, parameter01 is a List<int?>. If a non-integer value (e.g., a string) is passed to this parameter, the model binding process sets this value to null.
How do I intercept this as early as possible in the pipeline so I can return a HTTP status and description without handling this condition in the controller action?
Since you have tagged with asp.net-web-api2 I would recommend using Attribute Routing which enables you to constrain the Parameter Type. With this you'd able to switch handling according to the validity of your input. You can read up on this here
A second possibility would be to write a HTTPHandler which tests for valid input information. This one might be a bit trickier.
I try to get the value of an editbox of type Date/Time. If I test it with
getComponent("dateField").value
or
getComponent("dateField").getSubmittedValue();
and print the output to the console. It always returns "null" if the field is empty or
the field does not contain a valide date. Because of this I can't differ between invalide input and empty input.
Is there a way to get the information if the field is empty?
It depends on the refresh phase you're testing.
getValue() will always return blank, because only content that can be converted to the underlying data type will be passed to it. Even if you disable validation, converter checks still run, because serious errors will occur if you try to put "this is not a date" into a Date/Time.
getSubmittedValue() will always be null if you're checking in Invoke Application or Render Response phases. That's because during the Update Model Values phase, the submittedValue property is passed to the value property and the submittedValue property nulled.
If you're checking in a validator, the text value entered by the user has not yet been checked against validation rules (validation) or that it can be converted to the right data type (conversion), so getValue() will return the value stored last time round and getSubmittedValue() will give the string value (e.g. "this is not a date").
So the answer is you should be able tell whether the field is empty in a validator, but bear in mind custom validators only run if you also have a required validator.
I have a question here about html.textboxfor
I knew that we can use Html.TextBoxFor to restrict the size of the user input
Html.TextBoxFor(model => model.EmployerNumber, new {size=3})
But can we configure it to take numeric value only ?
I try to get Html.ValidationMessageFor to throw error when input value is not numeric.
Many thanks.
a textbox accepts text so its not really capable of being limited just to numbers. the best way to do what you want to do is have a model set up that only accepts numeric values and then use client side validation to alert the user that only numeric values are acceptable.
I've a small doubt. I use Spring SimpleFormController with a form backing object.
Let's say my formBackobject has the following member:
- Id
- Name
- Sex
on the jsp page, I only bind name and sex to input field. when i submit the form, the backend controller can remember the value of the id field and so can distinguish whether this is a "new" or "edit' mode.
Could you tell me the trick behind this?
Thanks,
In my opinion you need to override isEqual() and hashCode() function.
In my code I'm generating uuid and assign it to String and then implement isEqual() and hashCode() where I'm comparing these strings.
Such technique is very useful for Hibernate as well and it will assure you that you always generate unique object.
The 'trick' behind is that the form is kept in session. When you submit the form, only 'name' and 'sex' fields are overwritten and Id is left as it is.
It's logical to think that the id is saved in session. you're right. I don't submit the id value, but spring can auto load its value into the id field.
All this is done automatically behind the scene. And that's what caused my confusion since the first place.
Anyway, all of this are assumption made by you and me. It may not be true from the documentation.