I have an app in Play 2.6 and Scala and I want to configure all my Action to return Future or not, or i could say, to be Action or Action.async by a config file. So I could configure my entire app to work in production or test environment.
I have no clue how to do that. Hpw can I start to study and implement it?
Thank you
I wonder if you're looking for something like this which would allow you to provide environment specific configuration values? Including how to use those values in your controller
That document also covers how to specify which application.conf to use via the command line.
Related
I have a custom sails.js hook which implements a Websocket server (we can't use the built-in socket.js hook because we needed to match an old API).
I also have a custom sails run script that does background processing.
Right now, when the sails run -name-of-my-script command is run, it also runs my hook which makes extra listeners for all of the events used by this hook.
I would like to make it that the hook only starts on a main application startup (sails lift or the equivalent node app.js), not on sails run ....
I have looked through the code and the documentation, but I can't seem to see any official way to do this.
I can think of two options:
In the hook, check for whether a script is being run and don't initialize.
In the script, disable the hook.
Is there any way to do either of those things?
Right now, there is no built-in way to do this because Sails scripts have no way to modify configuration - they use the default sails instance with its default settings.
Here is the hack that I used to make it work:
Add a check for a configuration option in the hook's initialize method:
if (app.config.notifier.active === false) {
sails.log.verbose('Notifier disabled');
return cb();
}
// Continue with notifier hook setup here
Add setting an environment variable to the top of the script (before the module.exports:
process.env.sails_notifier__active = false;
(Note: Step 1 is based on this answer but the package linked there no longer uses this technique. That question and answer are also extremely old -- at least as Sails.js answers go -- from before sails run existed.)
I'm looking to create a vue-cli 3.x plugin that generates extra files in the project when invoked and templates these based on configuration info entered by the user.
It's rather easy to collect this information from user prompts but it'd be much nicer if users could put this info into some sort of configuration file and have the plugin read it from there.
I understand vue-cli now uses a vue.config.js file on the project level and ~/.vuerc on a more global (preset) level. However, it doesn't look like my generator function would have access to either one of those files.
"The entire preset" should be passed as the third argument to the function when invoking the plugin with module.exports = (api, options, rootOptions) => {} in ./generator/index.js, rootOptions is undefined.
Sililarly, the use of vue.config.js is discussed in the documentation when talking about service plugins, but there's no mention how to use it in a generator function.
Am I missing something obvious here or is there really no officially sanctioned way to do this? Nothing stops me from reading vue.config.js in my function, but this feels hacky. And I wouldn't even know how to find out which preset was used to create the project.
So your problem is that you can't find ~/.vuerc?
I had the same issue and I found the solution here.
The solution is to use the command line
vue config
to see .vuerc, and then use
vue config --delete presets.yourPresetName
to delete your preset.
As well, if you can't type in your preset name in the terminal because it contains a space or an apostrophe, you can use
vue config --edit
to open .vuerc with a text editor and just edit it there
I am developing a Play! 2 application that generates some html/js widgets which will be embedded into 3rd-party websites. Their linking are dynamic thus I cannot have static test files.
How can I have test views(and routes to those views) that works only in test mode, so I can test with Selenium.
Basically I want to add testView1.scala.html, testView1.scala.html to test/views and have routes to that, but do not want that these work in production mode. What is a good approach to that?
i'm not sure if this is the best way, but here is how i would do it.
create the test route and route to a test controller
in the test controller, create a wrapped action and have all of your routes use this action
this wrapped action will test to see what mode play is in. if play isnt in test mode, forward to 404, otherwise, run the action
when i get home, ill add some code to support, but this is the general workflow i would use.
hope it helps.
Simples...(now with years to answer..). A bit similar to what #mbseid answered:
Rename your /conf/routes to /conf/prod.routes, and specify it in your /conf/application.conf:
play.http.router = prod.Routes
Create a test routes file, e.g. /conf/test.routes, that exposes the test only route and delegates the rest to the prod routes.
/test/only/something controllers.testonly.TestOnlySomethingController.someMethod()
-> / prod.Routes
Make sure your test only controllers are in a different package than other controllers.
When you start your test application override play.http.router, e.g.:
sbt run -Dplay.http.router=test.Routes
It is a useful pattern in microservices environments with integration tests to expose data not otherwise exposed.
Note, play.http.router used to be called application.router before v2.5+
I'm new at using Play Framework 2.0 (I am using Scala) and have a question about sessions.
I come from a Ruby on Rails background, so I tend to think of everything that I learn in Play Framework with respect to Ruby on Rails.
With that in mind, is there any way for me to call stuff stored in the Session while I am in the view?
If I have "hello" -> "world" stored in the Session, I want to be able to do something like #session.get("hello") and be able to use "world" in the view. Is this possible?
The other option I see is to store the value in a variable in the controller, and pass that along to the view by doing something like OK( var ), but that way seems kind of clunky especially if I start using more variables.
Thanks!
Sessions in Play store in cookies and are really just for cross-request data. If that is what you want then you can use #session.get("hello") but what you might actually be after is a way to pass stuff from controllers to templates without having to specify them as parameters. In that case, see the very detailed answer to that question here:
https://stackoverflow.com/a/9632085/77409
Yes you can use #session.get("hello") in template, however it looks that you need to specify at least implicit parameter named 'session' at the beginning of the template when using templates with Scala controllers:
#()(implicit session: play.api.mvc.Session)
Also there is flash scope - it differs from session that it lives only for one request and is not signed. So it is most often used just for transporting error/inf messages.
See Session and flash scopes doc
Finally as each template is just a Scala function, you can also call some action from your controller and retrieve session data
You can definetly call ur session in play templates.
Try this code - it works in views:
$session.session_variable_name;
I'm trying to build a small application (ASP.NET MVC) that uses the plugin architecture. Along with Castle ActiveRecord Integration Facility. And I wish to let each plugin configure its own ActiveRecord behaviors. Like database connection string, proxy, etc..
However, I couldn't find a way to set multiple configurations without the use of web.config. The idea is to make this programmatically.
My goal is for each plugin in this system, if it defines its own ActiveRecord settings, the main application can set up next to ActiveRecordFacility these behaviors.
has someone do something like that?
P.S.: sorry, bad grammar...google translate...;P
You can set up the ActiveRecord configuration programmatically using InPlaceConfigurationSource (lots of examples around), then after initializing ActiveRecord (in your own code), call the ActiveRecordFacility with the skipARInitialization flag. e.g.:
container.AddFacility("ar", new ActiveRecordFacility(true));
This tells the facility not to try to initialize ActiveRecord, so it picks up the existing configuration.
Ok...the example in Lostechies works great. (link text)
Mauricio, thanks for the tip!