ContentLIBRE — strona główna

DOSTOSOWYWANIE

Zacznij od podstawy.
Dodaj to, co Cię wyróżnia.

Uczyń inwentarz środowiska uruchomieniowego decyzją. Utrzymuj kod projektu i konfigurację wdrożenia jawnymi, a potem zweryfikuj kompozycję, którą naprawdę zamierzasz dostarczyć.

Funkcja wymienia to, co wnosi.

Kompozycja startera ContentLIBRE jest addytywna: bundle jest obecny, ponieważ plik funkcji wymienia jego współrzędne. Funkcje grupują możliwości takie jak HTTP, renderowanie, magazyn i API. Rozszerzenie projektu powinno być równie jawne co do kodu, konfiguracji i każdego wnoszonego bootstrapu repozytorium.

Gdzie mieszka udokumentowany model rozszerzeń. text 
starter/
  platform/server/src/main/features/   możliwości środowiska uruchomieniowego
  bom/                                zarządzanie zależnościami dla konsumentów
customization/                        przykład dostosowania w projekcie pochodnym

Uproszczona mapa modułów z ARCHITECTURE.md. Dokładne nazwy artefaktów i wersje potwierdź w wybranym wydaniu.

OD WYMAGANIA DO KOMPOZYCJI

Świadomy proces rozszerzania.

  1. Zdefiniuj możliwość

    Zdecyduj, czy potrzebujesz kodu projektu, konfiguracji, treści czy nowej zależności. Nie dodawaj całego stosu dla możliwości, którą platforma już udostępnia.

  2. Zadeklaruj ją w kompozycji

    Wymień właściwe bundle i pliki funkcji. Utrzymuj jawne wersje zależności i wymagania kolejności startu. Addytywne podejście startera i prototyp w projekcie pochodnym to różne wzorce kompozycji.

  3. Przeanalizuj, potem uruchom

    Uruchom analizator funkcji i testy integracyjne wybranej kompozycji. Rozwiązanie importowanych pakietów to nie to samo, co aktywacja wszystkich usług w czasie działania.

  4. Udokumentuj granicę operacyjną

    Odnotuj nowe tożsamości, publiczne trasy, zapisywalne ścieżki i kanały instalacji. Traktuj zainstalowany kod jako kod zaufany, ze wszystkimi wynikającymi z tego odpowiedzialnościami.

Treść projektu i konfiguracja domen to różne sprawy.

Model frameworka witryn umieszcza komponenty, szablony i pliki frontendu w projekcie, podczas gdy powiązania należą do wdrożenia. To użyteczny podział, gdy ten sam projekt obsługuje więcej niż jedno środowisko. Dokument frameworka witryn wciąż ma nagłówek ze statusem „niezaimplementowane”, podczas gdy późniejsza dokumentacja API opisuje moduły oparte na witrynach jako zbudowane; potwierdź dokładną dostępność funkcji witryn i redakcji, zanim potraktujesz ten model jako obietnicę implementacji.

Rozszerzaj właściwy szew.

Integracje HTTP

Gdy Twój projekt publikuje operacje typowane, stosuj udokumentowane konwencje modułów Jakarta REST.

Przeczytaj przewodnik po API

Doświadczenia redakcyjne

Dokument witryn opisuje wersjonowany szew serwerowy z powłoką demonstracyjną. Kompletny edytor biznesowy nie jest potwierdzony opublikowanymi dowodami.

Sprawdź status redakcji

Reguły cyklu życia strony

Reaktory, walidatory i subskrybenci należą do proponowanej warstwy cyklu życia. Poznawaj projekt bez kompilowania wobec zakładanego, wydanego API.

Przeczytaj zapowiedź projektową

Niech każde dodanie pozostanie zrozumiałe.

Małe, dobrze opisane rozszerzenie łatwiej ocenić niż listę funkcji z ukrytymi zależnościami.

Przeczytaj o architekturze Bezpieczeństwo i eksploatacja