An Internationalized Resource Identifier (IRI) is an extended version of a Uniform Resource Identifier (URI) that supports Unicode characters beyond the ASCII character set. This allows non-Latin scripts (e.g., Chinese, Arabic, Cyrillic) and special characters to be used in web addresses and other identifiers.

Key Features of IRIs:

1. Unicode Support: While URIs are limited to ASCII characters (A-Z, 0-9, -, ., _), IRIs allow characters from the entire Unicode character set.
2. Backward Compatibility: Every IRI can be converted into a URI by encoding non-ASCII characters into Punycode or percent-encoded format.
3. Use in Web Technologies: IRIs enable internationalized domain names (IDNs), paths, and query parameters in URLs, making the web more accessible for non-English languages.

Example:

• IRI: https://de.wikipedia.org/wiki/Überblick
• Equivalent URI: https://de.wikipedia.org/wiki/%C3%9Cberblick
  (Here, Ü is encoded as %C3%9C)

Standardization:

IRIs are defined in RFC 3987 and are supported in modern web technologies like HTML5, XML, and RDF.

Conclusion:

IRIs make the internet more linguistically inclusive by allowing websites and resources to be referenced using non-Latin characters, improving accessibility worldwide.

A SUT (System Under Test) is the system or component being tested in a testing process. The term is commonly used in software development and quality assurance.

Meaning and Application:

• In software testing, the SUT refers to the entire program, a single module, or a specific function being tested.
• In hardware testing, the SUT could be an electronic device or a machine under examination.
• In automated testing, the SUT is often tested using frameworks and tools to identify errors or unexpected behavior.

A typical testing process includes:

1. Defining test cases based on requirements.
2. Executing tests on the SUT.
3. Reviewing test results and comparing them with expected outcomes.

The Whoops PHP library is a powerful and user-friendly error handling tool for PHP applications. It provides clear and well-structured error pages, making it easier to debug and fix issues.

Key Features of Whoops

✅ Beautiful, interactive error pages
✅ Detailed stack traces with code previews
✅ Easy integration into existing PHP projects
✅ Support for various frameworks (Laravel, Symfony, Slim, etc.)
✅ Customizable with custom handlers and loggers

Installation

You can install Whoops using Composer:

composer require filp/whoops

Basic Usage

Here's a simple example of how to enable Whoops in your PHP project:

require 'vendor/autoload.php';

use Whoops\Run;
use Whoops\Handler\PrettyPageHandler;

$whoops = new Run();
$whoops->pushHandler(new PrettyPageHandler());
$whoops->register();

// Trigger an error (e.g., calling an undefined variable)
echo $undefinedVariable;

If an error occurs, Whoops will display a clear and visually appealing debug page.

Customization & Extensions

You can extend Whoops by adding custom error handling, for example:

use Whoops\Handler\CallbackHandler;

$whoops->pushHandler(new CallbackHandler(function ($exception, $inspector, $run) {
    error_log($exception->getMessage());
}));

This version logs errors to a file instead of displaying them.

Use Cases

Whoops is mainly used in development environments to quickly detect and fix errors. However, in production environments, it should be disabled or replaced with a custom error page.

The Fetch API is a modern JavaScript interface for retrieving resources over the network, such as making HTTP requests to an API or loading data from a server. It largely replaces the older XMLHttpRequest method and provides a simpler, more flexible, and more powerful way to handle network requests.

Basic Functionality

• The Fetch API is based on Promises, making asynchronous operations easier.
• It allows fetching data in various formats like JSON, text, or Blob.
• By default, Fetch uses the GET method but also supports POST, PUT, DELETE, and other HTTP methods.

Simple Example

fetch('https://jsonplaceholder.typicode.com/posts/1')
  .then(response => response.json()) // Convert response to JSON
  .then(data => console.log(data)) // Log the data
  .catch(error => console.error('Error:', error)); // Handle errors

Making a POST Request

fetch('https://jsonplaceholder.typicode.com/posts', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ title: 'New Post', body: 'Post content', userId: 1 })
})
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

Advantages of the Fetch API

✅ Simpler syntax compared to XMLHttpRequest
✅ Supports async/await for better readability
✅ Flexible request and response handling
✅ Better error management using Promises

The Fetch API is now supported in all modern browsers and is an essential technique for web development.

A Single Page Application (SPA) is a web application that runs entirely within a single HTML page. Instead of reloading the entire page for each interaction, it dynamically updates the content using JavaScript, providing a smooth, app-like user experience.

Key Features of an SPA:

• Dynamic Content Loading: New content is fetched via AJAX or the Fetch API without a full page reload.
• Client-Side Routing: Navigation is handled by JavaScript (e.g., React Router or Vue Router).
• State Management: SPAs often use libraries like Redux, Vuex, or Zustand to manage application state.
• Separation of Frontend & Backend: The backend typically serves as an API (e.g., REST or GraphQL).

Advantages:

✅ Faster interactions after the initial load
✅ Improved user experience (no full page reloads)
✅ Offline functionality possible via Service Workers

Disadvantages:

❌ Initial load time can be slow (large JavaScript bundle)
❌ SEO challenges (since content is often loaded dynamically)
❌ More complex implementation, especially for security and routing

Popular frameworks for SPAs include React, Angular, and Vue.js.

CSS Media Queries are a technique in CSS that allows a webpage layout to adapt to different screen sizes, resolutions, and device types. They are a core feature of Responsive Web Design.

Syntax:

@media (condition) {
    /* CSS rules that apply only under this condition */
}

Examples:

1. Adjusting for different screen widths:

/* For screens with a maximum width of 600px (e.g., smartphones) */
@media (max-width: 600px) {
    body {
        background-color: lightblue;
    }
}

2. Detecting landscape vs. portrait orientation:

@media (orientation: landscape) {
    body {
        background-color: lightgreen;
    }
}

3. Styling for print output:

@media print {
    body {
        font-size: 12pt;
        color: black;
        background: none;
    }
}

Common Use Cases:

✅ Mobile-first design: Optimizing websites for small screens first and then expanding for larger screens.
✅ Dark mode: Adjusting styles based on user preference (prefers-color-scheme).
✅ Retina displays: Using high-resolution images or specific styles for high pixel density screens (min-resolution: 2dppx).

A Bearer Token is a type of access token used for authentication and authorization in web applications and APIs. The term "Bearer" means "holder," which implies that anyone in possession of the token can access protected resources—without additional verification.

Characteristics of a Bearer Token:

• Self-contained: It includes all necessary authentication information.
• No additional identity check: Whoever holds the token can use it.
• Sent in HTTP headers: Typically as Authorization: Bearer <token>.
• Often time-limited: Tokens have expiration times to reduce misuse.
• Commonly used with OAuth 2.0: For example, when authenticating with third-party services.

Example of an HTTP request with a Bearer Token:

GET /protected-data HTTP/1.1
Host: api.example.com
Authorization: Bearer abcdef123456

Risks:

• No protection if stolen: If someone intercepts the token, they can impersonate the user.
• Must be securely stored: Should not be exposed in client-side code or URLs.

💡 Tip: To enhance security, use short-lived tokens and transmit them only over HTTPS.

OAuth (Open Authorization) is an open standard protocol for authorization that allows applications to access a user's resources without knowing their credentials (e.g., password). It is commonly used for Single Sign-On (SSO) and API access.

How Does OAuth Work?

OAuth operates using tokens, which allow an application to access a user's data on their behalf. The typical flow is as follows:

1. Authorization Request: An application (client) requests access to a user’s protected data (e.g., Facebook contacts).
2. User Authentication: The user is redirected to the provider's login page (e.g., Google, Facebook) and enters their credentials.
3. Permission Granting: The user confirms that the application can access specific data.
4. Token Issuance: The application receives an access token, which grants permission to access the approved data.
5. Resource Access: The application uses the token to make requests to the API server without needing the user's password.

OAuth 1.0 vs. OAuth 2.0

• OAuth 1.0: More complex, uses cryptographic signatures but is secure.
• OAuth 2.0: Simpler, relies on HTTPS for security, and is the most commonly used version today.

Real-World Uses of OAuth

• "Sign in with Google/Facebook/Apple" buttons
• Third-party apps accessing Google Drive, Dropbox, or Twitter APIs
• Payment services like PayPal integrating with other apps

What is Twig?

Twig is a powerful and flexible templating engine for PHP, commonly used in Symfony but also in other PHP projects. It helps separate logic from presentation and offers many useful features for frontend development.

Key Features of Twig

1. Simple Syntax with Placeholders ({{ }})

Twig uses double curly braces to output variables:

<p>Hello, {{ name }}!</p>

→ If name = "Max", the output will be:
"Hello, Max!"

2. Control Structures ({% %})

Twig supports if-else statements, loops, and other control structures.

If-Else

{% if user.isAdmin %}
    <p>Welcome, Admin!</p>
{% else %}
    <p>Welcome, User!</p>
{% endif %}

Loops (for)

<ul>
{% for user in users %}
    <li>{{ user.name }}</li>
{% endfor %}
</ul>

3. Template Inheritance

Twig supports "Base Layouts", similar to Laravel's Blade.

Parent Template (base.html.twig)

<!DOCTYPE html>
<html>
<head>
    <title>{% block title %}My Page{% endblock %}</title>
</head>
<body>
    <header>{% block header %}Default Header{% endblock %}</header>
    <main>{% block content %}{% endblock %}</main>
</body>
</html>

Child Template (page.html.twig)

{% extends 'base.html.twig' %}

{% block title %}Homepage{% endblock %}

{% block content %}
    <p>Welcome to my website!</p>
{% endblock %}

→ The blocks override the default content from the base template.

4. Including Templates

You can include reusable components like a navbar or footer:

{% include 'partials/navbar.html.twig' %}

5. Filters & Functions

Twig provides many filters to format content:

6. Security & Escaping

Twig automatically escapes HTML to prevent XSS attacks:

{{ "<script>alert('XSS');</script>" }}

→ Outputs: <script>alert('XSS');</script>

To output raw HTML, use |raw:

{{ "<strong>Bold</strong>"|raw }}

7. Extensibility

• Twig supports custom filters & functions.
• You can use PHP objects and arrays directly inside Twig.

The View in Model-View-Controller (MVC)

The View is the presentation layer in the MVC architecture. It is responsible for displaying data from the Model in a user-friendly format.

Main Responsibilities of the View

✅ Displaying Data: Shows information from the Model (e.g., a list of blog posts).
✅ Reacting to User Interactions: Accepts user input and sends it to the Controller.
✅ Formatting & Layout: Structures content using HTML, CSS, or templating engines (e.g., Laravel Blade or Twig).
✅ Avoiding Business Logic: Contains only presentation logic, not data processing.

How Does the View Work in MVC?

1. The user sends a request (e.g., "Show all blog posts").
2. The Controller calls the Model to retrieve the data.
3. The Model returns the required data.
4. The View receives the data from the Controller and displays it.

Example: Blog System (View in Laravel Blade)

<!-- resources/views/blog/index.blade.php -->
@extends('layouts.app')

@section('content')
    <h1>Blog Posts</h1>
    @foreach ($posts as $post)
        <div>
            <h2>{{ $post->title }}</h2>
            <p>{{ $post->content }}</p>
        </div>
    @endforeach
@endsection

🔹 @foreach: Loops through the list of blog posts and displays them.
🔹 {{ $post->title }}: Outputs the title of the blog post.

Conclusion

✔ The View is responsible for presentation but does not process data.
✔ It ensures a clear separation between logic and display.
✔ Using templates or frontend technologies (e.g., Vue.js, React), the View can be dynamically rendered.