mwunsch / handlebars.scala Goto Github PK

Hello,

Is there a way to use partial with arguments ?

I tried with the following syntax :

{{> header scheduling = 1}}

And i got the error msg :

[2.39] failure:}}' expected but =' found {{> header scheduling = 1}}

this error msg is stored in parseResult.msg but it's not displayed.
It would be great to display the complete error msg.
I can provide a PR if you want

I appear to have run into a bug with nested conditionals - the inner one seemed to be ignored - and I noticed a comment ("resolve the bugs with nested conditionals") here:

http://tech.gilt.com/2013/08/29/handlebars-scala-a-handlebars-for-scala

Any plans to fix this, or is there a workaround?

Thanks. Here's my template:

Duration - {{#if durationData.durationDays}}{{#if durationData.pluralDays}}{{durationData.durationDays}} days {{else}}{{durationData.durationDays}} day {{/if}}{{/if}}{{#if durationData.durationHours}}{{#if durationData.pluralHours}}{{durationData.durationHours}} hours {{else}}{{durationData.durationHours}} hour {{/if}}{{/if}}{{#if durationData.durationMinutes}}{{#if durationData.pluralMinutes}}{{durationData.durationMinutes}} minutes{{else}}{{durationData.durationMinutes}} minute{{/if}}{{/if}}.

handlebars.scala is rather slow in environments where performance is critical. The default behavior is to use reflection on the fly to traverse the context given to the template. It would be great if we knew the type of the context before hand we could resolve errors at compile time and make rendering really fast!

It is not clear what type Helper[T] should be. Is it a return value? Should we extend it? I don't know? Also other scala programmers I asked weren't able to tell either.
Please help:(!!

The example libraryDependencies line in the README suggests that 1.0.0 is the current version of Handlebars.

However, it looks from the compiler error messages I'm getting that the documentation on building custom bindings is for version 1.1.0.

I've had a look on Sonatype releases and snapshots and it doesn't look like there's a published version of 1.1.0. Can you release this please?

Cheers,

Dave

Looks like a typo in the documentation:

scala> import com.gilt.handlebars.scala.scala.binding.dynamic._
<console>:14: error: object scala is not a member of package com.gilt.handlebars.scala
       import com.gilt.handlebars.scala.scala.binding.dynamic._
scala> import com.gilt.handlebars.scala.binding.dynamic._
import com.gilt.handlebars.scala.binding.dynamic._

Seems like this project is dead? We would love to get this PR merged (or commented on) #57, because then we don't need to maintain an internal forked version. What can we do to speed up the process? Do you need more maintainers?

Are you sure the example provided is correct, I am getting following error

java.lang.NoSuchMethodError: play.api.libs.json.JsLookup$.$bslash$extension(Lplay/api/libs/json/JsLookupResult;Ljava/lang/String;)Lplay/api/libs/json/JsLookupResult;
at com.gilt.handlebars.scala.binding.playjson.PlayJsonBinding.traverse(PlayJsonBinding.scala:42)
at com.gilt.handlebars.scala.context.Context$class.lookup(Context.scala:73)
at com.gilt.handlebars.scala.context.RootContext.lookup(Context.scala:14)
at com.gilt.handlebars.scala.context.Context$class.lookup(Context.scala:34)
at com.gilt.handlebars.scala.context.RootContext.lookup(Context.scala:14)
at com.gilt.handlebars.scala.visitor.DefaultVisitor$$anonfun$2.apply(DefaultVisitor.scala:74)
at com.gilt.handlebars.scala.visitor.DefaultVisitor$$anonfun$2.apply(DefaultVisitor.scala:74)
at scala.Option.orElse(Option.scala:289)
at com.gilt.handlebars.scala.visitor.DefaultVisitor.visit(DefaultVisitor.scala:72)
at com.gilt.handlebars.scala.visitor.DefaultVisitor.visit(DefaultVisitor.scala:45)
at com.gilt.handlebars.scala.visitor.DefaultVisitor$$anonfun$visit$1.apply(DefaultVisitor.scala:54)
at com.gilt.handlebars.scala.visitor.DefaultVisitor$$anonfun$visit$1.apply(DefaultVisitor.scala:54)
at scala.collection.immutable.List.foreach(List.scala:381)
at com.gilt.handlebars.scala.visitor.DefaultVisitor.visit(DefaultVisitor.scala:54)
at com.gilt.handlebars.scala.HandlebarsImpl.apply(Handlebars.scala:39)
... 43 elided

Is it possible to add templates inheritance ?

Like it was done with handlebars.java http://jknack.github.io/handlebars.java/reuse.html

Thanks

The inclusion of "org.slf4j" % "slf4j-simple" % "1.6.4" as a dependency causes problems with multiple StaticLoggerBinder implementation warnings:

SLF4J: Class path contains multiple SLF4J bindings.

Due to the inability to specify which SL4J implementation to use, this means that the first loaded JAR implementation of StaticLoggerBinder wins. In environments where you can't easily control the classpath order (e.g. the universal packaging format output by SBT), this is a problem.

Including the sl4j-api dependency alone will be enough and allow people using this lib to choose their own logging framework! :)

The default IfHelper always call options.inverse(binding) when the given predict is NOT true, which would cause warning message when there is NO inverse node.

I'm noticing that a lot of the pull-requests and issues are building up. Do you need a new maintainer for this project?

(I mean this in the kindest way possible, having been myself guilty of neglecting pull-requests on my projects at times)

Like first name: {{people.0.first_name}}

Can I access the first one in a list like this?

In the current implementation, errors are logged using slf4j. For example, if a value cannot be found in the context, it is just omitted from the result. I would like to obtain a list of the values that could not be found.

What would be the best way to implement this in your opinion?

HelperOptions[T] trait provides the argument method, which returns a single argument value. Is there any way to get a list of all argument values?

My specific use-case is building an i18n helper method which will accept a key, a language, and a variable list of arguments to substitute in the message.

It would fail to parse a template which includes "{{@../index}}" or "{{#each array as |value key|}}".

The handlebars-scala project depends on both slf4j-api and slf4j-simple. The latter is an SLF4J binding. This means that any project depending on handlebars-scala transitively depends on slf4j-simple, which conflicts with any other SLF4J binding they might want to use (e.g., Logback, Log4J).

The recommended approach for libraries is to depend on slf4j-api only. Could you remove the slf4j-simple dependency? If you need it for tests, you can always mark it with the test scope.

Current dependencies are quite dated and we need a new release.

@mwunsch I don't think I have maven central publish access; I could handle the release if I did.

It is not clear for a newbie what the types are for the helper functions:
"func" -> ((context:???, options:???, parent:???) => somestuff)

Are you sure the example provided is correct, I am getting following error when using : handlebars-play-json

java.lang.NoSuchMethodError: play.api.libs.json.JsLookup$.$bslash$extension(Lplay/api/libs/json/JsLookupResult;Ljava/lang/String;)Lplay/api/libs/json/JsLookupResult;
at com.gilt.handlebars.scala.binding.playjson.PlayJsonBinding.traverse(PlayJsonBinding.scala:42)
at com.gilt.handlebars.scala.context.Context$class.lookup(Context.scala:73)
at com.gilt.handlebars.scala.context.RootContext.lookup(Context.scala:14)
at com.gilt.handlebars.scala.context.Context$class.lookup(Context.scala:34)
at com.gilt.handlebars.scala.context.RootContext.lookup(Context.scala:14)
at com.gilt.handlebars.scala.visitor.DefaultVisitor$$anonfun$2.apply(DefaultVisitor.scala:74)
at com.gilt.handlebars.scala.visitor.DefaultVisitor$$anonfun$2.apply(DefaultVisitor.scala:74)
at scala.Option.orElse(Option.scala:289)
at com.gilt.handlebars.scala.visitor.DefaultVisitor.visit(DefaultVisitor.scala:72)
at com.gilt.handlebars.scala.visitor.DefaultVisitor.visit(DefaultVisitor.scala:45)
at com.gilt.handlebars.scala.visitor.DefaultVisitor$$anonfun$visit$1.apply(DefaultVisitor.scala:54)
at com.gilt.handlebars.scala.visitor.DefaultVisitor$$anonfun$visit$1.apply(DefaultVisitor.scala:54)
at scala.collection.immutable.List.foreach(List.scala:381)
at com.gilt.handlebars.scala.visitor.DefaultVisitor.visit(DefaultVisitor.scala:54)
at com.gilt.handlebars.scala.HandlebarsImpl.apply(Handlebars.scala:39)
... 43 elided

I upgraded my app from Scala 2.10 to 2.11 and found that now it's working much more slowly.

For example for a template like Hello {{name}}, You have just won ${{value}}! it takes about 300 ms now. And for my real templates (~500 lines with a few simple placeholders) it takes about ~1 min.
It's really slow now for template parsing (not for rendering, I'd checked it).

Is it only for me or something happened (changed) with 2.11 parsers?

Example in the documentation is not handling the {{kids.length}}, presumably due to the dot?

I absolutely love Scandlebars but I can't get it to compile using the latest Scala version 2.11.0 (getting a lot of errors). Any chance it'll get an upgrade?

I've got this Template:

{{#ScreenProperties}}
{
    "controllerName":"{{&AppName}}.controller.{{&name}}",
    "height": "100%",
        "width" : "100%",
    "content": [{
        "title":"{{&name}}",
                "showHeader" : {{&showHeader}},
        "content":[
                {{& ScreenContent}}
         ]
    }]
}
{{/ScreenProperties}}

and this is my JSON:

{
  "AppName": "Demo1",
  "ScreenContent": "Hello World",
  "ScreenProperties": {
    "name": "Screen1",
    "showHeader": true
  }
}

When I try to fill my Template, this is the result:

{
    "controllerName": ".controller.Screen1",
    "height": "100%",
    "width": "100%",
    "content": [
        {
            "title": "Screen1",
            "showHeader": true,
            "content": []
        }
    ]
}

But when I try to fill it via Try Mustache, it will give me the right Result.
Why does the behavior differ in this context?

PS: I know when my Template would look like that:

{
    "controllerName":"{{&AppName}}.controller.{{#ScreenProperties}}{{&name}}",
    "height": "100%",
        "width" : "100%",
    "content": [{
        "title":"{{&name}}",
                "showHeader" : {{&showHeader}},
                 {{/ScreenProperties}}
        "content":[
                {{& ScreenContent}}
         ]
    }]
}

it would work.

PS²:
Well, I got the reason, this post can be closed.

From what I can see subexpressions are currently not supported. Do you plan to introduce them?

If you pass an empty string to Handlebars.apply, it results in a parse error:

scala> import com.gilt.handlebars.Handlebars
import com.gilt.handlebars.Handlebars

scala> Handlebars("")
java.lang.RuntimeException: Could not parse template:


scala.util.parsing.input.CharSequenceReader@673c8b91
        at scala.sys.package$.error(package.scala:27)
        at com.gilt.handlebars.parser.ProgramHelper$$anonfun$programFromString$1.apply(ProgramHelper.scala:12)
        at com.gilt.handlebars.parser.ProgramHelper$$anonfun$programFromString$1.apply(ProgramHelper.scala:12)
        at scala.util.parsing.combinator.Parsers$ParseResult.getOrElse(Parsers.scala:123)
        at com.gilt.handlebars.parser.ProgramHelper$class.programFromString(ProgramHelper.scala:11)
        at com.gilt.handlebars.DefaultHandlebarsBuilder$.programFromString(HandlebarsBuilder.scala:32)
        at com.gilt.handlebars.DefaultHandlebarsBuilder$.apply(HandlebarsBuilder.scala:34)
        at com.gilt.handlebars.Handlebars$.createBuilder(Handlebars.scala:40)
        at com.gilt.handlebars.Handlebars$.apply(Handlebars.scala:37)

What is the path I have to add to the plugins.sbt file of my play project to install the libary (was doing it via /lib folder as a jar but it seems I have to also get the rest of the dependencies as well which I would rather not do (newbie here)).

Is there a plan to add support for the new Scala version? I don't mind submitting a PR to get it done (assuming it's not blocked), but would like to know that it would get released.

:)

Is there some comparison/benchmarking results? I see, benchmarking is very subjective, but being accompanied with test conditions they have some sense :) So, some simple comparisons with, say, freemarker and scalate would be informative.