OK, so this is the concept :
I'm currently writing a fairly complex project, consisting of 10's of different modules and classes.
I need to have one basic set of variables/options (an associative array?) which will be shared (read/write) by all modules (or selected ones) at any time.
What would be the most D-friendly way to achieve this?
UPDATE:
Hmm... just created a variable definition in one module (let's say globals.d module) and no matter where I import it, I can always get/set it. That simple?! (Or am I missing anything?)
Just filling this in so there's an answer: yes, you generally would want to make a new module like globals.d and simply import it from all the other modules that use it.
Related
I'm working on a a large scale angular project with a team of devs.
the problem we run into is if you have several files for a component, say a directive.
some-directive.js
some-directive-controller.js
in the definition of both files you would have to attach them to a module, however one file must create the module with []. If the developer forgets to poke around they will add [] in the second file called will actually overwrite the module. so now it becomes a memory game. Each developer has to remember to only declare the module in one file []
some-directive.js
angular.module('some-module',['some-dependencies']).directive('some-directive',function(){});
some-controller.js
angular.module('some-module',[]).controller('some-controller',function(){});
we have been using the following approach. Is there a better way?
some-directive.js
some-directive-module.js
some-directive-controller.js
where some-directive-module only contains the module creation, includes any dependencies, and does any .config needed. Still the dev needs to remember to
angular.module('some-directive') in all the other files without the square brackets.
some-directive-module.js
angular.module('some-directive',[])
.config(//someconfig stuff);
some-directive-module.js
angular.module('some-directive).directive(//declare directive);
some-directive-controller.js
angular.module('some-directive).controller(//declare contrller used by directive);
I suggested that instead we should do the following, it eliminates the issue of overwriting modules, but I received some negative feedback from one of the other devs
some-directive-module.js
angular.module('some-directive',['some-directive.directive','some-directive.controller'])
.config(//someconfig stuff);
some-directive-module.js
angular.module('some-directive.directive',[]).directive(//declare directive);
some-directive-controller.js
angular.module('some-directive.controller',[]).controller(//declare contrller used by directive);
Is there a better way? Or is one of the above options correct?
The recommended way (by multiple competent people) is to use the setter-getter-syntax (creating once with angular.module("someModule",[]) and accessing with angular.module("someModule") from there on). Putting the module definition and configuration into one file seems very clean and is common practice between a lot of developers. But make sure not to create a module for every single directive - group services, directives, constants and so on into reasonable functionality-modules instead.
Making clear what a file contains by its name is also a good idea in my opinion, so your some-directive-module.js approach seems fine to me. If developers "poke around" and "wildly add []", they should get a slap on the wrist follwoed by an explanation how modules work in angular, so they stop doing it ;-)
One of the projects I'm collaborating on has four different modules (Foo, Bar, Baz, and Plotting) and I've been tasked with combining them into a package. It is simple enough in Julia to make a new package:
julia> Pkg.generate("MyPackage", "MIT")
I copied my modules into the ~/.julia/v0.3/MyPackage/src/ and added include statements to MyPackage.jl. It looks something like this:
module MyPackage
include("foo.jl")
include("bar.jl")
include("baz.jl")
include("plotting.jl")
end
Each included file contains the corresponding module.
My main problem with this is Plotting takes forever to import and it's not needed very often when we're using the rest of MyPackage. I'd really like to be able to do something like using MyPackage.Foo to just get Foo (and particularly to exclude the Plotting and its slow import time). I've tried a couple different approaches for how I structure things, including having sub-modules explicitly defined inside MyPackage.jl instead of in each file individually, but no matter what I try, I always get the loading lag from Plotting.
Is it possible build a package so you can independently load modules from it? and if so, how?
Note: I'm new to Julia and newer still to building packages. Sorry if any of my semantics are wrong or anything is unclear.
Try Requires.jl:
Requires is a Julia package that will magically make loading packages faster, maybe. It supports specifying glue code in packages which will load automatically when a another package is loaded, so that explicit dependencies (and long load times) can be avoided.
Is it possible build a package so you can independently load modules from it? and if so, how?
Following the advice of this comment has worked for me:
https://discourse.julialang.org/t/multiple-modules-in-single-package/5615/7?u=nhdaly
You can change the top-level package-named Module to simply just expose the other four Modules as follows:
# <julia_home>/MyPackage/src/MyPackage.jl
module MyPackage
push!(LOAD_PATH, #__DIR__) # expose all other modules defined in this directory.
end
Then to import the other modules, say Bar, the user code would do:
# code.jl
using MyPackage; using Foo;
...
But it's worth noting that, then, Foo, Bar, Baz and Plotting are all also treated as top-level modules, so you'll want to make their names unique so they don't conflict with other Packages/Modules. (ie somethig like MyPackageFoo, not Foo.)
I'm developing an Apache based application witch few custom modules.
I'd like to share some functionality in one module with others.
I need to wire them together during stratup phase.
I want to use GetModuleHandle + GetProcAddress (it will rununder Windows only) with a module name - but this will succeed only if the module is already loaded by Apache server.
Is there a way to configure the loading order of Apache modules.
I only need to control my modules - others are irrelevant.
Thank's in advance.
If you're trying to control the Apache hook calling order from the source of your module, you can try using APR_HOOK_FIRST, APR_HOOK_MIDDLE, and APR_HOOK_LAST. Or you can specifically name other modules to enforce ordering constraints. From the docs:
... "There are two mechanisms for doing this. The first, rather crude, method, allows us to specify roughly where the hook is run relative to other modules. The final argument control this. There are three possible values: APR_HOOK_FIRST, APR_HOOK_MIDDLE and APR_HOOK_LAST.
"All modules using any particular value may be run in any order relative to each other, but, of course, all modules using APR_HOOK_FIRST will be run before APR_HOOK_MIDDLE which are before APR_HOOK_LAST. Modules that don't care when they are run should use APR_HOOK_MIDDLE. These values are spaced out, so that positions like APR_HOOK_FIRST-2 are possible to hook slightly earlier than other functions. ...
"The other method allows finer control. When a module knows that it must be run before (or after) some other modules, it can specify them by name. The second (third) argument is a NULL-terminated array of strings consisting of the names of modules that must be run before (after) the current module. For example, suppose we want "mod_xyz.c" and "mod_abc.c" to run before we do, then we'd hook as follows ..." [example follows]
This is something I have been struggling about for some time now. The thing is: I have many (20 or so) static arrays of values. I say static because that is how I'm actually storing them, as static arrays inside some domains. For example, if I have a list of known websites, I do:
class Website {
...
static websites = ["web1", "web2" ...]
}
But I do this just while developing, because I can easily change the arrays if needed, but what I'm going to do when the application is ready for deployment? In my project it is very probable that, at some point, these arrays of values change. I've been researching on that matter, one can store application properties inside an external .properties file, but it will be impossible to store an array, even futile, because if some array gets an additional value, the application can't recognize it until the name of the new property is added where needed.
Another approach is to store this information in the database, but for some reason it seems like a waste to add 20 or more tables that will have just two rows, an id and a name.
And the last option, as far as I know, would be an XML, but I'm not very experienced with those. It seems groovy has a way of creating and reading XML files relatively easy, but I don't know how difficult would be to modify an XML whose layout is predefined in the application.
Needless to say that storing them in the config.groovy is not an option since any change will require to recompile.
I haven't come across some "standard" (maybe a best practice?) way of dealing with these.
So the questions is: Where to store these arrays?
Use Enum for a fixed set of attributes. Do this, if you rely at some places in your code on some concrete values.
If you do not rely on the attributes within your code (which you obviously don't), use a String-type. In this case, if you need to provide a select box, just do a distinct-query on this property in your database.
Default: Use a domain class per dynamic set of attributes. Another table is OK.
For something as simple as arrays you should use groovy own type of property files. They allow you too define properties as proper groovy variables (not just strings) and obviously loading them would be done dinamically in a simple way by using ConfigSlurper. For an example on how to use this kind of file you can have a look at the following ConfigSlurper:
For defining properties:
my.property.array=[1,2,3,4]
For loading property files:
def config = new ConfigSlurper().parse(new File('myconfig.groovy').toURL())
assert [1,2,3,4] == config.my.property.array
Tip: When you want to access the property files you want to do it in a way that can work for any environment. To make paths environment-independent use the following path as the root path:
import org.codehaus.groovy.grails.commons.ApplicationHolder
def ctx = ApplicationHolder.application.mainContext.servletContext
def rootPath = ctx.contextPath
I writing a module for Drupal 7. It must get current $node variable in one function, e.g. hook_init() or similar, and this variable should be accessible from another function. I found discussion about node_load(arg(1)) and the author of solution said that performance is no concern because of caching.
So, should I call node_load() in every function I need not being afraid of performance issues of are there any other ways to pass variables between module functions?
To be more exact: I've placed a block with module on pages with a certain node types and in hook_block_view function I need to access to current node object. I'm succeeded using node_load so far. But maybe there is a better way.
Thanks in advance!
In drupal 7 node_load() calls entity_load(), which caches the results, so if you call node_load() twice, it will be returned from cache.
Using node_load() is better solution than passing global variables between modules, especially if you use some third-party caching modules (APC, memcached or other). If you care about performance just try to use one of these modules (I prefer memcached).