Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update php 7 > 8.1+, dependencies, phpunit10, psr12, bugfixing and co… #2

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
/vendor/*
/vendor/
.phpunit.result.cache
.phpunit.cache
.phpunit
composer.lock
auth.json
18 changes: 10 additions & 8 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,28 +3,30 @@
This framework for PHP applications delivers a vastly different approach to writing PHP applications for web and CLI.

The core principles and concepts are

- platform/runtime agnostic approach (cloud, local, containerized)
- abstraction and modularization
- vendor-lock-in avoidance
- interacting with data without committing to a specific storage technology
- reducing amount of time used for administering and managing databases
- reducing the amount of time used for administering and managing databases
- giving guide rails to keep application components meaningful
- inheritance and extension, even on cross-project-/application-level

## Additional packages, recommendations

While applications solely based on this package (`codename/core`) do run on their own,
you might take advantage of several additional packages (sometimes even 'apps' on their own):

- **architect**: [Repository](https://github.com/codename-hub/architect), [Package](https://packagist.org/packages/codename/architect)
- creating and migrating database/table schemas
- executing deployment and migration tasks
- creating and migrating database/table schemas
- executing deployment and migration tasks
- **core-ui**: [Repository](https://github.com/codename-hub/core-ui), [Package](https://packagist.org/packages/codename/core-ui)
- Generic CRUD and Form components
- UI-related components (web UI and CLI 'ui')
- Generic CRUD and Form components
- UI-related components (web UI and CLI 'ui')
- **core-io**: [Repository](https://github.com/codename-hub/core-io), [Package](https://packagist.org/packages/codename/core-io)
- data handling (load, transform, output), esp. for mass data
- data handling (load, transform, output), esp. for mass data
- **rest**: [Repository](https://github.com/codename-hub/rest), [Package](https://packagist.org/packages/codename/rest)
- supporting components for writing REST-endpoints and REST-style apps (or mixed ones)
- supporting components for writing REST-endpoints and REST-style apps (or mixed ones)

They're all installable and auto-loadable via Composer.

Expand All @@ -51,4 +53,4 @@ For Web-Apps, this might be the first part of the URI (if you're rewriting the U

A **model** defines a data structure and can be backed by a RDBMS (like MySQL/MariaDB, SQLite, etc.), pure JSON data, an abstract data source or even a mapped ER-model. A model allows you to query data, filter it, change it (create, modify, delete) or build more complex 'queries' by adding models upon each other.

A **bucket** is an abstraction layer for using data storages (like a local directory, connections like FTP(S) and SFTP, S3 buckets, etc).
A **bucket** is an abstraction layer for using data storages (like a local directory, connections like FTP(S) and SFTP, S3 buckets, etc.).
47 changes: 21 additions & 26 deletions TUTORIAL_BASIC_IO.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# TUTORIAL - BASIC IO #

This Tutorial is for giving you a quick overview about the most important components of the core framework.
This Tutorial is for giving you a quick overview about the most important parts of the core framework.

Requires the following knowledge:

Expand Down Expand Up @@ -51,7 +51,7 @@ class mycontext extends \codename\core\context {
_NOTES:_

* Make sure you're using the correct namespace (e.g. _namespace codename\demo\context_ if your app is called "_demo_")
* Make sure your class is inheriting from a context class (e.g. _\codename\core\context_ )
* Make sure your class is inherited from a context class (e.g. _\codename\core\context_ )
* Make sure you prefix all your view functions with view_
* You may omit the PHP closing tag (some modern-stylish PHP programming stuff...)
* Don't you ever dare to use __camelCasing__ for context backing class files
Expand All @@ -63,8 +63,7 @@ __Step 2: Create your view code__
Create a new PHP file (depending on your preferred templating engine)
at frontend/view/__your-context__/__your-view__.php
This may be the raw HTML/PHP-Inline code of your view.
If you're using __Twig__ for templating/writing views, it may be called __your-view__.twig

If you're using __Twig__ for templating/writing views, it may be called "__your-view__.twig"

~~~php
<?php namespace codename\demo;?>
Expand All @@ -75,45 +74,41 @@ If you're using __Twig__ for templating/writing views, it may be called __your-v
_NOTES:_

* The example is a bare inline PHP code
* Don't forget to namespace the code if you're using *.php files (irrelevant if you're using Twig)
* Then, you can access the response constainer via app::getResponse()->getData( ... );
* Remember to namespace the code if you're using *.php files (irrelevant if you're using Twig)
* Then, you can access the response container via app::getResponse()->getData( ... );

- - - -

__Step 3: Allow your view to be accessed__

Open your app configuration at __config/app.json__.
Under the key "__context__" create a json object declaring your context outline:

Under the key "__context__" create a JSON object declaring your context outline:

~~~json
{
...
"context": {
"mycontext": {
"defaultview": "myview",
"view": {
"myview": {
"public": true
}
}
},
...
"context": {
"mycontext": {
"defaultview": "myview",
"view": {
"myview": {
"public": true
}
}
}
}
}
~~~

_NOTES:_

* Required keys for each context:
defaultview
view
* Set __"public" : true__ for a view to be accessed without authentication. This is fine for testing purposes.
defaultview
view
* Set __"public": true__ for a view to be accessed without authentication. This is fine for testing purposes.
* Optional keys:
"type": optionally, you can define "crud" or another inheritable context type. Then, you might not need to define stuff that is already present in the base context type.
"template": explicitly use a template here
"defaulttemplateengine": explicitly use a template engine defined in environment.json here

"type": optionally, you can define "crud" or another inheritable context type. Then, you might not need to define stuff that is already present in the base context type.
"template": explicitly use a template here
"defaulttemplateengine": explicitly use a template engine defined in environment.json here

__Step 3.5: Test!__

Expand Down
58 changes: 30 additions & 28 deletions TUTORIAL_DATA.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ __Requirements__

* Model Definition
* Model Backing Class
* Your imagination - e.g. a blank context to work in
* Your imaginatione.g., a blank context to work in

__Files to be touched__

Expand All @@ -21,55 +21,57 @@ __Files to be touched__

__Step 1: Create your model definition__

Create a new json file in config/model/, e.g. demo_stuff.json.
It is always <schema>_<model>.json. Schema MAY be "demo", but it can also be "abc" or whatever you want it to become.
The schema translates to DB Schemata (or, if you're using MySQL, it matches up with a "database"). And yes, you can cross-join them.
Create a new JSON file in config/model/, e.g., demo_stuff.json.
It is always <schema>_<model>.json.
The Schema MAY be "demo", but it can also be "abc" or whatever you want it to become.
The schema translates to DB Schemata (or, if you're using MySQL, it matches up with a "database").
And yes, you can cross-join them.

~~~json
{
"field" : [
"field": [
"stuff_id",
"stuff_created",
"stuff_modified",
"stuff_name"
],
"primary" : [
"primary": [
"stuff_id"
],
"datatype" : {
"stuff_id" : "number_natural",
"stuff_created" : "text_timestamp",
"stuff_modified" : "text_timestamp",
"stuff_name" : "text"
"datatype": {
"stuff_id": "number_natural",
"stuff_created": "text_timestamp",
"stuff_modified": "text_timestamp",
"stuff_name": "text"
},
"options" : {
"stuff_name" : {
length: 64
"options": {
"stuff_name": {
"length": 64
}
},
"connection" : "myconnection"
"connection": "myconnection"
}
~~~

__NOTES:__

* Required keys:
field (array of field names / column names)
primary (array of fields to be the primary key - should be only 1 (!) at this time)
datatype (the core-framework-specific datatypes - one of those: text, number, number_natural, boolean, text, structure, ... - you can even use text_email)
field (array of field names / column names)
primary (array of fields to be the primary key - should be only 1 (!) at this time)
datatype (the core-framework-specific datatypes - one of those: text, number, number_natural, boolean, text, structure, ... - you can even use text_email)
* Optional keys:
foreign (for foreign key definitions)
db_column_type (see below)
connection (for using a specific db connection defined in environment.json)
foreign (for foreign key definitions)
db_column_type (see below)
connection (for using a specific db connection defined in environment.json)
* You may use "db_column_type" to specify the exact database-specific datatype. If undefined for a given key, the default values are used.

- - - -

__Step 2: Build__

If you don't want to create the databases, tables, fields and constraints yourself, you should use the __Architect__ to build you definition.
If you don't want to create databases, tables, fields and constraints yourself, you should use the __Architect__ to build your definition.
You have to have architect installed as a composer package.
If you're using the default prepared docker-compose environment, you can open up http://architect.localhost:8080/ to view pending changes. Click on Details of your app.
If you're using the default prepared docker-compose environment, you can open up http://architect.localhost:8080/ to view pending changes. Click on the Details of your app.
To execute the pending tasks, append the GET-Parameter exec=1 to the url.

- - - -
Expand All @@ -84,16 +86,16 @@ namespace codename\demo\model;

/**
* this is an example model
* without function
* without a function
*/
class stuff extends \codename\core\model\schematic\mysql {

/**
*
* {@inheritDoc}
*/
public function __CONSTRUCT(array $modeldata) {
parent::__CONSTRUCT($modeldata);
public function __construct(array $modeldata) {
parent::__construct($modeldata);
$this->setConfig(null, 'demo', 'stuff');
}

Expand All @@ -116,7 +118,7 @@ $model = app::getModel('stuff'); // do your stuff.

__NOTES:__

* If you're using app::getModel(), you have to be in the namespace codename\core; (or even your own app namespace). Otherwise, require it using "use \codename\core\app;".
* If you're working inside a context, you can also use $this->getModel( ... ), as the base context class provides you this method.
* If you're using app::getModel(), you have to be in the namespace codename\core; (or even your own app namespace). Otherwise, it requires it using "use \codename\core\app;".
* If you're working inside a context, you can also use $this->getModel(...), as the base context class provides you with this method.

- - - -
Loading