Form Helper

[Midnight Modding]

The form helper is generally great, but one downside of the current setup is when someone wants a change to part of an existing IPS form. Since the form is created in the php file (usually in one method), there aren't many options for changing just part of one. You'd have to either override a method and totally replace the code (not allowed in marketplace), do a really odd replace attempt, or... I don't know.

Maybe in 5.x have all of the forms similar to the content item ones where you set up an array of elements for the form, where you can simply overwrite an element? Maybe even have it also check for an existing function with the element's key for the function name where it doesn't even bother creating the original, if that method exists.

What got me thinking about this is someone asked me how to change some wording and yes it could be done by changing the lang bit, but it got me off onto thinking about other changes. In his case he could either change the lang bit value in the acp or do a hook and redefine the value of it before the parent executes. but it got me thinking beyond his example.

(I haven't had to do this in ages, so I may be forgetting existing possibilities, but I do remember having to totally do my own method for the move or delete form for my node... ie this was for an app, not a hook, thus didn't change behavior in the first party apps.)

[Midnight Modding]

Btw, is the marketplace rule solely that the parent method must run? Could you technically use $x = parent::whatever(); and then totally overwrite $x, making what the method did (well the resulting variable, anyway) moot? I mean I know we can do some changes "to" $x, but how much room we're allowed there, I don't know. I'm not sure if parent being required to execute is just to be sure certain code gets run or if it's also required not to overwrite the returned data. Examples on here show hooks adding "to" $x, but obviously we may need to change some of $x, as well.

[Mark]

No that wouldn't be allowed - but if you say what it is you're trying to do, we could advise the best way to do it.

[Midnight Modding]

8 hours ago, Mark said:

No that wouldn't be allowed - but if you say what it is you're trying to do, we could advise the best way to do it.

where is the line on that, though? for example, we can obviously add a join in joins(), so is the rule that we can modify by adding something, but not change it in a way that could affect other third party apps?

I don't have a real case example of needing it yet. I was just thinking ahead, generally.

I believe the form this client wanted to change was the registration form and he just wanted some wording for one of the inputs changed. So that one, has easy ways of doing it, since it's a lang bit. but let's just say he wanted to change one of the inputs on the form to where the actual input/element itself needed to be changed. I can't think of a good way, so just figured I'd mention how nice the forms are which first have arrays of elements.

[Fosters]

11 hours ago, Midnight Modding said:

I can't think of a good way

You can hook into \IPS\core\modules\front\system\register::buildRegistrationForm

[Midnight Modding]

2 hours ago, Fosters said:

You can hook into \IPS\core\modules\front\system\register::buildRegistrationForm

But still the whole form is set up in that method and we can only do something before or after the code in it, so the same problem remains if needing to change one of the inputs. (I don't think I've looked at what a $form object looks like before it's converted, so maybe there's a way to replace easily, but I didn't think so.)

[Fosters]

8 minutes ago, Midnight Modding said:

But still the whole form is set up in that method and we can only do something before or after the code in it, so the same problem remains if needing to change one of the inputs.

Absolutely not, there are several ways to achieve this.

[Midnight Modding]

Just now, Fosters said:

Absolutely not

Absolutely not what? They said we have to let all of their code execute in their methods.

[Midnight Modding]

ok, I just var_dumped a form and I see it stores the elements in $form->elements and it uses the field names for keys. I forgot a form is still an object at that point, not the html. 🙂 

So I'd let the parent method run, then overwrite $form->elements[""]['somekey']. Not sure why it uses "" instead of a numerical key, but either way I know what to do now, due to testing. 

So the only real issue would be forms that are both created and displayed within the same method. I guess for those you'd do a template hook and then either do php within the template or call one of your own methods (well technically that's php in the template too, to call it lol) and pass $form to it and then change the element there, before it gets actually displayed.

Still unsure just what we are allowed to change, though. Where's the line between being able to change something and not affecting other people's hooks? I mean if we change a yesNo to a Seleect, obviously other hooks would be affected, by expecting it to be the yesNo. Theoretically, adding a choice to an existing Select could affect other hooks (because two may add the same key). Which types of changes are allowed when listing in marketplace?

[bfarber]

I wouldn't be so focused on those details. Changing a YesNo field to a Select field would be allowed in most cases, unless it is going to dramatically break stuff. We understand that not every single plugin can work with every single other plugin.