Clicky

Skocz do zawartości


Zdjęcie
- - - - -

[K3] Workshop

13 odpowiedzi w tym temacie

  • Zaloguj się, aby dodać odpowiedź

#1 ZuyPan

ZuyPan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 171 postów

Napisano 03 maj 2012 - 23:14

Witajcie.

Postanowiłem opublikować pewien moduł, który aktualnie jest w fazie "oceńcie czy to ma sens". Jest to jak sama nazwa wskazuje warsztat na podstawie którego odrobinie łatwiej będzie tworzyć inne strony www. Wszystko oczywiście jest nastawione na Kohane 3.2.
O co chodzi?
Workshop pozwala na podzielenie kodu na biblioteki i moduły. Każdy programista pracujący z jakimś frameworkiem po jakimś czasie ma sporo modułów i tym podobnych służących do wielu różnych rzeczy. Z założenia każdy moduł jak np. Layout czy Language powinny być biblioteką modułu Workshop ponieważ są to klasy ułatwiające tworzenie serwisu. Można też mieć moduły - np. księga gości czy forum. Może ktoś z Was ma swój moduł dla kohany którym jest forum - takie gotowe systemy mają swoje miejsce w podkatalogu "modules" w katalogu Workshop. Po co to wszystko? Aby ustandaryzować i ułatwić sobie pracę. Mając kilka gotowych bibliotek podczas tworzenia nowego serwisu włączę te których aktualnie potrzebuje bez obawy, że jedna z nich potrzebuje drugiej itd.

Oto link do modułu: https://github.com/ZuyPan/Workshop

Mam nadzieję, że pomysł jako tako się przyjmie (już kiedyś był poruszany na tym forum). Aktualnie jest tylko jedna biblioteka - standardowa i zero modułów (git zjadł folder modules ponieważ był pusty). W tej jednej bibliotece zawarłem najbardziej podstawowe klasy z których korzystam. Taka właśnie jest idea Workshop. Mieć wszystko w osobnych bibliotekach, niezależne od siebie, ale działające w oparciu o wspólne api Workshop.
Teraz proszę o konstruktywną krytykę i wytykanie błędów :)

#2 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 04 maj 2012 - 07:37

Wedlug mnie ma to sens, bo wlasnie w tej chwili moduly ulatwiajace tworzenie aplikacji jak i funkcjonalne (np.forum) sa w jednym worze i przy ich duzej ilosci robi sie balagan

#3 Riu

Riu

    Senior Mastah

  • Webmastahy
  • PipPipPip
  • 949 postów

Napisano 04 maj 2012 - 12:55

Rozumiem założenie i problem, z którego wynika chęć zrobienia takiego modułu, natomiast uważam, że zamiast ułatwiać - komplikujesz sobie niepotrzebnie. Po co moduły ładować do jednego modułu - obecna konwencja jest zła? Są przestrzenie nazw, jest katalog vendor do biliotek i klas zewnętrznych - korzystanie z tego powoduje że nic się nie pogryzie. Tak naprawdę taki moduł burzy standard, a nie o niego dba.

Debian/Ubuntu + Kohana/Hanariu/Phalcon + MongoDB/MySQL + HTML5/CSS3 + Node.js/jQuery + CEO Sport Magazyn/CEO Hanariu


#4 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 04 maj 2012 - 19:09

Z tego co zrozumialem to oddziela od siebie moduly wspomagajace tworzenie aplikacji (np. ORM) od modulow dajacych jakas funkcjonalnosc (np. forum)

#5 ZuyPan

ZuyPan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 171 postów

Napisano 04 maj 2012 - 20:23

Dokładnie tak.
Są standardowe moduły kohany - one są zawarte w katalogu modules Kohany. One są standardem więc każdy wie jak działają itd. Oraz są te zawarte w module Workshop.
Wyobraźmy sobie sytuację, że serwis jest tworzony na podstawie naszych modułów których mamy kilka. Gdybyśmy wrzucili to wszystko do jednego wora z modułami Kohany robi się lekki bałagan nie tylko dla nas, ale także dla osoby która po nas musi kod konserwować. Co zatem daje Workshop? Workshop wprowadza dwa foldery:
* Libraries
* Modules

W folderze libraries trafiać będą nasze moduły odpowiedzialne np. za internacjonalizację, obsługę skórek strony. Coś jak biblioteka ORM - niby jest, ale trzeba jej odpowiednio użyć. W folderze Modules będą trzymane gotowe komponenty np. forum czy księga gości. To działa na zasadzie, że wrzucasz i masz już wszystko gotowe. Są już kontrolery, widoki itd.
Różnica jest więc taka, że bibliotek używasz tworząc aplikację a moduły dogrywasz jako gotowe części.
Jakie to ma zastosowanie w praktyce? Jak już wspomniałem przede wszystkim wprowadza pewien porządek. Ktoś kto odziedziczy po nas kod i spotka w katalogu Modules sporo różnych folderów ma sporo pracy aby zorientować się który do czego służy, jak działa itd. Pół biedy gdy programista rozważnie dobiera moduły Kohany i zostawia tylko te które używa, ale może być też tak, że będzie masa katalogów a tylko kilka z nich jest wykorzystywane. To jedna funkcjonalność, kolejna jest czysto teoretyczna - każda biblioteka powinna być w stanie działać bez siebie, mogą być włączane i wyłączane bez żadnych konsekwencji zaś wszystko to co znajdzie się w APPPATH i w modułach Workshop może korzystać z bibliotek. Wreszcie ostatnia cecha - api core Workshop. Jeśli ktoś przeglądnął klasy zawarte w folderze core zapewne zauważył pewne metody i właściwości w klasie core. Chodzi o to aby biblioteki i moduły mogły korzystać właśnie z tego api. Mamy więc:
* core - z głównymi trzema klasami
* libraries - biblioteki wprowadzające nowe klasy, ale korzystające z api core
* modules - samodzielne komponenty korzystające z bibliotek i api core
Jakie zatem korzyści? Powiedzmy, że tworzę standardową stronę - obsługa użytkowników, newsy, artykuły, forum i księga gości. Jak zaczynam pracę? Wrzucam bibliotekę "users", "news", "articles", oraz moduły "forum", i "guest_book". Ok mam już biblioteki i moduły co teraz? No to, że forum i księgę gości mam już zrobioną bo z założenia moduły Workshop są w stanie działać samodzielnie. Mam również biblioteki dzięki którym (a raczej ich api) będę w stanie bardzo szybko dopisać kontrolery i resztę serwisu w folderze APPPATH.
Owszem to samo można uzyskać po prostu wrzucając wszystko do MODPATH Kohany i będzie nawet szybsze, ale dla mnie pewna standaryzacja i fakt, że mogę włączać i wyłączać wszystko bez konsekwencji oraz trzymam to w porządku bez żadnych zagmatwań jest nieoceniony.
Riu napisałeś kiedyś na tym forum:

Modularyzacja - podstawa szybkiego tworzenia i w sumie podstawa do tworzenie dobrych generatorów (jeśli już ktoś chce).

Właśnie to miałem na myśli tworząc Workshop. Masz gotowe moduły które wrzucasz do odpowiedniego katalogu i połowa pracy za Tobą. Jedynym warunkiem jest to aby wszystkie te biblioteki i moduły trzymały się pewnych zasad i o to ma dbać Workshop.

Zapomniałem dodać więc się dopiszę tu - mam nadzieję, że Wam to nie umknie. Wszyscy wiemy jak jest z dokumentacją przeróżnych modułów Kohany. Raz jest raz nie ma, czasem jest, ale tak jak by jej nie było. Workshop już wkrótce otrzyma swoją rozbudowaną dokumentację z wyjaśnieniem co jak gdzie i po co. Każda biblioteka i moduł również takie coś otrzyma. A więc programista przeglądając kod trafia do folderu Workshop i kolejno czyta sobie dokumentację i ma wszystko to co potrzebne pod ręką, ładnie udokumentowane i z odpowiednim podziałem. A jak jest standardowo? Otwierasz MODPATH i co widzisz? Multum modułów, nie wiadomo który od czego, gdzie i jak został użyty itd. Chodzi o porządek, podział, standaryzację i dokumentację w sposób taki, że ktoś zupełnie nowy otwiera folder Workshop i ma wszystko.

#6 Riu

Riu

    Senior Mastah

  • Webmastahy
  • PipPipPip
  • 949 postów

Napisano 04 maj 2012 - 23:33

Przesadzasz z tym bałaganem, a do dokumentacji jest userguide, który jest świetny ;) Tym zostawianiem kodu dla tych co po Tobie też bym się nie podniecał, bo wszyscy tak gadają, ale każdy ma burdel :P (albo nam się tak wydaje).

Będę się przyglądał temu projektowi, chodź wróżę, że wkrótce odkryjesz kilka ciekawych problemów, które nieco zmienią Ci punkt widzenia na pisanie modułu do porządkowania modułów m.in z konfiguracjami, z trzymaniem plików statycznych, mediów, z instalacjami modułów, z trzymaniem zgodności i zależnościami od bibliotek. No ale trzymam kciuki :)


Debian/Ubuntu + Kohana/Hanariu/Phalcon + MongoDB/MySQL + HTML5/CSS3 + Node.js/jQuery + CEO Sport Magazyn/CEO Hanariu


#7 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 05 maj 2012 - 07:50

Riu:

a do dokumentacji jest userguide, który jest świetny

Tu chyba chodzilo o to, ze nie kazdy dokumentuje swoj kod i z tym sie zgodze w 100%.

ZuyPan:
Kiedys mialem podobny cel - kazdy modul ma byc autonomiczny i dzialac bez innego. Niestety piszac aplikacje technicznie poprawne nie da sie tego osiagnac - forum korzysta z modulu uzytkownikow. Jezeli modul uzytkownikow jest do forum skopiowany to jest to blad (moim zdaniem i nie tylko). Przykladem takiego modulu w kohanie jest ORM, ktory korzysta z Database. Tak samo auth na sterowniku ORM - powstaje sciezka Auth -> ORM -> Database. Sa po prostu pewne fundamentalne modulu jak database, bez ktorych inne nie sa w stanie istniej (jasne, ze mozna otwierac polaczenie w ORM i klepac zapytania w mysql_query(), ale nie taki jest cel frameworka).

#8 ZuyPan

ZuyPan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 171 postów

Napisano 05 maj 2012 - 08:14

I po to wprowadziłem metodę "load_library" gdzie w parametrze podajesz jedną lub całą tablicę bibliotek do załadowania na wypadek właśnie tych podstawowych działań.
Zdaję sobie sprawę, że forum będzie wymagać biblioteki users i dobrze, bo tak to z założenia ma działać. A jeżeli biblioteki będą wymagały siebie nawzajem to też mnie to wielkiego problemu nie robi, w końcu zawsze muszą być jakieś kompromisy. Zresztą tak fundamentalne rzeczy jak database nadal pozostawiam frameworkowi, niech to on się o to martwi. Biblioteki które mam zamiar dopisać będą korzystać ze wszystkiego co oferuje kohana i jeśli to konieczne z samych siebie, ale optymistycznie zakładając jeszcze nie wymyśliłem takiej która będzie wymagać innych bibliotek mojego autorstwa.
Workshop nie ma segregować już istniejących modułów do kohany. Każdy programista który zechce go używać powinien napisać biblioteki i moduły właśnie dla Workshop i tak je zaprojektować aby były jak najbardziej niezależne. Przykładem jest już zawarta w paczce Workshoplib gdzie mam:
* wyjątki które jedynie rozszerzając te kohanowskie, ale nie korzystają z innych części tej biblioteki,
* internacjonalizacje która jest nową klasą i nie korzysta z innych części tej biblioteki,
* layouty które rozszerzają widoki, ale nie korzystają z innych części tej biblioteki,
* flash messages które również są nowością i nie korzystają z innych części tej biblioteki
* kontrolery które są standardowymi kontrolerami.
W jednej bibliotece zawarłem fundamentalne klasy których zawsze używałem, ale tak je zaprojektowałem, że nawet gdy nie będę korzystał ze swojej wersji internacjonalizacji zadziała ta standardowa Kohanowska.
Generalnie ja póki co będę rozwijał ten moduł no chyba, że tak jak powiedział Riu szybko zrozumiem wady tego rozwiązania.
Btw. czy moglibyście rzucić okiem na kod zarówno core jak i biblioteki workshoplib (to jest ta domyślna i zresztą jak na razie jedyna) i wypowiedzieć się na temat właśnie kodu? Może coś źle robię, może macie jakieś rady jako dużo bardziej doświadczeni koledzy? :)

#9 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 05 maj 2012 - 10:54

Tak tylko rzucilem okiem i znalazlem takie rzeczy:

// Ustawia instancje cache.
            Workshop::$_cache = Cache::instance('file');
w metodzie init() klasy Workshop_Core. Przydaloby sie umozliwic konfiguracje z jakiego sterownika cache'u chcemy korzystac. Ten wybor powinien byc mozliwy w kazdej bibliotece workshop osobno, wiec Workshop::$_cache powinno sie odnosic do klasy Cache a nie juz konkretnego sterownika. Jesli chcesz zachecic innych do korzystania z workshop to musi byc on jak najbardziej konfigurowalny, ja np. korzystam z memcache.

Nie rozumiem troche filozofii technicznej workshop - calosc jest helperem (klasa z metodami statycznymi). Dlaczego? Po co? Ja bym to widzial tak, ze mam instancje workshopu (singleton) i sobie z niej korzystam w nastepujacy sposob:
Workshop::instance()->method();


#10 ZuyPan

ZuyPan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 171 postów

Napisano 05 maj 2012 - 16:54

Z instancją cache to mój błąd, w pliku konfiguracyjnym "workshop" jest możliwość ustawienia tego jednakże ja podczas tworzenia Workshop zmieniłem to na statyczne wybieranie i już zapomniałem naprawić.
Co do faktu, że core jest helperem to owszem, celowo zrobiłem go jako helper tak samo jak "libraries" i "modules". Oczywiście jeśli to błąd to ja to zmienię, po ot pytam się Was - bardziej doświadczonych ode mnie i po to Workshop ma flagę Development na git aby wszystko uregulować jak należy.
Core Kohany również jest helperem i szczerze powiem to właśnie naprowadziło mnie na ten tok rozumowania. I tu i tu są fundamentalne metody więc postanowiłem wzorować się na twórcach frameworka. Jeśli jednak jest to złe rozumowanie to z chęcią posłucham Waszych rad i zmienię co trzeba.

#11 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 05 maj 2012 - 20:22

Wedlug mnie jest zle, poniewaz zawsze trzeba wywolac metode init(), ja jestem zwolennikiem prostoty w uzytkowaniu. Do tego singleton idealnie nadaje sie dla workshop - w calej aplikacji moze byc tylko 1 instancja workshop. Generalnie jak cos ma byc obiektem to uwazam, ze powinno sie uzywac konstruktora a nie inicjalizowac recznie przez jakies metody.

#12 Zepco

Zepco

    Senior Mastah

  • Moderator
  • 1583 postów
  • Skąd:Kielce

Napisano 06 maj 2012 - 13:21

Ja się przychylam do zdania @Riu. Bardziej komplikujesz niż ułatwiasz. Niby chcesz niezależności bibliotek od samych siebie, a uzależniasz je od Workshop'a.
Ja mam w katalogu modules katalogi nazwane "core.database", "lib.messages", "mod.news".
Jakby do tego zrobić odpowiednią konfigurację z opisem zależności i występowaniem klas w danej paczce, to po małej modyfikacji autoloadera kohany wszystko by śmigało jak trzeba.
A jak ktoś by chciał to wrzuciłby sobie bibliotekę/moduł na sztywno i dodał do bootstrap jeśli wiadomo, że aplikacja zawsze z tego korzysta. Czyli w standardowy sposób z pominięciem Workshop'a.

OŚWIADCZENIE: Ja, niżej podpisany, świadomy wszystkich konsekwencji tego posta postanawiam go dopuścić do użytku publicznego, albowiem bo gdyż aczkolwiek uważam, że nie wyrządzi on (znaczy: post) krzywdy nikomu innemu niźli mnie samemu (czyli autorowi posta).
-- Zepco --


#13 ZuyPan

ZuyPan

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 171 postów

Napisano 06 maj 2012 - 15:35

Hmm... Nie bardzo wiem jak ugryźć wasze opinie :D
Tworząc Workshop przyświecała mi taka myśl: stworzyć pewną podstawę która ma swoje api i która będzie ładowała biblioteki i moduły. Co to daje? Wchodząc do folderu z workshopem jest czarno na białym co zostało użyte, w modułach są moduły a w bibliotekach biblioteki. Tymczasem w mojej skromnej opinii jeśli programista patrzy tylko pod kątem "aby działało" to wchodząc do MODPATH kohany czasami można złapać się za głowę. Więc wymyśliłem, że stworzę takiego jak by modloadera gdzie będę mógł umieszczać komponenty użyte przeze mnie podczas tworzenia serwisu a cała reszta to kwestia APPPATH.
Zepco napisałeś, że chcę uniezależnić od siebie biblioteki, ale zmuszam je do korzystania z Workshop - owszem taka jest idea tego projektu. Nie bardzo rozumiem z czego miały by korzystać te biblioteki jak nie z api systemu pod który są pisane? Zwłaszcza, że to api pozwala na zarządzanie konfiguracjami, daje instancje sesji i cache oraz zwraca inne informacje przydatne podczas działania samych bibliotek.
W przypadku zastosowania Workshop programista otwiera bootstrap oprócz takich standardowych wpisów jak database widzi też jeden niestandardowy - workshop. Otwiera więc ten moduł, czyta dokumentację i ma już jasno podzielone na Biblioteki i moduły które z nich korzystają. Otwiera następnie APPPATH i ma resztę projektu. Dla mnie jest to porządek, dla innych być może nie. Życzył bym sobie, aby każdy programista trzymał taki lub inny porządek w swoich aplikacjach bo naprawdę nieraz to aż się pracować nie chcę.
Tak czy postaram się rozwinąć Workshop i po jakimś czasie może uda mi się kogoś do niego przekonać :)
Pozdrawiam

#14 Zepco

Zepco

    Senior Mastah

  • Moderator
  • 1583 postów
  • Skąd:Kielce

Napisano 06 maj 2012 - 16:11

Szczerze mówiąc, to ja wolałbym, aby to w kontrolerach, modelach i samych bibliotekach był porządek i by były przejrzyste. Bo samo uporządkowanie osobnych modułów niewiele tu zmieni.
Miałem okazję pomagać kilka razy usuwać drobne błędy w pracach innych. Ale te drobiazgi były ciężkie w diagnozie właśnie ze względu na takie spaghetti w kodzie.
Oczywiście nie mam nic przeciwko Twojemu projektowi i będę mu się przyglądał.

OŚWIADCZENIE: Ja, niżej podpisany, świadomy wszystkich konsekwencji tego posta postanawiam go dopuścić do użytku publicznego, albowiem bo gdyż aczkolwiek uważam, że nie wyrządzi on (znaczy: post) krzywdy nikomu innemu niźli mnie samemu (czyli autorowi posta).
-- Zepco --





Użytkownicy przeglądający ten temat: 0

0 użytkowników, 0 gości, 0 anonimowych