$WebUserForm->fromArray($WebUser,$_POST);
$success= $object->save();
I don’t think of it as a need to compromise, but rather as having a choice depending on the task at hand. You can always remove unwanted $_POST variables very easily, and still have the convenience of using the $_POST var. You can also apply stringent validation in your schema and/or via API.
I got around the problem by creating a Class that extends MakeForm. The new class has a duplicate of the method processForm, but with this one line removed:
$success= $object->save();
I must say it still feels a bit strange updating every property of an object with the entire $_POST array without any kind of checking.
Wouldn’t malicious users be able to update, for example, the username and password of a WebUser, even though the form has no input fields for those?
I guess the alternative is to manually update the entire object with just the variables you want.
Is there a compromise?
That’s quite telling, Jason. For me, MakeForm is really only worth using for the buildForm() method. Without that, we’re reduced to doing forms the long, hard, old-fashioned way. And wouldn’t you still need to create a Class that generates form fields (select lists, checkboxes etc) and populates them from the DB and $_POST?
TBH, I rarely use MakeForm anymore and am considering removing it from xPDO altogether...
That is correct Ryan, and it needs to be part of MODx anyway, not xPDO, since it handles rendering forms in a way specific to MODx.
For a truly functional form class, it’s going to take a lot of different form output iterations and a lot of different baseline formatting chunk tpls. Of course this could all be placed into property sets so it would be relatively painless now with Revo but there’s a lot to consider. I think what Jason was honestly hoping is that someone would pick up where it left off and continue to improve MakeForm.