Spawn Framework 1.2.6 wydany! Opcje

[Spawnm]

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

[phpion]

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...

[Crozin]

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ć.

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)?

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ć.

Ten post edytował Crozin 19.09.2010, 12:32:06

[Spawnm]

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.

A to że jest jakaś popularność oceniam po google analytics oraz prywatnych korespondencjach.

[wookieb]

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

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

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ć.

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

Mocno przesadzasz, ale to pewnie kwestia gustu.

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.

[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 

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

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

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ść.

[Crozin]

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

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.

[Spawnm]

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
B) 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.

$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."
?

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

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 

[wookieb]

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.

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.

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

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

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

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ę)

[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 

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)

Ten post edytował wookieb 19.09.2010, 16:06:05

[Spawnm]

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ę z listą wszystkich wartości, które na pewno są prawidłowe.

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

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

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)

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

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

[Crozin]

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.

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.

[wookieb]

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

Faktycznie nie zauważyłem na liście

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

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 

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

Proszę o przykład

Ten post edytował wookieb 19.09.2010, 16:36:06

[Crozin]

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.

[nospor]

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ś.

[wookieb]

[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

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

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.

Ten post edytował wookieb 19.09.2010, 16:50:03

[Spawnm]

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

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

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

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ę :-)

[wookieb]

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

Ok super.

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ę :-)

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.

Ten post edytował wookieb 19.09.2010, 17:04:02

[Crozin]

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

Z niedowierzania aż sprawdziłem:

Kod

mysql> SELECT colname FROM nulltest;
+---------+
| colname |
+---------+
| NULL    |
|         |
+---------+
2 rows in set (0.00 sec)

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:

Kod

array
  0 =>
    array
      'colname' => null
      0 => null
  1 =>
    array
      'colname' => string '' (length=0)
      0 => string '' (length=0)

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.

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.

Ustawienie wartości na null oznacza jej brak, czyli wartość nie jest ustawiona.

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.

[wookieb]

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

[Crozin]

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ą.

[Spawnm]

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?