# თავი 3: ინტერაქტიული ვებ აპლიკაციების შექმნა

---

## 3.1 ჩვენებიდან (Display) ინტერაქციამდე

პირველ ორ თავში ჩვენ ავაშენეთ გვერდები, რომლებიც აჩვენებენ ინფორმაციას — სტატიკური კონტენტი, შაბლონის მიერ დარენდერებული განლაგებები (layouts) და controller-ებიდან model-ის მეშვეობით გადაცემული მონაცემები. მომხმარებელს შეეძლო კონტენტის ნახვა, მაგრამ არ შეეძლო უკან რაიმეს გაგზავნა. თუმცა, ნამდვილი ვებ აპლიკაცია არის საუბარი: მომხმარებელი აგზავნის (submits) მონაცემებს, სერვერი ამუშავებს მათ და აპლიკაცია შესაბამისად პასუხობს.

ეს თავი წარმოგიდგენთ მექანიზმებს, რომლებიც ამ საუბარს შესაძლებელს ხდის. ჩვენ ვისწავლით, თუ როგორ დავამუშავოთ ფორმის გაგზავნა (form submissions), დავაკავშიროთ ფორმის მონაცემები Java ობიექტებთან, გადავამოწმოთ მომხმარებლის მიერ შეყვანილი მონაცემები სერვერის მხარეს, ვაჩვენოთ ვალიდაციის შეცდომები მომხმარებელს, დავამუშავოთ ფაილების ატვირთვა და ავიცილოთ თავიდან დუბლირებული გაგზავნის პრობლემა Post/Redirect/Get პატერნით. ჩვენ ასევე შევქმნით შეცდომის (error) მორგებულ გვერდებს.

ამ თავში ფორმის ყველა რენდერინგი იყენებს **Spring-ის ჩაშენებულ FreeMarker მაკროებს** — `spring.ftl` ბიბლიოთეკას, რომელსაც პირველ თავში შევხვდით URL-ების გენერირებისთვის. ეს მაკროები უზრუნველყოფენ ფორმის დაკავშირებას (form binding), input-ების გენერაციას და შეცდომების ჩვენებას, რაც პირდაპირ ინტეგრირდება Spring MVC-ის data binding-ისა და ვალიდაციის ინფრასტრუქტურასთან.

---

## 3.2 HTTP GET და POST მოთხოვნების დამუშავება

ვებ აპლიკაციასთან ნებისმიერი ინტერაქცია იწყება HTTP მოთხოვნით (request). ფორმაზე დაფუძნებულ ვებ აპლიკაციებში დომინირებს მოთხოვნის ორი მეთოდი:

**GET** მოთხოვნები იღებენ (retrieve) მონაცემებს. როდესაც გადადიხართ URL-ზე, აკლიკებთ ბმულს ან კრეფთ მისამართს ბრაუზერის ველში, იგზავნება GET მოთხოვნა. GET მოთხოვნებმა არასოდეს უნდა შეცვალოს მონაცემები — ისინი უსაფრთხო და იდემპოტენტურია.

**POST** მოთხოვნები აგზავნიან (submit) მონაცემებს. როდესაც ავსებთ ფორმას და აკლიკებთ "Submit"-ს, იგზავნება POST მოთხოვნა, რომლის ტანშიც (body) მოთავსებულია ფორმის მონაცემები. POST მოთხოვნები, როგორც წესი, ქმნიან ან ცვლიან რესურსს სერვერზე.

Spring MVC-ში, handler მეთოდები `@Controller` კლასში უკავშირდება კონკრეტულ HTTP მეთოდებს `@GetMapping` და `@PostMapping` ანოტაციების გამოყენებით:

```java
@Controller
public class ProductController {

    private final ProductService productService;

    public ProductController(ProductService productService) {
        this.productService = productService;
    }

    @GetMapping("/products")
    public String listProducts(Model model) {
        model.addAttribute("products", productService.findAll());
        return "products/list";
    }

    @PostMapping("/products")
    public String createProduct(@ModelAttribute Product product) {
        productService.save(product);
        return "redirect:/products";
    }
}
```

ერთი და იგივე URL — `/products` — მუშავდება ორი განსხვავებული მეთოდის მიერ. Spring ანაწილებს მოთხოვნას სწორ მეთოდზე HTTP მეთოდის საფუძველზე. GET handler იღებს მონაცემებს და არენდერებს შაბლონს. POST handler ამუშავებს გამოგზავნილ ფორმის მონაცემებს და აკეთებს გადამისამართებას (redirect) (თუ რატომ აკეთებს გადამისამართებას პირდაპირ რენდერინგის ნაცვლად, განვიხილავთ 3.8 სექციაში).

---

## 3.3 ფორმების აშენება Spring-ის FreeMarker მაკროებით

ისეთი HTML ფორმის ასაშენებლად, რომელიც ინტეგრირდება Spring MVC-ის data binding-თან, ჩვენ ვიყენებთ `spring.ftl`-ში განსაზღვრულ მაკროებს. ეს მაკროები აგენერირებენ ფორმის input ელემენტებს, რომლებიც ავტომატურად უკავშირდებიან (bound) მოდელში არსებულ ფორმის დამხმარე ობიექტს (form-backing object, რომელსაც ასევე უწოდებენ "command object").

### ფორმის მომზადება Controller-ში

სანამ ფორმა დარენდერდება, GET handler-მა მოდელში უნდა დაამატოს ცარიელი ობიექტი. ეს არის ის ობიექტი, რომელთანაც Spring დააკავშირებს ფორმის ველებს:

```java
@GetMapping("/products/new")
public String showCreateForm(Model model) {
    model.addAttribute("product", new Product());
    return "products/create";
}
```

გასაღები `"product"` არის სახელი, რომლითაც ცნობილია ფორმის დამხმარე ობიექტი. შაბლონში, ფორმის მაკროს ყველა გზა (path) დაიწყება ამ სახელით.

### ფორმის შაბლონი (The Form Template)

აი სრული ფორმა, რომელიც იყენებს Spring-ის FreeMarker მაკროებს:

```html
<#import "/spring.ftl" as spring>
<#import "layout.ftlh" as layout>

<@layout.page title="Create Product">
    <h1>Create a New Product</h1>

    <form action="<@spring.url '/products'/>" method="post">
        <div>
            <label for="name">Name:</label>
            <@spring.formInput "product.name" 'id="name" class="form-control"'/>
            <@spring.showErrors "<br>" "error"/>
        </div>

        <div>
            <label for="price">Price:</label>
            <@spring.formInput "product.price" 'id="price" class="form-control"' "number"/>
            <@spring.showErrors "<br>" "error"/>
        </div>

        <div>
            <label for="description">Description:</label>
            <@spring.formTextarea "product.description" 'id="description" rows="5" class="form-control"'/>
            <@spring.showErrors "<br>" "error"/>
        </div>

        <button type="submit">Create Product</button>
    </form>
</@layout.page>
```

მოდით დავშალოთ, თუ რა ხდება აქ.

`<@spring.formInput "product.name" 'id="name" class="form-control"'/>` აგენერირებს `<input type="text">` ელემენტს. პირველი არგუმენტი — `"product.name"` — არის **გზა (path)**: ფორმის დამხმარე ობიექტის სახელი (`product`), რომელსაც მოსდევს ველის სახელი (`name`). მაკრო უკავშირდება ამ გზას, რაც იმას ნიშნავს, რომ ის შეავსებს input-ის `value` ატრიბუტს ობიექტის `name` property-დან, და დაარქმევს სახელს input-ს ისე, რომ გამოგზავნილი მონაცემები უკან დაუკავშირდეს ამ property-ს. მეორე არგუმენტი არის დამატებითი HTML ატრიბუტების სტრიქონი, რომლებიც უნდა ჩაირთოს გენერირებულ ტეგში.

`<@spring.formInput "product.price" '...' "number"/>` აჩვენებს არასავალდებულო მესამე არგუმენტს — ველის ტიპს. `"number"`-ის გადაცემით, მაკრო ნაგულისხმევი text input-ის ნაცვლად აგენერირებს `<input type="number">`-ს. აქ ასევე შეგიძლიათ გადასცეთ `"hidden"` ან `"password"`.

`<@spring.formTextarea "product.description" '...'/>` აგენერირებს `<textarea>` ელემენტს, რომელიც დაკავშირებულია `description` ველთან.

`<@spring.showErrors "<br>" "error"/>` აჩვენებს ვალიდაციის შეცდომებს ბოლოს დაკავშირებული ველისთვის. პირველი არგუმენტი არის გამყოფი მრავალ შეცდომის შეტყობინებას შორის. მეორე არგუმენტი არის CSS კლასის სახელი, რომელიც მიენიჭება თითოეული შეცდომის შემომფარგვლელ `<span>`-ს. გამოტოვების შემთხვევაში, შეცდომები მის ნაცვლად მოთავსდება `<b>` ტეგებში.

### ხელმისაწვდომი ფორმის მაკროები

Spring-ის `spring.ftl` უზრუნველყოფს შემდეგ მაკროებს ფორმის გენერაციისთვის:

| მაკრო | დანიშნულება |
|-------|---------|
| `<@spring.formInput path attrs fieldType/>` | Text input (ნაგულისხმევი), ან number/hidden/password `fieldType`-ის მეშვეობით. |
| `<@spring.formTextarea path attrs/>` | მრავალხაზიანი ტექსტის არე. |
| `<@spring.formPasswordInput path attrs/>` | Password input (არასოდეს ივსება წინასწარ). |
| `<@spring.formHiddenInput path attrs/>` | Hidden (დამალული) input. |
| `<@spring.formSingleSelect path options attrs/>` | ჩამოსაშლელი სია (select) (ერთი მნიშვნელობა). |
| `<@spring.formMultiSelect path options attrs/>` | მრავალმნიშვნელობიანი არჩევის (multi-select) სია. |
| `<@spring.formRadioButtons path options separator attrs/>` | Radio ღილაკების ჯგუფი. |
| `<@spring.formCheckboxes path options separator attrs/>` | Checkbox-ების ჯგუფი. |
| `<@spring.formCheckbox path attrs/>` | ერთი checkbox-ი. |
| `<@spring.showErrors separator classOrStyle/>` | აჩვენებს ვალიდაციის შეცდომებს ბოლოს დაკავშირებული ველისთვის. |
| `<@spring.message code/>` | გამოაქვს შეტყობინება resource bundle-დან. |
| `<@spring.url relativeUrl/>` | კონტექსტის მცოდნე URL (განხილულია 1-ლ თავში). |

არჩევანის მაკროებისთვის (`formSingleSelect`, `formRadioButtons`, და ა.შ.), `options` პარამეტრი არის `Map`, სადაც გასაღებები (keys) არის ფორმასთან ერთად გაგზავნილი მნიშვნელობები, ხოლო მნიშვნელობები (values) არის მომხმარებლისთვის ნაჩვენები ლეიბლები (labels). ეს map ჩვეულებრივ მოწოდებულია controller-ის მიერ:

```java
@ModelAttribute("categories")
public Map<String, String> populateCategories() {
    Map<String, String> categories = new LinkedHashMap<>();
    categories.put("electronics", "Electronics");
    categories.put("books", "Books");
    categories.put("clothing", "Clothing");
    return categories;
}
```

და გამოყენებულია შაბლონში:

```html
<div>
    <label>Category:</label>
    <@spring.formSingleSelect "product.category" categories 'class="form-control"'/>
    <@spring.showErrors "<br>" "error"/>
</div>
```

---

## 3.4 Data Binding `@ModelAttribute`-ით

როდესაც მომხმარებელი აგზავნის ფორმას, ბრაუზერი აგზავნის POST მოთხოვნას ფორმის ველების მნიშვნელობებით, რომლებიც ინკოდირებულია მოთხოვნის ტანში (request body). Spring MVC ავტომატურად უკავშირებს (maps) ამ მნიშვნელობებს Java ობიექტს პროცესით, რომელსაც ეწოდება **data binding**.

`@ModelAttribute` ანოტაცია მეთოდის პარამეტრზე ეუბნება Spring-ს, შექმნას მითითებული კლასის ინსტანსი, შეავსოს მისი ველები მოთხოვნის პარამეტრებიდან (სახელის დამთხვევის მიხედვით) და გადასცეს ის handler მეთოდს:

```java
@PostMapping("/products")
public String createProduct(@ModelAttribute Product product) {
    // 'product' is automatically populated:
    //   product.name = value from the "name" input
    //   product.price = value from the "price" input
    //   product.description = value from the "description" textarea
    productService.save(product);
    return "redirect:/products";
}
```

დაკავშირება (binding) მუშაობს ფორმის ველების სახელების (რომლებსაც Spring-ის მაკროები სწორად აყენებენ path-ის საფუძველზე) დამთხვევით ობიექტის property-ებთან. Spring ავტომატურად უმკლავდება ტიპების კონვერტაციას — მაგალითად, ის აკონვერტირებს სტრიქონს `"29.99"` ფორმიდან `Double`-ად `price` ველისთვის.

`@ModelAttribute` ასევე შეიძლება გამოყენებულ იქნას მეთოდის დონეზე, რათა დაემატოს ატრიბუტები მოდელს ყოველი მოთხოვნისთვის, რომელსაც ამუშავებს controller. ჩვენ ეს ზემოთ ვნახეთ `populateCategories` მეთოდით — ის ეშვება controller-ის თითოეული handler მეთოდის წინ და ამატებს კატეგორიების map-ს მოდელში.

---

## 3.5 სერვერის მხარის ვალიდაცია Bean Validation-ით

იმის მიღება, რასაც მომხმარებელი აგზავნის შემოწმების გარეშე, არის გზა ცუდი მონაცემებისკენ, გათიშვებისკენ (crashes) და უსაფრთხოების დაუცველობისკენ. სერვერის მხარის ვალიდაცია უზრუნველყოფს, რომ მონაცემები აკმაყოფილებს ჩვენს მოთხოვნებს მის დამუშავებამდე.

Spring Boot მხარს უჭერს **Bean Validation**-ს (Jakarta Validation სპეციფიკაცია, ყოფილი JSR 380) Hibernate Validator-ის იმპლემენტაციის მეშვეობით. მის გამოსაყენებლად, დაამატეთ validation starter-ი თქვენს `pom.xml`-ში:

```xml
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-validation</artifactId>
</dependency>
```

### Model კლასის ანოტირება

ვალიდაციის წესები ცხადდება პირდაპირ თქვენი model კლასის ველებზე ანოტაციების გამოყენებით:

```java
public class Product {

    @NotBlank(message = "Name is required")
    @Size(min = 2, max = 100, message = "Name must be between 2 and 100 characters")
    private String name;

    @NotNull(message = "Price is required")
    @Positive(message = "Price must be positive")
    private Double price;

    @Size(max = 500, message = "Description cannot exceed 500 characters")
    private String description;

    // getters and setters
}
```

ყველაზე ხშირად გამოყენებული ვალიდაციის ანოტაციებია:

| ანოტაცია | წესი |
|------------|------|
| `@NotNull` | არ უნდა იყოს null. |
| `@NotBlank` | არ უნდა იყოს null, ცარიელი ან მხოლოდ whitespace (მხოლოდ სტრიქონებისთვის). |
| `@NotEmpty` | არ უნდა იყოს null ან ცარიელი (სტრიქონებისთვის, კოლექციებისთვის). |
| `@Size(min, max)` | სტრიქონის სიგრძე ან კოლექციის ზომა უნდა იყოს დიაპაზონში. |
| `@Min(value)` / `@Max(value)` | რიცხვითი მნიშვნელობა უნდა აკმაყოფილებდეს საზღვარს. |
| `@Positive` / `@Negative` | უნდა იყოს დადებითი / უარყოფითი რიცხვი. |
| `@Email` | უნდა იყოს ვალიდური ელ. ფოსტის ფორმატი. |
| `@Pattern(regexp)` | უნდა ემთხვეოდეს რეგულარულ გამოსახულებას. |
| `@Past` / `@Future` | თარიღი უნდა იყოს წარსულში / მომავალში. |

### ვალიდაციის გამოძახება Controller-ში

ვალიდაციის გასააქტიურებლად, დაამატეთ `@Valid` `@ModelAttribute` პარამეტრის წინ და ჩართეთ `BindingResult` პარამეტრი უშუალოდ მის შემდეგ:

```java
@PostMapping("/products")
public String createProduct(@Valid @ModelAttribute Product product,
                            BindingResult bindingResult) {
    if (bindingResult.hasErrors()) {
        return "products/create";  // Re-display the form with errors
    }
    productService.save(product);
    return "redirect:/products";
}
```

როდესაც Spring ხვდება `@Valid`-ს, ის ატარებს ყველა ვალიდაციის ანოტაციას ობიექტზე, სანამ handler მეთოდი შესრულდება. თუ რაიმე შეზღუდვა დაირღვა, შეცდომები გროვდება `BindingResult`-ში. handler მეთოდი შემდეგ ამოწმებს `bindingResult.hasErrors()`-ს — თუ არის შეცდომები, ის აბრუნებს ფორმის შაბლონის სახელს (გადამისამართების გარეშე), რაც იწვევს ფორმის ხელახლა რენდერინგს. ვინაიდან ფორმის დამხმარე ობიექტი კვლავ მოდელშია (მომხმარებლის მიერ გაგზავნილი მნიშვნელობებითა და შეცდომებით), Spring-ის მაკროები ხელახლა შეავსებენ ველებს და `<@spring.showErrors>` მაკრო აჩვენებს შეცდომის შეტყობინებებს.

**მნიშვნელოვანია:** `BindingResult` უნდა გამოცხადდეს უშუალოდ `@Valid` პარამეტრის შემდეგ მეთოდის ხელმოწერაში (signature). თუ რაიმე სხვა პარამეტრი გამოჩნდება მათ შორის, Spring ვერ დააკავშირებს შეცდომებს სწორად.

---

## 3.6 ვალიდაციის შეცდომების ჩვენება

`<@spring.showErrors>` მაკრო, რომელიც ჩვენ უკვე გამოვიყენეთ 3.3 სექციაში, არის ძირითადი გზა FreeMarker შაბლონებში ვალიდაციის შეცდომების საჩვენებლად. ის აჩვენებს შეცდომებს იმ ველისთვის, რომელიც ბოლოს დაუკავშირდა (bound) — ანუ, ის ველი, რომელიც გამოყენებულ იქნა ბოლო `<@spring.formInput>`, `<@spring.formTextarea>`, ან მსგავსი მაკროს გამოძახებისას.

აი სრული ფორმა ვალიდაციის შეცდომის ჩვენებით:

```html
<#import "/spring.ftl" as spring>
<#import "layout.ftlh" as layout>

<@layout.page title="Create Product">
    <h1>Create a New Product</h1>

    <form action="<@spring.url '/products'/>" method="post">
        <div class="form-group">
            <label for="name">Name:</label>
            <@spring.formInput "product.name" 'id="name" class="form-control"'/>
            <@spring.showErrors "<br>" "text-danger"/>
        </div>

        <div class="form-group">
            <label for="price">Price:</label>
            <@spring.formInput "product.price" 'id="price" class="form-control"' "number"/>
            <@spring.showErrors "<br>" "text-danger"/>
        </div>

        <div class="form-group">
            <label for="description">Description:</label>
            <@spring.formTextarea "product.description" 'id="description" rows="5" class="form-control"'/>
            <@spring.showErrors "<br>" "text-danger"/>
        </div>

        <button type="submit" class="btn">Create Product</button>
    </form>
</@layout.page>
```

როდესაც ვალიდაცია მარცხდება, `<@spring.showErrors "<br>" "text-danger"/>` გამოძახებები აგენერირებენ ასეთ HTML-ს:

```html
<span class="text-danger">Name is required</span>
```

შეცდომის შეტყობინებები მოდის model კლასზე არსებული ვალიდაციის ანოტაციების `message` ატრიბუტიდან. CSS კლასი (ამ მაგალითში `"text-danger"`) საშუალებას გაძლევთ გააფორმოთ შეცდომის შეტყობინებები, რათა ვიზუალურად გამოირჩეოდეს — ჩვეულებრივ წითლად.

### ყველა შეცდომის ერთდროულად ჩვენება

თუ გირჩევნიათ ყველა შეცდომის შეჯამება აჩვენოთ ფორმის ზედა ნაწილში და არა თითოეული ველის გვერდით, შეგიძლიათ უშუალოდ გამოიყენოთ `<@spring.bind>` მაკრო და გადაუაროთ შეცდომის შეტყობინებებს:

```html
<@spring.bind "product"/>
<#if spring.status.errors?has_content>
    <div class="alert alert-danger">
        <ul>
            <#list spring.status.errors.allErrors as error>
                <li>${error.defaultMessage}</li>
            </#list>
        </ul>
    </div>
</#if>
```

`<@spring.bind "product"/>` მაკრო უკავშირდება ფორმის დამხმარე ობიექტს მთლიანობაში. `spring.status` ობიექტი შემდეგ იძლევა წვდომას ყველა შეცდომაზე ყველა ველისთვის.

---

## 3.7 ფაილების ატვირთვის დამუშავება

ბევრ აპლიკაციას სჭირდება ფაილების ატვირთვის მიღება — პროფილის სურათები, დოკუმენტის დანართები, ყდის სურათები. Spring Boot ამას ამარტივებს `MultipartFile`-ით.

### კონფიგურაცია

დააყენეთ ატვირთვის ზომის ლიმიტები `application.properties`-ში:

```properties
spring.servlet.multipart.max-file-size=10MB
spring.servlet.multipart.max-request-size=10MB
```

### ატვირთვის ფორმა

ფაილის ატვირთვის ფორმებმა უნდა გამოიყენოს `enctype="multipart/form-data"`. რადგან ფაილის input-ები არ უკავშირდება ფორმის დამხმარე ობიექტს ისე, როგორც ტექსტური ველები, ჩვენ ვიყენებთ ჩვეულებრივ HTML-ს ფაილის input-ისთვის:

```html
<form action="<@spring.url '/upload'/>" method="post" enctype="multipart/form-data">
    <div>
        <label for="file">Choose file:</label>
        <input type="file" id="file" name="file"/>
    </div>
    <button type="submit">Upload</button>
</form>
```

### Controller

ატვირთული ფაილი მოდის როგორც `MultipartFile` პარამეტრი, რომელიც გადაწყდება (resolved) `@RequestParam`-ის მეშვეობით:

```java
@Controller
public class FileUploadController {

    @PostMapping("/upload")
    public String handleFileUpload(@RequestParam("file") MultipartFile file,
                                   RedirectAttributes redirectAttributes) {
        if (file.isEmpty()) {
            redirectAttributes.addFlashAttribute("message", "Please select a file.");
            return "redirect:/upload";
        }

        try {
            byte[] bytes = file.getBytes();
            Path path = Paths.get("uploads/" + file.getOriginalFilename());
            Files.createDirectories(path.getParent());
            Files.write(path, bytes);

            redirectAttributes.addFlashAttribute("message",
                    "Uploaded successfully: " + file.getOriginalFilename());
        } catch (IOException e) {
            redirectAttributes.addFlashAttribute("message",
                    "Upload failed: " + e.getMessage());
        }

        return "redirect:/upload";
    }
}
```

`MultipartFile` გვაწვდის მეთოდებს ფაილის კონტენტზე წვდომისთვის (`getBytes()`, `getInputStream()`), მის ორიგინალურ სახელზე (`getOriginalFilename()`), მის კონტენტის ტიპზე (`getContentType()`) და მის ზომაზე (`getSize()`). ყოველთვის გადაამოწმეთ ფაილი შენახვამდე — შეამოწმეთ, რომ ის არ არის ცარიელი, რომ მისი კონტენტის ტიპი მისაღებია და რომ მისი ზომა თქვენი ლიმიტების ფარგლებშია.

---

## 3.8 Post/Redirect/Get პატერნი

განიხილეთ რა ხდება, როდესაც მომხმარებელი აგზავნის ფორმას. ბრაუზერი აგზავნის POST მოთხოვნას. სერვერი ამუშავებს მას. თუ სერვერი პირდაპირ პასუხობს HTML გვერდით (შაბლონის სახელის დაბრუნებით), ბრაუზერის მისამართის ველი კვლავ აჩვენებს POST URL-ს და ბრაუზერის ბოლო მოთხოვნა იყო POST. თუ მომხმარებელი დააჭერს განახლების (refresh) ღილაკს, ბრაუზერი ხელახლა გამოაგზავნის POST-ს — რითაც პოტენციურად შექმნის დუბლირებულ ჩანაწერს, ჩამოაჭრის საკრედიტო ბარათს ორჯერ ან ხელახლა გააგზავნის შეტყობინებას.

**Post/Redirect/Get (PRG)** პატერნი ამას თავიდან იცილებს. იმის ნაცვლად, რომ POST-ს პირდაპირ HTML-ით უპასუხოს, სერვერი პასუხობს HTTP 302 გადამისამართებით (redirect) GET URL-ზე. ბრაუზერი მიჰყვება გადამისამართებას და აგზავნის GET მოთხოვნას. ახლა, თუ მომხმარებელი აკეთებს განახლებას, მხოლოდ უსაფრთხო GET მოთხოვნა მეორდება.

მიმდინარეობა (flow) ასეთია:

1. მომხმარებელი აგზავნის ფორმას → **POST** `/products`
2. სერვერი ამუშავებს მონაცემებს, შემდეგ პასუხობს → **302 Redirect** `/products`-ზე
3. ბრაუზერი მიჰყვება გადამისამართებას → **GET** `/products`
4. მომხმარებელი აკეთებს განახლებას → მეორდება მხოლოდ GET (უსაფრთხოა)

Spring MVC-ში, გადამისამართება გამოიწვევა სტრიქონის დაბრუნებით, რომელიც იწყება `"redirect:"`-ით:

```java
@PostMapping("/products")
public String createProduct(@Valid @ModelAttribute Product product,
                            BindingResult bindingResult) {
    if (bindingResult.hasErrors()) {
        return "products/create";  // No redirect — re-display form with errors
    }
    productService.save(product);
    return "redirect:/products";   // PRG: redirect to GET endpoint
}
```

შეამჩნიეთ, რომ როდესაც ვალიდაცია მარცხდება, ჩვენ *არ* ვაკეთებთ გადამისამართებას — ჩვენ პირდაპირ ვაბრუნებთ შაბლონის სახელს. ეს განზრახ არის გაკეთებული. ვალიდაციის შეცდომები და ფორმის დამხმარე ობიექტი (მომხმარებლის მიერ გაგზავნილი მონაცემებით) იმყოფება მიმდინარე მოთხოვნის მოდელში. გადამისამართება მათ დაკარგავდა. ჩვენ გადამისამართებას ვაკეთებთ მხოლოდ წარმატების შემთხვევაში.

---

## 3.9 Flash Attributes (ფლეშ ატრიბუტები)

PRG პატერნი ქმნის პრობლემას: გადამისამართება არის ახალი HTTP მოთხოვნა და ორიგინალური POST მოთხოვნიდან მოდელის ატრიბუტები იკარგება. მაგრამ ზოგჯერ გჭირდებათ შეტყობინების გადაცემა გადამისამართებულ გვერდზე — მაგალითად, "პროდუქტი წარმატებით შეიქმნა!" სწორედ ამას აგვარებს **flash ატრიბუტები**.

Flash ატრიბუტები დროებით ინახება HTTP სესიაში. ისინი უძლებენ ზუსტად ერთ გადამისამართებას და შემდეგ ავტომატურად იშლება. Spring მათ უზრუნველყოფს `RedirectAttributes` პარამეტრის მეშვეობით:

```java
@PostMapping("/products")
public String createProduct(@Valid @ModelAttribute Product product,
                            BindingResult bindingResult,
                            RedirectAttributes redirectAttributes) {
    if (bindingResult.hasErrors()) {
        return "products/create";
    }
    productService.save(product);
    redirectAttributes.addFlashAttribute("successMessage", "Product created successfully!");
    return "redirect:/products";
}
```

სამიზნე შაბლონში, flash ატრიბუტი ხელმისაწვდომია როგორც ჩვეულებრივი მოდელის ცვლადი:

```html
<#if successMessage??>
    <div class="alert alert-success">
        ${successMessage}
    </div>
</#if>
```

გვერდის დარენდერების შემდეგ, flash ატრიბუტი ავტომატურად იშლება სესიიდან. თუ მომხმარებელი განაახლებს გვერდს, შეტყობინება აღარ გამოჩნდება — რაც ზუსტად სწორი ქცევაა.

---

## 3.10 შეცდომის მორგებული გვერდები (Custom Error Pages)

როდესაც რაღაც არასწორად მიდის — გვერდი არ მოიძებნა, სერვერის შეცდომა მოხდა — Spring Boot აჩვენებს ნაგულისხმევ შეცდომის გვერდს. საწარმოო (production) აპლიკაციაში დაგჭირდებათ ამის ჩანაცვლება მორგებული გვერდებით, რომლებიც ემთხვევა თქვენი აპლიკაციის დიზაინს.

### კონვენციაზე დაფუძნებული შეცდომის გვერდები

ყველაზე მარტივი მიდგომაა FreeMarker შაბლონების მოთავსება `/templates/error/` დირექტორიაში, რომლებიც დასახელებულია HTTP სტატუსის კოდების მიხედვით:

```
src/main/resources/templates/error/
├── 404.ftlh       ← ნაჩვენებია 404 Not Found-სთვის
├── 500.ftlh       ← ნაჩვენებია 500 Internal Server Error-სთვის
└── error.ftlh     ← ზოგადი სათადარიგო ნებისმიერი სხვა შეცდომისთვის
```

Spring Boot ავტომატურად უკავშირებს HTTP შეცდომის სტატუსის კოდებს ამ შაბლონებს. დამატებითი კონფიგურაცია საჭირო არ არის.

`404.ftlh` შაბლონი შეიძლება ასე გამოიყურებოდეს:

```html
<#import "/spring.ftl" as spring>
<#import "../layout.ftlh" as layout>

<@layout.page title="Page Not Found">
    <h1>404 — Page Not Found</h1>
    <p>Sorry, the page you are looking for does not exist.</p>
    <p><a href="<@spring.url '/'/>">Return to the home page</a></p>
</@layout.page>
```

Spring Boot რამდენიმე ატრიბუტს ხდის ხელმისაწვდომს შეცდომის შაბლონებში: `timestamp`, `status`, `error` (მიზეზის ფრაზა), `message` და `path` (URL, რომელმაც შეცდომა გამოიწვია). შეგიძლიათ გამოიყენოთ ისინი მეტი დეტალის უზრუნველსაყოფად:

```html
<p>Status: ${status!""}</p>
<p>Error: ${error!""}</p>
<p>Timestamp: ${timestamp!""}</p>
```

`!""` სინტაქსი არის FreeMarker-ის ნაგულისხმევი მნიშვნელობის ოპერატორი — თუ ცვლადი აკლია, ის გამოიტანს ცარიელ სტრიქონს შეცდომის დაფიქსირების (throw) ნაცვლად.

### მორგებული ErrorController

შეცდომების მართვის ლოგიკაზე მეტი კონტროლისთვის — მაგალითად, მოდელის ატრიბუტების დასამატებლად, შეცდომის დასალოგად ან სტატუსის კოდის მიხედვით განსხვავებული ლოგიკის გამოსაყენებლად — შეგიძლიათ დააიმპლემენტიროთ `ErrorController` ინტერფეისი:

```java
@Controller
public class CustomErrorController implements ErrorController {

    @RequestMapping("/error")
    public String handleError(HttpServletRequest request, Model model) {
        Object status = request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);

        if (status != null) {
            int statusCode = Integer.parseInt(status.toString());
            model.addAttribute("statusCode", statusCode);

            if (statusCode == HttpStatus.NOT_FOUND.value()) {
                return "error/404";
            } else if (statusCode == HttpStatus.INTERNAL_SERVER_ERROR.value()) {
                return "error/500";
            }
        }
        return "error/error";
    }
}
```

ეს controller აკავებს (intercepts) შეცდომის ყველა პასუხს. ის კითხულობს HTTP სტატუსის კოდს მოთხოვნიდან, ამატებს მას მოდელში და აკეთებს მარშრუტიზაციას (routes) შესაბამის შეცდომის შაბლონზე. შეგიძლიათ გააფართოვოთ ეს ლოგირებით, მორგებული შეტყობინებებით ან ნებისმიერი სხვა ლოგიკით, რაც გჭირდებათ.

კონვენციაზე დაფუძნებული მიდგომა და მორგებული `ErrorController` შეუძლია თანაარსებობდეს — `ErrorController`-ს ენიჭება უპირატესობა, როდესაც ის არსებობს, მაგრამ გადადის (falls back) კონვენციაზე დაფუძნებულ შაბლონებზე ნებისმიერი სტატუსის კოდისთვის, რომელსაც ექსპლიციტურად არ ამუშავებს.

---

## შეჯამება

ამ თავში განვიხილეთ მექანიზმები, რომლებიც მხოლოდ საჩვენებელ (display-only) ვებსაიტს ინტერაქტიულ აპლიკაციად აქცევს.

**HTTP GET და POST** მოთხოვნები ემსახურება სხვადასხვა მიზანს: GET იღებს მონაცემებს, POST აგზავნის მას. Spring MVC-ის `@GetMapping` და `@PostMapping` აკავშირებს handler მეთოდებს მოთხოვნის შესაბამის ტიპთან.

**Spring-ის FreeMarker ფორმის მაკროები** (`@spring.formInput`, `@spring.formTextarea`, `@spring.formSingleSelect`, `@spring.showErrors` და სხვები) აგენერირებენ HTML ფორმის ელემენტებს, რომლებიც დაკავშირებულია მოდელში არსებულ ფორმის დამხმარე ობიექტთან. ისინი უმკლავდებიან ველების არსებული მნიშვნელობებით შევსებას და ვალიდაციის შეცდომების ავტომატურად ჩვენებას.

**Data binding** `@ModelAttribute`-ით აკავშირებს გაგზავნილ ფორმის მონაცემებს Java ობიექტის property-ებთან სახელის მიხედვით. Spring ტიპების კონვერტაციას ავტომატურად უმკლავდება.

**Bean Validation** ანოტაციები (`@NotBlank`, `@Size`, `@Positive`, `@Email` და ა.შ.) აცხადებენ ვალიდაციის წესებს უშუალოდ model კლასებზე. `@Valid` ანოტაცია იწვევს ვალიდაციას, ხოლო `BindingResult` აგროვებს შეცდომებს. როდესაც შეცდომები არსებობს, ფორმა ხელახლა ნაჩვენები იქნება შეცდომის შეტყობინებებით, რომლებიც დარენდერებულია `<@spring.showErrors>`-ის მიერ.

**ფაილების ატვირთვა** იყენებს `MultipartFile`-ს და მოითხოვს `enctype="multipart/form-data"`-ს ფორმაზე. კონფიგურაციის property-ები აკონტროლებს ფაილისა და მოთხოვნის მაქსიმალურ ზომებს.

**Post/Redirect/Get პატერნი** თავიდან იცილებს ფორმის დუბლირებულ გაგზავნას წარმატებული POST-ის შემდეგ გადამისამართებით. **Flash ატრიბუტები** ინარჩუნებენ შეტყობინებებს გადამისამართებისას, სესიაში მათი დროებით შენახვით.

**შეცდომის მორგებული გვერდები** შეიძლება შეიქმნას შაბლონების განთავსებით `/templates/error/`-ში, რომლებიც დასახელებულია სტატუსის კოდების მიხედვით, ან `ErrorController`-ის იმპლემენტაციით შეცდომების მართვის პროგრამული კონტროლისთვის.

---

## რესურსები

- [Spring MVC — Annotated Controllers](https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-controller.html)
- [Spring MVC — FreeMarker Form Macros](https://docs.spring.io/spring-framework/reference/web/webmvc-view/mvc-freemarker.html)
- [Bean Validation (Hibernate Validator)](https://hibernate.org/validator/)
- [Spring Boot — File Upload Guide](https://spring.io/guides/gs/uploading-files/)
- [Spring Boot — Error Handling](https://docs.spring.io/spring-boot/reference/web/servlet.html#web.servlet.spring-mvc.error-handling)
- [Apache FreeMarker Manual](https://freemarker.apache.org/docs/index.html)

---

## პრაქტიკული დავალება: ააწყეთ ინტერაქტიული ვებ აპლიკაცია

გააფართოვეთ თქვენი ბლოგის აპლიკაცია ინტერაქტიული ფუნქციებით.

**მოთხოვნები:**

1. **შექმენით HTML ფორმა** ახალი ბლოგის პოსტის დასამატებლად (სათაური, ავტორი, კონტენტი და არასავალდებულო კატეგორია, არჩეული ჩამოსაშლელი სიიდან). გამოიყენეთ Spring-ის FreeMarker ფორმის მაკროები (`@spring.formInput`, `@spring.formTextarea`, `@spring.formSingleSelect`), რათა დააკავშიროთ ფორმა model ობიექტთან.

2. **დააიმპლემენტირეთ სერვერის მხარის ვალიდაცია** Bean Validation ანოტაციების გამოყენებით. სათაური უნდა იყოს სავალდებულო და 3-დან 100 სიმბოლომდე. კონტენტი უნდა იყოს სავალდებულო. აჩვენეთ ვალიდაციის შეცდომები თითოეული ველის გვერდით `<@spring.showErrors>`-ის გამოყენებით.

3. **გამოიყენეთ Post/Redirect/Get პატერნი** — წარმატებული გაგზავნისას მოახდინეთ გადამისამართება პოსტების სიის გვერდზე. ვალიდაციის ჩავარდნისას, ხელახლა აჩვენეთ ფორმა შეცდომებით და მომხმარებლის მიერ ადრე შეყვანილი მონაცემების შენარჩუნებით.

4. **დაამატეთ flash ატრიბუტები**, რათა აჩვენოთ წარმატების შეტყობინება (მაგ., "პოსტი წარმატებით შეიქმნა!") პოსტების სიის გვერდზე წარმატებული გადამისამართების შემდეგ.

5. **დააიმპლემენტირეთ ფაილის ატვირთვა** — მიეცით მომხმარებლებს საშუალება, დაურთონ სურათი ბლოგის პოსტს. გადაამოწმეთ, რომ ატვირთული ფაილი არ არის ცარიელი და არის სურათის ტიპის.

6. **შექმენით შეცდომის მორგებული გვერდები** — მინიმუმ, შექმენით `404.ftlh` და ზოგადი `error.ftlh` გვერდი, რომლებიც იყენებენ თქვენს layout მაკროს თანმიმდევრული დიზაინისთვის.