Change the way to differentiate between tudaexercise-exercise and -submission

[St0rml]

Hey,
firstly, thank you for creating this package! I've used it now for quite a bit and it worked really well :)

I do, however, think that the way that the user is required to provide info for the title-sub-parameter in the tudaexercise template is quite confusing. The documentation for title-sub.submission() and title-sub.excercise() is only found in the source code and therefore quite inaccessible for anyone, who does not want to change anything in the template. Also, the way the implementation is at the moment, it's difficult to extend and adapt the code, e.g. for a unified language handling system for all templates (which I am going to open another Issue & PR for shortly).

In short, I get why the implementation is how it is, but I want to suggest a more user-friendly implementation of differentiation between "exercise" and "submission" as laid out in the following:

1. Remove parameter title-sub
2. The user can switch between exercise template "exercise" and "submission" via a top level parameter of tudaexercise
3. Predefined fields (term, date, sheet, group, tutor, lecturer) are all provided via the info dictionary. Logic can then select the needed predefined fields depending on the type of exercise (submission or exercise)
4. Any custom additional fields should also be specified by the user in info but using string notation.
5. To allow for customization of the previous title-sub layout, introduce new parameter info-layout. Here, keys specified in info can be assigned to left or right by adding the key to the respective array.

#show: tudaexercise.with(
  type: "exercise" // Choose between "exercise" and "submission"
  language: "en",
  info: (
    title: "Usage of TUDaExercise",
    subtitle: "A small guide.",
    author: (("Andreas", "129219"), "Dennis"),
    term: "Summer semester 2021",
    date: datetime.today(),
    sheet: 5,
    group: 1,
    tutor: "Dr. John Smith",
    lecturer: "Prof. Dr. Jane Doe",
    "A custom key": "A custom value",
  ),
  info-layout: (
    left: ("term", "date", "sheet", "group"),
    right: ("tutor", "lecturer", "A custom key"),
  ),
  logo: image("logos/tuda_logo_replace.svg"),
  design: (
    accentcolor: "0b",
    colorback: true,
    darkmode: false,
  ),
  task-prefix: none,
)

Please let me know what you think about that suggestion. I will open a PR soon.

[FussballAndy]

I am slightly split minded about the proposal. Whilst I can see that the current implementation can be a bit confusing, I would also like to give the user more customizability over the area. The approach I did so far aimed to also allow the user to create their own style for the subline (as the main design document calls it). Inspiration for this came from SEEMOO, who afaik have been using a slightly modified version of this template for CNuvS exercises.

Now whilst they have not exactly been using the subline for the exercise specific content, I feel like adding the possibility to do so would be a nice touch. And thus I also made the title-sub as generic as possible s.t. perhaps different faculties can make different styles for it.

I was hoping that the doc text for tudaexercise and the note in the template guide would give enough explanation as to how this parameter can be used (at least for basic exercise/submission hand ins). (Maybe the documentation could also be improved?)

Those are my current thoughts about title-sub. If you think that the customization is not necessary or even better have an idea in mind how to incorporate such a functionality too, I'll be glad to hear it.

[St0rml]

I totally get the customization aspect. I do, however, believe that this customization can still be achieved through my proposal since any type of content can be passed through to the subline using a custom key-value pair. And with that, a lot of stuff can already be done:

This of course being in the two columns defined. But even that could easily be extended by adding one additional check like e.g.

#let resolve-info-layout(exercise-type, info, info-layout, dict) = {
  if info-layout == false:
    return [#info.at("custom")]
// [...]

which just returns the content of key "custom" and therefore gets rid of the predefined layout. With this, the user then has absolute freedom to do anything they want:

#show: tudaexercise.with(
  exercise-type: "exercise", // Choose between 'exercise' and 'submission'
  language: "eng",
  info: (
    title: "Usage of TUDaExercise",
    subtitle: "A small guide.",
    author: (("Andreas", "129219"), "Dennis"),
    // Add custom key values pairs like this:
    "custom": [
      *Lorem ipsum* dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
    ],
  ),
  // If you want to include custom keys in the info, uncomment the info-layout as shown below and expand it with the key of your key-value pair.
  info-layout: false,

results in

---

Some parts of this proposed implementation are still quite janky. While the key-value concept is really easy to grasp and quick to modify, my proposed implementation actually renders the key as a string in the subline. That's kinda dumb for many reasons. It makes way more sense to use the key for the positioning in the layout and just always only render the content of the value.

[FussballAndy]

I guess that is a solution that works. Perhaps the info-layout could however then rather be set to none instead of false. But those are implementation details, so I'll go separately about them in #21. 😄
I have also thought about maybe making a pretty customizable base template and then add corresponding fill ins for those templates to mimic exercise or submission. However this would probably also increase complexity as the user would then first of all need to find the different implementations.