Midnight Modding Posted May 25, 2019 Posted May 25, 2019 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 Posted May 25, 2019 Author Posted May 25, 2019 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 Posted May 25, 2019 Posted May 25, 2019 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 Posted May 25, 2019 Author Posted May 25, 2019 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 Posted May 26, 2019 Posted May 26, 2019 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 Posted May 26, 2019 Author Posted May 26, 2019 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 Posted May 26, 2019 Posted May 26, 2019 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 Posted May 26, 2019 Author Posted May 26, 2019 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 Posted May 26, 2019 Author Posted May 26, 2019 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 Posted May 28, 2019 Posted May 28, 2019 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.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.