In the silhouette implementation example found here, how in the template is the implicit 'env' value (of type Environment[User, CachedCookieAuthenticator]) used in line 28 of /app/controllers/SignUpController.scala, for example, defined using Guice?
I guess I do not understand how provideEnvironment in app/utils/di/SilhouetteModule.scala is used to "inject" the Silhouette Enviroment into SignUpController (for example) via the "injector" created in line 24 of app/Global.scala. I don't see provideEnvironment being used anywhere in the play-silhouette-slick-seed example, so I can't seem to figure out what values are given to its arguments (such as userService, authenticatorService etc).
This example of silhouette module use Guice for scala Dependency Injection framework. All bindings are configured in util.di.SilhouetteModule.scala file. There is another example where Dependency Injection is replaced by Cake pattern. look at this
[edited]In short:
If you look at the Global.scala file, you'll find the guice configuration. Guice is forced to create every controller. Every view is dependend on controllers and will be managed by guice too.
The SilhouetteModule.scala file, as was mentioned above, is for configuration Silhouette module. There are few methods annotated with #Provides. If you look at the Guice documentation. Such method is called by Guice every time it needs class type the method returns, for instance: each time guice need to inject Environment[User, CachedCookieAuthenticator] it call def provideEnvironment method because this method return such type.
Related
In ZIO we provide the Environment with initiating Traits:
program.provide(
new Console.Live with MyComponent {}
)
What I wanted to do is to inject MyComponent dynamically from a configuration file - analog Guice Modules.
The whole scenario is described in this Blog.
I can inject a dependency and then create the Environment like:
program.provide(
new Console.Live with Components.Live {
def compsService: Components.Service[Console] = service
}
)
Where service is injected.
This works but has one big disadvantage: We have to define the environment for all Service implementations. So for example if one of them wants to use Random, it is not possible, as we only provide Console.
Is there an alternative to this?
As an idea to solve this problem you could check this concept. Maybe sometimes i'll write library but i feel like it's enough to get idea.
https://gist.github.com/holinov/50fbf349fcb9f6e6c2b89ce319c20bba
If you could wrap injector creation in RIO[Config, Injector] and injection in RIO[Injector, Service] it could fit your needs
I'm learning the Play! framework (2.3.x). I am confused about the meaning of the '#' character in front of the controller in route definitions like this:
POST /myresource/:id/custom #controllers.MyResource.custom(id: Long)
As much as I can infer from the context I've seen this in, it probably has to do with the exact controller implementation (object vs class). Or am I completely wrong in this? I can't find anything in the docs and the code I've seen isn't exactly explanatory. Can anyone explain?
According to the documentation:
Play supports generating two types of routers, one is a dependency
injected router, the other is a static router. The default is the
static router, but if you created a new Play application using the
Play seed Activator templates, your project will include the following
configuration in build.sbt telling it to use the injected router:
routesGenerator := InjectedRoutesGenerator
The code samples in Play’s documentation assumes that you are using
the injected routes generator. If you are not using this, you can
trivially adapt the code samples for the static routes generator,
either by prefixing the controller invocation part of the route with
an # symbol, or by declaring each of your controllers as an object
rather than a class.
The equivalent in Java would be static vs non-static.
I understand that #GwtMock annotation creates a mock of a particular type when run with GwtMockitoTestRunner, but what if I had multiple items of a particular type in my widget? For example if I had many buttons, or many anchors in my widget, is there a way to create mocks for each one individually?
Right now I am thinking of bypassing this shortcoming in my test with something like
#GwtMock mockButtonn;
and then later on
when(mockButton.something()).thenReturn(value1,value2,value3,...)
so I can distinguish the buttons based on order of invocation. But this is definitely unmaintainable. Can someone suggest an alternative?
There are a few different ways to use the mocks generated by GwtMockito, take a look at the documentation at http://google.github.io/gwtmockito/ if you haven't already. It depends on how you're creating your widgets:
If you're creating widgets via UiBinder (fields annotated with #UiField), you don't have to do anything special - they will automatically be filled with mocks when you call createAndBindUi. You can then reference them directly in your tests, e.g. when(myClass.myLabel.getText()).thenReturn("some text"). This works because fields have to be package-private for UiBinder, so you can see them from your tests.
If you're passing widgets into your class via its constructor or some other way (dependency injection), then just declare fields in your test using the normal Mockito #Mock annotation. GwtMockito will invoke Mockito to fill these in automatically, but otherwise it's just the same as any other Mockito mock.
If you're creating widgets via GWT.create, this is where #GwtMock is valuable. The only difference between #GwtMock and #Mock is that #GwtMock also makes it so any calls to GWT.create will return the object annotated with #GwtMock. So it doesn't really make sense to annotate multiple fields of the same type with #GwtMock, since GWT.create can return only one of them.
If you're creating widgets directly via new, don't do that! It will be impossible to create fake version for testing, and you should use dependency injection instead.
1 and 2 are the most common cases by far - it's somewhat uncommon to actually have to use #GwtMock.
I want to build a simple 'rake' style command line tool that will allow me to define tasks in scala (that can optionally take additional command line arguments) that will be automatically loaded and accessible through a single main() method, to provide a single point of entry and minimize generating lots of wrapper scripts.
An example of what I'm looking for is Jersey, which will automatically load all annotated classes in a specified package and create REST endpoints. What's the right way to do this in scala? Basically, I just want to end up with a collection of instances of every class in a
package with a given annotation (which all have a Task trait or are a subclass of Trait, etc.)
I have an assignment to code several methods in Scala. The methods will be encapsulated in an object that has no main method. The professor gave us a JAR file that contains an interface (my object implements this interface) as well as a sort of pseudo test object that performs various assert statements against each of my functions. This object also does not contain a main method.
Now in Intellij I simply had to declare the dependency on the JAR in the classpath, and it runs fine. Eclipse is giving me trouble though because when I go to define a Scala application run configuration it specifically asks me to name the class that contains a main method, and there is no main method.
I am assuming that I might be choosing the wrong project type for this type of set up, but I am inexperienced with this and I would appreciate any advice you might have for running something like this in eclipse.
Thanks.
I would either:
just write an object with a main method which calls the test object, or
start a Scala interpreter in your project (from context menu, under Scala).
Preferring the first approach, because it's faster to repeat tests after a modification.