Play Vs Grails

[techie]

Anybody can give me a little information, how Play is different from
Grails ?
Is it just another framework like Grails? if now in what aspects it is
much powerful.
Play says --> Really fast Starts fast and runs fast! --> If Play and
Grails both use groovy, how come Play is faster than Grails?
Any developer answers to this questions my help a newbie like me.
cheers

[Guillaume Bort]

Play don't uses groovy as programming language, it uses Java. Groovy
is only used as expression language in the template engine. And there
is also a pure Java templating engine in the module repository.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> 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.
>
>

[dustin....@gmail.com]

I've used Grails quite a bit, and I think it's a fantastic framework, but there are major differences.

I'd say the most striking difference is Grails uses Groovy and strictly Groovy, which means everything is dynamically typed. This is fine for small applications, but becomes difficult to work with and requires extensive testing when a project reaches a larger size

Play only uses Groovy in its default views. Otherwise everything else it is Java (unless you feel like installing the Scala module), which means it statically typed, so you get compile time checks. Normally static typing makes building a web application sluggish and slow, but Play compiles your code on the fly, so it feels like you're building a Grails application, and you will get compile time warnings far in advance of any problems that will remain hidden if you're using Grails.

My preference for the two is Play because I've built large applications with Grails, and been bitten by dynamic typing (you end up building your own type checking via unit tests - arg!).

The one thing to note about Play is that it is not a servlet, which means if you wanted to include a servlet filter written by a third party, or some such thing, you'll have a tough time making it work with Play - you can do it, but you gotta jump through hoops (hoops that are on fire).

Dustin

[Guillaume Bort]

Also I would like to push a statically typed template engine as well.

It's difficult because a template engine need a lot of syntactic sugar
and expressiveness that it difficult to achieve using Java. But I hope
that groovy++ will allow to add more compile time checks. Another
possibility is to use Scala to create a statically typed DSL.

[Bing Ran]

BTW, The Japid rendering module uses static typing that gives end-to-end compile time error checking.

[Bendanpa]

Well said!

for developers, I think you might have to choose Play if you are a
beginner.
for app size, I think play is good for large apps.

if you are an experienced Groovy programmer, and you are working on a
small or middle size app you may choose Grails. But Play is as good as
Grails for this kind of scope, too.

I switched from Grails ==> Lift ==> Play!

Bendanpa

Dustin

[Daniel Guryca]

HI,

4 months ago we switched from Grails to Play. And now we know that it was a good decision !

Grails is nice but Play is better for us:

1.

Static typing means a superior error report checking, code refactoring, debuging, ...

2.

Everything is faster in play - startup time, tests, auto class reloading and no gotchas there.

3.

1 thing we like the most ... play's core is very simple to read - we love this aspect. If you do not know how it works you look into it and you see.

4.

Play does not overcomplicate things. We created around 11 grails plugins (caching, uploading, ...) many of these plugins are not needed in play. 

Either you find them redundant or we found them overkill.

That's what Play learned us ... just go the most simplest and natural path !

Disadvantage:

Many existing java libs require servlet api which can complicate things.

Stateless everything can be for some simple stupid projects overkill (but you can break it and do things your way - so it's not a real disadvantage)

Cheers

Daniel

On Thu, Mar 11, 2010 at 4:51 PM, techie <meet....@googlemail.com> wrote:

[Daniel Guryca]

Hey one important thing we forgot:

5.

Guys from Play team are fantastic. All bugs are solved within a piko second periods !!!!

This is a very huge difference.

In grails we reported many bugs. For some of them we added even a bugfix. It took them yeeeaaars to reflect them into builds.

This was the main aspect why we switched from grails to Play - Grails bugs and gotchas.

Maybe now it is better in grails but we really do not care !

We are running on 1.0 nightly build versions of Play and it's rock stable !

Cheers

Daniel

[mgutz]

I am doing something along these lines with Templa [1]. Scalate
isn't DRY enough for me.

[1] http://www.mgutz.com/2010/03/12/templa_is_code_infusion.html

[曹江华]

where is the website for 

Templa

???????????????

--

You received this message because you are subscribed to the Google Groups "play-framework" group.
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.

--
http://www.caojianghua.com

[Roch Delsalle]

One question mark is usually better if you are expecting an answer,

I don't know if it's available yet.

http://github.com/mgutz/templa

[phausel]

for scala projects, there is the scalate module as well which provides
a scala based, statically typed templating solution:
http://www.playframework.org/modules/scalate

On Mar 12, 9:44 am, Roch Delsalle <rdelsa...@gmail.com> wrote:
> One question mark is usually better if you are expecting an answer,
> I don't know if it's available yet.
>
> http://github.com/mgutz/templa
>
>
>
> On Fri, Mar 12, 2010 at 11:40 AM, 曹江华 <tujiao....@gmail.com> wrote:
> > where is the website for  Templa
> > ???????????????
>

> > On Fri, Mar 12, 2010 at 5:52 PM, mgutz <mario.l.gutier...@gmail.com>wrote:
>
> >> I am doing something along these lines with Templa [1]. Scalate
> >> isn't DRY enough for me.
>
> >> [1]http://www.mgutz.com/2010/03/12/templa_is_code_infusion.html
>
> >> On Mar 11, 8:28 am, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> >> > Also I would like to push a statically typed template engine as well.
>
> >> > It's difficult because a template engine need a lot of syntactic sugar
> >> > and expressiveness that it difficult to achieve using Java. But I hope
> >> > that groovy++ will allow to add more compile time checks. Another
> >> > possibility is to use Scala to create a statically typed DSL.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "play-framework" group.
> >> To post to this group, send email to play-fr...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/play-framework?hl=en.
>
> > --
> >http://www.caojianghua.com
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
> > To post to this group, send email to play-fr...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>

[mgutz]

I wanted to use Scalate, but having to declare binding variables in
the code, in the template and have to pass them as render arguments is
not very DRY.

Templa uses Scala's parser combinators. Customizing the 'grammar' or
creating
a new one is fairly easy (if you know Scala). Templa will make more
sense
once I describe how simple object oriented paradigms
replace partials and layouts. Templa works with both Java and Scala
syntax.

I will commit the source once I have a web app example. I currently
have testable specs for
the default processor, not much more.

[phausel]

On Mar 12, 11:15 am, mgutz <mario.l.gutier...@gmail.com> wrote:
> I wanted to use Scalate, but having to declare binding variables in
> the code, in the template and have to pass them as render arguments is
> not very DRY.
>

the controller part is the standard play stuff (ie either you use
render(//params) or renderArgs.put() ), and I believe you will need to
do something similar with Tempa as well.

The only difference between scalate and the standard groovy stuff is
that you need to tell the types of the variables at the template side
as well for a few reasons: to enable precompilation, to avoid casting
issues, to provide static typing. I guess you can say that it's not
entirely DRY but the current solution means that the the layers are
well separated.

That being said, my main interest is to provide the best end to end
scala experience for play and I dig your approach as well, so if you
make Tempa's code available, I am more than happy to contribute to
your project.

[julien Tournay]

@mgutz

I strongly agree with you, I also consider that templates should use
the language features, and not reinvent the wheel. I like what you're
trying to do here.

BUT

Declaring your vars / vals in the view is DRY in my opinion, because
the declaration in the template and it's call don't do the same thing.
Its just the very same when you create a class/function with
parameters and instanciate/call it somewhere.

Plus, I don't think that "injecting" the template in the controller is
a good idea since it will be a mess to debug.

Julien

[Mario Gutierrez]

I see your point with arguments vs parameters. I like how Ruby makes
all of this transparent and want the same in Play. For the most part, that's
what the default template engine in Play does for Java. I want less
code in the markup.

Debugging a template is the same as debugging before with any template. There
isn't any AFAIK in Play. The same effort. The generated class is viewable.

Also, code should not be injected into a controller. It should be in a view.

## Index view
object Index extends ViewContext with HtmlHelpers {
  def render = {
    // inject
  }
}

object Posts extends Controller {
  def render = Index.render
}

Where `ViewContext` has the  usual request, response.

[phausel]

On Mar 13, 12:40 pm, julien Tournay <boudhe...@gmail.com> wrote:
> @mgutz
>
> I strongly agree with you, I also consider that templates should use
> the language features, and not reinvent the wheel. I like what you're
> trying to do here.
>

scalate is using scala in "ssp" mode: http://scalate.fusesource.org/documentation/ssp-reference.html

[phausel]

On Mar 13, 1:36 pm, Mario Gutierrez <mario.l.gutier...@gmail.com>
wrote:

> I see your point with arguments vs parameters. I like how Ruby makes
> all of this transparent and want the same in Play. For the most part, that's
> what the default template engine in Play does for Java. I want less
> code in the markup.
>

it sounds like your issue really is static typing in which case I
would recommend to use either the standard groovy engine or create a
DSL which is not picky about types.

> Debugging a template is the same as debugging before with any template.
> There
> isn't any AFAIK in Play. The same effort. The generated class is viewable.
>
> Also, code should not be injected into a controller. It should be in a view.
>
> ## Index view
> object Index extends ViewContext with HtmlHelpers {
>   def render = {
>     // inject
>   }
>
> }
>
> object Posts extends Controller {
>   def render = Index.render
>
> }
>
> Where `ViewContext` has the  usual request, response.
>
>

BTW that was my point about parameter passing, you will need to do
this in this design as well. Also, unless you can somehow pregenerate
that extra Index object into a separate package (which can be tricky
to do if parameters are involved), it will be really cumbersome to do
this stuff per method. Please note, I am not saying your idea is a bad
idea, just that play integration can be tricky.

[phausel]

also, just to make it clear: you can use the scala module with the
groovy engine without any issues.

[julien Tournay]

@phausel
I wasn't talking specifically about any template engine. I've not
tried scalate, but i'll do :)

Concerning Templa.
I don't want to write code that's just "glue" between my template and
my controller.
Play! (and Rails, and Django and...) allow me (the devellopper) to
focus on my app features, not on boillerplate code that just here
because it's needed by the language / framework.