Is there a way to create an interface for a module that any host application can be expected to implement?
We've got a couple apps that have a lot of code that is common that we'd like to refactor into modules, but sometimes the module may need to call runEvent or setNextEvent for a handler method that lives in the host application due to unique behavior and implementation.
Can I specify in the module a contract like "host application must implement the following handlers: 'admin.foo', 'admin.bar', ..."?
I am guessing there's a module load intercept I could do this in manually, but I'm wondering if there's a convention so I can just drop the list in somewhere rather than copy-pasting boilerplate code into every module.
You can specify dependencies within your ModuleConfig.cfc : this.dependencies = [ "myOtherModule" ]. Those dependencies will load before the module. At this time, there is no way to "interface" a module to conform to a collection of handlers.
Typically, though, passing through to other modules this is easily handled by custom routing within the module configuration, rather than by a new implementation:
addRoute(
pattern="/this-module/foo",
moduleRouting="that-module"
)
or
addRoute(
pattern="/this-module/foo",
module="that-module",
handler="oldFoo"
action="bar"
)
More on routing
Related
I'm trying to use phpBB3 (forum app) along with ZF2. For that, I have to include a file from the phpBB3. In theory this is as simple as:
include('/path/to/phpbb3/common.php');
$user->session_begin(); //$user is defined in common.php file
In common.php a lot of globals are defined, and after that are required some files which are using those globals.
In ZF2 simply including the common.php would not work, because the scope of the globals will not span over the required files, so I tried a little trick:
//in Application/Forum/Service
public function callForumAPI(){
$zf_dir = getcwd();
chdir('/var/www/html/phpBB3');
include('common.php');
$user->session_begin();
chdir($zf_dir);
}
Neither in this case the scope of the global variables didn't span over the required files, so all the globals where NULL in those files.
How could I solve this issue?
I consider 2 main problems:
1. Loading resources
I dont know if you changed the code of phpBB3, since if you dont, your problem is other.
Phpbb3, as many systems, doesnt let you access directly to any file, you have to go through index.php. As you can see in common.php
if (!defined('IN_PHPBB'))
{
exit;
}
IN_PHPBB is defined in index.php, so you can simply use
Also, common.php and other files, makes use of $phpbb_root_path, that is defined in index.php.
So, at least, when you are going to include common.php you need
$zf_dir = getcwd();
chdir('/var/www/html/phpBB3');
define('IN_PHPBB', true);
$phpbb_root_path = (defined('PHPBB_ROOT_PATH')) ? PHPBB_ROOT_PATH : './';
include('common.php');
...
chdir($zf_dir);
probably there are some other things you have to take care about.
2. Variable scopes
Also, consider than in PHP, like in almost every language, a variable declared inside a function, is considered local, and will be undefined outside that function. So for sure, if you do that inside callForumAPI(), you wont have any variable outside, and moreover, depending on where you are doing that includes...it could be actually inside a function, no matter you can notice it or not, since ZF2 is a framenwork with a complex, non-obvius architecture.
So, what i recomend, as soon as you load the file, is to use the ZF2 service manager to store all the variables and object than you would use in your application. This is a good measure even if you didnt need it,since this way you can have everything integrated as much as possible, it is important to minimize and localize access to phpbb3, since it is not meant to be a library, maintenance could be tricky, so if everyhing is in the same file, and then you create your own internal api through the service manager, it will more encapsulated and nicer. I assume you already know how to do this, if you dont, just let me know.
try this, and tell me if its enough or we need more research
I defined both area/1 and perim/1 in modules sqaure and circle.
I want to import and use them in another module. Here is my import statements:
-import(square, [area/1, perim/1]).
-import(circle, [area/1, perim/1]).
I got these error messages.
~/test.erl:4: function area/1 already imported from square
~/test.erl:4: function perim/1 already imported from square
I know erlang does not support namespace. But since we can qualify a function call by specifying the module (i.e. square:area vs circle:area), I fail to see how the lack of namespace is the source of the error here.
So, what exactly caused the above error and how can I fix it?
In Erlang, "importing" a function from another module means being able to call it as if it were a local function, without the module prefix. So with this directive:
-import(square, [area/1, perim/1]).
you could write area(42) and it would mean the same as square:area(42).
However, if you include area and perim functions from two modules, it would be ambiguous which one you'd actually call when writing area(42).
As you correctly note, you can always qualify the function call with the name of the module, i.e. square:area(42) and circle:area(42) - so I would suggest doing so consistently and removing both import directives. This is also recommended by rule 6.6 of the Erlang Programming Rules - "Don't use import".
I'm currently writing some functions that are related to lists that I could possibly be reused.
My question is:
Are there any conventions or best practices for organizing such functions?
To frame this question, I would ideally like to "extend" the existing lists module such that I'm calling my new function the following way: lists:my_funcion(). At the moment I have lists_extensions:my_function(). Is there anyway to do this?
I read about erlang packages and that they are essentially namespaces in Erlang. Is it possible to define a new namespace for Lists with new Lists functions?
Note that I'm not looking to fork and change the standard lists module, but to find a way to define new functions in a new module also called Lists, but avoid the consequent naming collisions by using some kind namespacing scheme.
Any advice or references would be appreciated.
Cheers.
To frame this question, I would ideally like to "extend" the existing lists module such that I'm calling my new function the following way: lists:my_funcion(). At the moment I have lists_extensions:my_function(). Is there anyway to do this?
No, so far as I know.
I read about erlang packages and that they are essentially namespaces in Erlang. Is it possible to define a new namespace for Lists with new Lists functions?
They are experimental and not generally used. You could have a module called lists in a different namespace, but you would have trouble calling functions from the standard module in this namespace.
I give you reasons why not to use lists:your_function() and instead use lists_extension:your_function():
Generally, the Erlang/OTP Design Guidelines state that each "Application" -- libraries are also an application -- contains modules. Now you can ask the system what application did introduce a specific module? This system would break when modules are fragmented.
However, I do understand why you would want a lists:your_function/N:
It's easier to use for the author of your_function, because he needs the your_function(...) a lot when working with []. When another Erlang programmer -- who knows the stdlb -- reads this code, he will not know what it does. This is confusing.
It looks more concise than lists_extension:your_function/N. That's a matter of taste.
I think this method would work on any distro:
You can make an application that automatically rewrites the core erlang modules of whichever distribution is running. Append your custom functions to the core modules and recompile them before compiling and running your own application that calls the custom functions. This doesn't require a custom distribution. Just some careful planning and use of the file tools and BIFs for compiling and loading.
* You want to make sure you don't append your functions every time. Once you rewrite the file, it will be permanent unless the user replaces the file later. Could use a check with module_info to confirm of your custom functions exist to decide if you need to run the extension writer.
Pseudo Example:
lists_funs() -> ["myFun() -> <<"things to do">>."].
extend_lists() ->
{ok, Io} = file:open(?LISTS_MODULE_PATH, [append]),
lists:foreach(fun(Fun) -> io:format(Io,"~s~n",[Fun]) end, lists_funs()),
file:close(Io),
c(?LISTS_MODULE_PATH).
* You may want to keep copies of the original modules to restore if the compiler fails that way you don't have to do anything heavy if you make a mistake in your list of functions and also use as source anytime you want to rewrite the module to extend it with more functions.
* You could use a list_extension module to keep all of the logic for your functions and just pass the functions to list in this function using funName(Args) -> lists_extension:funName(Args).
* You could also make an override system that searches for existing functions and rewrites them in a similar way but it is more complicated.
I'm sure there are plenty of ways to improve and optimize this method. I use something similar to update some of my own modules at runtime, so I don't see any reason it wouldn't work on core modules also.
i guess what you want to do is to have some of your functions accessible from the lists module. It is good that you would want to convert commonly used code into a library.
one way to do this is to test your functions well, and if their are fine, you copy the functions, paste them in the lists.erl module (WARNING: Ensure you do not overwrite existing functions, just paste at the end of the file). this file can be found in the path $ERLANG_INSTALLATION_FOLDER/lib/stdlib-{$VERSION}/src/lists.erl. Make sure that you add your functions among those exported in the lists module (in the -export([your_function/1,.....])), to make them accessible from other modules. Save the file.
Once you have done this, we need to recompile the lists module. You could use an EmakeFile. The contents of this file would be as follows:
{"src/*", [verbose,report,strict_record_tests,warn_obsolete_guard,{outdir, "ebin"}]}.
Copy that text into a file called EmakeFile. Put this file in the path: $ERLANG_INSTALLATION_FOLDER/lib/stdlib-{$VERSION}/EmakeFile.
Once this is done, go and open an erlang shell and let its pwd(), the current working directory be the path in which the EmakeFile is, i.e. $ERLANG_INSTALLATION_FOLDER/lib/stdlib-{$VERSION}/.
Call the function: make:all() in the shell and you will see that the module lists is recompiled. Close the shell.
Once you open a new erlang shell, and assuming you exported you functions in the lists module, they will be running the way you want, right in the lists module.
Erlang being open source allows us to add functionality, recompile and reload the libraries. This should do what you want, success.
What is the best way to put custom library or helper methods in symfony?
I am using doctrine with my project. One place I consider to put is under project_root/lib/vendor/MyClasses/
But if I want to create a class or helper function which will use some core symfony/doctrine methods and return a result then how to do that and where should I put it?
I want it to call from different modules to avoid code duplication.
As for the custom library part of the question, you might probably want to put your external library into the lib/vendor folder. Since symfony doesn't automatically load everything that's in there, you'll have to tell its autoloader to do so.
You can either extend your config/ProjectConfiguration.class.php (as described here) or (and this is the much simpler and cleaner way) you add them to your config/autoload.yml (you might have to create this one).
For the latter option, this is a great place to start looking at.
It seems to be a duplicate question.
As asked in symfony's 1.2 "Definitive Guide" docs :
Helper functions (regular PHP functions returning HTML code) should be saved in a file called FooBarHelper.php, where FooBar is the name of the helper group. Store the file in the apps/myapp/lib/helper/ directory (or in any helper/ directory created under one of the lib/ folders of your project) so it can be found automatically by the use_helper('FooBar') helper for inclusion.
So, if you want to create custom helper FooBar for foo() function, create file lib/helper/FooBarHelper.php :
function foo() {echo "foo!"; }
to use it in your template:
use_helper('FooBar')
....
foo(); //outs "foo!"
How can I tell if a module is being called dynamically or statically?
If you are operating on z/OS, you can accomplish this, but it is non-trivial.
First, you must trace up the save area chain and use CSVQUERY to find out which program owns each save area. Every other program will be a Cobol runtime module, like IGZCPAC. Under IMS, CICS, TSO, et al, those modules might be different. That is the easy part.
Once you know who owns all the relevant save areas, you can use the OS LOADER / BINDER / LINKER utilities to discover what artifacts are in the same modules. This is the non-easy part.
The ONLY way is to look at the output of the linkage editor (IEWL) or the load module itself. If the module is being called DYNAMICALLY then it will not exist in the main module, if it is being called STATICALLY then it will be seen in the load module. Calling a working storage variable, containing a program name, does not make a DYNAMIC call. This type of calling is known as IMPLICITE calling as the name of the module is implied by the contents of the working storage variable. Calling a program name literal.
Calling a working storage variable,
containing a program name, does not
make a DYNAMIC call.
Yes it does. Call variablename is always DYNAMIC.
Call 'literal' is dynamic or static according to the DYNAM/NODYNAM compiler option.
Caveat: This applies for IBM mainframe COBOL and I believe it is also part of the standard. It may not apply to other non-standard versions of COBOL.
For Micro Focus COBOL statically linking is controlled via call-convention on the call (bit 3) or via the compiler directive LITLINK.
When linking statically the case of the program-id/entry-point and the call itself is important, so you may want to ensure it is exact and use the CASE directive.
The reverse of LITLINK directive is the NOLITLINK directive or a call-convention without bit 3 set!
On Windows you can see the exported symbols in your .dll by using the "dumpbin /exports" utility and on Unix via the 'nm' utility.
A import .lib for the .dll created via "cbllink" can be created by using the '-K'command line option on cbllink.
Look at the call statement. If the called program is described in a literal then it's a static call. It's called a dynamic call if the called program is determined at runtime:
* Static call
call "THEPROGRAM"
* Dynamic call
call wsProgramName