Dependency injection into Scala objects

[Ivan Meredith]

The injection support with the guice (and I assume spring) modules does not work because var and val fields in objects are not static in the byte code.

Does anyone have a work around for injecting into controllers?

[Guillaume Bort]

I don't think it is useful to support any kind of dependency injection
in Scala anyway. The built-in features of the Scala language are
already more powerful than Guice or Spring.

> --
> 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.
>

--
Guillaume Bort, http://guillaume.bort.fr

[Ivan Meredith]

Thats true in general, I'm just not sure how to inject things into a controller so that i can swap out a production class for a mock one (it hits a web api that i really cant have hit in test)

[Ivan Meredith]

If there is another solution available I would be for that. I don't really like the idea of DI, even in Java, I am just at a loss on how to do testing properly due to controllers being objects.

I guess I could set the object field at test run time, atlhough that seems like a bit of a hack :)

[Dave]

I'll agree that the benefits of Scala outweigh the loss of DI, but I wouldn't go so far as to say you don't need it. DI applies an implementation design pattern that no language construct has replicated. 

Is not supporting DI because of a technical problem in implementing it or just for lack of time? If it were the latter, perhaps someone else could help from within the Guice/Spring modules.

[Guillaume Bort]

There are several possibilities, but I would do something like:

object Application extends Controller with Services {

def index = {
val user = userService.get(session("connected"))
}

}

trait Services {
val userService = if(test) { new MockUserService } else { new
LdapUserService }

[Ivan Meredith]

putting test detectomg code inside the controller is a bit ick. Thats probably what I'll end up doing anyway... but Guice would be a more elegant solution that I could do in Java :)

[Julien Richard-Foy]

Why would it be more elegant?

[Ivan Meredith]

Because I could leave all mock classes in the test dir.

On 16 June 2011 10:24, Julien Richard-Foy <j...@zenexity.com> wrote:

Why would it be more elegant?

--

[Kodos]

Out of curiosity, how have others ended up solving this. I've been
struggling with the same issue that Ivan raised. I'm concerned that
the if(test) approach that Guillaume suggested implies that all tests
would utilize the same Mock implementations, and unless I'm
misunderstanding, it would also not allow for Mock usage in some tests
(e.g. Unit), and real implementations in others (e.g. Functional).

I'd like to use SubCut, the Cake Pattern, or something similar, but
thus far all I've come up with is coding my controllers as classes,
and then writing an object that extends it (which is dirty to say the
least). I can at least use the class with some DI conventions, and
get testability, but it is still FAR from ideal.

Any suggestions, stories, etc, would be appreciated.

On Jun 15, 3:37 pm, Ivan Meredith <i...@ivan.net.nz> wrote:
> putting test detectomg code inside the controller is a bit ick. Thats
> probably what I'll end up doing anyway... but Guice would be a more elegant
> solution that I could do in Java :)
>

> On 16 June 2011 03:24, Guillaume Bort <guillaume.b...@gmail.com> wrote:
>
>
>
>
>
>
>
> > There are several possibilities, but I would do something like:
>
> > object Application extends Controller with Services {
>
> >    def index = {
> >         val user = userService.get(session("connected"))
> >    }
>
> > }
>
> > trait Services {
> >    val userService = if(test) { new MockUserService } else { new
> > LdapUserService }
> > }
>
> > On Wed, Jun 15, 2011 at 11:31 AM, Ivan Meredith <i...@ivan.net.nz> wrote:
> > > If there is another solution available I would be for that. I don't
> > really
> > > like the idea of DI, even in Java, I am just at a loss on how to do
> > testing
> > > properly due to controllers being objects.
> > > I guess I could set the object field at test run time, atlhough that
> > seems
> > > like a bit of a hack :)
>

> > > On 15 June 2011 21:13, Ivan Meredith <i...@ivan.net.nz> wrote:
>
> > >> Thats true in general, I'm just not sure how to inject things into a
> > >> controller so that i can swap out a production class for a mock one (it
> > hits
> > >> a web api that i really cant have hit in test)
>

> > >> On 15 June 2011 20:48, Guillaume Bort <guillaume.b...@gmail.com> wrote:
>
> > >>> I don't think it is useful to support any kind of dependency injection
> > >>> in Scala anyway. The built-in features of the Scala language are
> > >>> already more powerful than Guice or Spring.
>

> > >>> On Wed, Jun 15, 2011 at 7:04 AM, Ivan Meredith <i...@ivan.net.nz>

> > wrote:
> > >>> > The injection support with the guice (and I assume spring) modules
> > does
> > >>> > not
> > >>> > work because var and val fields in objects are not static in the byte
> > >>> > code.
> > >>> > Does anyone have a work around for injecting into controllers?
>
> > >>> > --
> > >>> > 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.
>
> > >>> --

> > >>> Guillaume Bort,http://guillaume.bort.fr

>
> > >>> --
> > >>> 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.
>
> > > --
> > > 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.
>
> > --

> > Guillaume Bort,http://guillaume.bort.fr

[C.D.]

This thread has been dead for a while now. But, I could not find a good solution to this problem even now. 

Along with the controllers, you need a similar approach for Model's companion objects (have a trait that is replaceable and have an object extend it), basically every model will have a case class for data, a trait for singleton implementation and an object as the Companion object. 

I would appreciate some insight and sharing your experience here.

Thanks...

[Jason Pearson]

Does this help?  I wrote an example play scala app using the cake pattern.

https://github.com/kaeawc/play-cake-pattern

It stays pretty basic, has both unit and integration tests, and lets you swap out the real implementation for the mock at various levels.

[Steven Marcus]

Have you tried the approach outlined at http://eng.42go.com/play-framework-dependency-injection-guice/ ?

GL

[Christopher Hunt]

Here's a doc that may help you:

https://docs.google.com/a/typesafe.com/document/d/195YcVgL3Qgxazk3IH7a2nyBjKgH3kx3lZ0Nb7dYSyX4/pub

...and here's a project using Guice:

http://typesafe.com/activator/template/play-guice