Page

We explained the concepts of base and page here. We also explained how bases work. And now it's time to see how a page works.

The page is represented by the following classes:

For an overview of all properties and methods, see the individual class descriptions. This chapter will be devoted to explaining how the page works.

Note: As with the base, you have the option of replacing these classes with your own classes using the factories system and implementing the appropriate interfaces. You are therefore free to create your own implementation of the site that suits you. It also means that the page is never installed directly, but always via the relevant factory.

Where and how are the pages stored?

From the previous chapters, you already know where the bases are stored. That is, it's in the ~/application/bases/ directory. You also know that the base itself is a subdirectory of that directory, whose name corresponds to the base ID. Thus, the "web" base is in the ~/application/bases/web/ directory, "admin" is in ~/application/bases/admin/, and so on.

Also, you already know that one of the subdirectories of the base is the pages directory. In this directory, you will then find other subdirectories whose name corresponds to the localization code. Thus, ~/application/bases/web/cs_CZ/ contains the pages of the "web" localization base "cs_CZ" - Czech (Czech Republic).

In this directory you will find a number of subdirectories and also page_data.php files. The meaning of those subdirectories is already different from the base. The page no longer has any of its views, no layouts and so on. These subdirectories, and their other subdirectories, are already pages. The name of the subdirectories corresponds to the URL of the pages.

Let's take an example: Check out the sample application. For example, there is a secret area (a part of the site that a visitor cannot access without logging in and having the necessary rights). And this "passworded" page has some subpages. The URL of one of them is: http://somewhere.universe/tajna-oblast/tajna-informace-1/ and this URL therefore corresponds to the definition of the page in the ~/application/bases/web/cs_CZ/secret-area/secret-information-1/

In the page directory you will find the file page_data.php - which is the definition itself.

So ...

• What's a page is a directory - what's a directory is a page.
• The directory name corresponds to the page URL.
• When you want to add a page, you simply create a directory and its definition. Nothing more. And in practice, you're more likely to use Jet Studio, which has the necessary tools to manage pages.
• If you need to change the URL of a page (either to change part of the URL or to change the structure more fundamentally), you simply make the necessary changes to the directories - rename or move the relevant directories. Just keep the original page ID (the page ID is in the page definition, it has nothing to do with the directory name). If you generate the URL in the application as it should be (i.e. via page instances), you don't have to worry about anything - at most you can delete the cache if it is active.
• If you want, you can use diacritics for directory names. Jet can handle it. I'm not sure if that's quite the best way to go, but you have that option, and in the sample app a page whose URL has diacritics exists (for testing and demonstrating the possibilities).

And now it's time to look at the page definition itself, which is stored in the page_data.php

~/application/bases/BASE-ID/pages/LOCALE/**/**/page_data.php

The principle is exactly the same as for the base. That is, the files in question are the page definitions themselves, and they are again PHP file. I will not give an example of the contents of the definition file here. A page is actually a much larger and more complex entity than a base, but the principle still remains.

And even here, or rather especially here, you have Jet Studio at your disposal. So there is no need to do page definitions manually. You have a "clicker" for that.

When you want to do something as trivial as editing static content or creating a new static page, you might not even touch the source ... The goal is just to have time to do the work and not deal with the trivial stuff.

Pages defined by modules

In fact, this is not the only place where page definitions can be. Pages can define individual modules in their pages directory. In practice, I use this for administration, where individual modules form parts of the administration, and each carries with it its own pages just for administration. For what the visitor sees, I use this standard approach. (This is just an example - not dogma.)

The only difference is where the definition is - where it is actually stored. Furthermore (from the application's point of view), pages are always treated the same way.

Using pages in an application

Pages can do a lot. They carry important information (e.g. what the title is, what the meta tags will be on the page, whether the page is even active, and a whole host of other things) and they can simply "render" - that is, create output based on all this information. To see what the page can do, please go through each class.

Of course, the most common and most common thing that the application itself will do with the page is, for example, creating a URL. And let's use this typical example to show how to work with the page.

To get an instance of a page, use the Jet\MVC::getPage( ?string $page_id=null, ?locale $locale = null, ?string $base_id = null ): static|null;

The meaning of the parameters is probably obvious. In short, the method returns a specific page belonging to a specific locale of a specific base (or null if the page does not exist). Neither parameter is mandatory. This means that if you don't specify $locale and $base_id, for example, the current data (current base and current locale) is used. Which is actually probably the most common use.

So let's say you have a page with some contact information that has the ID "contacts" and you want to create a link to it (within the current locale of the current base). You do this:

Or do you need to find out what the page's title is for the menu? Then do this:

And that's it... You're assured of consistency. When someone decides to change the page URL, you just rename the directory (and delete the MVC cache). When the page title changes, you do it in one place - the page definition. All simple and straightforward.

By the way... For the base, I mentioned that I encapsulate getting a base instance in classes like JetApplication\Application_Web and don't use the base ID directly. Yes, the same should be true for pages. However, I don't have a one-size-fits-all method here. It's really not quite ideal to use the page ID as a string. Here it is already suggested to use at least some constants. Jet has one such constant, Jet\MVC::HOMEPAGE_ID. Because the root page - the so-called homepage, must always have this ID. So you can use constants you define for the page ID. Or you can also encapsulate it in some methods (if it is not already a cannon for sparrows in this case). It's good to have some easy way to track where the page is being used (e.g. in case it gets deleted).

Obviously, you can do a lot of other things with the site. How about finding out what subpages the current page has? No problem:

Do you need a parent page instead? Here it is

And so on ... But it's better to look at what the classes can do.