Witam, z lekkim opóźnieniem ale udało mi się ukończyć wersje 0.1 mojego frameworka .

Strona projektu: http://framework.mohebo.pl
Dokumentacja: http://framework.mohebo.pl/docs

Paczka do pobrania: http://framework.mohebo.pl/files/mohebo-fw-0.1.0.tar.gz

Wiem, że to nie jest jeszcze gigant jak Symfony i brakuje mu masy opcji. Jest to raczej rdzeń frameworka z zaledwie kilkoma bibliotekami(chociaż pracować się już na tym da ). Chciałbym jednak usłyszeć czy idę w dobrym kierunku , co wam się podoba, a co nie, co należy zmienić, co dodać.

Pozdrawiam

PS: Jeśli chodzi o prędkość - w pliku index.php są zakomentowane standardowe linijki mierzące przedkość kodu.

niezłe, widzę, że wzorowałeś się chyba na ZF

na głównej brakuje linka do docs (jest tylko w topie), rozdział 10. Modele gdzieś zaginął. Poza tym wygląda interesująco, taki mix, specjalnie się chyba czymś nie wyróżnia. Powodzenia w dalszej pracy.

Minimalnie(widać to chyba po klasie Input). U nich jednak nie podoba mi się ten rozrzut, nie ma żadnej logicznej spójności w całym frameworku.



Rozdział 10 wrzciłem. Dzięki za uwagę. Link też za chwilę poprawię. Co do wyróżniania się aktualnie pracuję nad dodatkowym narzędziem - ajaxowym generatorem aplikacji. Działa to mniej więcej tak: Wybieramy z listy odpowiednie bajery, wpisujemy nazwy akcji i pól z bazy, zaznaczamy kilka checkboxow i mamy gotowy panel adm, wyswietlanie rekordow, sortowanie, stronnicowanie etc. . Mam nadzieje że to przyciągnie przynajmniej małą grupę użytkowników.

Nie wiem co mam, ale komp nie chce mi otwierac GZ ;/ Tylko twoich, BBCoda też nie mogłem. Możesz wrzucić w zip lub rar?

I co, myślisz że jesteś fajny ? Ogólnie to kawał roboty Ja używać nie będę, z wiadomych powodów no ale jeśli będziesz go stale rozwijał i promował to może zdobędziesz grono użytkowników

nie miałem na myśli samej budowy klas itp ale logika mi przypomina ZF nie pisze ze to żle. Ale ogólnie świeta robota. gratuluję:)

Proszę :-)
http://framework.mohebo.pl/files/mohebo-fw-0.1.10.zip


Dziękuję ;-)

1) Brzydka literówka w plikach językowych. original a nie orginal!
2) Dlaczego kontrolery dziedziczą po klasie, która się nazywa MoheboApplication? Dziwne nazewnictwo...
3) Ręcznie ładujesz widoki do kontrolerów. Czy to nie jest niepotrzebne? Z helperami jest tak samo.... osobiście wolę, jak te rzeczy są ładowane automatycznie. Inna sprawa z bibliotekami, to oczywiście ładujemy ręcznie. I widzę, że Twoje rozwiązanie (metoda load) działa analogicznie do Zend_Loader z ZF.
4) Opcja "maincontroller" jest zbędna. Powinien być budowany kontroler błędu (ErrorController/ExceptionController), gdzie użytkownik zostanie poinformowany "o co kaman". Przynajmniej jako rzecz opcjonalna, chyba, że Mohebo ma obsługę tych błędów.
5) Byłbym bardziej za użyciem PDO niż mysqli i innych klas przeznaczonych dla jednej bazy danych. PDO daje możliwość szybkiej zmiany bazy danych bez większego babrania się w kodzie modelu.
6) Narzucasz układ katalogów, co jest złym pomysłem - według mnie.
7) Nazewnictwo po raz n-ty. Zupełnie MoheboInput nie kojarzy mi się z walidacją danych.
8) Nie widzę tam jednej rzeczy - chwytania błędów aplikacji. Wszystko idzie po zwykłych Parse Error czy generujesz własne komunikaty?

Ogólnie rzecz biorąc porywasz się z motyką na słońce, jednocześnie czerpiąc z innych FW (głównie z Zenda jeśli dobrze widzę). Ja wiem, że mieć swojego FW to fajna sprawa, ale... po co? Skoro jest tyle dobrych frameworków.

A, bym zapomniał... nie dokumentujesz kodu według np. phpDocumentatora. I jak potem wygenerujesz sobie API Frameworka?

Rozrzut w ZF jest przydatną sprawą, bo ZF to (nie)framework Możesz, ale nie musisz budować struktury MVC. Wybór należy do programisty. A jak chcesz korzystać z tego wzorca, to bardzo ładnie można wszystko sobie poukładać - przynajmniej mi się to udało

Ups.. dzięki poprawiłem, Paczki są już zaktualizowane.


Niestety, Nie wyobrażam sobie ładowania np. 2 identycznych widoków. Muszę użyć funkcji load aby określić w ten sposób nazwę dostępową dla każdego z nich
Zend_Loader? Nie zaglądałem. Wzorowałem sie na rozwiązaniu które kiedyś mi Moli podsunął na gg,


Nie ma nic takiego na razie. Jeszcze myśle nad implementacją

Z pozostałymi pkt się po prostu nie zgadzam. Są to osobiste "widzimisie"

Co do PDO - nie zawsze ono na serwerze jest. Zreszta napisanie modelu PDO to też żaden problem. Zawsze mogą sąsiadować. Ja osobiście wolę dostęp bezpośredni



Wyczuwam ironię "co za noob, niech sie za to nie bierze" ;] Trochę chyba nie na miejscu,,,

A po co powstał Zend skoro istniało już tyle dobych frameworków(np. Symfony)? Po co Athlan pisał Vframe a Prph Rapide Framework? Po prostu inne rozwiązania mi nie odpowiadają. Potrzebuję lekkiego i szybkiego frameworka. Symfony jest zbyt mozolny a Zend to raczej zbiór bibliotek a nie framework.


Myślałem nad tym, ale nie jestem przyzwyczajony do np. phpDocumentatora i nie było czasu się przyjrzeć temu bliżej. W wolnej chwili uzupełnię braki

OT: To może Kohana?

symfony mozolny... już nie mogę czytac tego typu tekstów... co przeczytałeś testy wydajnościowe frameworków opierających się na echo "test";? :]

Edit:

Co do frameworka:

No cóż, gratuluję samozaparcia, ale ja kiedyś usłyszałem taki tekst:
"Po co robić coś od nowa, nie lepiej jakbyś dopisał/poprawił coś w już istniejących rozwiązaniach?" - wtedy się wkurzyłem, teraz widzę, że to zdanie jest bardzo mądre.

Tak czy siak, życzę powodzenia, ale pamiętaj, że konkurencja jest miażdżąca. Jednym z najważniejszych względów przemawiających za sf i zf jest to, że pracodawcy zauważyli i docenili te frameworki.

Poza tym nie uznaję żadnego poważniejszego kawałka kodu który nie używa składni phpdoca - dzięki niemu mam cudowne podpowiadanie składni w eclipse przy pracy z sf.

Edit2:

Odnośnie zdań na stronie głównej (wg. mnie całkiem ładna i przyjazna - najważniejsze rzeczy podane na tacy)


Nie obraź się, ale czy właśnie w sumie nie będę tego robił korzystając z tego frameworka?



W rozwiązaniach biznesowych bardziej się liczy żeby szybko coś napisać, bo "klient cośtam cośtam, potrzebujemy tego na dzisiaj na 16".

Ale żeby nie było że tylko psioczę - jeśli miałbym napisać coś małego, może nawet i bym skorzystał z Twojego frameworka.

@phpion: sprawdzałem . Bardzo fajny framework. Kilka rzeczy mi się spodobało więc można się spodziewać kilku fajnych zmian w kolejnych wersjach Mohebo .
@exek: osobiście testów nie wykonywałem ale testy w internecie jasno pokazują niską prędkość Symfony. Zresztą większość programistów php tak twierdzi w coś w tym musi być.

PS: dla ciekawskich, uruchomiłem
svn: http://svn.assembla.com/svn/mohebo
trac: http://trac.assembla.com/mohebo

EDIT:
@exek: Skladnię phpdoca powoli implementuję . Głowne funkcje są już opisane(w svn)

heh, nie rośmieszaj mnie tymi testami, proszę Cię .

Aha, brakuje mi jednej rzeczy - API. Nie samą dokumentacją się żyje.

EDIT:
IMHO bardzo dobre posunięcie z tym trackiem i svnem. Ale commity to się opisuje

EDIT2:
Nawet jeśli sf jest wolniejszy, to co? w 15 minut mam porządny szkielet aplikacji (m.in. wygenerowane obiekty z propela), jedną komendą instaluję sobie plugin do autoryzacji, mam autogenerację CRUDa też za pomocą jednej komendy.

EDIT 3 :

Chcę wysłać maila? no problem - mam sfMail. Chce wygenerować miniaturkę? mam sfThumbGenerator. Chcę coś innego raczej typowego? Mam to już zrobione. Chcę włączyć cachowanie? Martwi mnie tylko jak długo ma się cache trzymać. Chcę żeby wszystko było wygenerowane jako cache - strony html? instaluję plugin, etc. etc. To jest potęga frameworka - przeżyję, że generuje się coś 10 ms dłużej, jak zakoduję całość w miesiąc szybciej.

@Exek: nie chcę się kłócić ale w pierwszym poście pisałem, że to tylko szkielet. Praca wrze . Nad CRUD pracuję(dokładniej nad graficznym generatorem kontrolerow/modeli/widokow/tłumaczen via www z prostego edytora). Nie dziwię się, że Symfony jest dużo bardziej rozbudowany, ten framework istnieje już kilka lat i ma już niemałą społeczność.

aj wybacz, bo ja jestem fanboyem symfony . Wiem, że to wersja 0.1... ale może pokusisz się o roadmap, żeby było wiadomo co chcesz tak na prawdę zrobić?

A co do tracka, obsługę ticketów zrobiłeś za pomocą assembly czy czysto przez tracka? Moim zdaniem, ładniej jest jak wszystko w tracku siedzi.

EDIT:
fajnie by było gdyby w katalogu application można było stworzyć więcej niż jedną aplikację (tak jak jest w symfony ). Tzn. mogę sobie zrobić backend i frontend które część konfiguracji mają wspólną.

Jest taka możliwość po przez odpowiednie ustawienia configset oraz controllerset dla poszczególnych aplikacji(nie ma mozliwości bezpośredniego przypisania poszczególnych plików lub np. kilku katalogów).

Roadmap na najbliższe 2 tyg. pisany na szybkiego: http://trac.assembla.com/mohebo/browser/README

Jeśli jest taka możliwość to czy jest to opisane w dokumentacji? (bez bicia powiem, nie sprawdziłem w docu).

Na razie wygląda to całkiem obiecująco, także życzę powodzenia w dalszej pracy .

Jest ;-) http://framework.mohebo.pl/docs-7
Umożliwia to stworzenie kilku aplikacji o różnych hostach w jednym miejscu w oparciu o te same pliki :-).


Dzięki za zainteresowanie i życzenia

Odnośnie http://framework.mohebo.pl/docs-8, zrób tak żeby w jedym pliku można było trzymać kilka tłumaczeń, bo tworzenie 4 plików w których tworzysz tyle samo <message> z takim samym <orginal>jest dobijające. Nie mówiąc jak później chce się dodać 10 nowych zdań do 4 różnych języków.

Aktualną składnię wybrałem ze względu na prędkość.
Powiązania między kilkoma plikami tłumaczeń będzie załatwiał graficzny edytor . Temat: Edytor_tlumaczen

Prędkość czego? Bo pewnie jakieś keszowanie zrobiłeś do tych xmli? A o edytorze zaraz się wypowiem w odpowiednim topicu.

W temacie dotyczącym Spawnm Frameworka Spawnm napisał:

Zajęło mi to kilka dni ale przygotowałem paczkę .

Mohebo Framework 0.2

Huh, minęły prawie 2 lata. Sporo programowałem w tym czasie, często w oparciu o mój własny framework. Ten czas spowodował, że kilka rzeczy usprawniłem tak aby pracowało mi się szybciej i wygodniej. Pełnej listy zmian nie jestem w stanie podać ponieważ nie robiłem jej na bieżąco i nie wiem dokładnie co się zmieniło ;]. SVN zaktualizuję jutro, wtedy dowiem się więcej.


Krótki Changelog


Framework można pobrać z mojego katalogu z projektami:
http://srodek.info/files/MoheboFramework-0.2.tar.gz

Dokumentacja jest dostępna pod adresem http://mohebo.com oraz wewnątrz paczki

Nowością jest katalog generator/ - jest w nim crud.php(nad tym to ja się dłuugo męczyłem) - plik generujący moduły administracyjne na podstawie plików konfiguracyjnych ( domyślnie 3 dostępne - in_news.php, in_galleries.php oraz in_photos.php) W środku katalogu TODO tłumaczące kilka rzeczy
Jestem leniwy i pisanie tych plików konfiguracyjnych ręcznie mnie nudzi więc tworzę powoli edytor graficzny - generator/configCreator.php Niestety nie działa on do końca poprawnie więc nie zalecam jego stosowania. Wrzuciłem jako ciekawostka

Czekam na wasze komentarze i opinie.

Co w najbliższej przyszłości? Zmiana architektury na prawidłowe MVC - tj. przerzucenie pobierania danych z kontrolera na widoki(starą konwencję również pozostawię) tak aby one same potrafiły dobrać się do odpowiedniego modelu. Możliwość tworzenia własnych filtrów oraz kilka innych usprawnień(to jeszcze zależy co mi zaproponujecie).

Dlaczego warto używać?
- lekki
- prosty
- chętnie pomogę na forum w przypadku wszelkich problemów oraz napiszę(o ile będą sensowne) dodatkowe moduły o jakie mnie poprosicie tak aby rozwijać ten framework w odpowiednim kierunku.

Pozdrawiam .

PS: piszę tutaj ponieważ jeden projekt = jeden temat. Jeżeli moderatorzy sądzą, że 2 lata to za długo to proszę wydzielić posty do oddzielnego tematu.

Z klas które mnie zainteresowały będzie chyba translator , przyjrzę się jemu potem z bliska

Ale sieczka z wcięciami , kodem w komentarzach i brakiem komentarzy przy wielu metodach xp
Nazwy plików też ciekawe imageCreator.php , rainbow.class.php , rainbow_compiler.class.php ...

Kwiatki:

[PHP] pobierz, plaintext 
class MoheboApplication extends MoheboController{}
/...
class MoheboView
{
	protected $core = null;
}
[PHP] pobierz, plaintext 

Spodziewałem się więcej po klasie mysqli ...
A pisałeś że masz lepszy

tzn?


Sporo tego jest powoli wszystko aktualizuję. Szczególnie wstawki phpdoc


To jest katalog z bibliotekami gdzie nie obowiązuje żadna konwencja co do nazwenictwa

Co do kwiatków w kodzie:
kwiatek 1: jest to spowodowane zmianą nazwy klasy z MoheboApplication na MoheboController. Zostawiłem do kompatybilności
kwiatek 2: Ok, brakuje słowa kluczowego abstract. Ta klasa jest bardziej pisana "na przyszłość"


mysqli wygląda jak wygląda ponieważ wbudowany w php moduł MySQLi jest całkiem dobry. Myślę jedynie nad dodaniem sterownika PDO lub własnego ORM-a

Zobacz sobie np. taki lib/mail.php

dalej:

[PHP] pobierz, plaintext 
	/**
     * Zwraca wartość opcji o określonej nazwie
     * @param string $name
     * @return string
     */
	public function getOption($name)
	{
		if(isset($this -> options[$name]))
			return $this -> options[$name];
		else return null;
    }
 
	/**
     * Ustala wartość opcji o określonej nazwie
     * @param string $name
     * @param mixed $value 
     */
	public function setOption($name, $value)
	{
		$this -> options[$name] = $value;
    }
[PHP] pobierz, plaintext 

nie wiem jak to tutaj wyświetli ale wcięcia to jak polecą tak będą z tego co widzę...

Dalej idąc - po co html ładowałeś do pagera ?

Ok dzięki. Reczywiście w email.php połowa wcięć jest robiona spacjami połowa tabulacją(przy ustawieniu tabulator = 4 spacje wygląda to normalnie). W pliku router.php komentarze dopisywałem później jak widzę z włączoną konwersją tabulatora na spacje. Zmienię to i sprawdzę czy inne pliki nie maj podobnych. Unormuję też kwestię pozostawiania lub nie nawiasów przy instrukcjach warunkowych bo jak widzę w starych plikach różnie to bywa.

2. A jak to inaczej rozwiązać? Pager powinien zwracać tablicę z elementami a nie kod html?

EDIT: poprawiłem te wcięcia, wyrzuciłem zakomentowane metody i zrobiłem reupload paczki

Zobacz jak to rozwiązałem ja
pager jako model robi obliczenia ile jest stron na jakiej jesteśmy itd. wynik przekazuje do widoku przez np. render po czym zwraca html z widoku. (do głównego pliku/kontenera widoku)
Czyli oddzielamy widok od modelu , u ciebie to jedność w pagerze.

[PHP] pobierz, plaintext 
public function rotate($angle)
	{
 
	}
[PHP] pobierz, plaintext 

Dalej

[PHP] pobierz, plaintext 
resize_photo($img,$max_width,$max_height, $saveTransparency)
[PHP] pobierz, plaintext 

Czemu tutaj już nie dałeś $this -> readyImage ?

//edit
widzę że mieszasz w nazwach metod, raz dajesz z garbem getOption a raz z '_' resize_photo

Chroń wszystkie plik przed bezpośrednim dostępem via WWW
/theme/framework/footer.php
/theme/framework/header.php
/theme/framework/index.php
(te pliki sypią błędami)

Utwórz pusty plik index / .htaccess bo możliwe jest listowanie katalogu
/application/cache/view/xhtml/

Nie privigles tylko privilege / privileges

Stworzę stosowny plik htaccess



Ups. Straszna literówka. No nic pozmieniam wszystko i wrzucę paczkę za kilka minut...
EDIT: literówka poprawiona, uprawnieniami do katalogów zajmę się później...

Nie zagłębiałem się rozwiązania, kiedyś jakiś kwiatek w FW Spawna znalazłem, ale nie chciało mi się pisać.
Teraz jednak zapytam.

[PHP] pobierz, plaintext 
class MoheboApplication extends MoheboController{}
class mysqliModel extends MoheboApplication {}
[PHP] pobierz, plaintext 

Czyli co w końcu?

@Cysiaczek: trafna uwaga. Po prostu model i controller współdzielą sporo rzeczy. Zmieniłem Appliacation na Controller, a nie sprawdziłem zależności ;]. Widzę, że będę musiał zrobić MoheboXX(nad nazwą pomyślę), a z niego bedzie dziedziczyc MoheboController oraz MoheboModel. MoheboApplication wywalę w ogóle.

Dzieki jeszcze raz za komentarze i wyłapywanie głupot .

A nie lepiej utworzyć klasę "MoheboXX", której obiekt będziesz przekazywał do obiektów MoheboController oraz MoheboModel? Co wspólnego ma model i kontroler? To nie jest ta sama gałąź dziedziczenia, mają całkowicie inną budowę, inne zadania, jest to inna warstwa aplikacji. Poza tym w niektórych sytuacjach dziedziczenie lepiej zastąpić kompozycją, tak jak np. w tym przypadku. Nadużywanie dziedziczenia nie jest dobrym nawykiem (tak w ogóle to nie ma dobrych nawyków, ale to temat na inną dyskusję ).

Jestem przyzwyczajony do tego, że jedna klasa lub nawet interfejs z jedną jedyną metodą jest w osobnym pliku, no chyba że jest to klasa, która jest wykorzystywana tylko przez główną klasę w pliku i żadna inna klasa nie wie o jej istnieniu. Ale to już kwestia standardów jakich się trzyma

@-=Peter=-: ok, dzieki za uwagi. Dostosuję sie


--
EDIT:
Robię powoli porządki.

Ukończyłem kolejną wersję mojego frameworka php. Zmian jest niewiele lecz dotyczą głównego rdzenia oraz struktury frameworka. Jeżeli zajdą kolejne w strukturze plików i katalogów będą one jedynie drobnymi zabiegami kosmetycznymi. Zaktualizowałem stronę frameworka ? http://mohebo.com. Przepisałem dokumentację, tak aby przykłady działały w wersji 0.3. W przypadku błędów, problemów itp. proszę o kontakt bezpośredni.

Zapewne wiele osósb mogłoby zarzucić mi podobieństwo do Zenda . Dzieje się tak ponieważ tworzę warstwę kompatybilności, co umożliwi mi włączanie poszczególnych elementów Zenda do siebie. Po prostu nie chcę pisać od zera wielu bibliotek(np. generatora pdf, mailera etc).

Najważniejsze zmiany:

* Rozbudowałem klasę logującą błędy o wyświetlanie backtrace?u w postaci pokolo­rowanego kodu php wyciągniętego z plików powodujących błąd.
* Zmiana struktury katalogów. /system został przekształcony w /library. Katalog /log wskoczył wewnątrz application oraz doszedł nowy katalog bin(w nim będzie dostępna konsola od 0.4).
* Zmiana nazw klas i plików. Teraz każdy plik i klasa rozpoczyna się wielką literą.
* Przebudowa autoloadera. W przypadku stworzenia obiektu klasy Klasa_Cos_Innego lub KlasaCosInnego zostanie autmatycznie odczytany plik Klasa/Cos/Innego.php. Jednak w przypadku tworzenia obiektu klasy Klasa_Cos_InnegoTutaj już Klasa/Cos/InnegoTutaj.php. Dzięki temu zachowałem w pewnym stopniu kompatybilność z PSR-0 jednocześnie pozostawiając własną metodologię nienaruszoną.
* Dodanie metod init() orad end() do controllera. init() jest wyko ny wane przed uru­chomieniem akcji, end() po(Przy czym, jeżeli jedna akcja wykona inną akcję init() oraz end() zostaną wywołane tylko raz).

Link bezpośredni do paczki: http://srodek.info/files/MoheboFramework-0.3.tar.gz