[CLOSED] TextField converts value to int, but when starts with zero becomes null

[bbros]

Hello, I get a buggy behavior in TextField and I don't know how avoid it.
I choose a TextField in order to put a string value in it, but if the value could be parsed to number it will be serialized as number.

Moreover (from bad to worse) there is another point which makes the control unusable; when its value starts with "0" or the "+" sign, the value won't be posted.
The control should contain phone numbers...

TextFieldWithLeadingZeros.cshtml


@page
@model ExtCookbook.Pages.TextFieldWithLeadingZerosModel
@{
}
<ext-section target="Main">
<ext-container region="Center" scrollable="true" paddingAsString="30 20 30 50">
<content>
<h1>TextField converts to int</h1>
Try the different behavior typing "123" first, and then "0123".
<ext-container id="MainContainer" model="Model.MainContainer">
</ext-container>
</content>
</ext-container>
</ext-section>

TextFieldWithLeadingZeros.cshtml.cs

using System;
using System.Collections.Generic;
using System.Globalization;
using System.Linq;
using System.Threading.Tasks;
using Ext.Net;
using Ext.Net.Core;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace ExtCookbook.Pages
{
public class TextFieldWithLeadingZerosModel : PageModel
{
public FieldContainer MainContainer { get; set; }

public void OnGet()
{
MainContainer = new FieldContainer()
{
Anchor = "100%"
};
MainContainer.Items.Add(new TextField()
{
Id = "phoneNumber"
});
var btn = new Button()
{
Text = "Click me"
};
btn.DirectEvents.Click.Method = HttpMethod.POST;
btn.DirectEvents.Click.Url = $"?handler=ClickMeButtonClick";
btn.DirectEvents.Click.ExtraParams.Add(new DirectEventParameter() { Key = "phoneNumber", Value = "App.phoneNumber.value", Mode = ParameterMode.Raw });

MainContainer.Items.Add(btn);

}

public IActionResult OnPostClickMeButtonClick(JsObject jObj)
{
if (jObj.GetValueOrDefault("phoneNumber") == null)
this.X().Toast($"Posted value is null");
else
{
var postedValue = jObj.GetValueOrDefault("phoneNumber").Value.ToString();
this.X().Toast($"Posted value is {postedValue}");
}

return this.Direct();
}
}
}


Checking with the developer console what contains App.phoneNumber.value the string value is correct.

help!

[fabricio.murta]

Hello @bbros!

You need to "tame" Ext.NET to do your bidding. You know what you want to pass is a string, so state it to the server and it shall obey. You're passing the parameter as phoneNumber, aren't you? Then change your OnPostClickMeButtonClick() to this:



public IActionResult OnPostClickMeButtonClick(string phoneNumber)
{
if (string.IsNullOrWhiteSpace(phoneNumber))
this.X().Toast($"Posted value is null or whitespace");
else
{
var postedValue = phoneNumber;
this.X().Toast($"Posted value is {postedValue}");
}

return this.Direct();
}


And a string is what it will parse the passed value as. No guesswork, no surprises. You can employ a good regular expression to validate the input value both in client and server side to ensure all is going the right way into your database.

Hope this helps!

[bbros]

Thanks, your solution works.
I'm sad that this is the expected behavior for you.
I'm used to get a JsObject; in this way, adding and removing parameters methods won't change; I get 20 controls over the form and I get methods wich works with JsObject for saving data using foreach cycles; this means that I need to do extra job to be compatible with the current config, expanding variables and creating a dictionary or jsobject inside the method.

very bad... :(

[fabricio.murta]

If anything I had this line different than yours in model code:



btn.DirectEvents.Click.ExtraParams.Add(new DirectEventParameter() { Key = "phoneNumber", Value = "App.phoneNumber.getValue()", Mode = ParameterMode.Raw });


But I reverted it to what yours read and it still works nicely. Reason I changed this is usually relying in the method (getter/setter) when available is the way to go, as it potentially handles some edge cases. Also when available it serves as a "contract" which Sencha is committed to keep their client-side code compatible across versions, as best as they can.

You got me there, I'm not sure what's going on that your version is not catching the change. In case you have left the other "overload", wipe it. It may be overruling the string alternative for some reason. Or rename the method to something else.

Other than that, I'm not sure why the solution still nulls when you send "0123". Notice the method parameter name must match the DirectEventParameter Key, or else you'd always get null in the method body -- and that's why I specificly used that variable name in the method. It is a guess I wanted Ext.NET to make (match passed variable name with handler variable name).

Hope I somehow guessed what's wrong on your attempt of the suggestion.

[bbros]

sorry I edited the previous post, because I was wrong, your suggestion was working.

[fabricio.murta]

Hello @bbros!

I'm sorry the solution is not something you'd enjoy the most in your actual scenario. As the jsObject approach is passive of assumptions for type inference, it is very hard to cover all possible scenarios and, unfortunately, as you get specific needs, one way or another, you'd have to be specific with how you want to handle it.

That said, using the explicit type is but one of the possible approaches to "specify" it. You can ensure you are not letting javascript or serializers "guess" on the other end as well. For instance, wrapping the string in quotes. You are using ParameterMode.Raw, this means you are up to the consequences of passing a resolved value as-is, you have the freedom to pass arbitrary data, but you are also responsible of keeping it sane.

In this approach, and back to your original test case, you can keep using JsObject and guarantee it is going to deem the parameter as a string -- no matter what -- by doing this:



btn.DirectEvents.Click.ExtraParams.Add(new DirectEventParameter() { Key = "phoneNumber", Value = "\"\\\"\" + App.phoneNumber.value + \"\\\"\"", Mode = ParameterMode.Raw });


Going a bit further, if you want to accept actual double quotes from the string (otherwise it'd be resolved to null), you'd need yet another wrapper method to properly escape them.

The alternatives are not limited to this, so if you fiddle far enough, you'd likely to find something you're happy to work with, it's probably just a matter of experimentation.

Hope this helps!

[bbros]

Thank you again.
I'm going to add double quotes and excape those reading values, or something like that.

It is not too bad ;)

[fabricio.murta]

Hello again!

Thanks for the feedback and glad the hints were helpful!