I agree, this would be useful. Something like this, perhaps?

With a default template? Hum why not!

I think it would a good feature to have!

The main problem I have are the constants in Template. For the SIZE_HINT we could simply use the median, I guess. But EXTENSION and MIME_TYPE might be off, e.g. if one enum variant should generate a plaintext error message.

I think, in a first iteration we could require that the ext parameter is the same for all variants. Later on, we could explore how to lift this requirement. If you too think that's a good idea, then I'll have a look how best to salvage askama-enum. I think most of the code can be copied.

Not sure if median is the best idea here. Maybe taking the biggest value would be better?

As a user, I would expect the HINT_SIZE to derived from the largest variant. This would mimic the rust sizing of enums. Just an opinion.

Maybe an attribute can be accepted when deriving enums that lets you specify an escape hatch. Unsure if it is worth the maintenance cost for how often it would actually get used. I imagine most users would just take the default and not worry about it.

#[derive(Template)]
#[derive(Serialize, Deserialize)]
#[template(size_hint = "median")]
// #[template(size_hint = "largest")] default
// #[template(size_hint = Self::MultipleChoiceText)] a "hot path" variant
pub enum QuestionData {
	#[template(path = "./templates/question/editor/multiple-text.html")]
	MultipleChoiceText {
		numbering: Numbering,
		text: Vec<String>,
	},

	#[template(path = "./templates/question/editor/multiple-image.html")]
	MultipleChoiceImage {
		numbering: Numbering,
		images: Vec<i32>,
	},
}

FWIW - I have many cases where I use a single field struct to wrap and display an enum like this, so this feature would be a great add. Especially Result like templates for handling form submissions would be 👍

If work is needed on implementation, I may be able to help a bit. Still getting used to the codebase and it seems substantial progress has already been made. Maybe if documentation or examples are needed?

As a user, I would expect the HINT_SIZE to derived from the largest variant. This would mimic the rust sizing of enums.

It's also what I think.

Maybe an attribute can be accepted when deriving enums that lets you specify an escape hatch. Unsure if it is worth the maintenance cost for how often it would actually get used. I imagine most users would just take the default and not worry about it.

That seems a bit too much in my opinion.

If work is needed on implementation, I may be able to help a bit. Still getting used to the codebase and it seems substantial progress has already been made. Maybe if documentation or examples are needed?

Work is already in progress in #255. But if you have some tests in mind, don't hesitate to post them there.