Basic layout and default directory structure
The default package, which you can download here, has a certain structure and layout, which we'll introduce here and which is then woven throughout the documentation. We'll tell you where what is and why it is that way.
It should be noted that this predefined structure is not fixed. Yes, it's a structure that I've gradually arrived at as optimal, but it's not fixed, and I have my own projects where the structure is different (single-purpose highly specialized applications). After all, you can set everything up as you need it, and if you're sure that a different solution is better suited for a certain situation, then use that option to adjust the structure. However, for the purpose of explaining how Jet works, one fixed point (so to speak) is needed and that is this default structure. And now to the point ...
Before we get into the individual directories and subdirectories, let's talk about the general principles that apply to the entire structure.
Directories with the _ character at the beginning
These are directories containing, for example, the installer and development tools (especially Jet Studio) - that is, auxiliary tools not related to the actual operation of the application. Directories are distinguished this way because they have no business on a production server. That's the main point of the _ sign. To show what not to upload to the server from which the production instance of your application is running. And if you need it there for a while, don't leave it there permanently. Thus, the _ character equals an internal / temporary thing.
Directories with a capital letter at the beginning
These are directories where you can find some classes (and theoretically functions). Simply put, some application logic, part of the logic, a component of the application.
Directories with a lowercase letter at the beginning
Lower case means: don't look for classes here. Here you will find mainly data, or view scripts. What data? For example, configuration files, dictionaries for the compiler, application state data, caches, and so on.
*.php vs *.phtml files
This is a basic distinction between view scripts (i.e., a script generating output) and a script containing some application logic.
Description of the default directory structure
Now we'll go through each directory, but I'll leave the most important ones for last.
If you've already installed the Jet sample application, here's the installer to guide you through the installation. It is a standalone mini application. It is only supposed to be present for installation and then removed by you.
The installer can be used as a basis for your own installer. Do you want to build your CMS on Jet? Fine, it can have an installer and here is the basis.
In addition, as I already mentioned, it is a standalone mini-application, but it is itself built on Jet and serves as a demonstration of one approach and strategy for creating online applications.
Profiler is a separate topic. See the relevant chapters for more details. But for the record, it's a mini-app to help you debug the performance of your project. Because it has a _ at the beginning, it is intended for you, the developer, and only for you, the developer, and has no business on a production environment (certainly not permanently).
In this directory you will find help tools designed to help you with your development.
A couple of help tools usable from the CLI environment (or command line, if you prefer).
Another mini app (although it's not very mini anymore) and a tool that makes life much easier: Jet Studio. Here you just do all sorts of things. It's a great theme and best to just try it out.
Jet Studio is an online application, so you can access it via the URL. The link is on the home page of the sample application.
And by the way, this is an example of another possible strategy for creating an online application...
The directory for storing cache data if the cache backend uses files (and not something like Redis). The directory is used by Jet and of course fully usable by your application.
Different logos. For example, this is where ErrorHandler stores error logs.
There's probably nothing to explain here ... :-)
~/css, ~/js a ~/images
What these directories are intended to do is obvious from their names. The important thing is that they are directly accessible directories via URL (still together with ~/_tools/studio/). All other traffic (http requests) is routed to boostrap applications.
If you need other such directories (I can think of ~/files/, ~/pdf/, etc.), feel free to create them.
I assume that you know how to properly edit the .htacces for your Apache, or NGinx (or other server) configuration. Thus, I will not discuss this topic here (and possibly duplicate the documentation of the respective webservers).
As the name suggests, this directory is for libraries.
Here in the ~/library/Jet directory you will find Jet itself.
However, the directory is also intended for other libraries used in the project - not just Jet.
In practice, it has worked well for me to separate everything (especially third-party libraries) that neither I nor my colleagues are supposed to touch. Certainly not without coordination and consideration (and testing) of the implications. That is, there is a clear separation between what is our application and what is a component that should actually be untouchable.
Hooray! Finally, we're at the most important directory. This is what I call the application space, and it's where our main "playground" is. This is where the entire application and everything related to it is stored. So let's break it down.
Destination directory for each MVC base.
What's that? For that, you need to study how MVC works in Jet. It's simple in its essence, but it's impossible to say it in one sentence, but I'll try: here are the definitions of individual parts of the project (e.g. administration, REST API and also the publicly visible part, whether it's a website, e-shop or whatever) and individual pages.
So for example the definition of what should happen at the URL https://my-web/about-us/ is right here.
Did the word "routing" come to mind? Yes, you could say that. But it's far from just routing. You'll learn all about it later.
In addition to definitions, there are also basic views and layouts in this directory. If you think it doesn't make sense, know that it does. You'll see :-)
Here are a number of configuration files and configuration scripts. For more on see here.
The internal application data is stored in this directory. That is, data that the application needs, but cannot be accessed from the outside.
For example, a list of installed and active modules and so on.
The directory is designed for Jet as well as for arbitrary use by your application.
As the name suggests, the translator dictionaries are stored here.
Here are the definitions of the different menus. Again, more info in a separate topic. But in short, here you will find the definition of your application's root administration menus and lots more - as you need them.
Oh, hey... A capital letter at the beginning, so there will be some classes hidden there :-). And that's it.
In this directory there are individual Loaders, i.e. modules of Autoloader.
Here are the initializations of the individual subsystems.
Do you want to know (and mainly influence) how AutoLoader starts, for example? You can find it right here in the initialization script ~/application/Init/Autoloader.php.
A detailed explanation of each initialization can be found always at the description of the relevant part of the system, so I will not list and describe everything that is in the initialization.
It is important to know that you should look for the initialization of anything here.
ErrorHandler has its modules in this ErrorHandlers directory.
This directory is for modules that perform the final operation on application errors. This means displaying them, logging them, and so on.
Here are your classes - the classes of your application.
As you will learn, Jet is modular. It allows you to split your application into modules and I highly recommend this approach for most projects.
But even a modular application has its general classes. Example? Such a generic class can be, for example, a class that prepares an article. And then one module works with the article for administration, another module displays the article on the web, and another module represents the REST API. But still, these modules work with one entity representing the article (or item, just whatever you can think of).
And it is for such general classes that this directory is intended - in fact, one of the most important directories.
In addition to the Classes directory, the most important directory and also the core of your application.
This script is the entry point of the application. It is where all traffic is directed to using .htaccess (or other settings - depending on your web server).
It calls configuration, initialization and then starts the MVC processing sequence.