The purpose of this class method (or function) is to provide a custom processing of the ServerRequestInterface and ResponseInterface objects BEFORE it is finally sent to the client, for example a custom-made HTML renderer for server-side template engines, or a response streaming, etc.
\ No newline at end of file
+
The purpose of this class method (or function) is to provide a custom processing of the ServerRequestInterface and ResponseInterface objects BEFORE it is finally sent to the client, for example a custom-made HTML renderer for server-side template engines, or a response streaming, etc.
\ No newline at end of file
diff --git a/configure/modules/index.html b/configure/modules/index.html
index 6880129..a8aefa3 100644
--- a/configure/modules/index.html
+++ b/configure/modules/index.html
@@ -1,4 +1,4 @@
- DI Modules - Koded Framework
The purpose of this feature is to setup the DI container in your app.
Once your app stops being "Hello World" and assuming you are going to follow some SOLID principles (or maybe not), the application may end up with lots of interfaces and concrete implementations. All of them can be mapped in the app module.
Koded Container supports multiple modules, but one is sufficient for the container's configuration. Again, it is up to you how you are going to structure the application, so sometimes it makes sense to create multiple modules.
Lets say you want to provide a database for the auth backend instance. Because Koded already has one registered by default (Koded\Framework\Auth\SessionAuthBackend) you can easily configure it in your DI module.
Anything that's bound by the default DI module can be replaced with custom implementation(s) in your application DI module(s). The default classes are from the Koded libraries.
\ No newline at end of file
+ Default framework dependencies - Koded Framework
Anything that's bound by the default DI module can be replaced with custom implementation(s) in your application DI module(s). The default classes are from the Koded libraries.
\ No newline at end of file
diff --git a/exception-handlers/index.html b/exception-handlers/index.html
index e1d5ff2..b5bf373 100644
--- a/exception-handlers/index.html
+++ b/exception-handlers/index.html
@@ -1,4 +1,4 @@
- Exception handling - Koded Framework
By default, the following exceptions are caught and handled
\Exception
\Error
Koded\Http\HTTPError
The error response payload follows the RFC-7807 specification.
If you wish to capture specific exception types and/or return custom error messages, create your own class and register it with the method App::withErrorHandler() to convert the exceptions into the desired HTTP responses.
handle() method signature
handle(request, response, exception): void
If app does not use 3rd party PSR-7 library, then Koded will use its own implementations from the Koded HTTP library.
By default, the following exceptions are caught and handled
\Exception
\Error
Koded\Http\HTTPError
The error response payload follows the RFC-7807 specification.
If you wish to capture specific exception types and/or return custom error messages, create your own class and register it with the method App::withErrorHandler() to convert the exceptions into the desired HTTP responses.
handle() method signature
handle(request, response, exception): void
If app does not use 3rd party PSR-7 library, then Koded will use its own implementations from the Koded HTTP library.
\ No newline at end of file
diff --git a/get-started/index.html b/get-started/index.html
index 4316c10..ad17ef5 100644
--- a/get-started/index.html
+++ b/get-started/index.html
@@ -1,4 +1,4 @@
- Get Started - Koded Framework
It is up to you how you're going to structure your project. A simple and clear structuring is essential for great development, on a long run (or short too), but that is up to developer needs, or based on the app complexity, team decisions, or various other reasons.
Let's look at something that is good in general as a startup,
app/
@@ -50,4 +50,4 @@
return$response;}))();
-
Now point your browser to app address. It should print "Work in Progress..." with status code 200.
From here on add more routes and resources to your API, but keep in mind that using closures as resources is NOT the recommended way to build the application. For more on this please follow the documentation further.
\ No newline at end of file
+
Now point your browser to app address. It should print "Work in Progress..." with status code 200.
From here on add more routes and resources to your API, but keep in mind that using closures as resources is NOT the recommended way to build the application. For more on this please follow the documentation further.
\ No newline at end of file
diff --git a/index.html b/index.html
index 4b10d5e..2d76e8d 100644
--- a/index.html
+++ b/index.html
@@ -1,4 +1,4 @@
- Koded Framework
Sometimes we want a prototype, or quick/simple operations, or solutions for building fast web APIs and app backends. And having a full-blown frameworks will eventually weight you down with tons of unnecessary abstractions and dependencies.
Koded offers small footprint with a clean design that follows the HTTP and ReST architectural style. It tends to be very fast and easy to work with.
Sometimes we want a prototype, or quick/simple operations, or solutions for building fast web APIs and app backends. And having a full-blown frameworks will eventually weight you down with tons of unnecessary abstractions and dependencies.
Koded offers small footprint with a clean design that follows the HTTP and ReST architectural style. It tends to be very fast and easy to work with.
Koded Framework follows the RMR web architectural pattern, but the developer is free to use whatever it prefers and does not enforce any programming patterns in the application.
However, it is strongly recommended adopting and using RMR because it is aligned nicely with the HTTP ReST concepts. After all, web apps needs fundamental directions and principles, not "perfect" solutions so RMR fits here very well.
An object in the RESTful system identified by a URL that exposes methods that corresponds to the standard HTTP methods (GET, POST, PUT, etc) i.e. a business object (entity).
The HTTP request method that corresponds a Resource method that is executed by the request/URL, which returns a Representation for that resource.
Provides a Resource to clients in a readable format (JSON, XML, PDF, HTML, etc). It is the payload of the response object (processed by the HTTP Method that is sent back to the client).
Koded Framework follows the RMR web architectural pattern, but the developer is free to use whatever it prefers and does not enforce any programming patterns in the application.
However, it is strongly recommended adopting and using RMR because it is aligned nicely with the HTTP ReST concepts. After all, web apps needs fundamental directions and principles, not "perfect" solutions so RMR fits here very well.
An object in the RESTful system identified by a URL that exposes methods that corresponds to the standard HTTP methods (GET, POST, PUT, etc) i.e. a business object (entity).
The HTTP request method that corresponds a Resource method that is executed by the request/URL, which returns a Representation for that resource.
Provides a Resource to clients in a readable format (JSON, XML, PDF, HTML, etc). It is the payload of the response object (processed by the HTTP Method that is sent back to the client).
\ No newline at end of file
diff --git a/middleware/builtin/index.html b/middleware/builtin/index.html
index eed33bd..8c3dd5b 100644
--- a/middleware/builtin/index.html
+++ b/middleware/builtin/index.html
@@ -1 +1 @@
- Built-in - Koded Framework
Out of the box Koded offers a curated list with common middleware functionality. The developers are encouraged to create their own (or use existing) PSR-15 middlewares to enhance the application features.
Out of the box Koded offers a curated list with common middleware functionality. The developers are encouraged to create their own (or use existing) PSR-15 middlewares to enhance the application features.
\ No newline at end of file
diff --git a/middleware/cors/index.html b/middleware/cors/index.html
index d3d663e..02416e1 100644
--- a/middleware/cors/index.html
+++ b/middleware/cors/index.html
@@ -1,4 +1,4 @@
- Cors - Koded Framework
CORS config directives will set the global behavior of the middleware. For example, if cors.methods has a value of GET, POST then only these two methods are allowed for all CORS requests. The same applies to all settings.
Directive
Type
Default
cors.origin
string
(empty)
The server origin address as in schema://host:port (if the port is not a standard port)
cors.methods
string
(empty)
Comma-separated list of supported HTTP methods
cors.headers
string
(empty)
Comma-separated list of supported headers
cors.expose
string
Authorization, X-Forwarded-With
Comma-separated list of exposed headers
cors.maxAge
int
0
max-age header for OPTIONS request (before the actual request is called)
cors.disable
bool
false
This directive will completely disable the middleware
CORS config directives will set the global behavior of the middleware. For example, if cors.methods has a value of GET, POST then only these two methods are allowed for all CORS requests. The same applies to all settings.
Directive
Type
Default
cors.origin
string
(empty)
The server origin address as in schema://host:port (if the port is not a standard port)
cors.methods
string
(empty)
Comma-separated list of supported HTTP methods
cors.headers
string
(empty)
Comma-separated list of supported headers
cors.expose
string
Authorization, X-Forwarded-With
Comma-separated list of exposed headers
cors.maxAge
int
0
max-age header for OPTIONS request (before the actual request is called)
cors.disable
bool
false
This directive will completely disable the middleware
\ No newline at end of file
diff --git a/middleware/psr-15/index.html b/middleware/psr-15/index.html
index 34b8666..cc7c9e2 100644
--- a/middleware/psr-15/index.html
+++ b/middleware/psr-15/index.html
@@ -1,4 +1,4 @@
- PSR-15 - Koded Framework
The PSR-15 method signature for processing the incoming server request is very simple:
process(request, handler): response
request is the server side incoming request object, handler is the object that receive the request, do some work and returns a response.
It is important to keep in mind when creating a custom middleware class for your app, where the processing of the ServerRequestInterface and ResponseInterface instances will take place.
This list of middlewares is an additional list that is merged with each route in the $routes list and differ from the $middleware list in the route method in this manner.
This list of middlewares is an additional list that is merged with each route in the $routes list and differ from the $middleware list in the route method in this manner.
\ No newline at end of file
diff --git a/routing/parameters/index.html b/routing/parameters/index.html
index 4220432..e9d44bc 100644
--- a/routing/parameters/index.html
+++ b/routing/parameters/index.html
@@ -1,4 +1,4 @@
- URI parameters - Koded Framework
The URI parameters are named variables wrapped with curly braces {} in the URI template string.
->route('/{param1}/{param2}/{param3}/...')
If the URI matches the route template, the values of the parameters will be stored in the Psr\Http\Message\ServerRequestInterface@attributes and available through the request object with the getAttribute() method
Try to not overcomplicate your regular expressions, in most cases a simple type is sufficient.
\ No newline at end of file
+
Keep it simple
Try to not overcomplicate your regular expressions, in most cases a simple type is sufficient.
\ No newline at end of file
diff --git a/search/search_index.json b/search/search_index.json
index 5b44923..3aefe4f 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"The Koded Web Framework","text":""},{"location":"#why","title":"Why?","text":"
Sometimes we want a prototype, or quick/simple operations, or solutions for building fast web APIs and app backends. And having a full-blown frameworks will eventually weight you down with tons of unnecessary abstractions and dependencies.
Koded offers small footprint with a clean design that follows the HTTP and ReST architectural style. It tends to be very fast and easy to work with.
Koded Framework follows the RMR web architectural pattern, but the developer is free to use whatever it prefers and does not enforce any programming patterns in the application.
However, it is strongly recommended adopting and using RMR because it is aligned nicely with the HTTP ReST concepts. After all, web apps needs fundamental directions and principles, not \"perfect\" solutions so RMR fits here very well.
Resource
An object in the RESTful system identified by a URL that exposes methods that corresponds to the standard HTTP methods (GET, POST, PUT, etc) i.e. a business object (entity).
Method
The HTTP request method that corresponds a Resource method that is executed by the request/URL, which returns a Representation for that resource.
Representation
Provides a Resource to clients in a readable format (JSON, XML, PDF, HTML, etc). It is the payload of the response object (processed by the HTTP Method that is sent back to the client).
"},{"location":"default-dependencies/","title":"Default framework dependencies","text":""},{"location":"default-dependencies/#framework-di-module","title":"Framework DI module","text":"
Anything that's bound by the default DI module can be replaced with custom implementation(s) in your application DI module(s). The default classes are from the Koded libraries.
By default, the following exceptions are caught and handled
\\Exception
\\Error
Koded\\Http\\HTTPError
The error response payload follows the RFC-7807 specification.
If you wish to capture specific exception types and/or return custom error messages, create your own class and register it with the method App::withErrorHandler() to convert the exceptions into the desired HTTP responses.
handle() method signature
handle(request, response, exception): void
If app does not use 3rd party PSR-7 library, then Koded will use its own implementations from the Koded HTTP library.
<?php\n\n# CustomExceptionHandler.php\n\nuse Koded\\Framework\\App;\nuse Koded\\Http\\HTTPError;\nuse Koded\\Http\\Interfaces\\{Request, Response};\n\nclass CustomExceptionHandler {\n\n public static function handle(\n Request $request,\n Response $response,\n HTTPError $exception): void\n {\n // do something with $exception\n // i.e. re-format the error message and set it in the response\n }\n}\n
Order matters. It is required to register the custom exception handlers BEFORE the routes, otherwise they won't be handled if the request/route has been resolved.
It is up to you how you're going to structure your project. A simple and clear structuring is essential for great development, on a long run (or short too), but that is up to developer needs, or based on the app complexity, team decisions, or various other reasons.
Let's look at something that is good in general as a startup,
Everything regarding your application goes into the app/ folder. This is an example, app is not a requirement and it can be anything you want.
Protect your code!
It is important to keep everything outside the html/ folder (app/, vendor/ or anything that is app related and may expose the code). Make sure the app code is not accessible from the outside.
A composer.json scaffold for your project. Run composer update every time a new class is added, or use psr-4 in autoload section while you develop the app, whatever you prefer most.
Now point your browser to app address. It should print \"Work in Progress...\" with status code 200.
From here on add more routes and resources to your API, but keep in mind that using closures as resources is NOT the recommended way to build the application. For more on this please follow the documentation further.
The configuration object is created by setting the config directives in the Koded\\Framework\\App constructor.
Argument Type Required Default modules array no [] A list of DIModules for the app middleware array no [] The app middleware stack config object, string no '' A path to a config file, FQCN of the configuration class, or an instance of a config object renderer string no 'start_response' Response renderer function/method
All directives are optional.
<?php\n\nnew App(\n modules: [\n // a list of DIModule implementation(s)\n ],\n middleware: [\n // a list of PSR-15 middleware classes (global)\n ],\n config: __DIR__ . '/path/to/my/config.php', \n // or\n config: '.env', \n // or\n config: new MyConfig(),\n\n renderer: MyRenderer::class,\n // or\n renderer: 'my_renderer_function'\n);\n
A custom renderer for the processed ResponseInterface object. This method/function is executed by the DI container, meaning the depencencies can be anything that the container is able to resolve.
The purpose of this class method (or function) is to provide a custom processing of the ServerRequestInterface and ResponseInterface objects BEFORE it is finally sent to the client, for example a custom-made HTML renderer for server-side template engines, or a response streaming, etc.
The purpose of this feature is to setup the DI container in your app.\n
Once your app stops being \"Hello World\" and assuming you are going to follow some SOLID principles (or maybe not), the application may end up with lots of interfaces and concrete implementations. All of them can be mapped in the app module.
Koded Container supports multiple modules, but one is sufficient for the container's configuration. Again, it is up to you how you are going to structure the application, so sometimes it makes sense to create multiple modules.
Lets say you want to provide a database for the auth backend instance. Because Koded already has one registered by default (Koded\\Framework\\Auth\\SessionAuthBackend) you can easily configure it in your DI module.
<?php\n\n# /opt/my-app/MyAppModule.php\n\nnamespace My\\App;\n\nuse Koded\\{DIContainer, DIModule};\nuse Koded\\Framework\\Auth\\AuthBackend;\nuse My\\App\\Auth\\DatabaseAuth;\n\nclass MyAppModule implements DIModule {\n\n public function configure(DIContainer $container): void\n {\n $container->bind(AuthBackend::class, DatabaseAuth::class);\n }\n}\n
Out of the box Koded offers a curated list with common middleware functionality. The developers are encouraged to create their own (or use existing) PSR-15 middlewares to enhance the application features.
CORS config directives will set the global behavior of the middleware. For example, if cors.methods has a value of GET, POST then only these two methods are allowed for all CORS requests. The same applies to all settings.
Directive Type Default cors.origin string (empty) The server origin address as in schema://host:port (if the port is not a standard port) cors.methods string (empty) Comma-separated list of supported HTTP methods cors.headers string (empty) Comma-separated list of supported headers cors.expose string Authorization, X-Forwarded-With Comma-separated list of exposed headers cors.maxAge int 0 max-age header for OPTIONS request (before the actual request is called) cors.disable bool false This directive will completely disable the middleware"},{"location":"middleware/psr-15/","title":"Middleware stack","text":"
The PSR-15 method signature for processing the incoming server request is very simple:
process(request, handler): response\n
request is the server side incoming request object, handler is the object that receive the request, do some work and returns a response.
It is important to keep in mind when creating a custom middleware class for your app, where the processing of the ServerRequestInterface and ResponseInterface instances will take place.
when request object (ServerRequestInterface) is passed into the first middleware in the stack, it propagates forward through all middleware classes by modifying the instance,
up to the point where the middleware classes are exhausted, then request object enters the Resource
at this point the request object has been modified by all middleware classes in the stack
once the Resource object return the ResponseInterface instance, it continue to propagate backwards through the middleware stack, now modifying the response object
and finally response exits the middleware stack, to be processed by the Koded renderer and sent back to the caller (ex. browser)
<?php\n\nnamespace My\\App\\Middleware;\n\nuse Psr\\Http\\Message\\{ResponseInterface, ServerRequestInterface};\nuse Psr\\Http\\Server\\{MiddlewareInterface, RequestHandlerInterface};\n\nclass MyMiddleware implements MiddlewareInterface {\n\n public function process(\n ServerRequestInterface $request, \n RequestHandlerInterface $handler): ResponseInterface\n {\n // --> Everything here is about the $request object\n\n $response = $handler->handle($request);\n\n // <-- Everything here is about the $response object\n\n return $response;\n }\n}\n
Lets set a random string for the request and pass it in the response header:
<?php\n\nnamespace My\\App\\Middleware;\n\nuse Psr\\Http\\Message\\{ResponseInterface, ServerRequestInterface};\nuse Psr\\Http\\Server\\{MiddlewareInterface, RequestHandlerInterface};\n\nclass RequestIdMiddleware implements MiddlewareInterface {\n\n public function process(\n ServerRequestInterface $request, \n RequestHandlerInterface $handler): ResponseInterface\n {\n $request = $request\n ->withAttribute('req-id', bin2hex(random_bytes(8)));\n\n // [NOTE]: the next middleware (or the resource object)\n // will have the ID in the request \"attributes\" property \n\n $response = $handler->handle($request);\n\n return $response\n ->withHeader('X-Req-ID', $request->getAttribute('req-id'));\n }\n}\n
is a list of middleware classes/objects for this particular route.
This argument solves the need to attach any functionalities with middlewares to the route. A good example is to provide an AuthMiddleware to protect the route(s) with authentication/authorization logic:
This list of middlewares is an additional list that is merged with each route in the $routes list and differ from the $middleware list in the route method in this manner.
The URI parameters are named variables wrapped with curly braces {} in the URI template string.
->route('/{param1}/{param2}/{param3}/...')\n
If the URI matches the route template, the values of the parameters will be stored in the Psr\\Http\\Message\\ServerRequestInterface@attributes and available through the request object with the getAttribute() method
<?php\n\n public function put(ServerRequestInterface $request) {\n $param1 = $request->getAttribute('param1');\n $param2 = $request->getAttribute('param2');\n $param3 = $request->getAttribute('param3');\n ...\n }\n
->route('/{ident:uuid}')\n\n // ie. \"/7eacf466-321f-4ceb-914e-e525987e7804\" \n // the value is STRING ('ident' => '7eacf466-321f-4ceb-914e-e525987e7804')\n
The recommended translation editor is Poedit that supports this kind of translations."},{"location":"translation/formatters/","title":"Formatters","text":"
String formatters are used to replace the translation arguments provided in the __(string, arguments) function. The default formatter is DefaultFormatter and it's set in the Koded DIModule.
Choose one
Once you start with translations, the format of the strings with arguments matters, because the argument replacement is different for DefaultFormatter and StrtrFormatter.
The (app) caching is bolted-in and always on. The default cache library is Koded Simple Cache.
Application caching
The cache functionality is available in the user app by simply demanding an instance of PSR-16 Psr\\SimpleCache\\CacheInterface instance. The DI container will inject the configured cache client.
<?php\n\n...\n public function something(CacheInterface $cache) {\n // ...\n }\n...\n
Default cache is Memory and does not require a special treatment. It will provide caching for the duration of the request which is useful for development and unit testing.
Memory (default)
No need to set anything in the configuration. This is the default caching client.
The conf key loggers is a list of Koded\\Logging\\Log log processor implementations. By default only one log processor is registered that processes all log levels.
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"The Koded Web Framework","text":""},{"location":"#why","title":"Why?","text":"
Sometimes we want a prototype, or quick/simple operations, or solutions for building fast web APIs and app backends. And having a full-blown frameworks will eventually weight you down with tons of unnecessary abstractions and dependencies.
Koded offers small footprint with a clean design that follows the HTTP and ReST architectural style. It tends to be very fast and easy to work with.
Koded Framework follows the RMR web architectural pattern, but the developer is free to use whatever it prefers and does not enforce any programming patterns in the application.
However, it is strongly recommended adopting and using RMR because it is aligned nicely with the HTTP ReST concepts. After all, web apps needs fundamental directions and principles, not \"perfect\" solutions so RMR fits here very well.
Resource
An object in the RESTful system identified by a URL that exposes methods that corresponds to the standard HTTP methods (GET, POST, PUT, etc) i.e. a business object (entity).
Method
The HTTP request method that corresponds a Resource method that is executed by the request/URL, which returns a Representation for that resource.
Representation
Provides a Resource to clients in a readable format (JSON, XML, PDF, HTML, etc). It is the payload of the response object (processed by the HTTP Method that is sent back to the client).
"},{"location":"default-dependencies/","title":"Default framework dependencies","text":""},{"location":"default-dependencies/#framework-di-module","title":"Framework DI module","text":"
Anything that's bound by the default DI module can be replaced with custom implementation(s) in your application DI module(s). The default classes are from the Koded libraries.
By default, the following exceptions are caught and handled
\\Exception
\\Error
Koded\\Http\\HTTPError
The error response payload follows the RFC-7807 specification.
If you wish to capture specific exception types and/or return custom error messages, create your own class and register it with the method App::withErrorHandler() to convert the exceptions into the desired HTTP responses.
handle() method signature
handle(request, response, exception): void
If app does not use 3rd party PSR-7 library, then Koded will use its own implementations from the Koded HTTP library.
<?php\n\n# CustomExceptionHandler.php\n\nuse Koded\\Framework\\App;\nuse Koded\\Http\\HTTPError;\nuse Koded\\Http\\Interfaces\\{Request, Response};\n\nclass CustomExceptionHandler {\n\n public static function handle(\n Request $request,\n Response $response,\n HTTPError $exception): void\n {\n // do something with $exception\n // i.e. re-format the error message and set it in the response\n }\n}\n
Order matters. It is required to register the custom exception handlers BEFORE the routes, otherwise they won't be handled if the request/route has been resolved.
It is up to you how you're going to structure your project. A simple and clear structuring is essential for great development, on a long run (or short too), but that is up to developer needs, or based on the app complexity, team decisions, or various other reasons.
Let's look at something that is good in general as a startup,
Everything regarding your application goes into the app/ folder. This is an example, app is not a requirement and it can be anything you want.
Protect your code!
It is important to keep everything outside the html/ folder (app/, vendor/ or anything that is app related and may expose the code). Make sure the app code is not accessible from the outside.
A composer.json scaffold for your project. Run composer update every time a new class is added, or use psr-4 in autoload section while you develop the app, whatever you prefer most.
Now point your browser to app address. It should print \"Work in Progress...\" with status code 200.
From here on add more routes and resources to your API, but keep in mind that using closures as resources is NOT the recommended way to build the application. For more on this please follow the documentation further.
The configuration object is created by setting the config directives in the Koded\\Framework\\App constructor.
Argument Type Required Default modules array no [] A list of DIModules for the app middleware array no [] The app middleware stack config object, string no '' A path to a config file, FQCN of the configuration class, or an instance of a config object renderer string no 'start_response' Response renderer function/method
All directives are optional.
<?php\n\nnew App(\n modules: [\n // a list of DIModule implementation(s)\n ],\n middleware: [\n // a list of PSR-15 middleware classes (global)\n ],\n config: __DIR__ . '/path/to/my/config.php', \n // or\n config: '.env', \n // or\n config: new MyConfig(),\n\n renderer: MyRenderer::class,\n // or\n renderer: 'my_renderer_function'\n);\n
A custom renderer for the processed ResponseInterface object. This method/function is executed by the DI container, meaning the depencencies can be anything that the container is able to resolve.
The purpose of this class method (or function) is to provide a custom processing of the ServerRequestInterface and ResponseInterface objects BEFORE it is finally sent to the client, for example a custom-made HTML renderer for server-side template engines, or a response streaming, etc.
The purpose of this feature is to setup the DI container in your app.\n
Once your app stops being \"Hello World\" and assuming you are going to follow some SOLID principles (or maybe not), the application may end up with lots of interfaces and concrete implementations. All of them can be mapped in the app module.
Koded Container supports multiple modules, but one is sufficient for the container's configuration. Again, it is up to you how you are going to structure the application, so sometimes it makes sense to create multiple modules.
Lets say you want to provide a database for the auth backend instance. Because Koded already has one registered by default (Koded\\Framework\\Auth\\SessionAuthBackend) you can easily configure it in your DI module.
<?php\n\n# /opt/my-app/MyAppModule.php\n\nnamespace My\\App;\n\nuse Koded\\{DIContainer, DIModule};\nuse Koded\\Framework\\Auth\\AuthBackend;\nuse My\\App\\Auth\\DatabaseAuth;\n\nclass MyAppModule implements DIModule {\n\n public function configure(DIContainer $container): void\n {\n $container->bind(AuthBackend::class, DatabaseAuth::class);\n }\n}\n
Out of the box Koded offers a curated list with common middleware functionality. The developers are encouraged to create their own (or use existing) PSR-15 middlewares to enhance the application features.
CORS config directives will set the global behavior of the middleware. For example, if cors.methods has a value of GET, POST then only these two methods are allowed for all CORS requests. The same applies to all settings.
Directive Type Default cors.origin string (empty) The server origin address as in schema://host:port (if the port is not a standard port) cors.methods string (empty) Comma-separated list of supported HTTP methods cors.headers string (empty) Comma-separated list of supported headers cors.expose string Authorization, X-Forwarded-With Comma-separated list of exposed headers cors.maxAge int 0 max-age header for OPTIONS request (before the actual request is called) cors.disable bool false This directive will completely disable the middleware"},{"location":"middleware/psr-15/","title":"Middleware stack","text":"
The PSR-15 method signature for processing the incoming server request is very simple:
process(request, handler): response\n
request is the server side incoming request object, handler is the object that receive the request, do some work and returns a response.
It is important to keep in mind when creating a custom middleware class for your app, where the processing of the ServerRequestInterface and ResponseInterface instances will take place.
when request object (ServerRequestInterface) is passed into the first middleware in the stack, it propagates forward through all middleware classes by modifying the instance,
up to the point where the middleware classes are exhausted, then request object enters the Resource
at this point the request object has been modified by all middleware classes in the stack
once the Resource object return the ResponseInterface instance, it continue to propagate backwards through the middleware stack, now modifying the response object
and finally response exits the middleware stack, to be processed by the Koded renderer and sent back to the caller (ex. browser)
<?php\n\nnamespace My\\App\\Middleware;\n\nuse Psr\\Http\\Message\\{ResponseInterface, ServerRequestInterface};\nuse Psr\\Http\\Server\\{MiddlewareInterface, RequestHandlerInterface};\n\nclass MyMiddleware implements MiddlewareInterface {\n\n public function process(\n ServerRequestInterface $request, \n RequestHandlerInterface $handler): ResponseInterface\n {\n // --> Everything here is about the $request object\n\n $response = $handler->handle($request);\n\n // <-- Everything here is about the $response object\n\n return $response;\n }\n}\n
Lets set a random string for the request and pass it in the response header:
<?php\n\nnamespace My\\App\\Middleware;\n\nuse Psr\\Http\\Message\\{ResponseInterface, ServerRequestInterface};\nuse Psr\\Http\\Server\\{MiddlewareInterface, RequestHandlerInterface};\n\nclass RequestIdMiddleware implements MiddlewareInterface {\n\n public function process(\n ServerRequestInterface $request, \n RequestHandlerInterface $handler): ResponseInterface\n {\n $request = $request\n ->withAttribute('req-id', bin2hex(random_bytes(8)));\n\n // [NOTE]: the next middleware (or the resource object)\n // will have the ID in the request \"attributes\" property \n\n $response = $handler->handle($request);\n\n return $response\n ->withHeader('X-Req-ID', $request->getAttribute('req-id'));\n }\n}\n
is a list of middleware classes/objects for this particular route.
This argument solves the need to attach any functionalities with middlewares to the route. A good example is to provide an AuthMiddleware to protect the route(s) with authentication/authorization logic:
This list of middlewares is an additional list that is merged with each route in the $routes list and differ from the $middleware list in the route method in this manner.
The URI parameters are named variables wrapped with curly braces {} in the URI template string.
->route('/{param1}/{param2}/{param3}/...')\n
If the URI matches the route template, the values of the parameters will be stored in the Psr\\Http\\Message\\ServerRequestInterface@attributes and available through the request object with the getAttribute() method
<?php\n\n public function put(ServerRequestInterface $request) {\n $param1 = $request->getAttribute('param1');\n $param2 = $request->getAttribute('param2');\n $param3 = $request->getAttribute('param3');\n ...\n }\n
->route('/{ident:uuid}')\n\n // ie. \"/7eacf466-321f-4ceb-914e-e525987e7804\" \n // the value is STRING ('ident' => '7eacf466-321f-4ceb-914e-e525987e7804')\n
The recommended translation editor is Poedit that supports this kind of translations."},{"location":"translation/formatters/","title":"Formatters","text":"
String formatters are used to replace the translation arguments provided in the __(string, arguments) function. The default formatter is DefaultFormatter and it's set in the Koded DIModule.
Choose one
Once you start with translations, the format of the strings with arguments matters, because the argument replacement is different for DefaultFormatter and StrtrFormatter.
The (app) caching is bolted-in and always on. The default cache library is Koded Simple Cache.
Application caching
The cache functionality is available in the user app by simply demanding an instance of PSR-16 Psr\\SimpleCache\\CacheInterface instance. The DI container will inject the configured cache client.
<?php\n\n...\n public function something(CacheInterface $cache) {\n // ...\n }\n...\n
Default cache is Memory and does not require a special treatment. It will provide caching for the duration of the request which is useful for development and unit testing.
Memory (default)
No need to set anything in the configuration. This is the default caching client.
The conf key loggers is a list of Koded\\Logging\\Log log processor implementations. By default only one log processor is registered that processes all log levels.
"}]}
\ No newline at end of file
diff --git a/shared-instances/index.html b/shared-instances/index.html
index ea69074..d283135 100644
--- a/shared-instances/index.html
+++ b/shared-instances/index.html
@@ -1 +1 @@
- Shared instances - Koded Framework
String formatters are used to replace the translation arguments provided in the __(string, arguments) function. The default formatter is DefaultFormatter and it's set in the Koded DIModule.
Choose one
Once you start with translations, the format of the strings with arguments matters, because the argument replacement is different for DefaultFormatter and StrtrFormatter.
String formatters are used to replace the translation arguments provided in the __(string, arguments) function. The default formatter is DefaultFormatter and it's set in the Koded DIModule.
Choose one
Once you start with translations, the format of the strings with arguments matters, because the argument replacement is different for DefaultFormatter and StrtrFormatter.
The (app) caching is bolted-in and always on. The default cache library is Koded Simple Cache.
Application caching
The cache functionality is available in the user app by simply demanding an instance of PSR-16 Psr\SimpleCache\CacheInterface instance. The DI container will inject the configured cache client.
The (app) caching is bolted-in and always on. The default cache library is Koded Simple Cache.
Application caching
The cache functionality is available in the user app by simply demanding an instance of PSR-16 Psr\SimpleCache\CacheInterface instance. The DI container will inject the configured cache client.
The conf key loggers is a list of Koded\Logging\Log log processor implementations. By default only one log processor is registered that processes all log levels.
\ No newline at end of file
+
The conf key loggers is a list of Koded\Logging\Log log processor implementations. By default only one log processor is registered that processes all log levels.