\IPS\Helpers\Form\Translatable + toggles + validation

[newbie LAC]

Hello,

\IPS\Helpers\Form\Translatable doesn't respect

- the  toggles

POC

$form = new \IPS\Helpers\Form;

$form->add( new \IPS\Helpers\Form\YesNo( 'test', 0, FALSE, array( 'togglesOn' => array( 'form_test2' ) ) ) );
$form->add( new \IPS\Helpers\Form\Translatable( 'test2', NULL, TRUE, array( 'maxLength' => 5 ) ) );

if ( $values = $form->values() )
{
	$form->addMessage( 'Ok', 'ipsMessage ipsMessage_info' );
}

Result

- the validation

POC

Pay attention on 'maxLength' => 5

Result

[CodingJungle]

On 9/6/2019 at 6:05 AM, newbie LAC said:

Hello,

\IPS\Helpers\Form\Translatable doesn't respect

- the  toggles

POC

$form = new \IPS\Helpers\Form;

$form->add( new \IPS\Helpers\Form\YesNo( 'test', 0, FALSE, array( 'togglesOn' => array( 'form_test2' ) ) ) );
$form->add( new \IPS\Helpers\Form\Translatable( 'test2', NULL, TRUE, array( 'maxLength' => 5 ) ) );

if ( $values = $form->values() )
{
	$form->addMessage( 'Ok', 'ipsMessage ipsMessage_info' );
}

I notice this happen on a hidden password field too, i usually work around this issue by turning off required and using appearRequired and using my own custom validation. 

Edited September 17, 2019 by CodingJungle

[bfarber]

I'm assuming you're not seeing this behavior occurring natively anywhere at present? If there's an existing form that isn't working, it would be easier to get this raised and fixed quicker.

[newbie LAC]

14 hours ago, bfarber said:

I'm assuming you're not seeing this behavior occurring natively anywhere at present?

I don't know. It's custom app.

14 hours ago, bfarber said:

If there's an existing form that isn't working, it would be easier to get this raised and fixed quicker.

Use example from my start post

[Adriano Faria]

On 9/23/2019 at 11:25 AM, bfarber said:

I'm assuming you're not seeing this behavior occurring natively anywhere at present? If there's an existing form that isn't working, it would be easier to get this raised and fixed quicker.

It's not working too with a simples YESNO and togglesOn in a text field:

		$form->add( new \IPS\Helpers\Form\YesNo( 'field1', \IPS\Settings::i()->field1, FALSE, array( 'togglesOn' => array( 'field2' ) ) ) );
		$form->add( new \IPS\Helpers\Form\Text( 'field12', \IPS\Settings::i()->field2, TRUE, array(), NULL, NULL, NULL, 'field2' ) );

I have to make a custom validation to avoid the error.

[bfarber]

You quoted my post, but then pointed to custom code again. 😛 I was asking if there's anywhere within the Suite at present where this issue is occurring, so we could focus on that.

We try hard to ensure every API and method works as expected and everyone can use them with ease and so on, but we do have limited development resources at the end of the day, so it's not always the easiest task justifying development time on something that has absolutely no impact to how the software functions out of the box. That isn't to say of course we don't want to ensure the framework is rock solid (both for us, and for third parties), but hopefully you can understand that an issue like this would be at the very very bottom of the totem pole in terms of where we focus our efforts.

[Adriano Faria]

2 minutes ago, bfarber said:

You quoted my post, but then pointed to custom code again.

Sorry, Brandon. Two examples are showing that there's some problem and you insist in want us to show this happening in the suite. The form helper is part of the API. There's a problem; it's simple like that. Unless a bug from now on is if it happens somewhere in the official files, then it's ok. I'll keep using custom validation.

[bfarber]

I raised this internally in our tracker to get some more input, and unfortunately this isn't something that can/will be changed.

Setting the 'required' flag on a form helper most often sets the 'required' HTML attribute as well, so there is browser-level validation going on as well which has no understanding of our toggles system. What you will need to do is what you are already doing - set required to NULL (or set appearRequired) and then perform custom validation on the input as needed.

[newbie LAC]

3 hours ago, bfarber said:

Setting the 'required' flag on a form helper most often sets the 'required' HTML attribute as well, so there is browser-level validation going on as well which has no understanding of our toggles system.

Not in my case

And what about 2nd issue?

On 9/6/2019 at 4:05 PM, newbie LAC said:

- the validation

POC

Pay attention on 'maxLength' => 5

 

[Ryan Ashbrook]

1 hour ago, newbie LAC said:

And what about 2nd issue?

 

The Translatable helper does not currently support maxLength.

[newbie LAC]

6 minutes ago, Ryan Ashbrook said:

The Translatable helper does not currently support maxLength.

\IPS\Helpers\Form\Text support maxLength

\IPS\Helpers\Form\TextArea support maxLength

\IPS\Helpers\Form\Editor support maxLength

\IPS\Helpers\Form\Translatable can be text or textarea or editor. So should support maxLength

[IPCommerceFan]

Does Translatable support $customValidationCode as of 4.6.5.1?

I just finished a brain-bending session in 4.4.10 trying to get it to work to no avail despite it working fine with \IPS\Helpers\Form\Text

After discovering this thread I went ahead and implemented the validation somewhere else.

 

[Daniel F]

9 hours ago, IPCommerceFan said:

Does Translatable support $customValidationCode as of 4.6.5.1?

 

This was supported since 4.0.x !
Take a look at applications/core/extensions/core/FrontNavigation/CustomItem.php for an example 🙂

[IPCommerceFan]

Thanks Daniel. I tried and failed, then. lol

This is how I was attempting to use it:

        $form->add( new \IPS\Helpers\Form\Translatable( 'dripcampaigns_step_vin_regex', $this->id ? $this->input_format : NULL, FALSE, array( 'placeholder' => '/[A-Z0-9]+/i', 'app' => 'dripcampaigns', 'key' => ( $this->id ? "dripcampaigns_step_vin_regex_{$this->id}" : NULL ), function( $val )
        {
            if ( $val AND @preg_match( $val, NULL ) === false )
            {
                throw new \DomainException('form_bad_value');
            }
        }, NULL, NULL, 'dripcampaigns_step_vin_regex' ) ) );

It seems to not even try to run the custom validation code this way.

The regex validation is copied from system\CustomField (notably a Text field):

		$form->add( new \IPS\Helpers\Form\Text( 'pf_input_format', $this->id ? $this->input_format : NULL, FALSE, array( 'placeholder' => '/[A-Z0-9]+/i' ), function( $val )
		{
			if ( $val AND @preg_match( $val, NULL ) === false )
			{
				throw new \DomainException('form_bad_value');
			}
		}, NULL, NULL, 'pf_input_format' ) );

If I re-format it as a text field, it works:

        $form->add( new \IPS\Helpers\Form\Text( 'dripcampaigns_step_vin_regex', $this->id ? $this->input_format : NULL, FALSE, array( 'placeholder' => '/[A-Z0-9]+/i' ), function( $val )
        {
            if ( $val AND @preg_match( $val, NULL ) === false )
            {
                throw new \DomainException('form_bad_value');
            }
        }, NULL, NULL, 'dripcampaigns_step_vin_regex' ) );

It needs to be Translatable so that the value can be stored as a language string when the form is submitted though.

Thank you for pointing me in the right direction.  I'll look at CustomItem and report back if I get it to work!

[IPCommerceFan]

I gave it a shot:

        $form->add ( new \IPS\Helpers\Form\Translatable( 'dripcampaigns_step_vin_regex', NULL, NULL, array( 'placeholder' => '/[A-Z0-9]+/i', 'app' => 'dripcampaigns', 'key' => $this->id ? "dripcampaigns_step_vin_regex_{$this->id}" : NULL ), function( $val )
        {
            if ( $val[1] AND @preg_match( $val[1], NULL ) === false )
            {
                throw new \DomainException($val[1] . ' is not a valid regex string');
            }
        } )	);

It worked!

Upon closer inspection, it appears I had a parenthesis where one didn't belong, so this was ultimately a syntax error:

'key' => ( $this->id

Incidentally, the validation was treating $val as an array rather than a string, so validation kept failing.   

e.g.

  

If we json_encode the array, it appears like this:

Thus changing $val to $val[1] fixed it, though I get the impression this field value should not be treated as an array in the first place.

In any case, this works now! Thanks again for taking a look @Daniel F!  Your support is very much appreciated.

[Daniel F]

Looking at your first and second code there's also something else..;)

if ( $val AND @preg_match( $val, NULL ) === false )

In your first attempt you were assuming that $val is a string, but it's literally an array with the language ID as key and the string as value .

This means that even your current code with $val[1] could result in an error!

[IPCommerceFan]

Ahh, I thought it conspicuous that 1 wasn't a 0 (my assumption being it represented the first item in an array)

I've modified it to indicate the language key for the logged in member:

        $form->add ( new \IPS\Helpers\Form\Translatable( 'dripcampaigns_step_vin_regex', NULL, NULL, array( 'placeholder' => '/[A-Z0-9]+/i', 'app' => 'dripcampaigns', 'key' => $this->id ? "dripcampaigns_step_vin_regex_{$this->id}" : NULL ), function( $val )
        {
            $langID = \IPS\Member::loggedIn()->language()->id;
            if ( $val[$langID] AND @preg_match( $val[$langID], NULL ) === false )
            {
                throw new \DomainException( $val[$langID] . ' is not a valid regex string.');
            }
        } )	);

		return parent::form( $form );

Thanks again!

[Daniel F]

On 8/25/2021 at 5:33 PM, IPCommerceFan said:

Ahh, I thought it conspicuous that 1 wasn't a 0 (my assumption being it represented the first item in an array)

I've modified it to indicate the language key for the logged in member:

        $form->add ( new \IPS\Helpers\Form\Translatable( 'dripcampaigns_step_vin_regex', NULL, NULL, array( 'placeholder' => '/[A-Z0-9]+/i', 'app' => 'dripcampaigns', 'key' => $this->id ? "dripcampaigns_step_vin_regex_{$this->id}" : NULL ), function( $val )
        {
            $langID = \IPS\Member::loggedIn()->language()->id;
            if ( $val[$langID] AND @preg_match( $val[$langID], NULL ) === false )
            {
                throw new \DomainException( $val[$langID] . ' is not a valid regex string.');
            }
        } )	);

		return parent::form( $form );

Thanks again!

  

Why would you even use a translatable field with a validation?:D
What's going to happen if you're logged in with the "English" language in your ACP, and you set English and French and there's a typo in the French field? It won't return any error, right?;) 

So you'll literally have to save the form, change the ACP language to French and resave the form again to run the validation for the French field

 

Sorry, I'm just nitpicking, and I guess you know what you're doing, but had to mention it for anybody else searching for something similar and finding the topic and your (bad code:P ) 😄

[IPCommerceFan]

Valid point!  (no pun intended haha)

Bill Gates used to say in meetings when presented with something that didn't make sense:   "I'm confused."   If you really mucked it up, he'd say "You're confused.".  😄

Anyway, the validation is to make sure valid regex is entered into the field, so it should be language agnostic..  The reason it is Translatable is simply because I'm trying to stick to the conventions set out in the 3rd party application I'm writing a plugin for (all the other fields that would normally be 'Text' are 'Translatable' here).  So, the use of the Translatable field is sort of a "when in Rome" approach. 🙂

Btw if we _really_ want to nitpick, I should have also used a language string for ' is not a valid regex string.', but it was an acceptable casualty. Maybe I'll go fix it later.  lol

edit:  I think I see what you're saying now, but it probably still doesn't matter since this plugin won't see any sort of distribution beyond my own site where only one language string is in use.   Fair warning to anyone considering this method though!

Edited August 27, 2021 by IPCommerceFan