I am working on an Elixir/Phoenix app that is intended to create a user in my UserController controller. There is a /lib/helpers/user_helpers directory with a number of modules (each in a separate file). These modules all have a common namespace UserHelpers.ModuleName. In each of these modules I have a function called apply which I want to apply to the user data. For example if I have the following file structure:
-lib
-helpers
-user_helpers
-module1
-module2
-...
-moduleN-1
-moduleN
where each of module1 and module2 contains a function apply(user_info) which returns user_info. In my UserController I have the function create(conn, params) in which I want to run the following:
user_data
|> UserHelpers.Module1.create
|> UserHelpers.Module2.create
|> ...
|> UserHelpers.ModuleN-1.create
|> UserHelpers.ModuleN.create
But I'm unsure how to dynamically load all of the modules in the UserHelpers folders to do the above. Any suggestions?
Assuming, that your application is called :my_app and helpers have the .ex extension and/or explicitly compiled into your application:
with {:ok, list} <- :application.get_key(:my_app, :modules) do
list
|> Enum.filter(& &1 |> Module.split |> Enum.take(1) == ~w|UserHelpers|)
|> Enum.reduce(user_data, fn m, acc -> apply(m, :create, acc) end)
end
:application.get_key(:my_app, :modules) returns the list of modules, known to that application. The second line filters out those unneeded, and the latter one applies their :create functions to user_data subsequently.
You probably want to embed Enum.sort just before the last line to sort the modules to apply in the appropriate order.
Related
I embedded YAWS in my application at production environment, and I use the function yaws:start_embedded/4 to start YAWS.
Below is my code:
Id = "my_server",
GconfList = [{logdir, "./log"}, {id, Id}],
SconfList = [{docroot, Docroot},
{port, Port},
{listen, Listen},
{appmods, [
{"/rest", mod_rest, []},
{"/file", mod_file, []}
]}
],
yaws:start_embedded(Docroot, SconfList, GconfList, Id).
I'd like to add another appmod, e.g: {"/upload", mod_upload, []}
Is it possible to add appmods at runtime without restarting YAWS?
You can add appmods at runtime by first retrieving the current configuration, using it to create a new configuration containing your new appmods, and then setting the new configuration.
Call yaws_api:getconf/0 to get a 3-tuple {ok, GlobalConf, ServerConfs} where GlobalConf is the global Yaws configuration and ServerConfs is a list of lists of Yaws server configurations. The global conf is a record type named gconf, and the server conf is a record type named sconf; both of these record types are defined in the yaws.hrl header file.
Work through the server configurations to find the one containing the appmods you want to change. This is slightly tricky because you're dealing with a list of lists, and you need to keep the shape of the overall data structure unchanged.
Once you find the sconf, create a new sconf instance from it by adding your new appmod to its current list of appmods. Each element of the appmod list is a tuple consisting of a URL path for the appmod and the name of the appmod module. An appmod tuple can also optionally contain a third field consisting of a list of paths under the first path to be excluded; see the description of exclude_paths in the Yaws appmod documentation for more details.
Replace the existing sconf value in ServerConfs with your new value.
Call yaws_api:setconf/2 to set the new configuration, passing the existing GlobalConf as the first argument and the new ServerConfs containing your new sconf as the second argument.
The am_extend module below shows how to do this. It exports an add/1 function that takes a function that can identify and augment the appmods in the particular server you care about.
-module(am_extend).
-export([add/1]).
add(AppmodAdder) ->
{ok, GlobalConf, ServerConfs} = yaws_api:getconf(),
NewServerConfs = add_appmod(ServerConfs, AppmodAdder),
yaws_api:setconf(GlobalConf, NewServerConfs).
add_appmod(ServerConfs, AppmodAdder) ->
lists:foldl(fun(Val, Acc) ->
Acc ++ [AppmodAdder(A) || A <- Val]
end, [], ServerConfs).
An example of using this code is to pass the function below as the AppmodAdder argument for am_extend:add/1. For this example, we're looking for a server that has an appmod path "/sse" so we can add another appmod to that server for the path "/sse2". Any server conf we don't care about is just returned unchanged.
-include_lib("yaws/include/yaws.hrl").
add_sse2(#sconf{appmods=AM}=SC) ->
case lists:keyfind("/sse", 1, AM) of
false ->
SC;
_ ->
SC#sconf{appmods=[{"/sse2", my_sse_module}|AM]}
end.
Note that our add_sse2/1 function must be compiled with yaws.hrl included so it has the definition for the sconf record available.
Looking at the WixHelper for F# documentation it looks like I can pass in a -filter parameter. I am still learning F# and I can't figure out how this method is supposed to work.
https://github.com/fsharp/FAKE/blob/master/src/app/FakeLib/WiXHelper.fs#L60-60
METHOD
wixDir fileFilter asSubDir directoryInfo
I am trying to adapt this call to filter out *.exe (I do not want to include them).
wixDir (fun file -> true) true (DirectoryInfo (buildDir ## "/SetupFiles"))
You just need to change (fun file -> true) to only return true when the file doesn't end with ".exe" I assume file is a FileInfo, so you would check if the file extension is "exe". I haven't tested this, but it should be something like this:
(fun file -> not (file.Extension = ".exe"))
How does one inject state into ring handlers most conveniently (without using global vars)?
Here is an example:
(defroutes main-routes
(GET "/api/fu" [] (rest-of-the-app the-state)))
(def app
(-> (handler/api main-routes)))
I would like to get the-state into the compojure handler for main-routes. The state might be something like a map created with:
(defn create-app-state []
{:db (connect-to-db)
:log (create-log)})
In a non ring application I would create the state in a main function and start injecting it, or parts of it, as function parameters to the different components of the application.
Can something similar be done with ring's :init function without using a global var?
I've seen this done a couple of ways. The first is using middleware that injects the state as a new key in the request map. For instance:
(defroutes main-routes
(GET "/api/fu" [:as request]
(rest-of-the-app (:app-state request))))
(defn app-middleware [f state]
(fn [request]
(f (assoc request :app-state state))))
(def app
(-> main-routes
(app-middleware (create-app-state))
handler/api))
The other approach is to replace the call to defroutes, which behind the scenes will create a handler and assign it to a var, with a function that will accept some state and then create the routes, injecting the state as parameters to function calls within the route definitions:
(defn app-routes [the-state]
(compojure.core/routes
(GET "/api/fu" [] (rest-of-the-app the-state))))
(def app
(-> (create-app-state)
app-routes
api/handler))
Given a choice, I'd probably go with the second approach.
In addition to what Alex described some routing frameworks for ring have a place for additional arguments which can be accessed by all handlers. In reitit this would work by putting custom objects under :data:
(reiti.ring/ring-handler
(reiti.ring/router
[ ["/api"
["/math" {:get {:parameters {:query {:x int?, :y int?}}
:responses {200 {:body {:total pos-int?}}}
:handler (fn [{{{:keys [x y]} :query} :parameters}]
{:status 200
:body {:total (+ x y)}})}}]] ]
{:syntax :bracket
:exception pretty/exception
:data {:your-custom-data your-custom-data
:coercion reitit.coercion.spec/coercion
:muuntaja m/instance
:middleware []}}))
In your handler you're supposed to only work with :parameters, but you will be able to access your custom data by selecting :reitit.core/match and :data. The argument that the handler receives is based entirely on this:
(defrecord Match [template data result path-params path])
(defrecord PartialMatch [template data result path-params required])
The "correct" way to do this is to use a dynamically bound var. You define a var with:
(def ^:dynamic some-state nil)
And then you create some ring middleware which binds the var for each handler call:
(defn wrap-some-state-middleware [handler some-state-value]
(fn [request]
(bind [some-state some-state-value]
(handler request))))
You would use this to inject dependencies by using this in your 'main' function where you launch the server:
(def app (-> handler
(wrap-some-state-middleware {:db ... :log ...})))
Okay, I'm using Meck and I'm lost. My first language (that I've been writing for about 7 months) is Ruby, so I can't seem to wrap my brain around Meck mocking yet. I do get Ruby mocking though. Hoping someone can help me. Also, I've only been writing Erlang for a week.
Updated Code (but mocking still isn't working)...
I have a Erlang console_io prompter module that looks like this:
-module(prompter).
-export([prompt/1, guess/0]).
prompt(Message) ->
console_io:gets(Message).
gets() ->
{_, [Input]} = io:fread("Enter: ", "~s"),
Input.
guess() ->
Guess_Input = gets(),
Guess_List = convert_guess_to_list(Guess_Input).
convert_guess_to_list(Guess_Input) ->
re:split(Guess_Input, "", [{return, list}, trim]).
My test now looks like this:
-module(prompter_test).
-include_lib("eunit/include/eunit.hrl").
guess_1_test() ->
meck:new(prompter),
meck:expect(prompter, gets, fun() -> "aaaa" end),
?assertEqual(prompter:guess(), ["a","a","a","a"]),
?assert(meck:validate(prompter)),
meck:unload(prompter).
The error I'm getting is this:
Eshell V5.9.3.1 (abort with ^G)
1> prompter_test: guess_1_test (module 'prompter_test')...*failed*
in function prompter:guess/0
called as guess()
in call from prompter_test:guess_1_test/0 (test/prompter_test.erl, line 10)
in call from prompter_test:guess_1_test/0
**error:undef
I want to mock (stub?) the gets function in my test so that gets will return "aaaa" and then when I assert on get_guess() it should equal ["a", "a", "a", "a"].
How do I do this?
There are two problems:
The prompter module has two exported functions, but you only mock one of them (gets) with meck:expect. By default, Meck creates a new module that only contains the functions that you explicitly mock. You can change that by using the passthrough option:
meck:new(prompter, [passthrough]),
When you mock the gets function, all module-prefixed calls (i.e. prompter:gets()) are intercepted, but Meck has no way (yet?) of intercepting internal calls (e.g. the gets() call in the guess function), so you would still get the unmocked version of the function. There is no completely satisfactory way to avoid this. You could change the call in guess to prompter:gets(), or you could move gets into a separate module and mock that.
The first line says to create a new mocked module, my_library_module:
meck:new(my_library_module),
Next, we mock the function fib in my_library_module to return 21 when 8 is passed in:
meck:expect(my_library_module, fib, fun(8) -> 21 end),
We have some eunit assertions to test our mocked function. The code_under_test:run call is what you want to replace with the the function using your mocked module, and the 21 is the result you are expecting from the function call:
?assertEqual(21, code_under_test:run(fib, 8)), % Uses my_library_module
?assert(meck:validate(my_library_module)),
Then we unload the mocked module:
meck:unload(my_library_module).
If you wanted to write the same test for your module, you could write:
my_test() ->
meck:new(console_io),
meck:expect(console_io, gets, fun() -> "aaaa" end),
?assertEqual(["a", "a", "a", "a"], console_io:get_guess()), % Uses console_io
?assert(meck:validate(console_io)),
meck:unload(console_io).
I want to call xyz with the name of a function to be invoked.
-module(sample).
-export([xyz/1]).
xyz(Name) -> Name().
p() -> "you called p".
g() -> "you called g".
But I get the following error:
1> c(sample.erl).
./sample.erl:6: Warning: function p/0 is unused
./sample.erl:7: Warning: function g/0 is unused
{ok,sample}
2> sample:xyz('p').
** exception error: bad function p
in function sample:xyz/1
3>
It is correct that you have to export p and g. You can then use apply/3 to call it.
erlang:apply(sample, p, []).
Only fun-values are usable with the Fun(...) syntax. You are passing in an atom-value. An atom is a 'bad function' as the error message go. You could do something similar to
xyz(p) -> fun p/0;
xyz(g) -> fun g/0.
Then go ahead and call
Fun = xyz(p),
Fun()
-module(sample).
-export([xyz/1, p/0, g/0]).
xyz(Name) -> ?MODULE:Name().
p() -> "you called p".
g() -> "you called g".
1> sample:xyz(p).
"you called p"
Pattern match is the idiom to use:
-module(sample).
-export([xyz/1]).
xyz(p) -> p();
xyz(q) -> g().
p() -> "you called p".
g() -> "you called g".
If you want to be dynamic you can use a gen_event server.
Essentially what this is is a server that holds a state which consists of key/function pair like so:
[{p, #func1},
{g, #func2},
{..., ...},
...]
You can then essentially bind events to functions. (there is, needless to say, a bit more to it than that.
The easiest way to do is to try exporting p and g along with xyz.
-export([xyz/1, p/0,g/0]).
After exporting the function p and g can be called as follows :
1> sample:xyz(fun sample:p/0).
"you called p"
2> sample:xyz(fun sample:g/0).
"you called g"
Another way to look at it is that (depending on the problem you're solving) dynamic calls to functions isn't necessarily the right approach. Given that processes and message passing are the way you organize your code in Erlang since it's a "concurrency oriented language", maybe you could just use message passing with a selective receive rather than mimicking idioms of a sequential language? Send a message for what you want and get the custom reply based on that. It's about the result of each function, not the function itself, after all. (Plus there's the flexibility and scalability of message passing, etc.)
Although processes aren't totally free compared to calling from a library module, Erlang-level processes are dirt cheap (especially if the message communication is within the same node). They're not OS-level processes. The overhead would be comparable (or better) to dynamic function calls and object instantiation in heavier scripting languages.