I have a Padrino app which doesn't seem to be aware of its own root path. The app works fine, but when I try to require a file I wrote and put into the models folder, it says it cannot find it. The file is required from within another file in the models folder: DvdActor.rb. I can use any of these paths and it won't find it:
/app/models/file.rb
file.rb
models/file.rb
app/models/fie.rb
...
It will only find it if I use:
"#{Padrino.root}/app/models/file.rb"
Furthermore, the Thnking Sphinx gem will also have problems writing its configuration file or indexing (if I hardcode the path to the config file).
And when I have Padrino generate a Model, it will create a new model folder in the root folder insted of in the app folder itself.
I could recreate my app from scratch and copy the files over but I already have Heroku and git setup, etc. and don't want to recreate all this (sometimes simply copying the files over doesn't work properly).
Is there a way to reset this?
Related
I know this question will get so many downvotes and will be marked as a duplicate.
The problem is I searched a lot about that question and never got a satisfying answer.
When working with sources in HTML and we want to get an image from the same folder of the HTML file we type the image name directly. If it's inside a folder which is in the same place as the HTML file is, we type the folder name then image, and so on....
If the image is in a folder which contains another folder in which the HTML file exists, so we want to get one step back. We type ../ which means go one step back then the image name.
When I started learning node and how to use modules, modules which were in the same folder as the node file is, must be imported using ./ which was explained as 'in the same folder', while when we import modules like 'fs' and 'events' they don't need a ./
Can someone explain why we don't use ./ in html files while they are used sometimes in node and sometimes no?!
I want to explain it because the node default import setting.
like 'fs' and 'events', these library was installed with node installed, and was included by default. And these will be stored in system directory. Just like <stdio.h> for c, fs from python. It's the default library for the corresponding language.
But sometimes you write you own libraries wanted to be import by other node file, you should import it by using relative path...Because if you don't write './', it will default search the system file directory where is stored 'fs', 'http' and so on, node will not find your libraries.
Before we start ./ and ../ notation is used to refer files relatively.
Why we sometimes don't use ./ in node?
All the modules we install in NodeJS are in the folder node modules. Whenever you require a module require('fs') or require('3rdparty'). Node exactly knows where to look for the module as it is installed as a folder in local node_modules or global node_modules. And then it loads the index.js and then so on..
When to use ./ in node?
./ is a way(Relative way) to refer files in the file system. If you have a script which is part of the file system and not as part of a node_module, then you use './' or '../' notation based on your file location
Why we don't use ./ in HTML files?
As said by #sami, you can use either ./ or not. It works in both ways. I am accustomed to ./ when I work. It's more of personal opinion.
Hope this helps.
Starting with a default installation of SilverStripe (using composer), I have the folders framework, cms, mysite, etc.
Using composer I then added some additional code, such as userforms with the command:
composer require silverstripe/userforms
This created the folder userforms in the root of my site.
However, to manage my code more easily, it would be nicer if all modules added by composer were in a subfolder together. This answer indicates how a default vendor-dir directory can be specified using the composer.json file.
There is already a vendor folder in existence (if I understand correctly, this is used by composer). Is it ok to use the vendor folder as the default vendor-dir setting, or would it be better to create a new folder instead?
Also, what do I need to do to move existing folders (such as userforms) into the appropriate sub-folder?
This behaviour is specified by type. The packages with "type": "library" will be placed into vendor folder.
This is how the framework was designed, it expects the files to be located where they are now. It uses legacy code and is unable to make use of Composer autoloading.
I'm starting a new web app with Openshift (jboss, mysql). It's the first time I use openshift and after reading through some doc and experimenting a bit with it, I'm having one question regarding best practices for the architecture of my app.
There will be some files generated by- or uploaded to the application (resources). I'd like those files to be outside the deployment folder so they are not erased/overwritten when the app deploys again. I have browsed through the directories and I was wondering:
is it ok to use the /var/lib/openshift/[openshift-id]/app-root/data folder for these files?
Yes, you should use your ~/app-root/data folder for any files that you want to not be erased when you do a git push, there is also an environment variable that you can use that points to that folder called OPENSHIFT_DATA_DIR. Please note that if you are using a scaled application, that folder is not shared among your gears.
The source for my Jekyll-powered website lives in a git repo, but the website also needs to have a couple large static files that are too large to go under version control. Thus, they are not part of the Jekyll build pipeline.
I would like for these to simply live in an assets directory in the Jekyll destination (which is a server directory; note that I don't have have any control over the server here; all I can do is dump static files into a designated directory) that does not exist in the git repo. But, running jekyll build deletes everything in the output directory.
Is there a way to change Jekyll's behavior in this case? Or is there some other good way to handle this issue?
Not sure this addresses the specific case in the OP, but seeing as how I kept getting to this page when I finally found an answer here, I thought I'd add an answer to this question in case it helps others.
I have a git post-hook that builds my jekyll site in my webhost when I push to my host, but it was also deleting anything else that I had FTP'ed over. So now I've put anything I need to stick around in a directory (external/ in my case), and added the following to my _config.yml:
exclude: [external]
keep_files: [external]
and now files in external/ survive.
If you upload Jekyll's output directory via FTP to your server, you can use a FTP tool that lets you ignore folders.
For example, my own site is built with Jekyll, but hosted on my own webspace, so I'm uploading it via FTP.
I explained in this answer how I scripted the building and uploading process, so I can update my site with a single click.
In my case (Windows), I used WinSCP, a free command-line FTP client, for this.
If you're not on Windows, you need to use something else, but there are probably other FTP tools out there that are able to ignore folders.
To ignore your assets folder in WinSCP, you just need to put this line into the script file:
(the file which contains the actual WinSCP commands - read my other answer for more information)
option exclude "assets/"
Now you can upload your large assets folder on the server once, and it won't be overwritten/deleted when you later update your site via FTP.
I've just installed Kohana 3.0.4.2 and I have run the index.php file successfully. According to the documentation, the next step is to edit the config files in the application/config folder. I have that folder but there are no files in it! I downloaded the package again to make sure it wasn't corrupted, but the same problem exists. Why is the application/config folder empty?
You're probably looking at outdated (2.*) documentation. The only config file to edit after an install is application/bootstrap.php. There is some configuration in index.php, but you really shouldn't be touching that unless you want to change the directories things are stored in.
The config folder is used for config files of your custom classes. Since you obviously don't have any in an empty project, the folder is empty. You can see an example of them in use by looking at system/config, where the config files for some of the system classes lie.
As of now, the best docs are the unofficial Kohana wiki. There's also the official docs, but they're a work in progress.
One of the best things about Kohana 3 is that it's extensible and really modular.
In you case, there are no config files by default, you only have the clean framework with couple of modules ( you'll find them in the /modules folder ). Every modul has pretty much the same hierarchy as application folder, so you'll probably find the default config files there.
If you need database config, go to /modules/database/config/ and you'll find the default one, copy it to application/config and you've overwriten the default one from being used ( Kohana autoload just works this way; first looks for files in application folder, then the loaded modules folder(s), and the system (framework) folder is the last.