I have gone through Laravel beginners tutorial, and now I can understand every topics listed in those tutorials and have created my own project, but as I saw in those, the tutors were able to understand what each file was meant for and had the capability to edit it and change it as per their needs.
So how do they learn so deeply and from which source?
I will try brief what is said at Laravel Official Documentation
The root directory
In the root directory of every Laravel project you can find the following directories:
The app directory, as you might expect, contains the core code of your application. Models, controllers, services, middlewares are stored here.
The bootstrap folder contains a few files that bootstrap the framework and configure autoloading, as well as a cache folder that contains a few framework generated files for bootstrap performance optimization. Commonly you don't need touch this folder.
The config directory, as the name implies, contains all of your application's configuration files. You have to set your database connections, email drivers, sessions storage configuration (and much more), here.
The database folder contains your database migration and seeds. If you wish, you may also use this folder to hold an SQLite database. Migrations allows you define your database without writing any SQL code. It's very useful if you are interested at versioning your database structure. See more info here
The public directory contains the front controller and your assets (images, JavaScript, CSS, etc.).
The resources directory contains your views, raw assets (LESS, SASS, CoffeeScript), and localization files. By default, views uses the view engine named blade, but you could change this in the config folder.
The storage directory contains compiled Blade templates, file based sessions, file caches, and other files generated by the framework. This folder is segregated into app, framework, and logs directories. The app directory may be used to store any files utilized by your application. The framework directory is used to store framework generated files and caches. Finally, the logs directory contains your application's log files.
The tests directory contains your automated tests. An example PHPUnit is provided out of the box.
The vendor directory contains your Composer dependencies and the libraries needed for you application. Each library installed through composer will be stored here.
App folder
The app folder contains the core code of your application. There different directories inside this folder, each one has an specific purpose:
The app directory ships with a variety of additional directories such as Console, Http, and Providers. Think of the Console and Http directories as providing an API into the "core" of your application. The HTTP protocol and CLI are both mechanisms to interact with your application, but do not actually contain application logic. In other words, they are simply two ways of issuing commands to your application. The Console directory contains all of your Artisan commands, while the Http directory contains your controllers, middleware, and requests. The routes of your application are defined in this directory also.
The Events directory, as you might expect, houses event classes. Events may be used to alert other parts of your application that a given action has occurred, providing a great deal of flexibility and decoupling. Check this link for more info
The Exceptions directory contains your application's exception handler and is also a good place to stick any exceptions thrown by your application.
The Jobs directory, of course, houses the queueable jobs for your application. Jobs may be queued by your application or run synchronously within the current request lifecycle. There is more info here.
The Listeners directory contains the handler classes for your events. Handlers receive an event and perform logic in response to the event being fired. For example, a UserRegistered event might be handled by a SendWelcomeEmail listener.
The Policies directory contains the authorization policy classes for your application. Policies are used to determine if a user can perform a given action against a resource. More info here.
Related
I am confused about how Laravel protects keys using environment variables. It seems to me that a hacker could just look through the environment variables or at the hidden file. How is this better than storing it in the default array. Does Laravel do something with the environment variable to make this more secure? Or is it just a way to separate keys for different configurations.
I tried searching for an answer but I only found a non-Laravel question of the same nature that didn't seem to have a good answer either.
The configuration file is not meant to be stored in source control. This means the sensitive data is never stored anywhere it does not need to be. If a hacker were to gain access to your repository, they wouldn't be able to access for example; your database password.
This configuration file will placed upon deployment or once manually (eg ssh) into the project for the application to access.
Web server rewrites (apache .htaccess) or NGINX config will ensure that this configuration file can never be directly accessed.
If a hacker gets access to your server via an exploit or another method, they will still be able to access the configuration file.
Security is about having multiple layers, and removing this sensitive data from source control is one of many.
At the bottom of the configuration section in the laravel docs it mentions this very briefly:
Be sure to add the .env.local.php file to your .gitignore file. This
will allow other developers on your team to create their own local
environment configuration, as well as hide your sensitive
configuration items from source control.
Now, on your production server, create a .env.php file in your project
root that contains the corresponding values for your production
environment. Like the .env.local.php file, the production .env.php
file should never be included in source control.
I'm setting up a master-replica setup in a load balanced cluster and am trying to figure out which directories to exclude from syncing to other machines. I naturally don't want to sync the storage/logs folder and DO want to sync the view cache folder (as "php artisan optimize" is run on the master), but I'm having a harder finding information on when the other directories in app/storage are used. Would appreciate an explanation.
Well, storage/cache and storage/sessions are used for, as their names suggest, cache and session storage. Specifically when using the file driver for those components. You probably don't want to include that.
storage/meta holds information the framework parses about itself, such as which components are provided by which service providers. You might want to include that, but I don't think it's crucial.
I have a few resources (log files, database files, separate configuration files, etc.) that I would like to be able to access from my OSGi bundles. Up until now, I've been using a relative file path to access them. However, now my same bundles are running in different environments (plain old Felix and Glassfish).
Of course, the working directories are different and I would like to be able to use a method where the directory is known and deterministic. From what I can tell, the working directory for Glassfish shouldn't be assumed and isn't spec'ed (glassfish3/glassfish/domains/domain1/config currently).
I could try to embed these files in the bundle themselves, but then they would not be easily accessible. For instance, I want it to be easy to find the log files and not have to explode a cached bundle to access it. Also, I don't know that I can give my H2 JDBC driver a URL to something inside a bundle.
A good method is to store persistent files in a subdirectory of the current working directory (System.getProperty("user.dir") or of the users home directory (System.getProperty("user.home"))
Temporary and bundle specific files should be stored in the bundle's data area (BundleContext.getData()). Uninstalling the bundle will then automatically clean up. If different bundles need access to the same files, use a service to pass this information.
Last option is really long lived critically important files like major databases should be stored in /var or Window's equivalent. In those cases I would point out the location with Config Admin.
In general it is a good idea to deliver the files in a bundle and expand them to their proper place. This makes managing the system easier.
You have some options here. The first is to use the Configuration Admin service to specify a configuration directory, so you can access files if you have to.
For log files I recommend Ops4J Pax Logging. It allows you to simply use a logging API like slf4j and Pax Logging does the log management. It can be configured using a log4j config.
I think you should install the DB as a bundle too. For example I use Derby a lot in smaller projects. Derby can simply be started as a bundle and then manages the database files itself. I'm not sure about h2 but I guess it could work similarly.
I’ve got two applications running in my CI deployment. I’m using a separate folder to hold shared resources between the two apps.
Then in autoload.php i have:
$autoload['packages'] = array(SHARED_RESOURCES_PATH);
I’m finding models and helpers load fine from the shared directory, however i’ve added a config folder with database.php and this doesn’t get loaded.
Anyone know why this would be?
Most likely the new config directory you created does not have the same permissions or ownership as your other shared directories; compare permissions/ownership & insure config matches the others (this is usually the culprit when all else is functioning properly).
In my application I am retrieving data from database and showing in it. In db some of the tables contain 1000+ records. Now my requirement is to show this data even if there is no net connection, so I am planning to store the tables in SQLite db at user's machine, but there is a worry:
Since SQLite db will be included
within resources folder, in project,
so it will be by default contained
within application binary. So I want
to know that when the application will
be launched will all this data reside
on RAM ? If yes, then I think this can
cause some problems, so in that case- is
there any alternative solution to
store data locally?
Thanks,
Miraaj
No, it won't all reside in RAM. The contents of the application bundle (NIB files, images, etc.) are not all automatically loaded into memory when the app is launched. Resources are typically loaded on demand. For example, a view controller might call initWithNibName: to load the resources for that view.
Also, unless the database is a read-only part of the application (never changes unless you upgrade), you probably don't want to store it in the app bundle -- use the application documents directory instead (although you might include an initial "default" copy of the database within the app bundle). See "A Few Important Application Directories" in the iOS Application Programming Guide