Which statement is used to associate a submodule and a parent module in a YANG data model?
A. import
B. namespace
C. include
D. belongs-to
I'm caught up between C(include) and D(Belongs to). Based on the readings i've been doing, my final answer would be D(Belongs to).
Submodules allow a module designer to split a complex model into several pieces where all the submodules contribute to a single namespace, which is defined by the module that includes the submodules. The “submodule” statement defines the submodule’s name, and groups all statements that belong to the submodule together. The “belongs-to” statement specifies the module to which the submodule belongs.
The “include” statement is used to make content from a submodule available to that submodule’s parent module, or to another submodule of that parent module. A module may include any number of submodules, but each submodule may belong to only one module. When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module.
In this short example the module top includes two sub modules, and instantiates the groupings defined by the submodules.
Related
I have a file structure looking somewhat like the following:
src/
--clients/
----queue_client/
------mod.rs
--data_evaluator/
----data_evaluator.rs
In data_evaluator, I want to use the queue_client module, but when I do mod queue_client in data_evaluator.rs- I get the following error - File not found for module queue_client. It only finds the module if I move it into the data_evaluator folder.
My question is, how do I correctly use modules that are outside of the consumer code's directory? Apologies if there is an easy way to do this, I did try searching for quite a while and couldn't find a way.
You seem to be a bit confused.
In Rust, you build the module tree.
You use mod to register a module as a submodule of your current module.
You use use to use a module within your current module.
This article may clear some things up: http://www.sheshbabu.com/posts/rust-module-system/
Aside from that, to use a module that's higher in the tree than your current module, you use crate to get to the root of your module tree.
So in your case, crate::clients::queue_client.
The generated Angular component names and module names are prefixed with the base application name specified when generating the code with JHipster as seen by the Entity Module imports shown below for a generated project.
In the following example from a generated entity.module.ts file, the entity module names have a prefix of "Gohomenotes" based I had specified a base application name of "gohomenotes" when I generated the code.
#NgModule({
imports: [
GohomenotesPersonModule,
GohomenotesStudentModule,
GohomenotesHomeRoomModule,
GohomenotesTeacherModule,
GohomenotesSchoolModule,
GohomenotesHostRequestModule,
GohomenotesGuestRequestModule,
GohomenotesEarlyPickupRequestModule,
GohomenotesTransportationChangeRequestModule,
GohomenotesFamilyModule,
GohomenotesFamilyMemberModule,
GohomenotesAddressModule,
GohomenotesPhoneNumberModule,
GohomenotesGoHomeNotesSettingsModule
However, the corresponding filenames do not include the base application name. This is not consistent with the Angular style guide and makes the code harder to read IMO.
Unless there is a practical reason that this is necessary, I'd prefer to not have the base application name on the component and module class names. Is there any harm if I remove the application base name from the module and component class names?
I asked this question on Gitter and got an answer from Shaheen Georgee #1in9ui5t...
Why are Angular Component and Module class names for Entities prefixed with the application base name?
"MyAppStudentModule" Rather than just "StudentModule" when I have an entity named "Student"?
Most likely to avoid potential naming conflicts with other modules in your Angular application. For example, let’s say you were working on a medical application and had a Test entity to signify some medical exam that your organization conducts; if you generated a Test entity (poor name I know), then generated test.module.ts would cause a naming conflict as there is already a module with that name.
I’m taking a guess here, I know from looking at Jhipster code in the past that there are black-listed terms.
Related: Name collision by module import in Angular 2 - is there a way to prevent it
My module tree is like this
- modules
- socle1
- stdlib
- socle2
- ntp
How do I include the stdlib module in my site.pp?
I have tried include socle1::stdlib and it is not working .
Should I modify the environment.conf for the directory environment?
If you want to arrange your modules in separate trees, then you may do so. You should then include each base path in your environment's modulepath, and refer to the modules by their regular names. Note in particular that altering the path to a module does not change its name or the names of any of the classes or types it defines -- the path influences only whether the autoloader can find them.
I strongly advise against making subdirectories of the standard module directory, however. Instead, if you want to group modules in multiple directories then create parallel module directories for that purpose:
- modules
- socle1
- stdlib
- socle2
- ntp
Should I modify the environment.conf for the directory environment?
In order to support any module directories beyond or instead of the default, yes, you should. The puppet documentation describes how to configure your environment's modulepath. But do consider following #MattSchuchard's advice and instead restricting yourself to the standard module directories.
You are not supposed to put modules inside of other modules. Your tree should be like:
- modules
- socle1
- stdlib
- socle2
- ntp
Also, you would very rarely include stdlib, because stdlib is almost entirely a type/function module, so you would only reference its types and functions. You would not be declaring its classes unless you were planning on using the stages functionality it provides (thanks to John Bollinger for corrections to this paragraph).
However, declaring the ntp module in your site.pp is as simple as:
include ntp
or:
class { 'ntp': }
inside of your node { }.
In your init.pp
class classname ( parameters ) {
include ::socle2::ntp
}
Try this and tell me if this works or not!
I have a puppet module that uses gini-archive. Recently I change my module to depend on biemond-wildfly, which depends on nanliu-archive.
However, I can't install nanliu-archive, because both of these archive modules install into a directory called archive. This, I believe, violates the puppet module requirements, as they should both install into directories called <username>-archive.
However, even if I put them in different directories, I still have a problem. Both classes are called archive (actually one is a class and one is a define, but I don't think that's too important right now), so when my module says include archive, puppet isn't going to know which one I want.
Note I have a java background where every class is in a package hierarchy which prevents these kind of issues, but I can't see any equivalent for puppet.
I know I could have a whole load of different modules directories (/etc/puppet/modules, /etc/puppet/modules2 etc), but puppet still seems to look through these in order, meaning it will always load the archive class from the first module directory in the list.
Is there any way of solving this or have I reached the limit of what puppet can do? I'd rather not have to fork every single module and change the class names, that seems to defeat the point of the forge.
Thanks.
The name of the directory the module is in must be archive, the username is only used for the purpose of distributing and packaging modules but is not used by puppet while autoloading. Basically, what you are seeing is correct.
There seems to be two ways of handling this:
Fork one of the two archive modules and rename the module so that it does not collide
Fork one of the modules using the archive modules and migrate it to use the same archive module as the other one. Since the two archive modules do almost the same thing, I prefer this method.
I just did this so I'm going expand a bit on option (1) in #ChrisPitman's answer by including more details using a module I just forked & renamed as an example.
(Unfortunately) the simplest solution is to fork one of the modules and rename it. Below is an example using puppet/selinux and thias/selinux which have a namespace collision at selinux. The following steps were taken to re-namespace the thias/selinux module into the namespace selinux_thias:
Fork the module. In this example I have created USF-IMaRS/puppet-selinux from thias/puppet-selinux.
Install the module into modules/$NEW_NAME. Using git submodules this is: git submodule add https://github.com/USF-IMARS/puppet-selinux modules/selinux_thias
rename the module class(es). Here is a commit demonstrating what this basically looks like.
modify modules using thias/selinux to use new name selinux_thias instead of selinux.
In RequireJS documents (http://requirejs.org/docs/api.html#modulename), I couldn't understand this sentence.
You can explicitly name modules yourself, but it makes the modules less portable
My question is
Why explicitly naming module makes less portable?
When explicitly naming module needed?
Why explicitly naming module makes less portable?
If you do not give the module a name explicitly, RequireJS is free to name it whichever way it wants, which gives you more freedom regarding the name you can use to refer to the module. Let's say you have a module the file bar.js. You could give RequireJS this path:
paths: {
"foo": "bar"
}
And you could load the module under the name "foo". If you had given a name to the module in the define call, then you'd be forced to use that name. An excellent example of this problem is with jQuery. It so happens that the jQuery developers have decided (for no good reason I can discern) to hardcode the module name "jquery" in the code of jQuery. Once in a while someone comes on SO complaining that their code won't work and their paths has this:
paths: {
jQuery: "path/to/jquery"
}
This does not work because of the hardcoded name. The paths configuration has to use the name "jquery", all lower case. (A map configuration can be used to map "jquery" to "jQuery".)
When explicitly naming module needed?
It is needed when there is no other way to name the module. A good example is r.js when it concatenates multiple modules together into one file. If the modules were not named during concatenation, there would be no way to refer to them. So r.js adds explicit names to all the modules it concatenates (unless you tell it not to do it or unless the module is already named).
Sometimes I use explicit naming for what I call "glue" or "utility" modules. For instance, suppose that jQuery is already loaded through a script element before RequireJS but I also want my RequireJS modules to be able to require the module jquery to access jQuery rather than rely on the global $. If I ever want to run my code in a context where there is no global jQuery to get, then I don't have to modify it for this situation. I might have a main file like this:
define('jquery', function () {
return $;
});
require.config({ ... });
The jquery module is there only to satisfy modules that need jQuery. There's nothing gained by putting it into a separate file, and to be referred to properly, it has to be named explicitly.
Here's why named modules are less portable, from Sitepen's "AMD, The Definite Source":
AMD is also “anonymous”, meaning that the module does not have to hard-code any references to its own path, the module name relies solely on its file name and directory path, greatly easing any refactoring efforts.
http://www.sitepen.com/blog/2012/06/25/amd-the-definitive-source/
And from Addy Osmani's "Writing modular javascript":
When working with anonymous modules, the idea of a module's identity is DRY, making it trivial to avoid duplication of filenames and code. Because the code is more portable, it can be easily moved to other locations (or around the file-system) without needing to alter the code itself or change its ID. The module_id is equivalent to folder paths in simple packages and when not used in packages. Developers can also run the same code on multiple environments just by using an AMD optimizer that works with a CommonJS environment such as r.js.
http://addyosmani.com/writing-modular-js/
Why one would need a explicitly named module, again from Addy Osmani's "Writing modular javascript":
The module_id is an optional argument which is typically only required when non-AMD concatenation tools are being used (there may be some other edge cases where it's useful too).