[1.x] Japid vs Rythm ?

[Rakesh Waghela]

Both Japid & Rythm are alternate template engines for Play ! 1.x.
Given the fact that Japid was released earlier than rhythm , what make more sense to learn today for ? Merits/Demerits ? Other module support/compatibility ?

Links :-

http://www.playframework.org/modules/japid

http://www.playframework.org/modules/rythm

[green]

hi I am author of rythm and I try to put my understanding here without bias:

1. Both Japid and Rythm parse template files into java source file and then compile into bytecode. Both are high performance templates engine which is multiple times faster than groovy.

2. Japid has been created for more than 2 years and should be more stable.

3. Rythm should be easier to integrate than Japid. With Japid your controller must be sub class of JapidController while there is no obligation of doing similar things with Rythm. rewrite the view file is the only thing you need to do to migrate from groovy to rythm.

4. Japid has restrictions on view folder layout; Rythm has no limitation on view folders, it simply follow play's rule on view file locations.

5. Japid template can extends templates in 'app/japidviews/_layouts' folder while rythm templates can extends any other templates

6. Japid template can call tags in 'app/japidviews/_tags' folder; Rythm template can call any templates (even include the current template itself) as a tag; Rythm also support existing FastTags defined in application.

7. Rythm use '@' to mark all the keywords, directives; expressions and tags; Japid use '`' or '@' to mark keywords and tags, '$' for expressions.

8. Japid provides a eclipse plugin while rythm doesn't at the moment.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/XuhtXgiadtUJ.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[Andy]

Are there any similar templates (parsing template files into java)
that work with Play 2.0?

On Mar 20, 6:43 am, green <greenlaw...@gmail.com> wrote:
> hi I am author of rythm and I try to put my understanding here without bias:
>
> 1. Both Japid and Rythm parse template files into java source file and then
> compile into bytecode. Both are high performance templates engine which is
> multiple times faster than groovy.
>
> 2. Japid has been created for more than 2 years and should be more stable.
>
> 3. Rythm should be easier to integrate than Japid. With Japid your
> controller must be sub class of JapidController while there is no
> obligation of doing similar things with Rythm. rewrite the view file is the
> only thing you need to do to migrate from groovy to rythm.
>
> 4. Japid has restrictions on view folder

> layout<http://www.playframework.org/modules/japid-0.9.3.2/home#RuntimeDirect...>;

> Rythm has no limitation on view folders, it simply follow play's rule on
> view file locations.
>
> 5. Japid template can extends templates in 'app/japidviews/_layouts' folder
> while rythm templates can extends any other templates
>
> 6. Japid template can call tags in 'app/japidviews/_tags' folder; Rythm
> template can call any templates (even include the current template itself)
> as a tag; Rythm also support existing FastTags defined in application.
>
> 7. Rythm use '@' to mark all the keywords, directives; expressions and
> tags; Japid use '`' or '@' to mark keywords and tags, '$' for expressions.
>

> *8. Japid provides a eclipse plugin while rythm doesn't at the moment.*

[green]

there is no such template for 2.0 as far as i know.

[冉兵]

2012/3/20 green <green...@gmail.com>

hi I am author of rythm and I try to put my understanding here without bias:

1. Both Japid and Rythm parse template files into java source file and then compile into bytecode. Both are high performance templates engine which is multiple times faster than groovy.

2. Japid has been created for more than 2 years and should be more stable.

3. Rythm should be easier to integrate than Japid. With Japid your controller must be sub class of JapidController while there is no obligation of doing similar things with Rythm. rewrite the view file is the only thing you need to do to migrate from groovy to rythm.

4. Japid has restrictions on view folder layout; Rythm has no limitation on view folders, it simply follow play's rule on view file locations.

 

The view folder in Japid is reserved for Groovy templates, so there is no mixed-up in a mixed projects where both Japid and Groovy are used.

 

5. Japid template can extends templates in 'app/japidviews/_layouts' folder while rythm templates can extends any other templates

So is Japid. 

 

6. Japid template can call tags in 'app/japidviews/_tags' folder; Rythm template can call any templates (even include the current template itself) as a tag; Rythm also support existing FastTags defined in application.

So is Japid for tags, including recursive invocations.  FastTags not supported. But Japid's capability to nest controller action invocations are lot more powerful and a lot easier to author than the FastTags. 

 

7. Rythm use '@' to mark all the keywords, directives; expressions and tags; Japid use '`' or '@' to mark keywords and tags, '$' for expressions.

8. Japid provides a eclipse plugin while rythm doesn't at the moment.

logs, template name markers, stop watches, mime type markers, content negotiation....

[Andy]

On Mar 20, 7:05 am, green <greenlaw...@gmail.com> wrote:
> there is no such template for 2.0 as far as i know.

I see. Do you have any plan to migrate Rythm to Play 2.0?

[green]

No I don't. But thanks for open source, people could do it if they want.

[R. Rajesh Jeba Anbiah]

I have not tried rythm, but will prefer Japid for it's being more
than a template solution, offering:

1. Content negotiation http://www.playframework.org/modules/japid-0.9.3.2/home#ContentNegotiation
Caveat is that supporting pdf, csv, vcard, etc looks nightmare.

2. "invoke" that helps you to have SSI or iframe like stuff
http://www.playframework.org/modules/japid-0.9.3.2/home#InvokingActionsinTemplates

rythm looks good when you have to quickly migrate groovy code to
high performance template system. If I'm not mistaken, it cannot
coexist with other template solution (unlike Japid). However it seems
to support FastTags. No offense, but personally had tough time with
Green's few other plugs.

[green]

 If I'm not mistaken, it cannot
coexist with other template solution (unlike Japid).

This is not true. Rythm can coexist with groovy or Japid or any other templates. You can put rythm view files in app/rythm folder just like you put groovy files in app/views folder.

 

However it seems
to support FastTags. No offense, but personally had tough time with
Green's few other plugs.

Sorry about that. What problems did encountered? have you posted the issues you encountered to the group or reported it to github? 

This is not true. Rythm can coexist with groovy or Japid or any other templates. You can put rythm view files in app/rythm folder just like you put groovy files in app/views folder.

 

However it seems
to support FastTags. No offense, but personally had tough time with
Green's few other plugs.

Sorry about that. Did you post the issues you encountered to the group or report it to github? 

[thinkmustache]

What about speed? Japid seems to be faster than other template systems
(May 2011):
http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

> >http://www.playframework.org/modules/japid-0.9.3.2/home#ContentNegoti...

> > Caveat is that supporting pdf, csv, vcard, etc looks nightmare.
>
> > 2. "invoke" that helps you to have SSI or iframe like stuff
>

> >http://www.playframework.org/modules/japid-0.9.3.2/home#InvokingActio...

[green]

rythm is at the same level of Japid.

Benchmark test suite 1: https://github.com/greenlaw110/blogpost_files, the fork of the bench mark tests that back the blog:  http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/ 

Benchmark test suite 2: pure template rendering performance: https://github.com/greenlaw110/template-engine-benchmarks. Result of this benchmark can be found at  http://rythmengine.com/document/feature 

[Rakesh Waghela]

Thank you Green & Bing ! Will try both.

One interesting thing is the version scheme, Both modules are almost versioned similrly i.e, 0.9x , does it mean both are mature and production ready to cover basic use cases f view layer of traditional web app development ( not necessarily compliant to restful principals ) ?

[冉兵]

Japid started from version 0.2 two years ago and the latest is 0.9.3.4 after 20 something releases. I have basically followed the NGINX release pattern: solid/production ready releases with small version numbers. 

2012/3/20 Rakesh Waghela <java...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/DZZfqOguVw8J.

[Andy]

On Mar 20, 12:51 pm, 冉兵 <bing....@gmail.com> wrote:
> Japid started from version 0.2 two years ago and the latest is 0.9.3.4
> after 20 something releases. I have basically followed the NGINX release
> pattern: solid/production ready releases with small version numbers.

Is Japid going to support Play 2.0?

[Rakesh Waghela]

I can understand Andy's concern ! He already asked the same about Rythm ;)

[sas]

with the issues raised by scala long compiling times, I think that a
port of any of them to play 2.0 would be very welcome indeed...

[冉兵]

It will. Not sure of the schedule though. 

2012/3/21 Andy <selfor...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

[R. Rajesh Jeba Anbiah]

On Mar 21, 11:20 am, 冉兵 <bing....@gmail.com> wrote:
> It will. Not sure of the schedule though.

Have you changed your mind to switch to 2.0? Curious to know the
reason;)

[R. Rajesh Jeba Anbiah]

On Mar 21, 12:13 am, sas <open...@gmail.com> wrote:
> with the issues raised by scala long compiling times, I think that a
> port of any of them to play 2.0 would be very welcome indeed...

Just curious, why do you want 2.0? I personally find
form.bindFromRequest() useful and can't seem to notice anything better

[tschundeee]

Rajesh +1.

Play2 feels like an alpha version. Features are missing, the website looks horrible, documentation is ":/" compared to play1.

The real play2 would be play1 + japid or rythm + better form helper (like simple_form in rails or the form helper from play2).

I don't want scala in my code. It's a personal opinion but scala is not as readable as java.

[R. Rajesh Jeba Anbiah]

On Mar 21, 1:58 pm, tschundeee <b.rahn...@gmail.com> wrote:
> Rajesh +1.
> Play2 feels like an alpha version. Features are missing, the website looks
> horrible, documentation is ":/" compared to play1.

I must confess that I have not checked 2.0 closely. But, quickly
found some changed APIs and useful form.bindFromRequest(). I may be
missing something... so if anyone can list some differences, that will
be useful.

> The real play2 would be play1 + japid or rythm + better form helper (like
> simple_form in rails or the form helper from play2).

Yes, this is what I'm thinking at the moment and I'm more inclined
towards Japid for invoke support (Probably mentioned over 100 times
here;) )

> I don't want scala in my code. It's a personal opinion but scala is not as
> readable as java.

Yes, I'm on the same boat. Scala may be attractive to people
coming from Python or Ruby background. I stared with Scala and moved
to Java, mostly for weird compile errors and readability.

[sas]

here's a summary of the difference between play1 & play2

http://www.scoop.it/t/playframework/p/1461028414/playframework-what-are-the-major-differences-between-play-framework-1-0-and-2-0-stack-overflow

On 21 mar, 06:55, "R. Rajesh Jeba Anbiah"

[sas]

that's great news!

On 21 mar, 03:20, 冉兵 <bing....@gmail.com> wrote:
> It will. Not sure of the schedule though.
>

> 2012/3/21 Andy <selforgani...@gmail.com>

[green]

Hi I would like to bring the invoke support into rythm but before that I need to understand why invoking a controller action method inside template is good design.

From my understanding, the controller action invocation is heavy because you need to pass through the whole stack of processing including all @Before/@After@Final injections, all module's relevant handling methods and the binding process built into the framework. Why do we need to bother with it if we have much cheaper fasttag implementation to go?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

[Gaëtan Renaudeau]

2012/3/21 tschundeee <b.ra...@gmail.com>

Rajesh +1.

Play2 feels like an alpha version. Features are missing, the website looks horrible, documentation is ":/" compared to play1.

What feature is missing? Help us make it better.

The real play2 would be play1 + japid or rythm + better form helper (like simple_form in rails or the form helper from play2).

I don't want scala in my code. It's a personal opinion but scala is not as readable as java.

Sorry but you can't say, that, Play2 provides a Java API for making java application, scala is just a core implementation choice.

Am Mittwoch, 21. März 2012 09:36:53 UTC+1 schrieb R. Rajesh Jeba Anbiah:

On Mar 21, 12:13 am, sas <open...@gmail.com> wrote:
> with the issues raised by scala long compiling times, I think that a
> port of any of them to play 2.0 would be very welcome indeed...

   Just curious, why do you want 2.0? I personally find
form.bindFromRequest() useful and can't seem to notice anything better

--

You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/TH03Ggm1nSYJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
Gaëtan Renaudeau, @greweb
blog | gaetanrenaudeau.fr

[Andy]

On Mar 21, 2:20 am, 冉兵 <bing....@gmail.com> wrote:
> It will. Not sure of the schedule though.

Any rough estimate on timeline? I'll be starting a new project in a
month or so, will Japid be available by then?

[冉兵]

It'll probably make it in a month, but you really need to factor in the maturity when your do your planning. My team won't be developing on Play2, so it won't get as much rigorous test as Japid1. 

2012/3/22 Andy <selfor...@gmail.com>

[GrailsDeveloper]

Will it have a compile-safe render-method like the scala-template-engine?

Niels

Am Donnerstag, 22. März 2012 02:44:53 UTC+1 schrieb Bing Ran:

It'll probably make it in a month, but you really need to factor in the maturity when your do your planning. My team won't be developing on Play2, so it won't get as much rigorous test as Japid1. 

2012/3/22 Andy <selfor...@gmail.com>

On Mar 21, 2:20 am, 冉兵 <bing....@gmail.com> wrote:
> It will. Not sure of the schedule though.

Any rough estimate on timeline? I'll be starting a new project in a
month or so, will Japid be available by then?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.

[R. Rajesh Jeba Anbiah]

On Mar 22, 12:47 am, green <greenlaw...@gmail.com> wrote:
> Hi I would like to bring the invoke support into rythm but before that I
> need to understand why invoking a controller action method inside template
> is good design.
>
> From my understanding, the controller action invocation is heavy because
> you need to pass through the whole stack of processing including all
> @Before/@After@Final injections, all module's relevant handling methods and
> the binding process built into the framework. Why do we need to bother with
> it if we have much cheaper fasttag implementation to go?

Japid looks faster here. So, you may get idea from that.

Yes, it really saves lot of time. For example, in a user view page,
you may want to list his top 10 photos. If you don't have invoke
feature, you have to pull user contents and photos and put that in a
single view file. With invoke, it's just like SSI or iframe logic--you
may reuse lot of code with minimal-generated-crud code. Refer
CakePHP's requestAction()
http://bakery.cakephp.org/articles/gwoo/2007/04/12/creating-reusable-elements-with-requestaction
Displaying recent 10 posts anywhere is just calling $this-
>requestAction('posts/index/sort:created/direction:desc/limit:10',
array('return')); provided you don't have to tweak anything anywhere.

[R. Rajesh Jeba Anbiah]

On Mar 21, 7:39 pm, sas <open...@gmail.com> wrote:
> here's a summary of the difference between play1 & play2
>

> http://www.scoop.it/t/playframework/p/1461028414/playframework-what-a...

Thanks. Do *you* find the differences attractive to make a switch?

[green]

Fair enough. Just release Rythm 0.9.7 where you can invoke controller action as:

@controllers.Application.index()

No direct cache support yet. But you can easily do it with the @cache tag

@cache("controller-application-index", "10mn") {

    @controllers.Application.index()

}

or 

@cacheOnProd("controller-application-index", "10mn") {

    @controllers.Application.index()

}

I am also thinking of adding something syntax sugar like:

@controllers.Application.index().cacheFor("1mn")

[tschundeee]

Play2 is currently missing the following things:

• WAR deployment
• Form SecurityToken
• E-Mail sending workflow
• Eclipse Plugin
• Standard Java Memory Consumption for Jetty & PROD is set to 512MB (pretty much for a lightweight framework)
• Updated Bootstrap support
• CRUD-Module
• Scaffolding
• Nice Template for Java Apps at least (why do I have to create the model or lib folder myself?)
• Image Editing Lib like Play1 had

This list is not complete and you are free to add stuff...

[R. Rajesh Jeba Anbiah]

On Mar 29, 11:56 am, green <greenlaw...@gmail.com> wrote:
> Fair enough. Just release Rythm 0.9.7 where you can invoke controller
> action as:
>
> @controllers.Application.index()

<snip>

(Apologies for the late reply; I was away.) If you're planning to
offer all features of Japid, what about keeping Japid core and keeping
the syntax handlers as pluggable? This way, it would be easier to have
different syntaxes (Groovy, Japid, etc) handled/compiled in the same
way as Japid. This would also let people to come up with more template
languages.

[Pascal Voitot Dev]

If all alpha versions could be like Play2, how happy I would be in my everyday life as a developer!
Don't forget that you can contribute or evaluate stuff really easy in play2 so don't hesitate to help us!

--

You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/h1euVVupI_cJ.

[green]

Hi Rajesh,

I am not trying to clone Japid by creating Rythm. Instead I learn from Japid and other great products including Groovy, Jamon and Velocity to create a something which better meet my own flavour. There are good things I like in Japid and there are something (NOT necessarily bad) I don't like and syntax is not the only one:

* You must extend JapidController to use it.

* The render methods used in JapidController is more complicated compare to the render() methods defined in play's Controller. And I prefer to use play's way of handling named arguments. 

* By using Rythm(or Groovy) I could use one Controller method to generate csv, xls and html view respectively merely based on request.format. This is not doable if I am using Japid because it doesn't integrate into Play's template render process and Japid is the only template engine you can invoke using JapidRender.

* The template parsing/compilation process. You are forced to run a command line tool to compile the template at prod mode. And "one must write the templates first and convert them to Java classes (manually or automatically, depending on the development environment) before they can be used in controller actions. (from Japid document)". I also don't like the java files get generated in the view(JapidViews) folder because it's hard to handle from SCM perspective. As the contrast Rythm cache bytecode and java source in the tmp/rythm folder.

* Error reporting. Japid report compilation error in the Java code instead of template code.

* Rythm syntax is simpler. E.g. 

** invoke tag; japid: `t tagName(args1,...) rythm: @tagName(args1,...)

** invoke action: japid: `a controllers.ControllerClass.actionMethod(...), rythm: @controllers.ControllerClass.actionMethod(...)

* Rythm core is 100% independent of Play and is easier to use in a plain Java environment.

Actually before creating Rythm I tried to write a plugin based on Japid to make it more tightly integrated with Play and I found it's very hard to do. It's also not easy to dress it another syntax cloth.

Again, Rythm does not copy Japid and give it an new dress. I created it because I want something that is not presented in current products (Japid and Groovy).

[冉兵]

2012/4/6 green <green...@gmail.com>

Hi Rajesh,

I am not trying to clone Japid by creating Rythm. Instead I learn from Japid and other great products including Groovy, Jamon and Velocity to create a something which better meet my own flavour. There are good things I like in Japid and there are something (NOT necessarily bad) I don't like and syntax is not the only one:

* You must extend JapidController to use it.

Not entirely true. The controller does not need to inherit anything if explicit linking to the view is used. 

 

* The render methods used in JapidController is more complicated compare to the render() methods defined in play's Controller. And I prefer to use play's way of handling named arguments. 

 

RenderJapid(   ) is all you need. The others are for extra. 

 

* By using Rythm(or Groovy) I could use one Controller method to generate csv, xls and html view respectively merely based on request.format. This is not doable if I am using Japid because it doesn't integrate into Play's template render process and Japid is the only template engine you can invoke using JapidRender.

Content negotiation is always supported for xml, json, js, css, txt, html, etc.  The classic render() is still there to serve Groovy templates. 

 

* The template parsing/compilation process. You are forced to run a command line tool to compile the template at prod mode. And "one must write the templates first and convert them to Java classes (manually or automatically, depending on the development environment) before they can be used in controller actions. (from Japid document)". I also don't like the java files get generated in the view(JapidViews) folder because it's hard to handle from SCM perspective. As the contrast Rythm cache bytecode and java source in the tmp/rythm folder.

The templates are compiled automatically when the app is started in PROD mode.  One needs to write templates first ONLY if he/she want to link the views statically. Otherwise use whatever work flow that suits. One can configure  SCM to ignore these Java artifacts like we do. Having them side-by-side makes navigation a lot easier. 

 

* Error reporting. Japid report compilation error in the Java code instead of template code.

My fork of Play (https://github.com/branaway/play) takes care of the pretty error. You were right. I should have made it available by itself. 

 

* Rythm syntax is simpler. E.g. 

** invoke tag; japid: `t tagName(args1,...) rythm: @tagName(args1,...)

** invoke action: japid: `a controllers.ControllerClass.actionMethod(...), rythm: @controllers.ControllerClass.actionMethod(...)

So there is one character difference and I find it helps remind code readers of the semantics:  is it calling an imported static method, a method from super class, a tag or a controller action?

 

* Rythm core is 100% independent of Play and is easier to use in a plain Java environment.

Use Japid as a generic template engine: 

https://github.com/branaway/Japid/blob/master/documentation/manual/Japid_Generic_Engine.textile

 

Actually before creating Rythm I tried to write a plugin based on Japid to make it more tightly integrated with Play and I found it's very hard to do. It's also not easy to dress it another syntax cloth.

Again, Rythm does not copy Japid and give it an new dress. I created it because I want something that is not presented in current products (Japid and Groovy).

Innovations are always welcome. 

[green]

On Sat, Apr 7, 2012 at 1:11 AM, 冉兵 <bing...@gmail.com> wrote:

2012/4/6 green <green...@gmail.com>

Hi Rajesh,

I am not trying to clone Japid by creating Rythm. Instead I learn from Japid and other great products including Groovy, Jamon and Velocity to create a something which better meet my own flavour. There are good things I like in Japid and there are something (NOT necessarily bad) I don't like and syntax is not the only one:

* You must extend JapidController to use it.

Not entirely true. The controller does not need to inherit anything if explicit linking to the view is used. 

 

Sounds good. So explicit linking require you have the template ready first otherwise controller report compilation error. However this feature should be embraced by play2 guys.

 

* The render methods used in JapidController is more complicated compare to the render() methods defined in play's Controller. And I prefer to use play's way of handling named arguments. 

 

RenderJapid(   ) is all you need. The others are for extra. 

 

I see. I prefer play's way to handle named arguments. Of course this is purely a personal flavour.

 

* By using Rythm(or Groovy) I could use one Controller method to generate csv, xls and html view respectively merely based on request.format. This is not doable if I am using Japid because it doesn't integrate into Play's template render process and Japid is the only template engine you can invoke using JapidRender.

Content negotiation is always supported for xml, json, js, css, txt, html, etc.  The classic render() is still there to serve Groovy templates. 

Play's rendering process does not only handle content negotiation, but also allow you to call different template engines based certain logic condition. For example, if request format is "xls" or "xlsx", Excel template engine shortcut the rendering process and if there are template files found in rythm view folder, Rythm template engine shortcut the rendering process, while you don't need to branch your code in controller action code like if (x) renderJapid(...) otherwise render(...)

 

* The template parsing/compilation process. You are forced to run a command line tool to compile the template at prod mode. And "one must write the templates first and convert them to Java classes (manually or automatically, depending on the development environment) before they can be used in controller actions. (from Japid document)". I also don't like the java files get generated in the view(JapidViews) folder because it's hard to handle from SCM perspective. As the contrast Rythm cache bytecode and java source in the tmp/rythm folder.

The templates are compiled automatically when the app is started in PROD mode.  One needs to write templates first ONLY if he/she want to link the views statically. Otherwise use whatever work flow that suits. One can configure  SCM to ignore these Java artifacts like we do. Having them side-by-side makes navigation a lot easier. 

 

Hmm... this is good and I guess you can update the Japid document to highlight this feature. Configuring SCM to ignore java artifactis in view folder might not be a big thing, it just makes me a little bit upset (again this is very subjective feeling). In the mean time I don't think people have the needs to navigate to the intermediate artifacts (the java source code). Might be useful in rare case when you want dig into the java source for debugging purpose etc, but definitely not a very common thing to do to application developer. Even in that rare case you can still check your source code in the temp directory, right?

 

* Error reporting. Japid report compilation error in the Java code instead of template code.

My fork of Play (https://github.com/branaway/play) takes care of the pretty error. You were right. I should have made it available by itself. 

 

* Rythm syntax is simpler. E.g. 

** invoke tag; japid: `t tagName(args1,...) rythm: @tagName(args1,...)

** invoke action: japid: `a controllers.ControllerClass.actionMethod(...), rythm: @controllers.ControllerClass.actionMethod(...)

So there is one character difference and I find it helps remind code readers of the semantics:  is it calling an imported static method, a method from super class, a tag or a controller action?

From my understanding, calling tag, controller action, a static or dynamic methods are essentially the the same thing: you are calling some function defined some where in the source code and get the render result of that function. Namespace is enough to distinguish one from the other, do we really need to involve additional language elements to differentiate them?

 

* Rythm core is 100% independent of Play and is easier to use in a plain Java environment.

Use Japid as a generic template engine: 

https://github.com/branaway/Japid/blob/master/documentation/manual/Japid_Generic_Engine.textile

 

Actually before creating Rythm I tried to write a plugin based on Japid to make it more tightly integrated with Play and I found it's very hard to do. It's also not easy to dress it another syntax cloth.

Again, Rythm does not copy Japid and give it an new dress. I created it because I want something that is not presented in current products (Japid and Groovy).

Innovations are always welcome. 

Thanks. All in all, I think the differences between Japid and Rythm are more about personal flavour than technical superiority. You can use either one with Play-1.x for a high performance templating solution. If you are migrating from groovy template, rythm provides an easier way to go.

[冉兵]

2012/4/7 green <green...@gmail.com>

 

* By using Rythm(or Groovy) I could use one Controller method to generate csv, xls and html view respectively merely based on request.format. This is not doable if I am using Japid because it doesn't integrate into Play's template render process and Japid is the only template engine you can invoke using JapidRender.

Content negotiation is always supported for xml, json, js, css, txt, html, etc.  The classic render() is still there to serve Groovy templates. 

That's what I meant. The proper template was selected automatically based on the mime-type. No big if/else.

 

 

* Rythm syntax is simpler. E.g. 

** invoke tag; japid: `t tagName(args1,...) rythm: @tagName(args1,...)

** invoke action: japid: `a controllers.ControllerClass.actionMethod(...), rythm: @controllers.ControllerClass.actionMethod(...)

So there is one character difference and I find it helps remind code readers of the semantics:  is it calling an imported static method, a method from super class, a tag or a controller action?

From my understanding, calling tag, controller action, a static or dynamic methods are essentially the the same thing: you are calling some function defined some where in the source code and get the render result of that function. Namespace is enough to distinguish one from the other, do we really need to involve additional language elements to differentiate them?

Anything to help the readers to understand your code is a positive thing. If you import the package/class in the front and not using the full qualified name (can you really do this at all?) in invoking tags/actions, readers will lose track. I think Rythm has some rules for users to remember to resolve naming conflicts caused by using the same grammar to invoke different things. 

[green]

On Sat, Apr 7, 2012 at 3:16 PM, 冉兵 <bing...@gmail.com> wrote:

2012/4/7 green <green...@gmail.com>

 

* By using Rythm(or Groovy) I could use one Controller method to generate csv, xls and html view respectively merely based on request.format. This is not doable if I am using Japid because it doesn't integrate into Play's template render process and Japid is the only template engine you can invoke using JapidRender.

Content negotiation is always supported for xml, json, js, css, txt, html, etc.  The classic render() is still there to serve Groovy templates. 

That's what I meant. The proper template was selected automatically based on the mime-type. No big if/else.

I know content negotiation could enable the render engine pick up template files automatically and no need for if/else. What I mean is Play's render process does not only allow you to pick up template files, but also pick up render engine. For example, excel files can be processed by  rythm while it can processed by excel module. Play's render process allow it dispatch to excel spreadsheet render engine when it comes to "xls" format, this is not doable in Japid's own render process. And excel just name one possibility. Other types of render engine could be plugged into the queue like PDF, flash, image, svg etc.

 

 

 

* Rythm syntax is simpler. E.g. 

** invoke tag; japid: `t tagName(args1,...) rythm: @tagName(args1,...)

** invoke action: japid: `a controllers.ControllerClass.actionMethod(...), rythm: @controllers.ControllerClass.actionMethod(...)

So there is one character difference and I find it helps remind code readers of the semantics:  is it calling an imported static method, a method from super class, a tag or a controller action?

From my understanding, calling tag, controller action, a static or dynamic methods are essentially the the same thing: you are calling some function defined some where in the source code and get the render result of that function. Namespace is enough to distinguish one from the other, do we really need to involve additional language elements to differentiate them?

Anything to help the readers to understand your code is a positive thing. If you import the package/class in the front and not using the full qualified name (can you really do this at all?) in invoking tags/actions, readers will lose track. I think Rythm has some rules for users to remember to resolve naming conflicts caused by using the same grammar to invoke different things. 

A main concept in Rythm is "every template is a Java class", so you must obey the Java's rule that the class name should be unique inside the same package. As long as a java developer has no problem to follow this rule, he should have not problem in using Rythm. 

A special note is now you need full qualified name to invoke a tag and controller action. But I don't think it's a big problem, as you seldom use a tag more than once in a template, so there is no difference between writing an import statement and invoke it with full qualified name. However both could be improved so that it allows to import declaration and suppress full qualified name invocation. 

In essence I don't think a template (tag) invocation, action invocation and static/dynamic methods are "different things" from the language level.