Witam srdecznie,

Wygląda na to,iż będę tu dosyć często zaglądał.

Tak jak w temacie chodzi mi o schemat klasy i jej działanie.

[PHP] pobierz, plaintext 
<?php
class userRegist
{
     konstruktor - używam go do przeniesienia połączenia z baza danych
 
     funkcja sprawdzająca poprawność email zwraza true
    
     funkcja sprawdzająca czy podany email jest w bazie zwraca false jesli adres istnieje
   
     funkcja sprawdzająca długość podanego hasła zwraca true jeśli hało ma więcej niż x znaków
 
    funkcja sprawdzająca czy hasło i powtórzenie hasła pasują do siebie zwraca true
 
      funkcja do sprawdzania tokena przepisanego i wygenerowanego zwraca true     
}
?>
[PHP] pobierz, plaintext 

i teraz tak jezeli email jest prawidłowy przechodzi do sprawdzania w bazie, jeżeli go nie ma w bazie zwraca true, sprawdza hasla zwraca true, sprawdza tokeny i zwraca true w wyniku czego następuje wsadzenie rekordu do bazy i wysłanie emaila pod wskazany adres. i jest ok.


ale chodzi mi o sprawdzanie wartosci (true, false) z funkcji normalnie rozwiazal bym to tak ale chodzi mi o jakieś może lepsze rozwiazanie

[PHP] pobierz, plaintext 
<?php
//funkcje i cała reszta z kasy
 
if(poprawnyEmail)
{
   if(!emailJestWBazie)// tu akurat oczekuje false
     {
        if(dlugoscHaslaJestOdpowiednia)
          {
              if(podaneHaslaSaTakieSame)
               {
                    if(tokenSaTakieSame)
                    {
                           $this->rejejstrracja;
                      }
                 }
           }
      }
}
?>
[PHP] pobierz, plaintext 

mam nadzieję, że jasno to napisze!! Czy można by było to zapisać w jakiś inny sposób niż taki "blok" if??

Można. Na przykład obiektowo wykorzystując istniejący już system walidacji.

Nie jest może najlepszy, ale polecam Zend_Validate

i na zenda przyjdzie czas :-)

Na razie przez to muszę przejść, że tak powiem :]

To może inaczej, sposób jaki zaprezentowałeś działa, ale jest z punktu programistycznego zły (mało reusable).

Trzymasz w jednej klasie najróżniejszego rodzaju metody walidujące. Rozbij je. Zrób klasę do walidacji stringów; inną do walidacji liczb etc. Jak już będziesz miał jakiś zestawik, zacznij się bawić.

Natomiast jeżeli uważasz, że Twoj problem nie wymaga niewiadomo czego - to olej klasy i napisz wszystko proceduralnie - [sarkazm]też będzie działać[/sarkazm]

:]

Wolę jednak mieć to obiektowo :]

więc jak widać zabrałem się do tego z innej strony :]

Tyle tylko, że to co zaproponowałeś ma tyle wspólnego z OOP co JavaScript z Java.

Tak jak napisałem schemat nie samo działanie.

W trakcie jest tak jak pisał Twój poprzednik. Klasy do walidacji stringów liczb itp. Wtedy to może będzie miało coś więcej wspólnego z OOP. Niż to forum z gotowaniem :]

Gdyby nie ta klasa "userRegist" to bym uwierzył :] A tak przyjmij słowa krytyki - to naprawdę nie jest flame.

Ja chylę czoła przed ludźmi znającymi sie na rzeczy. I to samo robię tutaj. :-) Dopiero zgłębiam wiedzę na ten temat, nie każdy jest geniuszem informatyki (zwłaszcza mechanik) ale nic nie stoi na przeszkodzie by nim zostać. :-)

A patrzyłeś chociaż na schemat działania podanego wcześniej Zend_Validate?

Witam, nie rozpisując się moge powiedzieć, że przedstawiony wyżej blok można zamienić na podobny lecz z ciekawym dodatkiem jakim niewątpliwie jest obsługa wyjątków.

[PHP] pobierz, plaintext 
<?php
$a = 1;
$b = 2;
try 
{
  if($a != $b)
  {
  throw new exception('error'); // jeżeli $a != $b zgłoś wyjątek
  }
  echo 'success'; // jeżeli wszystkie warunki spełnione 
}
 
catch (exception $e) // przechwytuje wyjątki
{
  echo $e->getmessage(); // wyświetla wyjątek
}
?>
[PHP] pobierz, plaintext 

~marcok właśnie podałeś najlepszy przykłąd na to ... gdzie powinno się unikać wyjątków i jak o nich nie powinno się myśleć.
Wyjątek to ... wyjątek. Sytuacja wyjątkowa, niespodziewana.

A co jest niespodziewanego w tym że pewne parametry są niepoprawne? Nic.

Sztuczne zastępowanie instrukcji warunkowych wyjątkami to błąd. Wydawałoby się że to jest "pro" ale tak nie jest. Stosowanie wyjątków ma swoje konsekwencje. Kod zamknięty w try ... catch wykonuje się dłużej. Mechanizm dla parsera robi się cięższy.

~mike mówisz, że wyjątki służą do sytuacji wyjątkowych jednak idąc dalej tym tropem gdy wstawiasz w kod try ... catch przewidujesz wystąpienie anomalii więc po co catch lepiej upakować to w if'y. Mówisz, że kod taki wykonuje się dłużej, szczerze mówiąc nie wiem nie sprawdzałem jednak dla klasy obsługującej jedynie rejestracje - czynność zdecydowanie rzadszą od np. wyświetlania strony głównej etc. Moim zdaniem jest to sposób korzystniejszy abstrahując od wydajności kodu, która czasami nie jest tak ważna.

[PHP] pobierz, plaintext 
<?
 
//poprawne użycie wyjątku
if(!file_exists('./myConfig.php')){
  //plik ten powinien zawsze istniec
  throw new Exception('....', 123);
}
 
//niepoprawne użycie wyjątku
$username = $_POST['username'];
if(mb_strlen($username) < 3){
  //to nie jest sytuacja wyjątkowa, jest ona wręcz powszechna
  throw new Exception('...', 321);
}
?>
[PHP] pobierz, plaintext 

Tak jak napisał mike - poza tym, że kod jest "ciekawszy" i wygląda "fajniej"/"pr0" jest on zły.

Dobre nawyki programowania powinno sosować się zawsze. Jeśli czasem odpuszczasz "bo to tylko jedna klasa" to po pewnym czasie pisząc dużą aplikację połowa to będzie jakiś "spaghetti code".
Tu dopuszczasz sprawdzaine parametrów przy rejestracji, tak? A podczas wykonywania dowolnej innej akcji jak sprawdzasz parametry żądania? Inaczej?
Po co dwa różne sposoby? COś mam wrażenie, że gdzieś indziej też byś tak zrobił a "dowolna inna akcja" wykonuje się już "trochę" częściej niż rejestracja.
W takim razie mam proste pytanie. Co zyskujesz, skoro tak jest korzystniej?

Spłaszczasz problem. Oczywiście, że można pokazać sytuacje kiedy wiesz, że coś może wystąpią ale nadal będzie to dla Ciebie niespodziewane. ~Crozin pokazał przykład.
Kolejny przykład - łączysz się z bazą, to połączenie zawsze powinno być ale dopuszczasz możliwość, że baza padła. Sieci nie ma. Dane dostępowe się zmieniły. Dajesz to w try ... catch bo niby połączenie zawsze powinno istnieć ale co jeśli?

@mike, jeżeli pozwolisz, spróbuje wyklarować sytuację w kilku zdaniach.
Wyjątki nie służą do powiadamiania o błedach jako takich (np. błedy użytkownika). Za pomocą wyjątków kształtuje sie przepływ aplikacji. Mówimy tu o sytuacji gdy część kodu nie działa jak powinna (a wystapienie błedu walidacji jest jak najbardziej rzeczą normalną i przewidywalną) i trzeba obsłużyć alternatywę - nic wiecej.

Wydaje mi się, że to jest esencja wyjątków.

Pozdrawiam, Alan