Add alternate problem html template.

[vexorian]

In regards to problem statement formatting, I think it is impossible to make a single option that will follow everyone's taste. I think it would be great to give plenty of template choices for HTML so that we could also inspire coders to make and share their own. Here is my alt1 problem statement template. The idea is that we can allow coders to say:

shared.templateDef.problem-desc.templateFile = "builtin problem/alt1.desc.html.tmpl"

Differences with default template:

• Dark gray background, light gray font low contrast.
• Images are not scaled down.
• ;html("grid") renderer option for parameter values, so that String[]s are rendered as grids if appropriate.
• Different output format. Mostly to allow the grid feature.

[zen0wu]

I like the theme idea. I will take some time and look at the difference between them. alt1 seems a bad name, maybe dark or something like that?

Also if you think the html renderer is necessary and we should all use it, please add it to the default template too.

[vexorian]

The html; renderer is used by the default template already, was in the PR.

This template uses the "grid" parameter. The default template cannot use it because multiline arguments break the formatting. Plus whether or not to use "grid" is a matter of opinion.

My original plan was to have various alternate templates, so there would be alt2, alt3, etc. Maybe dark is better. Although colors are not the only difference. darkgrid.desc.html ?

[vexorian]

Maybe split theme and behavior. 4 templates:

light.desc.html : Current default light-grid.desc.html : light template with grid behavior. dark.desc.html: Same as default, but dark. dark-grid.desc.html: Same as default, but dark.

Actually... The CSS could be a separate template. We have different templates for appearance and color. The statement template just calls the CSS template by its key inside the tags. Would just need to come up with a way to make the two kinds of behaviors able to use the same CSS.

Like this:

light.desc.css.tmpl
dark.desc.css.tmpl
black.desc.css.tmpl
desc.html.tmpl
grid.desc.html.tmpl

[vexorian]

Something bad about the previous idea is that it further complicates the template list.

[ filetest, source, testcase, problem-css, problem-desc ]

So maybe we can just call this template "dark-grid" and call it a day :).

[zen0wu]

Yes, I'm also considering #56 in respect of this problem. If when we define template, we can declare its dependencies, then this messy template list will be gone and we get a simple and intuitive one. Now I feel it should not cause too much trouble in the configuration file, only add a field called dependency on something like that is good enough.

[vexorian]

I just noticed there is a slight problem with that.

Currently , "source" calls a template by the key "TestCode". This is cool because all you need to change the TestCode template used from "filetest" to "test" is to change the template list. Allows me to have a dualcolor-test too.

If we made the dependencies add templates automatically, this useful behavior wouldn't be possible.

[zen0wu]

Yes, that is a problem. To tackle this, we may need to define more types of dependencies like optional dependencies or one-of dependencies (just an idea pop up in my head), if we want to go on the automatic dependency path.

[zen0wu]

I just thought of another possibility, we can have dependency on other templates and dependency on bind keys, dependency on other files, as well. This will solve the problem.

[vexorian]

How about there is only dependency on bind keys?

The dependency declaration requires both a bind key and a template to call by default in case no template with that bind key was called yet. Looks something like this:

source.required = [ ( testcode, filetest) ]

Indicates the source template requires a template with bind key testcode, and call filetest in case none of those templates was called.

[zen0wu]

We can define the more general case

source.required = [ 
  ["${TestCode}", unittest ],
  dep1,
  dep2
]

Defines 3 rules of dependency. The sequence has the one-of semantic, while the other two are just direct reference, no matter key or template. But it may cause the config mapping to get more complicated, we may need a one-of type like Either<Pair, String>.

[wookayin]

I think we could discuss on this at #56. Your suggestion is quite good, but the one-of semantic seems to be not exposed well. I prefer a syntax like (template).'dependsOn' (motivated by gradle)

[vexorian]

I am closing this. I think a better alternative will be to make the problem statement template use options.