Dziś ukazała się nowa wersja popularnego frameworka dla programistów php Spawn Framework o numerze 1.2.6.

Najważniejsze zmiany:

Nowa klasa - sf_translate !

Dodane nowe metody dla sf_acl:

* inherit($name, $inherit)
* getGroupRole($name)
* getRole()
* removeGroupRole($name, $role)
* removeGroup($name)
* removeRole($name)
* getGroup()
* groupIsset($name)


Modyfikacja sf_auth -
dodanie nameIsset(),
rozbudowa konfiguracji.

sf_db , sf_orm - dodanie getParam()
sf_view - dodanie replace().
Dodatkowo - optymalizacja kodu, poprawa kilka niedociągnięć :-)

Najnowszą wersję można pobrać z http://spawnframework.com/download

Czy inherit w Acl działa "live" tzn jeżeli
B dziedziczy po A
to czy po zmianie uprawnień A uzyska je ODRAZU B?

Tak z czystej ciekawości: przeglądam dokumentację Spawn Framework i odczuwam dość mocne wpływy Kohany. Dobrze odczuwam?

@wookieb - inherit(a, dziedziczy z b wszystkie role z chwili wywołania , jeśli już po inherit zajdą jakieś zmiany na b , a tego nie odczuje.

@phpion - np? W czasie pisania fw przeglądałem kilka innych fw szukając inspiracji , pewnie i jakieś rozwiązania z kohany mogłem dodać u siebie bo uznałem że są ok.(ale na pewno nie pod względem budowy kodu bo ten w ko jest chwilami bardzo słabej jakości )

Szczerze? To wolałbym, żęby taki INHERIT został zrobiony na poziomie interfejsu niż w php, ponieważ nie ma to sensu.

Hmm przemyślę to co mówisz

Popularny to jest Zend, Kohana, Cake, ty lepiej wpisz "autorskiego frameworka" bo jeżeli miarą popularności jest liczba pobrań to wiedz że ludzie chcą wniknąć w kod, i podejrzewam że niewiele (jeśli wogóle są) jest projektów z jego wykorzystaniem napisanych (pewnie twoje są).

No ale oby tak dalej bo idzie w dobrą stronę

skowron-line - wiadomo że nie tak popularnego jak zend. A to że jest jakaś popularność oceniam po google analytics oraz prywatnych korespondencjach.

@skowron-line to samo chcialem mu napisac ale zostawilem dla siebie ta uwage.

Tak ogolnie to obrazisz sie jak porzycze sobie twoja klase do Acl oczywiscie w pliku bedzie napisane ze to twoja klasa, obrazisz sie?Bo nie chce mi sie kodu klepac.

Ja moge polecic: http://redmine.boduch.net/projects/coyote/repository i tam samo CMF postawionym na tym fw, zajebista sprawa!Inne popularne fw maja chyba na noc ;]

Spoko, pożyczaj

@marcio: http://spawnframework.com/license
O ile będziesz przestrzegać zapisów w tej prostej licencji, nie musisz prosić autora o zgodę, może się on na Ciebie obrazić - i tak Ci nie będzie mógł zabronić korzystania z tego.

Hehehe . Panie moderatorze, czyżby nie nazbyt naciągnięta opinia ?

Czy ja przypadkiem 4 posty wyżej nie wyjaśniałem kwestii popularności tego fw?

Hehe Sława uderzyła do glowy
Nie no żartuje
Co Cię skłoniło do "upublicznienia" swojej pracy?

Kurde tez bym pokazal swoje dzielo, tak zeby poschulas opini innych czy fajne sa moje rozwiazania itp..itd...
Kod jednak w wielu miejscach nie jest zbyt piekny, calosc chodzi pieknie i wedlug ma troche wiecej mozliwosci rozbudowy, jesli chodzi o komponenty itp...
Moze jak skoncze pochwale sie ;p

Mam mieszane uczucia co do upubliczniania swoich prac z tego względu, że ocena "dzieła" nigdy nie będzie prawdziwie miarodajna.
Podam przykład. Spotkałem się z przypadkiem wyboru uploadera flashowego.
Jednym z kryteriów wyboru było "ilość wyników w google" - google trends i jazda. Wybór padł na swfupload i co? Okazało się, że jest w nim jeden zajebiście duży błąd a mianowicie
handler obsługujący zdarzenie onUploadError jako trzeci parametr powinien przekazać KOMUNIKAT zwrócony z serwera a zwraca status http (czyli zawsze 500) i do tej pory ten błąd nie jest poprawiony.
Jak to możliwe?
A teraz zapytaj na naszym forum o dobry uploader flashowy to spotkasz się odpowiedzią "SWFUpload" pomimo tego, że jest wiele innych lepszych uploaderów. Pomijam kwestię, że uploader w stylu SWFUpload jest... ośmieszającym podejściem do tematu.

Dla mnie osobiście "produkt" spawn'a nie jest rewelacją. Nie podoba mi się, mam inny "gust" programistyczny i nawet gdyby był dobry to mało kto dostrzegłby jego wartość. Takie jest moje zdanie.

@SPAWN mam nadzieję, że kiedyś znajdę czas aby opisać co mi nie pasuje w twoim FW.

Jeśli chodzi o upubliczniania swoich prac.
Idąc tropem że open-source jest be dzisiaj mieli byśmy monopol m$ i jechali byśmy na ręcznym(bez fw typu zend) w php ... a nie , php jest open-source ...


Masz prawo mieć własny gust , nie podoba ci się Spawn możesz wybrać coś innego lub napisać własne fw. Kto powiedział że mój fw ma się podobać wszystkim
Jednak jeśli w wolnej chwili wymienisz główne elementy tego fw które cię do niego zniechęcają będe wdzięczny. Może dzięki temu z czasem mój fw stanie się jeszcze lepszy.

Co do "mało kto dostrzegłby jego wartość." to czas mi pokazuje że coraz więcej osób rezygnuje z kohany na rzecz spawna , tyczy się to zwłaszcza osób które dopiero wchodzą w świat frameworków i zawiodły się na Ko. Czyli mojemu fw potrzebny jest czas aby 'ktoś' dostrzegł jego wartość.


Aż tyle tego No spoko, chętnie poznam twoją opinię na temat poszczególnych elementów mojego fw, priv zawsze czysty jak coś

No i nadeszła chwila prawdy
Na początek przyznam, że nie czytałem dokumentacji.
Skupiłem się tylko i wyłącznie na kodzie, poprawności napisania, łatwości użytkownika, szukania pułapek dla programisty.
Zaczynamy:

- Jaka jest różnica między plikami .phtml a .html w szablonach? Dlaczego nie może być jednego rozszerzenia?
-

[PHP] pobierz, plaintext 
defined('SPAWNM') OR die('No direct access allowed.');
[PHP] pobierz, plaintext 

Takie coś robi się za pomocą .htaccess (tak jak to masz w library/sf/cache) albo umieszczenie plików poza katalogiem www
- Podoba mi się, że używasz standardowych szablonów korzystając z czystego .php ale niestety składnia jaką się posługujesz powinna być inna (jak dla mnie bardziej czytelna) w stylu

[PHP] pobierz, plaintext 
<?php if(true) : ?>
<?= $zmienna ?>
<?php endif; ?>
[PHP] pobierz, plaintext 

- Co to za pusty bootstrap?

- sf_acl - Żadna klasa, która ma wpływ na system NIE MOŻE być klasą statyczną. Wywal statici. Jeżeli ktoś będzie chciał, użyć Acla w stylu "statycznym" użyje Rejestru. Uwaga tyczy się reszty statycznych klas, mających wpływ aplikację. Narzucasz użytkownikowi pewną "konieczność", która jest zła.
- Gdzie są testy jednostkowe?
- Singleton z registry Śmieszna i wybuchowa mieszanka
- sf_session::deleteAll - Naprawdę nie prościej jest zrobić?

[PHP] pobierz, plaintext 
$_SESSION = array();
[PHP] pobierz, plaintext 

- Skalowalność sesje, cache itd a właściwie jej brak
- Masz zły phpdoc

Powinno być

- Brak phpdoca dla właściwości klas - szczerze to prawie cały jest do zmiany
sf_captcha : 16 - nie wiem co to za obiekt.
- controller.php : 88 getAction
Dla mnie mały "bałagan". Dlaczego metoda kontrolera może tworzyć inne kontrolery i pobierać od nich akcje? Czy nie powinno się to dziać w frontControlerze (którego chyba nie masz)?
- Klasa Date - naprawdę DateTime wbudowany natywnie w php jest wystarczający

- Db - wspomnę jeszcze raz, że statyki nie mogą mieć wpływu na system. W tej klasie jedyną metodą statyczną jaka powinna mieć miejsce to "poCoszukaszTutajStatic"
- Exception : 21 - chyba nie ma klasy sf_filtr
- Form poległ na całej linii - polecam spojrzeć jak działają klasy formularzy w innych fw np w Zendzie
- sf_html - Po co takie klasy w kodzie? Ale tak szczerze. Zbyt wiele nie ułatwiają a czasem są kompletnie nieprzydatne.
- sf_image - typ obrazka sprawdzamy za pomocą FileInfo z tego względu, że get imagesize można dość łatwo oszukać
- sf_image::trueResize - w temacie OFFTOP podałem ciekawszą metodę obliczania nowych rozmiarów zdjęć
- sf_jquery - Jak już to do tego celu służa helpery w szablonach
- sf_math - służy jedynie dla przeliczania kolorów więc nazwa jest myląca. Dlaczego by nie przenieść do sf_colortransform?
- na temat modelu i orm się nie wypowiadam bo to bardzo śliski temat
- sf_pager podaj przykład paginacji na rekordach. Chyba nie obejdzie się bez ręcznego klepania?
- sf_request - dlaczego ludzie filtrują dane na samym wstępie aplikacji zamiast po prostu wtedy kiedy potrzebują?
- class sf_template extends sf_controller - o nie nie panie. Logicznie te klasy nie mogą mieć ze sobą nic wspólnego ponieważ realizują kompletnie 2 różne funkcjonalności
- sf_translate::_loadTranslate - obsługę różnych formatów robi się za pomocą adapterów albo rozszerzeń klasy bazowej
- sf_upload : 147

[PHP] pobierz, plaintext 
if( isset($this->_img->sevaFileName) ) $newFileName = $this->_img->sevaFileName;
[PHP] pobierz, plaintext 

sevaFileName? W klasie sf_image nie ma takiej właściwości.
- gdzie repozytorium dla projektu? Chociażby GitHub
Podsumowanie
Wydaje mi się, że nie projektowałeś tego FW tylko pisałeś na żywioł. Brak testów jednostkowych powoduje, że twojemu FW nie można po prostu ufać.
Jest kompletnie nieskalowalny i nie założyłeś możliwości bardziej zaawansowanego użycia. Przykładowo nie mogę zmienić mechanizmu przechowywania sesji na memcache albo coś innego, ale przypadków jest oczywiście znacznie więcej.
Oczywiście nie mówię aby system był w stanie obsłużyć wszystko, ale ty powinieneś dać możliwość łatwego rozszerzenia jego funkcjonalności. Aktualnie jest to niezwykle trudne (czytaj nieskalowalne).
W skrócie system był dobry parę lat temu ale nie na te czasy.

A teraz plusy
- prefixy klas - prawidłowo sf_*, controller_*
- method chaining
- brak statycznego sf_translate
- ogólnie bardzo prosty w użyciu
- ... staram się szukać czegoś na siłe ale to chyba tyle

Może, standardowo ładuje .phtml .
Rozdzielanie na .phtml i .html ma informować o treści szablonu - .phtml - html z php , .html czysty html
Oczywiście możesz wszystko ładować tylko do .phtml


plik dla programisty oddzielający jego skrypty od spawnowych, dajesz tam np. translateUri


Hmm tak powiadasz Przemyślę.


I tak zrobię, dzięki :-)


Mocno przesadzasz, ale to pewnie kwestia gustu.

[PHP] pobierz, plaintext 
$pager=new sf_pager(array(
    'total'=>sf_orm::factory('news')->count(),
    'limit'=>5
));
$news=sf_orm::factory('news')->findAll( $pager->offset(), 5);
foreach($news as $key){
   echo $key->title.'<br/>';
}
echo $pager->render(); 
[PHP] pobierz, plaintext 

Hmm gdzieś musiało mi się coś pomieszać, poprawię


Przejrzyj dokumentację a może stanie się jeszcze prostszy oraz chociaż częściowo zmienisz zdanie o niektórych klasach.

Mam prośbę: źródło.

@Crozin - chcesz maile/imiona ? Jakiego ty się źródła spodziewasz bo nie za bardzo wiem ...

Jakiegokolwiek źródła, skąd masz takie informacje? Pewnie napiszesz, że z prywatnej korespondencji mailowej - a może jednak podasz jakiegoś linka do poparcia tego stwierdzenia? Przyznam, że jest ono dość odważne...

Piszesz o "popularnym frameworku" (wiem, że już to sprostowałeś, jednak w pierwszym poście nadal to wisi), "osobach odchodzących od Kohany na rzecz SF" - to wszystko ładnie brzmi, ale jeżeli nie jest poparte jakimiś statystkami to jest to zwyczajne "marketingowe kłamstwo". Poza tym ile osób przerzuciło się na Twoje rozwiązanie? W jaki sposób mierzysz popularność? Chyba nie względem ilości pobrań? Bo w tej chwili właśnie nabiłem Ci statystkę, ale używać tego FW nie mam zamiaru. Ile osób w tym czasie zaczęło korzystać ze wspomnianej Kohany (notabene słaby FW).

Swoją drogą do sprawdzania czy klucz tablicy istnieje jest array_key_exists, nie isset - oto dlaczego

EDIT: zapomniałem dopisać.
A index.php to niby co to jest jak nie Front Controller? I dla jasności: we front kontrolerze nie powinno dochodzić do wywoływania akcji/ustalania co wywłać.

Wiem że jest dość odważne, możliwe że nawet trochę nie rozsądne na daną chwilę bo mogłem się spodziewać pytań o linki/źródła czy coś.
No ale jednak jak pisałem wcześniej moje 'statystyki' jeśli chodzi po popularność to tylko google analytics z którego takich info nie mam i privy.

1) array_key_exists jest wiele razy wolniejsze od isset (sprawdzałem, zachęcam do przeprowadzenia testu)
2) najczęściej szukając klucz w pewnej tablicy spodziewamy się iż ma jakąś wartość, więc jeżeli ma null nas to nie interesuje, dlatego lepiej użyć isset


Oj chyba jednak powinno. Zresztą wszystko zależy od struktury FW.


Oczywiście, że nie przesadzam ponieważ twoja klasa formularza służy tylko i wyłącznie do jego wyświetlania.
Nawet nie wspiera:
a) walidacji
filtrowania danych
c) nie posiada zabezpieczenia przed xss, tudzież niepoprawnie wyświetla wartości w atrybutach "value"
d) tak naprawdę całą obsługę formularza wraz z wszystkimi standardowymi operacjami isset, trzeba pisać ręcznie.

Co mi po takim narzędziu do formularzy skoro równie dobrze można zamknąć całą jego funkcjonalność w zwykłe szablony.


Ok a jak to bedzie wyglądało na zapytaniach bardziej złożonych? Np z joinami?


Niee. Napisanie w dokumentacji "tak jest bo jest" nie zmieni mojego zdania, które podałem wcześniej. A szczególnie kładę nacisk na skalowalność.

Tak, wiem że jest wolniejsze - ale za to działa poprawnie. I nie mów, że jak sprawdzamy czy klucz tablicy istnieje to wartości NULL nas nie interesują bo to już pod bzdurę podchodzi. Zresztą NULL to już jest jakaś wartość i informacja zarazem.

$form->toError($valid->getError()); jeśli chodzi o wsparcie walidacji

"d) tak naprawdę całą obsługę formularza wraz z wszystkimi standardowymi operacjami isset, trzeba pisać ręcznie."
?


Ale w czym problem? Co takie bajery mają do samej paginacji?

[PHP] pobierz, plaintext 
$pager=new sf_pager(array(
    'total'=>sf_orm::factory('news')->with('cos')->where(...)->count(),
    'limit'=>5
));
$news=sf_orm::factory('news')->with('cos')->where(...)->findAll( $pager->offset(), 5);
foreach($news as $key){
   echo $key->title.'<br/>';
}
echo $pager->render(); 
[PHP] pobierz, plaintext 

W ile procentach przypadków? 5%? Oczywiście, że w większości nas to nie interesuje bo rzadko kiedy trzyma się nulla w tablicy po prostu.


Łoo no to żeś wsparł walidację...


Czyli twoja klasa formularza załatwia tylko wyświetlanie ale nie sprawdzi już czy wartość przesłana POST-em w selectcie występuję na liście jego opcji. Nie sprawdzi czy wartość dla elementu powinna być tablicą czy nie. Dodatkowo musisz sprawdzić czy wszystkie pola są aby na pewno w POST (czyli isset($_POST['pole']) itd). Prawdziwa klasa formularza dostaje na wejściu np POST-a i w metodzie getValues() zwraca Ci ładną przygotowaną tablicę wszystkich wartości, które na pewno są prawidłowe (jeżeli dane przeszły walidację)



Sprawdź dokładnie czy to działa, bo w metodzie sf_db::count nie widzę uwzględnienia:
a) joinów
where
c) group by
d) having Ci daruje

W metodzie sf__orm::with nie rozróżniasz typów Join-a (LEFT, INNER, OUTER)

od isset $_POST masz sf_request np. $req->post('dupa');


No rzeczywiście przez te kropki w where(...) wywala jakiś błąd
A na serio to działać działa z wszystkimi bajerami bo nawet na stronie z fw jest kilka joinów itd. (np. na forum)


Jaśniej , przecież ustawiasz w modelu tabeli 'type'=>'join', //join , join left etc...

5% przypadków to mało? Przy czymś takim 0.1% to już zdecydowanie za dużo. Kod ma sprawdzić czy klucz istnieje - klucz istnieje, a ten zwraca, że nie - to jest po prostu błędny kod i nie ma tu usprawiedliwienia.

To, że Ty rzadko używasz NULLa, to Twoja sprawa - mi się to zdarza relatywnie często.

Faktycznie nie zauważyłem na liście


A no tak bo to ORM. A jeżeli zaistnieje konieczność zmiany typu joina to co wtedy? Da się to jakoś zmienić?

Co do paginacji zaraz sprawdzę.
Where działa. Joinów nie sprawdzałem a group by nie działa.
Spaginuj takie zapytanie

[SQL] pobierz, plaintext 
SELECT * FROM tabela GROUP BY jakies_pole_powodujace_zwrocenia_mniej_rekordow_niz_w_calej_tabeli
[SQL] pobierz, plaintext 

Proszę o przykład

Ale co, mam Ci podać przykłady użycia NULLa (to, że akurat mowa o NULLu w tablicy nie ma większego znaczenia)?

Przede wszystkim zawsze kiedy chcesz poinformować, że czegoś nie ma, jest nie ustawione, nie istnieje lub nie jest za zainicjalizowane.
Przykładowo: pobierasz dane z bazy i masz kolumnę z NULLem.

Do php dotrze to jako pusty tekst a nie jako null.

NIe mniej jednak zgadzam się z Tobą, że isset dajacy dla wartosci null FALSE to pomyłka jakaś.

[PHP] pobierz, plaintext 
isset($rekord['pole'])  // ups zapomniałeś podać jakieś pole
array_key_exists('pole', $rekord) && !$rekord['pole'] // ups zapomniałeś podać jakieś pole
[PHP] pobierz, plaintext 

Jeżeli to zły przykład to nawet gdy pobierasz rekord z tablicy to raczej znasz strukturę tablicy zwrotnej.


Ja doskonale rozumiem, że null w tablicy może wystąpić ale dzieje się to tak kur.... rzadko (szczególnie, jeżeli w aplikacji używasz mało tablic) że często się to pomija.
W formularzach? isset
W iteratorach? tak tutaj może być array_key_exists - zależy kto jak często używa iteratorów
W szablonach i metodach __set __get nie ma kompletnie żadnej różnicy
Obsługa $_GET, $_POST, $_COOKIE - isset (nie jest możliwe wstawienia NULL-a)
Wszelkie kontenery - jeszcze nie spotkałem przypadku, gdzie kontener musiałby mi przechowywać null-e

Jak dla mnie ogromne ułatwienie. Poza tym sama nazwa wskazuje na
is (czy jest) set (ustawiony). Ustawienie wartości na null oznacza jej brak, czyli wartość nie jest ustawiona.

możesz zadeklarować w modelu tabeli kilka opcji dla with() lub użyć od tak ...->join()->...


hmm jeśli chodzi o group to racja, obecnie w count sprawdzam czy jest where i jak nie ma to leci sztywne zapytanie, aby działało trzeba by dać jakikolwiek where np id>0... poprawi się :-)

Ok super.


Niestety nie.
Count dla zapytań z group by robi się w ten sposób

[SQL] pobierz, plaintext 
SELECT count(DISTINCT coalesce(pole_z_group_by,1) [, coalesce(pole_z_group_by, 1)] ) FROM tabela [WHERE] -- już bez group by
[SQL] pobierz, plaintext 

gdzie coalesce wstawiasz tylko dla tych pól, które mogą mieć NULL w wartości

Przy having jest chyba jeszcze trudniej.

Z niedowierzania aż sprawdziłem:
Jeden wiersz to pusty tekst, drugi NULL

[PHP] pobierz, plaintext 
<?php
 
$h = new PDO('mysql:host=127.0.0.1;dbname=test;', 'root', '');
$stmt = $h->query('SELECT colname FROM nulltest;');
var_dump($stmt->fetchAll());
[PHP] pobierz, plaintext 

Wynik:

To, że nie jest to jakieś wyjątkowo częste zjawisko to chyba wszyscy się zgadzamy. Ale ono występuje i trzeba to mieć na uwadze, bo w końcu wystąpi i będziesz przez 5 godzin szukał przyczyny - albo co gorsza, nie zauważysz błędu. isset jest szybsze, ale się nie nadaje, bo nie spełnia warunków - nie jest w stanie określić czy klucz tablicy istnieje - to jaką on ma wartość to nas nie interesuje.

Tak - wartość nie jest ustawiona - ale klucz już tak. Poza tym brak wartości to już wartość. Czym innym jest $a = null;, a czym innym jest w ogóle nie istnienie zmiennej $a.

Hehe Crozin nie rozumiemy się
Ja nie mówię, że array_key_exists nie powinno się używać. Jak najbardziej powinno ale tylko w miejscach w których możliwe jest wstawienie NULL-a tylko, że tych miejsc jest wyjątkowo mało

Właściwie to można przyjąć, że w $_GET/$_POST/$_COOKIE nie ma nulli - chociaż jakby się uparł ($_POST['a'] = null; (notabene PHP powinien obsługiwać final dla zmiennych) - ale jak występuje takie coś to ktoś już ma dużo poważniejszy problem :]). Wszędzie indziej mogą wystąpić i prędzej czy później wystąpią.

A ja mam pytanie - wypomniałeś mi że używam isset zamiast array_key_exists - gdzie twoim zdaniem lepiej sprawdzi się array_key_exists bo osobiście nie widzę takiego miejsca?

O ile dobrze pamiętam to w sf_array::get - nie chce mi się wszystkiego ściągać jeszcze raz.