Różnice

Różnice między wybraną wersją a wersją aktualną.

--- pl:python:django [2023/12/02 13:58] – [Czasem nie wszystko da się wykonać po stronie modeli] sindap
+++ pl:python:django [2023/12/22 20:36] (aktualna) – [Django] sindap
@@ Linia 6: / Linia 6: @@
   * Opcje Meta [[:pl:python:meta|Meta ogólnie]]
   * Opcje [[:pl:python:metawmodelach|Meta w modelach]]
-  * Opcje [[:pl:python:metawforms|Meta w formularzach]]
+  * [[:pl:python:metawforms|Opcje Meta w formularzach]]
+  * [[:pl:python:views|O widokach ogólnie]]
+  * [[:pl:python:importmdb2models|Import danych z bazy MS Access]]
+  * [[:pl:python:serwerdjango|Serwer Django]]
 ===== Wiele aplikacji w jednym projekcie czy każda w osobnym projekcie? =====
@@ Linia 143: / Linia 145: @@
 Pamiętaj, że ostateczna decyzja o umieszczeniu logiki w warstwie modelu czy widoku zależy od konkretnego kontekstu projektu i wymagań funkcjonalnych. Ważne jest zachowanie zasady czytelności kodu i unikanie nadmiernego rozbijania kodu, co mogłoby utrudnić zrozumienie i utrzymanie systemu.
-**Warto wspomnieć o innych zasadach:**
+===== Warto wspomnieć o innych zasadach: =====
 W programowaniu w Django istnieje kilka innych zasad i praktyk, które są powszechnie stosowane w celu zachowania czytelności kodu, zwiększenia elastyczności systemu oraz ułatwienia utrzymania. Oto kilka z nich:
-. **DRY (Don't Repeat Yourself):**
+==== 1. DRY (Don't Repeat Yourself) ====
   * Zasada DRY nakazuje unikanie powtarzania tego samego kodu. Jeśli pewna funkcjonalność występuje w wielu miejscach, warto ją zrefaktorować do jednego miejsca, aby zmniejszyć ryzyko błędów, ułatwić utrzymanie i uniknąć redundancji.
-. **Fat URLs, Thin Views:**
+==== 2. Fat URLs, Thin Views ====
   * Zasada ta podkreśla, aby unikać zbyt rozbudowanych adresów URL i przenosić logikę związaną z analizą adresów URL do widoków. Adresy URL powinny być przejrzyste i jednoznaczne, a złożone operacje powinny być obsługiwane w warstwie widoku.
-. **Separacja obowiązków (Separation of Concerns):**
+==== 3. Separacja obowiązków (Separation of Concerns) ====
   * Rozdzielanie odpowiedzialności pomiędzy różne komponenty systemu. Modele powinny zajmować się danymi i logiką biznesową, widoki obsługą żądań HTTP i przetwarzaniem danych, a szablony prezentacją. To pomaga w utrzymaniu klarowności i modularności kodu.
-. **KISS (Keep It Simple, Stupid):**
+==== 4. KISS (Keep It Simple, Stupid) ====
   * Zasada KISS sugeruje, że rozwiązania powinny być jak najprostsze. Unikaj nadmiernego skomplikowania kodu, jeśli nie jest to konieczne. Prosta implementacja jest łatwiejsza do zrozumienia i utrzymania.
-. **Consistent Naming Conventions:**
+==== 5. Consistent Naming Conventions ====
   * Konsekwentne stosowanie konwencji nazewniczych. Nazwy klas, funkcji, zmiennych i innych elementów kodu powinny być nazywane zgodnie z przyjętymi konwencjami. W Django stosuje się zasady PEP 8.
-. **Aplikacje jako niezależne komponenty:**
+==== 6. Aplikacje jako niezależne komponenty ====
   * Tworzenie aplikacji Django jako niezależnych, wielokrotnie używanych komponentów, które można ponownie wykorzystać w innych projektach. Każda aplikacja powinna mieć jasno zdefiniowany zakres funkcjonalny.
-. **Test-Driven Development (TDD):**
+==== 7. Test-Driven Development (TDD) ====
   * Praktyka polegająca na tworzeniu testów jednostkowych przed napisaniem właściwej implementacji. TDD może pomóc w zwiększeniu jakości kodu i ułatwieniu utrzymania.
-. **Zasada Atomic Design w szablonach:**
+==== 8. Zasada Atomic Design w szablonach ====
   * Stosowanie zasady Atomic Design do projektowania szablonów. Podział szablonów na atomowe komponenty (np. button, form, input) ułatwia budowanie spójnych interfejsów.
-. **Optymalizacje wydajnościowe:**
+==== 9. Optymalizacje wydajnościowe ====
   * Rozważanie optymalizacji wydajnościowej kodu, szczególnie w obszarach, które mają wpływ na szybkość odpowiedzi aplikacji. Użycie cache, optymalizacja zapytań do bazy danych, czy stosowanie indeksów to przykłady praktyk mających na celu poprawę wydajności.
 Zasady te są ogólnymi wytycznymi, a ich zastosowanie zależy od konkretnego kontekstu projektu. Optymalny wybór zasad zależy od charakterystyki projektu, zespołu programistycznego oraz wymagań biznesowych.