I'm developing an Angular application and I'm using the following folder structure:
.
├── app
│ ├── assets
│ │ ├── images
│ │ │ ├── brands
│ │ │ ├── coletaSeletiva
│ │ │ ├── quiz
│ │ │ └── vidaEmLem
│ │ │ └── avatars
│ │ ├── sass
│ │ └── stylesheets
│ ├── scripts
│ │ └── controllers
│ └── views
│ └── coleta
└── test
└── spec
└── controllers
This is the yeoman angular generated project.
The generated css that come from SASS is pointing to files with the following path '/app/assets/...', because config in at the project's root.
My server is starting from app folder, so I call my assets using just /assets/...
What should I do?
Should I place config.rb inside of app folder and change assets paths?
My config.rb looks like this:
http_path = "/"
css_dir = "app/assets/stylesheets"
sass_dir = "app/assets/sass"
images_dir = "app/assets/images"
javascripts_dir = "app/assets/javascripts"
relative_assets = true
You can minify your code with "grunt" or "grunt --force". Then i think there will be no issues.
If still you got the issue of images . Try to set the path like ../images/image.png [if image folder is in parent folder] or ./images/image.png [if image folder is in the same folder].
Related
I have the following dir structure:
.
├── project
│ ├── dag_1
│ │ ├── dag
│ │ │ ├── current
│ │ │ └── dag_1_v2.py
│ │ │ └── deprecated
│ │ │ └── dag_1_v1.py
│ │ └── sparkjobs
│ │ ├── current
│ │ └── deprecated
│ └── dag_2
│ ├── dag
│ │ ├── current
│ │ └── dag_2_v2.py
│ │ └── deprecated
│ │ └── dag_2_v1.py
│ └── sparkjobs
│ ├── current
│ └── deprecated
I want to ignore all deprecated folders, so I used .airflowignore to do that. When I place .airflowignore with */deprecated inside dag_1 or dag_2 folder, Airflow ignores the deprecated dag, like:
├── project
│ ├── dag_1
│ │ ├── .airflowignore
│ │ ├── dag
│ │ │ ├── current
│ │ │ └── dag_1_v2.py
│ │ │ └── deprecated
│ │ │ └── dag_1_v1.py
Considering this, I'll have to place a .airflowignore inside each dag folder. When I try to put onlny one .airflowignore using **/**/deprecated in the project folder the deprecated dags returns to Airflow, like:
├── project
│ ├── .airflowignore
│ ├── dag_1
│ │ ├── dag
│ │ │ ├── current
│ │ │ └── dag_1_v2.py
│ │ │ └── deprecated
│ │ │ └── dag_1_v1.py
My question is: How can I have only one .airflowignore in the project dir level to ignore all deprecated folders inside each dag_n/dag folder? Is this possible?
.airflowignore has same logic as .gitignore so what ever solution applies to .gitignore will also work here.
I believe what you are after is just
deprecated/
on the top level.
See also ignoring any 'bin' directory on a git project
So if I try to load a page for example /patient_profile the css loads correctly, it's when I continue the path to /patient_profile/settings_patient_profile the css just breaks, both pages that I mentioned above are the same file, I just tried to test the routing to see if it works.
the route is managed like this:
route('/patient_profile/:id')
route('/patient_profile/settings_patient_profile/:id')
And I do land in the desired page, only the design elements don't work.
I read in another topic here that setting a static route with express to assets in my situation should fix the issue, but it didn't, I probably didn't understand how correctly use static path.
this directory tree:
.
├── docs
├── LICENSE
├── package.json
├── package-lock.json
├── README.md
├── src
│ │ ├── bootstrap
│ │ │ ├── css
│ │ │ │ └── bootstrap.min.css
│ │ │ └── js
│ │ │ └── bootstrap.min.js
│ │ ├── css
│ │ │ ├── FontAwesome.css
│ │ │ ├── font-awesome.min.css
│ │ │ ├── Footer-Basic-1.css
│ │ │ ├── Footer-Basic.css
│ │ │ ├── Login-Form-Clean.css
│ │ │ ├── Navigation-with-Button.css
│ │ │ ├── Registration-Form-with-Photo.css
│ │ │ └── style.css
│ │ ├── fonts
│ │ ├── img
│ │ │ ├── avatars
│ │ │ ├── dogs
│ │ └── js
│ │ ├── bs-init.js
│ │ ├── chart.min.js
│ │ ├── custom.js
│ │ ├── jquery.min.js
│ │ ├── smoothscroll.js
│ │ └── theme.js
│ ├── controllers
│ │ └── user_controller.js
│ ├── fonts
│ ├── img
│ ├── index.js
│ ├── js
│ ├── routes
│ │ ├── profile_route.js
│ │ └── route.js
│ └── views
│ ├── index.ejs
│ ├── partials
│ ├── patient_profile.ejs
│ ├── previous_appointments.ejs
├── test
│ └── array.spec.js
└── tree.txt
I ignored some files like fonts and pictures to make the tree more readable
index.js
const express = require('express')
const routes = require('./routes/route')
const appPort = process.env.PORT
const app = express()
//.env
require('dotenv').config({
path: path.join(__dirname, './.env')
})
//Setting up Handlebars
app.set('view engine', 'ejs')
app.set('views', __dirname + '/views')
app.use('/src', express.static(__dirname + '/src'))
app.use('/views', express.static(__dirname + '/views'))
app.use('/fonts', express.static(__dirname + '/fonts'))
app.use('/js', express.static(__dirname + '/js'))
app.use('/img', express.static(__dirname + '/img'))
app.use('/assets', express.static(__dirname + '/assets'))
app.use('/', routes)
//Creating a connection
app.listen(appPort, () => {
console.log(`App is running. serve at port: ${appPort}`)
console.log(`http://127.0.0.1:${appPort}`)
})
Again, sanitized programming related to DB etc.
my css referral in settings_patient_profile.ejs:
<link rel="stylesheet" href="../assets/bootstrap/css/bootstrap.min.css">
<link href='http://fonts.googleapis.com/css?family=BenchNine:300,400,700' rel='stylesheet' type='text/css'>
<link rel="stylesheet" href="../assets/fonts/fontawesome-all.min.css">
<link rel="stylesheet" href="../assets/fonts/font-awesome.min.css">
<link rel="stylesheet" href="../assets/fonts/fontawesome5-overrides.min.css">
For your CSS files to work reliably, no matter what the path of the parent page is, you need to use absolute URLs for the CSS links, not relative links. So, start the link with /, not with ../.
You don't show exactly where the target CSS files are in your server file system, but I would guess that you need to change this:
<link rel="stylesheet" href="../assets/fonts/fontawesome-all.min.css">
to something like this:
<link rel="stylesheet" href="/assets/fonts/fontawesome-all.min.css">
And, then use one express.static() middleware that serves everything in the assets hierarchy:
app.use('/assets', express.static(__dirname + '/assets/src'));
This particular recommendation is based on the view of your file system that shows all the assets are in /assets/src on your server disk.
Also, as long as you're willing to prefix all your static URLs with /assets, you should not be needing all of these as they can all be handled by the one previous express.static() middleware:
app.use('/src', express.static(__dirname + '/src'))
app.use('/views', express.static(__dirname + '/views'))
app.use('/fonts', express.static(__dirname + '/fonts'))
app.use('/js', express.static(__dirname + '/js'))
app.use('/img', express.static(__dirname + '/img'))
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 starting to work on a new app at my company. I'm hoping to run a quick process that will generate an outline, tree, or other map-type thing of all of the CSS and SASS files in the app directory.
I know I can grep it, but I wanted to see if someone had something more targeted I could use.
If you're simply looking to generate a tree, the common tree command can filter by file type if provided a pattern. Maybe this will help:
tree -P "*.css" --prune
The -P option allows you to match a pattern, and the --prune option hides empty folders (or ones which don't contain match files).
It's a pretty nifty tool; here's some sample output from tree -P "*.js" --prune on a node project directory:
.
├── Authorize.js
├── collections.js
├── functions
│ ├── downloadImage.js
│ ├── generateThumbnails.js
│ ├── hashImage.js
│ ├── loadMedia.js
│ └── uploadFile.js
├── node_modules
│ ├── body-parser
│ │ ├── index.js
│ │ ├── lib
│ │ │ ├── read.js
│ │ │ └── types
│ │ │ ├── json.js
│ │ │ ├── raw.js
│ │ │ ├── text.js
│ │ │ └── urlencoded.js
│ │ └── node_modules
│ │ ├── bytes
│ │ │ └── index.js
│ │ ├── content-type
│ │ │ └── index.js
More documentation here: http://www.computerhope.com/unix/tree.htm
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.