Template options

[vexorian]

Template options

[zen0wu]

This is actually a pretty awesome idea!
Definitely gonna have this!

The type should be a string array I guess, according to the current use case.
Do you think this is enough?
Maybe we need

  options {
    multiprocess = true
    timeout = 3 seconds
  }

But this will make things more complicated, and I'm not even sure if the template can support things like 3 seconds in the if statement. Likely not. :-|

[vexorian]

That's enough. Of course a more flexible syntax would be better but I know that's hard and we need to avoid making things too complicated.

You can do ${if ssss = 3}, but it doesn't work with many variables. It is very odd that it randomly works or not.

Of course, in that idea , it would be better if you defined things that are not just for ${if, but also for printing in the template. If you could print ${options.timeout}, that would be cool. But so far if only the boolean flags thing is possible, that's good.

[vexorian]

Of course, for setting theme options maybe something like:

options {
    backgroundColor = #eee 
    forrgroundColor = #111 
}

Would be nice, but it does get more complicated.

[vexorian]

No, that would be a bad idea, but maybe if we could use:

problemdesc {
options {
     styleSheet = 'somecustompath.css'
}
}

So that coder could use own style sheet it would be cool.

[vexorian]

About the syntax (and if we agree with it, I can try implementing it as it is a wonderful unbusy time I am having). There are two things I think would be wonderful to be able to have.

• Boolean conditions (So that we can do ${if}, ${else}.
• String fields. I didn't think of this at first, but I think it would be very important to be able to determine what to type in some parts of template.

I think the answer to do this both is something like this:

• A part related to template definition declares the variables it has available.
• Initially, all variables are initialized with null.
• default.conf possibly shouldn't set any of the variables that are meant to be used with ${if} (leave them as null). This way, if someone's config file doesn't set them, they are null too, but this someone can set them to non-null.

If we could do string comparisons inside ${if} it would be easier, but I tried and jmte doesn't seem to like them.

@wookayin : More opinions would be good.

[zen0wu]

In my opinion, a options map from string to string is enough. For example,

options {
  multiprocess = true
  theme = dark
}

If jmte can recognize ${if options.multiprocess} iff it has a non-null value, any value is fine.
In this way, the string->(boolean | string) map is expressive enough, I think.

[vexorian]

If default.conf has:

options {
    multiprocess = true
}

And greed.conf has:

options {
      theme = dark
}

Will options.multiprocess still be "true"?

[zen0wu]

Yes, that's a problem.
But according to jmte doc, user can set it to false, and it will be false.
When evaluating if condition, it checks if it's null or toString resulting in false.

http://jmte.googlecode.com/svn/trunk/doc/index.html

[vexorian]

Yes, that's a problem.

Do you mean that options.multiprocess will be "true" ? That's actually very good.

[zen0wu]

Oh, I misunderstood you.
Yes, in your situation it will be true.
I thought you meant user may not able to disable the multiprocess, so I looked up the doc of jmte and it turns out the user can disable it by setting the value to false.