Rails STI uses the type
special column to store the class name. Student.new(type: 'HighSchoolStudent')
would build a Student
which would later act as a HighSchoolStudent
.
This solution would not run validations, callbacks, etc. defined only for HighSchoolStudent
but would run everything from Student
.
To do that, you could do something like @PinnyM suggested, or you could have a hidden input for the type
attribute: hidden_field_tag :type, 'Student'
followed by a check_box_tag :type, 'HighSchoolStudent'
and use that to determine the right class to create, which does buy you all of the validations and callbacks while being more maintainable as it uses the correct attribute.
All that to say, STI may be the wrong solution for you here.
Can I only require that the extra attributes created for the subclass are only required for the form to be submitted if that specific class is checked?
This tells me that you've added - to your students
table - attributes which are irrelevant to non-HighSchool students.
A better solution might be to have a class like HighSchoolStudentProfile
as an association and a method high_schooler?
on student that checks for its presence. This prevents you from running into a problem I've faced before, which is having a "sparse table" and which generally grows into needing various conditional validations and has complex logic.