set_data() doesn't seem to be setting some hidden variables

set_data() doesn't seem to be setting some hidden variables

by Mike Worth -
Number of replies: 7
In my newest version on termreview in cvs I am having a problem. When view.php is loaded within a tutor group it is fine, however when it is submitted the form doesn't re-load properly. The hidden fields action1id, action2id and action3id are only set if they were already set before the form was submitted.

I have used a var_dump to make sure that they are set in $tabledata just before $mform->set_data($tabledata); but for some reason this isn't actually setting them

Is this a bug? Is it known about? Is there a workaround?

Thanks,
Mike
Average of ratings: -
In reply to Mike Worth

Re: set_data() doesn't seem to be setting some hidden variables

by Mike Worth -
I've done some more investigation, and it turns out that I cannot use set_data() to get any data into a form if it has just been submitted. This is a big problem as the data on the form is spread across several tables and after a new row has been created the id must be given back into the form to prevent a new copy of that row being created each time.

I've tried unset($mform) followed by re-initialising the form, but that doesn't work. Surely I'm not the only person who has ever wanted to use set_data() on a form that has just been submitted?

Thanks,
Mike
In reply to Mike Worth

Re: set_data() doesn't seem to be setting some hidden variables

by Mike Worth -
I've managed to get a workaround, after processing the uploaded data simply redirect back to the same page- this loads a fresh copy of the form. Is this really the way to do this?

Thanks,
Mike
In reply to Mike Worth

Re: set_data() doesn't seem to be setting some hidden variables

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
It would be a big security problem if get_data() returned fields that are not part of the form definition.

In any case current moodle forms may behave a bit unexpectedly in some corner cases, because recommended procedure is to define form, set current data, verify if submitted and then process submitted data. Any other order of actions may not work as expected and may give different results in each version (1.8/1.9/2.0).
In reply to Petr Skoda

Re: set_data() doesn't seem to be setting some hidden variables

by Mike Worth -
What I'm trying to do is:

  • define form
  • insert data from database into form
  • display form
  • user submits form
  • data saved
  • some extra data put into form for re-display
  • This is where I get the problem- the data displayed at this stage is just the data the user just entered.

The reason this is a problem is that there is a boxes where the user can add actions, these are stored in a different database table; if the user has just entered a new action I need to save the action, get the id of that action and put it back into a hidden field. As this doesn't work, if the user edits the form contents and submits it again then a second copy of that action is created (if the actionid is empty it is taken to be a new action)

Mike
In reply to Mike Worth

Re: set_data() doesn't seem to be setting some hidden variables

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
You could create two different forms, after getting the result of first form display the second and use the received data as default.
In reply to Petr Skoda

Re: set_data() doesn't seem to be setting some hidden variables

by Mike Worth -
It is the same form as users will get if some data is already in the database from a previous insertion. I think that just refreshing the page with the form on to load the form data from the database is the cleanest way to do this.

Is there a specific reason why setting data into a form immediately after getting data is prohibited?

Thanks,
Mike
In reply to Mike Worth

Re: set_data() doesn't seem to be setting some hidden variables

by David Jones -
G'day Mike,

This may be out of date for you, but I found the thread via Google due to having a similar problem as you.

I've currently adopted the solution I think you used - redirect to the same page - as time was running out for a deadline.

As for why it works this way? The best I can do is guess, and that guess doesn't sound sensible to me.

David.