Nowe jądro - założenia, Praca nad założeniami pod nowy PuciekOS Opcje

[Puciek]

Ostatnio postanowiłem zacząć pisać całkiem nową wersje PuciekOS, takiego mojego jądra. Postanowiłem przejść z jednej skrajności z drugą, znaczy z bardzo małej zależności od jądra na całkowitą zależność.

Tak więc jedynym dostępnym outputem będzie aktywny Cache. Jako szablon modułu myślę nad czymś w stylu:

[PHP] pobierz, plaintext 
<?php
/*Opis modulu*/
 
if( $alvl == 2 )
{
   //tutaj wykona sie modol
}
else
{
   call_403();
}
?>
[PHP] pobierz, plaintext 

Jak można zauważyć (acz ciężko z powodu małej ilości kodu) mam zamiar nieużywać opcji echo, a jądro będzie przyjmowało sygnały od każdego modułu, sumowała wynik i wybierało odpowiednią stronę z cacha.

Diabeł tkwi w tym jak zrealizować ładowanie modułów, czy choćby segregację sygnałów otrzymywanych z modułów, ładowania ich oraz sam system cachowania strony.

[scanner]

Chyba za bardzo nie wiadomo o Co Tobie tak w zasadzie chodzi...

[DeyV]

rozwiązanie jest proste, i mieści sie w jednym słowie...

Smarty

Dlaczego?
Bo zawiera świetny moduł cache, który w pełni rozwiązuje problemy z wydajnością.
Bo pozwala na uniknięcie kodu html w php
Bo pozwala na łątwe sprawdzenie, czy istnieje scachowany output dla danego moduły, co oznacza, że nie ma konieczności ładowania go, czy też potrzeba go wykonać.


A jak tym zarządzać?
Kłania się MVC.
Czyli istnieje jakiś router, który decyduje jaka akcja ma zostać wywołana (poprzednio nieopatrznie użyłem słówa moduł).
Przesyła tą informację dalej, gdzie jest sprawdzane, czy taka akcja istnieje, czy musi zostawać wykonana, czy też może wszystko już jest w cache.
Jeśli jest - po prostu to wyświetlamy.
Jeśli nie - na podstawie nazwy akcji otrzymanej z routera generujemy nazwę pliku z klasą akcji, i uruchamiamy ją.
Akcja ta generuje jakieś dane, i przesyła je do smarty, które na zakończenie, generuje wynik.

Proste, prawda?

[rogrog]

z tego co wiem to generalnie dąży się do tego żeby jądro było tylko ogólne i nakładało jak najmniejsze ograniczenia... i żeby można było wykonać duże zmiany w aplikacji nie ruszając jądra... albo z kolei wypuścić poprawki w jądrze, które nie spowodują błędów w aplikacji - po prostu taka jest tego idea

PS. Puciek: jeśli chodzi o nazwę tego twojego jądra, to mam pytanie: czy na pewno wiesz co oznacza skót OS

[M4chu]

PS. Puciek: jeśli chodzi o nazwę tego twojego jądra, to mam pytanie: czy na pewno wiesz co oznacza skót OS

Sorki, ze sie wtrace ale moze Open Source?

[Aztech]

Oh Shit Operating System
Do adminówi Pućka: sorki ale nie mogłem się powstrzymać

[Dravo]

Według mnie należy zwrócić uwagę na odwrotna zależność (pisze z kawiarenki między lekcjami, więc przpraszam za `po łebkach`). Tzn. w tym przypadku moduly mają być zależne od jądra a nie na odwrót, czyli:
każda zmiana w jądrze może (ale nie musi) pociągać zmiany w modulach. Dlatego tak ważne jest dobre zaprojektowanie serca systemu.
Można również odpowiednio zdefiniować używane standardy i w razie jakiś zmian czy to w jednym czy to w drugim dalej będzie wszystko ladnie ze sobą gralo.
Ale tu nas ogranicza czas... Wiadomo że inaczej się pisze na prace magisterską a inaczej dla wlasnych potrzeb - w celach praktyki.

PS. Jestem niewyspany, więc prosze o wybaczenie...