Adapted display of solutions according to their type

[nborie]

When in a template, the solution field is of type code, it would be good if the display of the solution adapts to the type of the solution.

In the example above, the template allows you to produce exercises with Mini Brain, a kind of CPU simulator with simple code that looks like assembly language.

code and plaintext are the two most suitable parameter values ​​for this Mini Brain code snippet. But it would be necessary to frame with <pre>, with <code>, with ``` or other depending on the type of response.

[mciissee]

@nborie I don't think I understood the need. Doesn't the solution key solution already allow you to put whatever you want in it and format it with custom html?

[nborie]

There are two versions of the solution: the raw solution (what the learner must produce) which is potentially built by the builder and used by the grader for correction.

On the other hand, there is the solution suitable for web display. In fact, often, it's the raw solution with contextual code to present well on the web.

Ideally, when I code an exo, I just want to put the raw solution in the solution field (including in a template) otherwise I duplicate a lot of code just for display.

Overall, adding the contextual code to make a good display is easy but removing it is difficult.

[nborie]

For exemple in C,

I love to place raw solution in the solution field :

int main(){
  printf("Hello World\n");
}

Because I can use the content of the champ in my grader executing the piece of code

```c
int main(){
  printf("Hello World\n");
}
```

The extended solution with contextual dispay is relatively easy in this case but sometime, reconstructing the raw usable solution is sometimes complicated.

so I argue instead for really only placing the raw semantic solution in the solution field. Adapting the display of the solution field according to its nature is, however, a responsibility of the platform. It's my intuition, it's debatable but I think it's better this way.

[mciissee]

@nborie In its design, the solution key is a display key like title, statement and form, giving exercise designers complete freedom to display what they want. Changing this behavior for the solution key to store the raw value of the solution greatly complicates the display of the page and will lead to an evolution request for all possible display types. At present, it's possible to display formatter code while still having a reference to the solution's raw value using the wc-code-viewer component and its code field.

viewerSolution = :wc-code-viewer
viewerSolution.code ==
MY RAW SOLUTION
===

solution==
{{ viewerSolution }}
==

[nborie]

Yes, this makes seense for me.

The first templates I did implement did use the key solution for the raw solution and my builders and my graders did use it. This is the orginal mistake. I should rewrite some of them with the following semantic :

solution : the final code adapted for a web display (latex, code coloration, etc...)

internal_solution : the raw solution ( (C-python) code only or bash command only or number only) to be exploited in builder / grader.

This semantic was also already include in the doc :

Il est possible d'afficher la solution d'un exercice à l'aide de la clé solution. Cette clé suit la même logique que la clé form, sauf qu'elle contient le HTML/Markdown à afficher à l'apprenant lorsqu'il demande la solution.

I think you can closed the ticket.