Folder Structure

How neoan3 is structured

CLI templating

You can influence the cli-generated output with templates. To do so, place a folder _template in your project. Basic variable support works with double curly braces without spaces ( {{example}} ) The following files are respected:

Template File Entity Vairable Note
api.php component (API) name, frame
route.php component (Route) name, frame
model.php model name
view.html component (Route) name
ce.php Custom element name *PHP files for custom element is only generated if template is present
ce.js Custom element name
ce.html Custom element name
*.json Credential template It might sometimes be useful to provide a template for credentials to provide your team with the possibility for an easy setup.

If the the cli-command `neoan3 new [component|model] <name>` finds the according template, it generates files accordingly. Want to learn more about cli-templating?

github.com/neoan3/cli#templates

Asset folder

This folder is intended to hold static files of all sorts and neoan3 holds no opinion on the deeper structure.
Classically, you might want to have an image and/or upload folder within it.

Component folder

This folder holds hybrid, route, api and custom components. Components must have their own directory.
Note that neoan3's routing system performs a kebab-to-pascal-case transformation when evaluating routes. (as opposed to kebab-to-camel in versions <3.0)
This means that

your-app.com/my-component/ targets the component
/component/MyComponent

learn more about components

Frame folder

Frames are a unique and vital piece to a Neoan3. Frames hold global information & functionality and hook into the framework's Serve class. As such, a frame tends to provide project-specific settings like the HTML skeleton, used CSS, includes, apps etc. Components can either extend a particular frame (default behavior of API-components), construct them via the unicore singleton or use them as instance ( new MyFrameName() ).

learn more about frames

Model folder

Neoan3 follows an MVC-approach that isn't obvious when looking at the folder structure. Models, however, do have their own directories within the model-folder. While static use is encouraged due to some third party apps, Neoan3 does not dictate a certain structure.

learn more about models

Provider folder

In order to decouple components and models from the executing instance - and in order to use external testing/mocking - you can program against interfaces that provide required instances as dependency injection. The current version ships with a MySql provider for database transactions.

learn more about providers

default.php

This file is requested early in the initiation process and facilitates the possibility to hook into early events. After installation, the default controller (usually a route controller) and 404-controller are already defined. In most use-cases, you will want to change at least the value of default_ctrl to your "homepage" controller. For example, if your application has a "home" route component with your start page, your default.php could look like this:


                    <?php
                    // default route (homepage)
                    const default_ctrl = 'home';
                    // or: define('default_ctrl','home');

                    // optional: custom 404
                    const default_404 = 'notFound';
                    // or: define('default_404','notFound');

                    // optional: react on early events
                    Event::listen('Core\Route::notFound', function($call){
                        // redirect?
                    })
                 

.htaccess & Apache

When running Neoan3 on Apache, the easiest way to set up intended behavior is using the provided .htaccess. In most cases, you likely want to change the "RewriteBase" to "/" (assuming your web-root equals the application root). Neoan3 requires mod_rewrite to be available.