First of all, I am familiar with what the Meteor docs say about this, which I have summarized here:
Files in subdirectories are loaded before files in parent
directories, so that files in the deepest subdirectory are loaded
first, and files in the root directory are loaded last.
Within a directory, files are loaded in alphabetical order by
filename.
After sorting as described above, all files under directories named
lib are moved before everything else (preserving their order).
Finally, all files that match main.* are moved after everything else
(preserving their order).
(Not sure why they say "moved" instead of "loaded", but I think they just mean "loaded".)
My app has the following structure:
├── client/
│ ├── html/
│ │ ├── main.html
│ │ ├── nav.html
│ │ └── login.html
│ ├── js/
│ │ ├── lib/
│ │ │ └── util.js
│ │ ├── main.js
│ │ └── nav.js
│ └── my_app.less
├── packages/
│ └── some_stuff_here
├── server/
│ └── main.js
├── shared.js
├── smart.json
└── smart.lock
In client/js/nav.js file I have the following JavaScript code:
Template.nav.nav_close = function() {
return ! Session.get(slugify(this.name)+'-nav-close')
}
In client/js/lib/util.js file I have the following JavaScript code:
var slugify = function(value) {
if (value) {
return value.replace(/\s+/g, '-').replace(/\./g, '-').toLowerCase();
}
}
My understanding is that the client/js/lib/util.js file should get loaded first, which will make my slugify function available, and then client/js/nav.js should get loaded and the slugify function should be available to it.
In fact what happens is that I see the following error in my Chrome console:
Exception from Deps recompute function: ReferenceError: slugify is not defined
at Object.Template.nav.nav_close (http://localhost:3000/client/js/nav.js?4d7c7953063828c0e4ec237c1a5c67b849076cb5:2:26)
Why am I getting this error?
slugify has file scope because it is declared with var. Remove var to give it package (application) scope.
Meteor Namespacing
slugify = function(value) {
if (value) {
return value.replace(/\s+/g, '-').replace(/\./g, '-').toLowerCase();
}
}
Related
I have a typo3 extension (created with extension manager) and it seems no matter what I try I always get the following error:
Class CM\Parser\Controller\ParserController does not exist. Reflection failed.
I used the explanations for this problem TYPO3 tutorial extension, controller does not exist and "Controller does not exist. Reflection failed." TYPO3. Neither of them seem to work.
My composer.json in the root directory has the following entry:
"autoload": {
"psr-4": {
"CM\\parser\\": "./packages/cm-parser/Classes"
}
}
My typo3conf/ext folder has a symlink on packages/cm-parser. My composer.json inside the extension directory (packages/cm-parser) has the entry:
"autoload": {
"psr-4": {
"CM\\parser\\": "./Classes"
}
}
Thanks in advance for any help.
My directory structure looks like this (starting in /opt/lampp/htdocs/my-new-project) which is a typo3 v9.5 installation
> .
├── packages
│ └── cm-parser
│ ├── Classes
│ ├── Configuration
│ ├── Documentation.tmpl
│ ├── Resources
│ └── Tests
├── public
│ ├── fileadmin
│ │ ├── _processed_
│ │ ├── _temp_
│ │ └── user_upload
│ ├── typo3
│ │ └── sysext
│ ├── typo3conf
│ │ ├── ext
│ │ └── l10n
│ ├── typo3temp
│ │ ├── assets
│ │ └── var
│ └── uploads
│ └── tx_extensionbuilder
├── var
...
In my typo3conf/ext directory there is a symlink called parser to packages/cm-parser (I think the composer created that for me).
So I hope this symlink works for Typo3.
The files ext_emconf.php and ext_localconf.php are also in the right place. The folder structure above only displays my folders (tree -L 3) up to the third level.
The controller class is CM\Parser\Controller\ParserController, while in your composer.json you're using CM\\parser\\ (with a lowercase p) in the PSR4 autoload. This should be CM\\Parser\\
After changing this you need to of course run composer dumpautoload to reload the autoload information.
In your root composer.json file:
➊ You do not need the PSR-4 autoload section for "CM\\parser\\".
➋ You possibly have to add the path to packages/* as a repository.
➌ You have to include the composer namespace of your extension.
In your file system:
➍ You do not need typo3conf/ext/ as a symbolic link to packages/.
Try the following changes:
In your root composer.json file, remove the PSR-4 autoload section as outlined above. Add the packages/ directory as a path under repositories. For example:
{
"repositories": [
{
"type": "composer",
"url": "https://composer.typo3.org/"
},
{
"type": "path",
"url": "packages/*"
}
],
...
}
Store your extension code in the following path: packages/parser/.
Assuming your extension key reads parser and your vendor name is CM, the composer namespace becomes cm/parser. Add this as a requirement to the composer config file. You can use the following command on the command line:
composer require cm/parser:dev-master
This assumes, that packages/parser/ is a valid Git repository and has the master branch (do not use a version in the extension's composer.json file).
If the local Git repository and version (in the example above: dev-master) can be found, composer will automatically install all dependencies as required and it will create a symbolic link:
typo3conf/ext/parser -> ../../../packages/parser/
Also double check if all PHP files show the correct PHP namespace: CM\Parser\... and your controller class name reads ParserController.
If you can share your TYPO3 extension code, upload it to GitHub (or any other place) and share the link here. This way people can review your code and possibly spot further errors.
So I'm building a WP plugin and it's customary to put empty index.html files into every folder to prevent directory listing where the host allows it. I'm building the deployment-ready package with grunt, but the only thing I'm missing are these files. I have many folders and would rather not create these files by hand. I'm happy to create one, and make Grunt copy that file to every path. But how?
No additional grunt plug-ins are necessary. Your requirement can be achieved using Grunt's built-in features.
Consider adding a custom Task to your Gruntfile.js as per the one named createEmptyHtmlFiles shown below.
Gruntfile.js
module.exports = function(grunt) {
grunt.initConfig({
// ...
});
/**
* Custom task to create empty `index.html` file in all folders.
*/
grunt.registerTask('createEmptyHtmlFiles', function() {
var fileName = 'index.html',
contents = '';
grunt.file.expand({ filter: 'isDirectory' }, 'dist/**/*')
.forEach(function(dirPath) {
var htmlFilePath = dirPath + '/' + fileName;
grunt.file.write(htmlFilePath, contents, { encoding: 'utf8'})
});
});
grunt.registerTask('default', ['createEmptyHtmlFiles']);
};
Explanation:
Typically your Gruntfile.js will include grunt.initConfig({ ... }); section that defines the configuration of various Tasks that you want to perform. This part should remain as per your current configuration.
A custom Task named createEmptyHtmlFiles is registered that does the following:
Assigns the desired filename, i.e. index.html, to the fileName variable and also assigns an empty string to the contents variable.
Next we utilize grunt.file.expand to which we pass a globbing pattern. In the example above the glob provided is 'dist/**/*'. The globbing pattern combined with the filter: 'isDirectory' option essentially obtains the pathnames to all folders inside the dist directory.
Important: This glob pattern you will need to change as per your directory structure.
Next we iterate each directory pathname using the Array's forEach method.
In each turn of the forEach loop we assign to the htmlFilePath variable a new pathname for where the resultant index.html file is to be created.
Each index.html file is created using grunt.file.write.
Demo:
Lets say the project directory is structured as follows:
.
├── Gruntfile.js
├── dist
│ ├── a
│ │ ├── b
│ │ │ └── 1.txt
│ │ └── c
│ │ └── 2.txt
│ ├── d
│ │ ├── 3.txt
│ │ └── e
│ │ └── 4.txt
│ └── f
│ └── g
│ └── 5.txt
├── node_modules
│ └── ...
└── package.json
Given the Gruntfile.js above after running $ grunt it will change to the following:
.
├── Gruntfile.js
├── dist
│ ├── a
│ │ ├── b
│ │ │ ├── 1.txt
│ │ │ └── index.html <-----
│ │ ├── c
│ │ │ ├── 2.txt
│ │ │ └── index.html <-----
│ │ └── index.html <-----
│ ├── d
│ │ ├── 3.txt
│ │ ├── e
│ │ │ ├── 4.txt
│ │ │ └── index.html <-----
│ │ └── index.html <-----
│ └── f
│ ├── g
│ │ ├── 5.txt
│ │ └── index.html <-----
│ └── index.html <-----
├── node_modules
│ └── ...
└── package.json
Note Every folder inside the dist directory now includes an empty index.html file.
You may need to exclude the index.html from being created in specific directories. In which case we can you can negate specific directories via the glob pattern(s) passed to the grunt.file.expand method.
For instance, lets say we configure it as follows in the createEmptyHtmlFiles task:
...
grunt.file.expand({ filter: 'isDirectory' }, ['dist/**/*', '!dist/a/{b,c}'])
...
Note: This time we pass an Array that contains two glob patterns. The first one is the same as per the previous example, however the second one begins with ! which will negate a match.
Running $ grunt using the the aforementioned glob patterns will result in the following directory structure:
.
├── Gruntfile.js
├── dist
│ ├── a
│ │ ├── b
│ │ │ └── 1.txt
│ │ ├── c
│ │ │ └── 2.txt
│ │ └── index.html <-----
│ ├── d
│ │ ├── 3.txt
│ │ ├── e
│ │ │ ├── 4.txt
│ │ │ └── index.html <-----
│ │ └── index.html <-----
│ └── f
│ ├── g
│ │ ├── 5.txt
│ │ └── index.html <-----
│ └── index.html <-----
├── node_modules
│ └── ...
└── package.json
Note Every folder inside the dist directory, excluding folders b and c, now include an empty index.html file.
btw. When you say "empty index.html files", I've taken that literally. However if you did need some html markup in each file you can assign that to the contents variable. For example:
contents = '<!DOCTYPE html>\n<html>\n<head></head>\n<body></body>\n</html>';
But I said "copy a file ..."
In which case you can change the custom Task to the following:
/**
* Custom task to copy a source `index.html` file in all folders.
*/
grunt.registerTask('copyFileToFolders', function() {
var srcFilePath = './path/to/file/to/copy/index.html';
grunt.file.expand({ filter: 'isDirectory' }, 'dist/**/*')
.forEach(function(dirPath) {
grunt.file.copy(srcFilePath, dirPath + '/index.html')
});
});
Notes:
This utilizes grunt.file.copy to copy the source file to all folders.
The pathname assigned to the srcFilePath variable should be substituted with a real pathname to the actual master index.html file that you want to copy to all folders.
As per the first example, the glob pattern passed to grunt.file.expand must be change as necessary.
To make Artifactory as self-service as possible for our users, giving permissions to users to deploy to parts of repositories using their personal or team accounts, I'm trying to figure out how to configure this.
For readable directory structure based repositories like anything in the java world, the Permission Targets work perfectly (https://www.jfrog.com/confluence/display/RTF/Managing+Permissions). But I can't find any docs on how to use this for non-human-predicatable/readable directory structures, like PIP, or the flat directory structure, like NPM.
In the java world, repositories have a nicely structured tree like:
~/.m2/repository$ tree org/ | head -20
org/
├── antlr
│ ├── antlr4-master
│ │ └── 4.7.1
│ │ ├── antlr4-master-4.7.1.pom
│ │ ├── antlr4-master-4.7.1.pom.sha1
│ │ └── _remote.repositories
│ └── antlr4-runtime
│ └── 4.7.1
│ ├── antlr4-runtime-4.7.1.jar
│ ├── antlr4-runtime-4.7.1.jar.sha1
│ ├── antlr4-runtime-4.7.1.pom
│ ├── antlr4-runtime-4.7.1.pom.sha1
│ └── _remote.repositories
├── apache
│ ├── ant
│ │ ├── ant
│ │ │ ├── 1.10.1
│ │ │ │ ├── ant-1.10.1.jar
│ │ │ │ ├── ant-1.10.1.jar.sha1
For example, to give teamantl permission to only read, annotate, and write to org/antlr/antlr4-master/**, the following json can be PUT to Artifactory REST API (PUT /api/security/permissions/{permissionTargetName})
{
"includesPattern": "org/antlr/antlr4-master/**",
"repositories": [
"libs-release-local",
"libs-snapshot-local"
],
"principals": {
"groups" : {
"teamantl": ["r","n","w"]
}
}
}
But for example a pip repo is completely hashed:
Which is completely useless in the permission target "includesPattern".
How should this (Permission Targets) work for repo's like PIP, and NPM?
Your screenshot shows a virtual PyPI repo, which is generated and thus hash-structured.
Normally, these are backed by physical repos, filled using twine upload and thus having a ‹pkg›/‹version›/‹file› structure – i.e. perfectly usable as permission targets with package granularity.
I'm using Spring Boot and I want to know how exactly we mention the path to static content in my JSP files?
I tried to make them in src/main/resources/static/css but it was not working, and in my JSP I called them by using:
<link href="<c:url value="/css/bootstrap.min.css" />" rel="stylesheet" type="text/css">
I have no special configuration in my SpringBoot Class just the call SpringApplication.run(...)
Thank you so much for the help!
you have to have configuration that extends WebMvcAutoConfigurationAdapter , it has registry implementation that has automatically scans for some default locations and adds them to classpath
/META-INF/resources/
/resources/
/static/
/public/
Just add,
#Configuration
#EnableWebMvc
#ComponentScan
public class ServerConfiguration extends WebMvcAutoConfiguration{
}
using springboot 1.5.6.RELEASE my folder structure looks like
~/repos/static-content-example/src > tree
.
├── main
│ ├── java
│ │ └── com
│ │ └── example
│ │ └── demo
│ │ ├── DemoApplication.java
│ │ └── MvcConfig.java
│ └── resources
│ ├── application.properties
│ ├── public
│ │ └── test.html
│ └── templates
└── test
└── java
└── com
└── example
└── demo
└── DemoApplicationTests.java
and when I start the server, I can browse to
http://localhost:8080/test.html
http://localhost:8080/public/test.html
anything in the folder "public" is accessible by default at your context root (#1 above). MvcConfig.java allows for #2. I always setup that alias so I can ignore security on any URL that starts with /public. In order to do that without the MvcConfig setup, you'd have to put a folder named public inside the public folder, which is just confusing.
I have no idea why spring doesn't do that by default....seems like it would clear up lots of confusion...
I'm porting an application from php to node(sailsjs) at the same time trying to replace ant with grunt. I like the current project build structure and I would like to preserve some of it.
It looks like below...
project root
├── build (git ignored)
│ ├── coverage
│ ├── dist(to be deployed to target env)
│ └── local(to be deployed to local env)
├── lib
│ └── some library files like selenium..etc.
├── src
│ ├── conf
│ │ └── target/local properties
│ ├── scripts(may not be needed with grunt??)
│ │ ├── db
│ │ │ └── create_scripts...
│ │ ├── se
│ │ │ └── run_selenium_scripts...
│ │ └── tests
│ │ └── run_unit_test_scripts...
│ ├── tests
│ │ └── test_code....
│ └── webapp(this is where I'd like to place node[sailsjs] code)
│ └── code....
└── wiki .etc...
It doesn't exactly have to be the same way as above but more or less I prefer to build something similar. Now, pretty much all the sailsjs examples I have seen look like below.
project root
├── .tmp
│ └── stuff...
├── package.json
├── tasks
│ ├── config
│ │ └── grunt task configs...
│ └── register
│ └── grunt task registrations...
├── tests
│ ├── unit
│ └── selenium
└── Gruntfile.js
Where should I place Gruntfile.js, app.js, package.json to achieve what I want? What other detail should I have to make grunt function and create artifacts as I want them?
Note: Obviously I'm not expecting to get all the details of grunt configuration. But I guess it helps to see where most important things go and how basic tasks could be configured.
Thanks for your answer.
It's hard to give a precise answer without a detail of your build steps, but I would suggest:
Gruntfile.js and package.json go to your root folder
you setup your individual build tasks (whatever they are) to output to build: see the doc of each task on how to do that, it's usually the dest option
Hope this helps a bit.