Forum PHP.pl

Jeśli chcesz wszystkie to:

[SQL] pobierz, plaintext 
UPDATE `config` SET config_value = 'wartosc';
[SQL] pobierz, plaintext 

a wybrane:

[SQL] pobierz, plaintext 
UPDATE `config` SET config_value = 'wartosc' WHERE config_name IN ('n1', 'n2', 'n3');
[SQL] pobierz, plaintext 

Zgadzam się z LSM, że myślenie 'na przyszłość' jest zgubne, ale pod warunkiem, że rozważasz rozwiązania, które przypuszczasz, że kiedyś, może zostaną zaimplementowane. Wtedy nie implementujesz setek wzorców itp. tylko po to, żeby można było zrobić z tym wszystko, co ci się żywnie podoba, tyle, że w przyszłości, implementując rzeczy, których możesz nigdy nie implementować, ponieważ twoje przewidywania były błędne.
Co do rozwiązania Crozina, to nie jest ono 'nad wyrost', robienie czegoś poprawnie, nie jest wprowadzaniem nadmiernej elastyczności.

Co do klasy Damian, to:
Z wikipedii:

i mamy dalej:


Czyli klasa definiuje atrybuty i zachowanie obiektów, ale dopiero przy ich tworzeniu określamy ich stan.
Rozumiem, że klasa Damian dziedziczyłaby po klasie Człowiek tyle, że ustawiałaby jakieś domyślne wartości, tak? No to się to trochę kłóci z powyższymi.

Programowanie obiektowe zostało wymyślone w celu jak najdokładniejszego odwzorowania rzeczywistości.
Załóżmy więc, że Damian to model. W takim wypadku, czym są jego instancje? Damian1, Damian2 itp.? Nawet jeżeli każdy Damian jest rudy, sympatyczny i nieprzeciętnie inteligenty, to czy oznacza to, że mamy do czynienia z nowym człowiekiem? Wątpię

Jeżeli już koniecznie chcesz robić coś takiego, to możesz stworzyć jakąś fabrykę, która zwraca ci obiekt klasy Człowiek z odpowiednimi ustawieniami (czyli umiejętnościami, imieniem, IQ i wszystkim innym, co tylko chcesz).
Takie samo rozwiązanie zastosowałbym do przykładu, który przedstawił Orzeszekk (z klasą AvatarUploader). Tutaj też rozwiązaniem byłaby fabryka.
Bo tworzenie dziedziczenia tylko i wyłącznie po to, żeby klasy od razu miały ustawiony szereg odpowiednich wartości jest bez sensu i nie jest poprawne, nie ważne czy uczy tego Duńczyk, Holender, Polak, czy wiesz to z tutoriali. Bo w takim wypadku dojdziesz do skrajności, gdzie dla każdego zestawu danych będziesz miał osobny obiekt?

Dziedziczenie powinno rozszerzać funkcjonalność i wtedy ma ono sens. Jeżeli służy tylko do ustawiania wartości, 'bo taki zestaw danych jest często używany' tzn. że mamy do czynienia z błędnym rozumieniem dziedziczenia.

A co do pytania głównego, to tutaj pisałem trochę na temat tego, kiedy interfejs a kiedy klasa abstrakcyjne. W Twoim wypadku, uwzględniając tylko te informacje, które przekazałeś i nic więcej (bez przypuszczeń), to interfejs jest Ci nie potrzebny, wszystko ląduje w klasie abstrakcyjnej.

Powinno zadziałać:

[SQL] pobierz, plaintext 
    SELECT movie_name, p1.people_fullname AS leadactor, p2.people_fullname AS director
    FROM movie
    LEFT JOIN people AS p1
    ON movie_leadactor = people_id
    LEFT JOIN people AS p2
    ON movie_director = people_id
    ORDER BY movie_name;
[SQL] pobierz, plaintext 

Najpierw explode(), żeby zrobić z tego tablicę (rozbijasz po znaku nowej linii). Następnie sort(), aby posortować alfabetycznie i shuffle(), żeby kolejnością rządził przypadek:)

Najlepiej to pogrupować te funkcje jakoś logicznie, zrobić z tego klasy, każdą klasę umieścić w osobnym pliku, w odpalanym skrypcie dołączyć klasę/funkcję do autoloadingu zarejestrować ją przy użyciu spl_autoload_register i wtedy to, co będziesz potrzebował będzie wczytywane w locie:)

Kod klasy jest taki jak powyżej i wywołujesz tylko te dwie metody, nic więcej?
Może chodzi ci o to, że metoda $cache->cacheSaveData(array('d')); zwraca null, co jest prawdą, bo ona nic nie zwraca (brak return w metodzie), a 'object' jest wyświetlany, bo wywołujesz gettype(). Innego pomysłu nie mam.

Czyli rozumiem, że robisz coś takiego (muszę sobie to łopatologicznie przedstawić dla lepszego zrozumienia:):
- tworzę misję UratujMisia, dodaję opis: 'Pomóż Ani uratować misia z rąk złej, brzydkiej czarownicy'. I dodaję opcje: SzukajMisiaWZamku, SzukajWLochach, SzukajWPokojuAni
- następnie biorę opcję SzukajMisiaWZamku, dodaję opis: 'Przeszukaj cały zamek, wszystkie komnaty i wypytaj ludzi, czy nie widzieli misia'. Dodaję opcje: SzukajWKomnacieKrólewskiej, SzukajWJadalni etc.
i oczywiście te kroki powtarzamy zagłębiając się jeszcze głębiej.
O to chodzi?
Jak nie, to rzuć przykładem, jeżeli tak, to twoim rozwiązaniem jest:
Composite lub po polsku.

Metoda getRequest() powinna zwracać obiekt klasy Request, która zawiera informacje nt. aktualnego requestu, czyli jej budowa może wyglądać mniej więcej tak:

[PHP] pobierz, plaintext 
class Request {
private $_controllerName;
private $_actionName;
private $_params = array(); //dobrze byłoby, gdyby istniał podział na parametry przekazane za pomocą metody GET i POST
public function getControllerName($default = 'index') {} //jeżeli nie został przekazany w url kontroler, to zostaje zwrócony domyślny
public function getActionName($default  = 'index') {} //analogicznie j.w.
public function getParams($method = Request::ALL) {} //zwraca wszystkie parametry. Tutaj radziłbym zastosować jakieś consty do określenia czy wszystkie wysłane postem, getem, czy ogólnie wszystkie
public function getParam($name, $default = null) {} //zwraca wartość parametry lub $default, gdy parametr nie został przekazany
}
[PHP] pobierz, plaintext 

Oczywiście to tylko sugestia, bo można spokojnie to rozbudować. Dodatkowo pozostaje decyzja, czy parametry są przekazywane, czy sam obiekt dobiera się do nich z tablic globalnych. To samo tyczy się nazw akcji i kontrolera. Czy pobierać je wewnątrz obiektu klasy, czy może przekazywać. Jeżeli chcesz to wszystko ustawiać to raczej proponowałbym takie dane przekazywać w konstruktorze, a nie za pomocą seterów, ponieważ logika podpowiada, że po utworzeniu obiektu klasy request raczej nie powinien się zmienić.
Temat można rozwinąć, jeżeli zakładasz również obsługę kodu z linii poleceń. W takim wypadku doradzałbym wyciągnięcie klasy bazowej (abstrakcyjnej) wyżej i stworzenie Request_HTTP i Request_CLI lub coś w tym stylu.

Tym, jaka akcja dla danego kontrolera powinna zostać wykonana zajmuje się front controller.
Jeżeli nie ma żądanego kontrolera lub brakuje akcji dla danego kontrolera, to powinien (front controller) w tym miejscu zwrócić wyjątek.
Coś w tym stylu, załóżmy, że metoda uruchamiająca odpowiednią akcję nazywa się run:

[PHP] pobierz, plaintext 
public function run()
{
  $request = $this->getRequest(); //metoda request powinna zwracać obiekt z danymi dotyczącymi requestu
  $controllerName = $request->getControllerName(); //zwraca nazwę kontrolera lub nazwę domyślnie ustawioną, gdy url jest bez parametrów
  $actionName = $request->getActionName(); //analogicznie jak wyżej
  try {
    $controller = new $controllerName; //autoloader powinien wyrzucić wyjątkiem, jeżeli nie znajdzie kontrolera
    $controller->setRequest($request); //request powinien zostać przekazany do kontrolera
  }
  catch(Autoloader_Exception $e)
  {
      throw new Controller_Exception('Kontroler ' . $controllerName .' nie istnieje.'); //wyrzucone, gdy autoloader nie znajdzie klasy
  }
 
  if(!method_exists($controller, $actionName))
     throw new Controller_Exception('Akcja '.$actionName.' nie istnieje.'); //wyrzucane, gdy brakuje metody
 
  $controller->{$actionName}; //wykonanie akcji, możesz zwracać wynik, jeżeli zachodzi taka potrzeba.
}
[PHP] pobierz, plaintext 

A kod kontrollera wygląda np. tak:

[PHP] pobierz, plaintext 
Controller_A {
public function foo() {}//gdy url: www.site.com/a/foo
public function boo() {}//gdy url: www.site.com/a/boo
}
[PHP] pobierz, plaintext 

Radzę zastosować zamiast takich urli: www.site.com/index.php?module=user&action=shownotactive&other=1_2 coś takiego: www.site.com/user/shownotactive?other=1_2 wygląda o wiele ładniej. Wartość parametru other powinna być dostępna z obiektu Request, a nie przekazywana jako parametr metody akcji.

Tak na pierwszy rzut oka to ok.
Usunąłbym jednak te constant value. Po co ci one? I tak z bazą łączysz się raz. Już prędzej wykorzystałbym to do przechowywania soli.
A następny krok to OOP:)

Sorry, z tą solą to trochę pokręciłem. Tak to jest jak się robi dziesięć rzeczy na raz:P
Sól to jest unikalny string (zazwyczaj). Może on być zahardcodowany w pliku lub zapisany w bazie. Dzięki niej ciężej jest odkryć hasło, które zostało przepuszczone przez funkcję haszującą.
Twoją solą może być np. 'sad8%$9sdk' lub cokolwiek zechcesz. Im bardziej przypadkowy jest to zbiór znaków, tym lepiej.
I tą właśnie sól doklejasz do hasła, które przesłał użytkownik, nie ważne czy to rejestracja, czy logowanie.
http://en.wikipedia.org/wiki/Salt_%28cryptography%29

[PHP] pobierz, plaintext 
$pass = md5(htmlspecialchars(stripslashes(strip_tags(trim($_POST['password'])))));
[PHP] pobierz, plaintext 

To, co robisz w tym kodzie jest całkowicie zbędne. Wystarczy, że użyjesz funkcji haszującej, jest to wystarczające zabezpieczenie.

[PHP] pobierz, plaintext 
$user_password = sha1($pass.$user_login);
[PHP] pobierz, plaintext 

A takie zabawy są już ciekawsze:) Tylko zamiast $user_login używa się zazwyczaj soli, czyli jakiegoś indywidualnego ciągu znaków, który również zapisujesz do bazy. Możesz użyć np. funkcji http://pl2.php.net/manual/en/function.microtime.php do jego generowania.

[PHP] pobierz, plaintext 
$user_login = htmlspecialchars(stripslashes(strip_tags(trim($_POST['username']))));
[PHP] pobierz, plaintext 

Wystarczy, że użyjesz metody:
http://pl2.php.net/manual/en/function.mysq...cape-string.php
Jednak osobiście uważam, że co do loginu, to walidacja powinna wyglądać trochę inaczej. Chodzi o to, że zazwyczaj login ma pewien określony zbiór znaków, z których może się składać np. litery, cyfry, _, -, spacja itp. W każdym razie zbiór dozwolonych znaków jest określony dlatego też lepiej walidować login użytkownika, a nie (tak jak ty) filtrować.
Do walidacji przydaje się funkcja:
http://pl2.php.net/manual/en/function.preg-match.php

Chciałbyś, aby po wciśnięciu buttona wykonała się metoda get()?
Jeżeli tak, to nie ma takiej możliwości. Kod php'a jest po stronie serwera i zostaje zakończony nim jest przekazany do klienta. A to klient wciska button.
Możesz użyć AJAX'a, aby przesłać zapytanie do serwera i odebrać odpowiedź.

Możesz użyć:
http://dev.mysql.com/doc/refman/5.5/en/str...ction_substring

Używając strpos() zastąpisz tylko pierwsze wystąpienie danej litery. Możesz ciąg traktować jako tablicę, czyli:

[PHP] pobierz, plaintext 
$text = 'some cool text';
$position = strpos($text, 'o');
$text[$position] = 'x';
echo $text;
[PHP] pobierz, plaintext 

lub możesz skorzystać z funkcji str_replace(), aby zastąpić wszystkie wystąpienia liter:

[PHP] pobierz, plaintext 
<?php
$text = 'some cool text';
echo str_replace('o', 'x', $text);
[PHP] pobierz, plaintext 

Co do kwestii klasy user, to tworzenie jej obiektu powinno wyglądać tak:

[PHP] pobierz, plaintext 
$user = new User();
[PHP] pobierz, plaintext 

Bez id, ponieważ jeżeli podajesz id w konstruktorze oznacza to, że użytkownik nie jest tworzony tylko pobierany z bazy.

Pobieranie użytkownika z bazy powinno wyglądać tak:

[PHP] pobierz, plaintext 
$user = Users::find(3);
[PHP] pobierz, plaintext 

I w tym momencie, jeżeli istnieje użytkownik o id 3, to klasa Users go zwraca, a jeżeli nie istenieje, to zwraca false. Dlatego też nie jest ci potrzebna metoda exists()

Coś o TableAbstract:

[PHP] pobierz, plaintext 
abstract class TableAbstract
{
  public function find($id) {}
  public function delete($id) {}
  public function update($id, array $data) {}
  abstract protected function _getTableName();
}
 
class Users extends TableAbstract
{
   protected function _getTableName() {
      return 'Users';
   }
}
 
 
class Groups extends TableAbstract
{
   protected function _getTableName() {
      return 'Groups';
   }
}
[PHP] pobierz, plaintext 

Mniej więcej o to chodzi. Jak dobrze przemyślisz sprawę to metody update, delete i find różnią się tak naprawdę jedynie nazwą tabeli.

1) W klasach User i Group masz settery i gettery do każdej wartości, więc jaki jest ich sens? Przypuszczam, że i tak będziesz wysyłał zawsze pełny zestaw danych więc zastanów się nad zastąpieniem tych metod: setData(array $data).
2) W konstruktorze nie powinno być parametru id, bo skąd wiesz jaki id będzie miał rekord? Przypuszczam, że kolumna jest auto inkrementowana. Id powinien być ustawiany dopiero po zapisie User/Group w bazie.
3) Groups i Users powinny rozszerzać klase abstrakcyjną np. TableAbstract, ponieważ w innym wypadku będziesz miał sporo kodu, który będzie duplikował się.
4) Metody add() i remove() powinny przyjmować jako parametr obiekt klasy User/Group, ponieważ to właśnie je chcesz zapisać/usunąć w/z bazy.
5) Czy rzeczywiście jest ci potrzebna metoda exist() ? Zastąpiłbym ją raczej find(), która zwróci albo obiekt (czyli rekord jest) albo false (brak rekordu).
6) Metody check() i hash() z klasy Users powinny wylecieć. check() jest metodą autoryzacji, więc powinna się znaleźć w tego typu klasie, natomiast hash() przypuszczam, że wykonuje jakieś operacje na stringu, więc na to konto również powinna być odpowiednia klasa.

Nie wydaje mi się, żeby coś takiego było potrzebnym zabiegiem. W końcu wiesz, które akcje mają być responsem ajaxowym, a które nie, więc po co dodatkowo to sprawdzanie robić po stronie serwera? Jeżeli użytkownik wpisze ajaxowy url z palca to dlaczego otaczać to dodatkowo layoutem? Taka akcja nie jest pożądana, więc dlaczego nie wypluć po prostu czystego responsa?


Dobrze prawi:) Logika jest ważniejsza niż typ żądania.

Funkcja podaj_dane() wyciąga dane z pliku, więc powinna je wyciągać z bazy.
Najpierw łączysz się z bazą: http://pl.php.net/manual/en/mysqli.connect.php
Następnie pobierasz dane: http://pl.php.net/manual/en/mysqli.query.php
Przy użyciu selecta wynikiem jest: http://pl.php.net/manual/en/class.mysqli-result.php
Żeby dostać dane w postaci tablicy asocjacyjnej wykonujesz metodę: http://pl.php.net/manual/en/mysqli-result.fetch-assoc.php
I gotowe:)

http://php.net/manual/en/function.preg-replace.php
Coś w stylu:

[PHP] pobierz, plaintext 
$data = preg_replace('/' . $id . ' => "[a-z0-9]+",/','',$data);
[PHP] pobierz, plaintext 

Pisane na szybko i pewnie się gdzieś wysypie, ale chodzi mniej więcej o coś takiego.
Mimo wszystko takie kombinacje nie są czymś ładnym i moim zdaniem powinieneś zmienić coś w kodzie, a nie bawić się w takie operacje.

z php.net:

oraz:
http://www.php.net/manual/en/pdostatement.rowcount.php
i z tego masz:

[PHP] pobierz, plaintext 
return $result === false ? 0 : ($result->rowCount ? 1 : 0);
[PHP] pobierz, plaintext 

pierwsze jest po to, aby sprawdzić, czy nie było żadnego faila.

A jaki sposób kodowania ustawiasz w nagłówkach maila?
Dodaj do header'a:
'Content-type: text/html; charset=utf-8'
powinno pomóc.

http://www.php.net/manual/en/function.eval.php
nic dodać, nic ująć

http://www.php.net/manual/en/function.str-replace.php
lub
http://www.php.net/manual/en/function.preg-replace.php
ale w Twoim przypadku wystarczy pierwsza.

Tak powinno wyglądać twoje wyrażenie:

[PHP] pobierz, plaintext 
array_key_exists('a', $_GET) && ($_GET['a'] === 'pomoc' || $_GET['a'] === 'faq')
[PHP] pobierz, plaintext 

A co było źle w Twoim?

[PHP] pobierz, plaintext 
$_GET['a'] == 'pomoc' && 'faq'
[PHP] pobierz, plaintext 

Po pierwsze, tak jak napisał sadistic_son, to: && -> and, || -> or. Możesz też używać słów or i and. Interpreter da radę
Po drugie and lub or są łącznikami wyrażeń logicznych więc to co ty zrobiłeś to:
$_GET['a'] == 'pomoc' i 'faq', gdzie:
1) $_GET['a'] == 'pomoc' - równa się true, gdy wchodzisz na 'pomoc', a false, gdy na 'faq'
2) 'faq' - zawsze równe true