webtool(3erl) [linux man page]
webtool(3erl) Erlang Module Definition webtool(3erl) NAME
webtool - WebTool is a tool used to simplify the implementation of web based tools with Erlang/OTP. DESCRIPTION
WebTool makes it easy to use web based tools with Erlang/OTP. WebTool configures and starts the webserver httpd. EXPORTS
start()-> {ok,Pid}| {stop,Reason} Start WebTool with default data, i.e. port 8888, ip-number 127.0.0.1, and server-name localhost . If port 8888 is in use, port 8889 is tried instead. If 8889 is also in use, 8890 is tried and so on. Max number of ports tried is 256. The mime.types file and WebTool's own HTML files are assumed to be in the directory webtool-<vsn>/priv/root/conf . start(Path,Data)->{ok,Pid}|{stop,Reason} Types Path = string() | standard_path Data = [Port,Address,Name] | PortNumber | standard_data Port = {port,PortNumber} Address = {bind_address,IpNumber} Name = {server_name,ServerName} PortNumber = integer() IpNumber = tuple(), e.g. {127,0,0,1} ServerName = string() Pid = pid() Use this function to start WebTool if the default port, ip-number,servername or path can not be used. Path is the directory where the mime.types file and WebTool's own HTML files are located. By default this is webtool-<vsn>/priv , and in most cases there is no need to change this. If Path is set to standard_path the default will be used. If Data is set to PortNumber , the default data will be used for ip-number ( 127.0.0.1 ) and server name ( localhost ). stop()->void Stop WebTool and the tools started by WebTool. debug_app(Module)->void Types Module = atom() Debug a WebTool application by tracing all functions in the given module which are called from WebTool. stop_debug()->void Stop the tracing started by debug_app/1 , and format the trace log. CALLBACK FUNCTIONS
The following callback function must be implemented by each web based tool that will be used via WebTool. When started, WebTool searches the Erlang code path for *.tool files to locate all web based tools and their callback functions. See the WebTool User's Guide for more information about the *.tool files. EXPORTS
Module:Func(Data)-> {Name,WebData}|error Types Data = term() Name = atom() WebData = [WebOptions] WebOptions = LinkData | Alias | Start LinkData = {web_data,{ToolName,Url}} Alias = {alias,{VirtualPath,RealPath}} | {alias,{erl_alias,Path,[Modules]} Start = {start,StartData} ToolName = Url = VirtualPath = RealPath = Path = string() Modules = atom() StartData = AppData | ChildSpec | Func AppData = {app,AppName} ChildSpec = {child,child_spec()} See the Reference Manual for the module supervisor in the STDLIB application for details about child_spec(). Func = {func,{StartMod,StartFunc,StartArg}, {StopMod,StopFunc,StopArg}} AppName = StartMod = StartFunc = StopMod = StopFunc =atom() StartArg = StopArg = [term()] This is the configuration function ( config_func ) which must be stated in the *.tool file. The function is called by WebTool at startup to retrieve the data needed to start and configure the tool. LinkData is used by WebTool to create the link to the tool. Alias is used to create the aliases needed by the webserver. Start is used to start and stop the tool. SEE ALSO
start_webtool(1) , WebTool User's Guide Ericsson AB webtool 0.8.7 webtool(3erl)
Check Out this Related Man Page
supervisor_bridge(3erl) Erlang Module Definition supervisor_bridge(3erl) NAME
supervisor_bridge - Generic Supervisor Bridge Behaviour. DESCRIPTION
A behaviour module for implementing a supervisor_bridge, a process which connects a subsystem not designed according to the OTP design principles to a supervision tree. The supervisor_bridge sits between a supervisor and the subsystem. It behaves like a real supervisor to its own supervisor, but has a different interface than a real supervisor to the subsystem. Refer to OTP Design Principles for more informa- tion. A supervisor_bridge assumes the functions for starting and stopping the subsystem to be located in a callback module exporting a pre- defined set of functions. The sys module can be used for debugging a supervisor_bridge. Unless otherwise stated, all functions in this module will fail if the specified supervisor_bridge does not exist or if bad arguments are given. EXPORTS
start_link(Module, Args) -> Result start_link(SupBridgeName, Module, Args) -> Result Types SupBridgeName = {local,Name} | {global,Name} Name = atom() Module = atom() Args = term() Result = {ok,Pid} | ignore | {error,Error} Pid = pid() Error = {already_started,Pid} | term() Creates a supervisor_bridge process, linked to the calling process, which calls Module:init/1 to start the subsystem. To ensure a synchronized start-up procedure, this function does not return until Module:init/1 has returned. If SupBridgeName={local,Name} the supervisor_bridge is registered locally as Name using register/2 . If SupBridgeName={global,Name} the supervisor_bridge is registered globally as Name using global:register_name/2 . If no name is provided, the supervisor_bridge is not registered. If there already exists a process with the specified SupBridgeName the function returns {error,{already_started,Pid}} , where Pid is the pid of that process. Module is the name of the callback module. Args is an arbitrary term which is passed as the argument to Module:init/1 . If the supervisor_bridge and the subsystem are successfully started the function returns {ok,Pid} , where Pid is is the pid of the supervisor_bridge. If Module:init/1 returns ignore , this function returns ignore as well and the supervisor_bridge terminates with reason normal . If Module:init/1 fails or returns an error tuple or an incorrect value, this function returns {error,Term} where Term is a term with information about the error, and the supervisor_bridge terminates with reason Term . CALLBACK FUNCTIONS
The following functions should be exported from a supervisor_bridge callback module. EXPORTS
Module:init(Args) -> Result Types Args = term() Result = {ok,Pid,State} | ignore | {error,Error} Pid = pid() State = term() Error = term() Whenever a supervisor_bridge is started using supervisor_bridge:start_link/2,3 , this function is called by the new process to start the subsystem and initialize. Args is the Args argument provided to the start function. The function should return {ok,Pid,State} where Pid is the pid of the main process in the subsystem and State is any term. If later Pid terminates with a reason Reason , the supervisor bridge will terminate with reason Reason as well. If later the super- visor_bridge is stopped by its supervisor with reason Reason , it will call Module:terminate(Reason,State) to terminate. If something goes wrong during the initialization the function should return {error,Error} where Error is any term, or ignore . Module:terminate(Reason, State) Types Reason = shutdown | term() State = term() This function is called by the supervisor_bridge when it is about to terminate. It should be the opposite of Module:init/1 and stop the subsystem and do any necessary cleaning up. The return value is ignored. Reason is shutdown if the supervisor_bridge is terminated by its supervisor. If the supervisor_bridge terminates because a a linked process (apart from the main process of the subsystem) has terminated with reason Term , Reason will be Term . State is taken from the return value of Module:init/1 . SEE ALSO
supervisor(3erl) , sys(3erl) Ericsson AB stdlib 1.17.3 supervisor_bridge(3erl)