Closed vexorian closed 10 years ago
After some changes to #113 , it is possible to select the language in Type;html(cpp), this way we can actually make the definition always use Java/ c++/ C# syntax in definition. Which is like the problem statement in statistics. So that is an alternative, make problem-desc always use Java by default, allow to change to c++ and maybe C# if it is really that different to Java.
Currently my definition looks like this, except using c++ http://gist.github.com/vexorian/8177600
@vexorian I've reimplemented this functionality, it turns out it's not that complicated.
The workaround is to add a renderMethod
method to each language, then the method signature can be successfully rendered, including Python.
About the problem of <>
under C++, I rewrote the TemplateEngine to work on this.
Now there's a new named renderer called seq
, which is a special one.
Here's a simple description.
It accepts a list of renderers, like ${key;seq(a,b,c)}
,
it's an iterative renderer, if you see a renderer as a function, then the output is c(b(a(key)))
.
The form of a
could be:
${key}
$x(y,z)
, means take the previous output as a key name k
and call ${k;x(y,z)}
.
(Haven't tested this, since there's currently no usage scenario, but seems interesting and powerful,
also not sure about whether the $
will cause any problems.)html(grid)
, just means the same as ${key;html(grid)}
.This renderer allows nested named and normal rendering, which may make the engine more powerful,
although not in a direct way. Then the result of rendering a type in C++ can be further rendered by
writing ${p.type;seq(#, html)}
. The language-specific HTML renderer change has been roll backed.
This is a major rewrite, and may cause bugs, please help me test it.
Also, we can remove the showDefinition
options in the problem desc template, but it's also OK to leave it there.
I'm also considering to simplify some of the complexity from this template, it seems to be too complex, like the fancy circle on the case number. And it seems to be suffering some aligning problems.
hmnn.
<type>
tags in statement are still using java anyway (unless we managed to fix this somehow). So I would like to keep the ;html(java) renderer or something similar for a custom template :).forceDefLanguage
is added to force the definition part to some given language, false
means no forcing.
Does anyone else think this feature could be useful? Adding the definition section to the problem statement template.
Good things:
long
it can be a hint.Bad things:
problem-definition
template as a requirement for the problem-desc template. (Will template requirements automatically call a requirement if none is defined?) Since this requirement of an extra template will complicate things and configuration, that's why I am asking...Update: In reality, it appears it is quite possible to make a template that works in all the C-like languages. Python and VB would need separate templates. It still requires us to have a separate problem-definition template for each language, though.
Update 2: Python might be an issue to do even with a separate template. An alternative would be to make a different HTML renderer for each language. The python HTML renderer should turn integer type to "integer" as opposed to just empty. There could also be a method HTML renderer. This might be too much of an issue, indeed.