Forum PHP.pl

Polecam Umbrello UML.

Maguma jest w tej chwili bardzo zaburaczona - może to, że stała się OpenSourcowa poprawi sytuację.

Dobry program do php według mnie powinien mieć:
-autouzupełnianie
-przeglądarkę klas/funkcji
-kolorwanie składni (nie musi być jakieś super jeśli tylko można to edytować samemu)
-wbudowany debugger i profiler
-obsługę PHPDoca
-obsługę polskich znaków, jak się należy - UTF-8 minimum
-być wygodny
-...i darmowy
Ten ostatni punkt skreśla z miejsca Zenda niestety - cena jego jest wg. mnie przesadzona (100$ bym jeszcze zrozumiał), ale na szczęście jest alternatywa:
Eclipse+TruStudio ma wszystko co wymieniłem i jeszcze więcej (zwijanie bloków kodu np.), no może oprócz profilera(ale może się myle i gdzieś tam jest). To, że w Javie napisany w tych czasach już nie powinno przeszkadzać.
Co najlepsze - TruStudio ma wbudowane php5, wygląda więc na to, że można dzięki temu mieć bez problemu na jednym kompie php4 i 5 (nie wiem jeszcze jak to jest z dostępem z poziomu przeglądarki). W każdym bądź razie polecam.

Z innych programów: Maguma Openstudio ma potencjał, może kiedyś będzie z tego coś naprawdę dobrego.

Gdyby było tak jak mówisz to problemu bym nie miał, ale problem niestety jest. Znalazłem jednak wyjście: zamiast phpMyAdmina do eksportu/importu bazy użyłem mysqlbackupro i działa

Mam taki o to problem z MySQLem, a dokładniej z phpMyAdminem.
Mam sobie bazę danych, dane w niej zapisane w utf-8 - na stronie wszystko jest jak trzeba, ale problemem jest wyeksportowanie bazy. Znikają polskie czcionki - tj. zostają zastąpione dziwnymi znakami, w stylu: Ą Ł Ó Ś Ĺť Ĺš ł - z którymi nie za bardzo jest co zrobić. Do tego część pól jest kodowanych binarnie i one również gubią polskie znaki. Na domiar złego: powymieniałem w pliku .sql wyżej wymienione znaki na ich prawidłowe odpowiedniki ("Ą" -> Ą) i przy imporcie one również zostały zgubione. Wie ktoś co z tym można zrobić?

Tylko pamiętajcie, że ani $_SERVER['HTTP_HOST'], ani $_SERVER['REQUEST_URI'] nie można zbytnio ufać (patrz: http://shiflett.org/archive/98, komentarz Geoffrey'a Younga)

To nie framework tylko, jak zresztą nazwa wskazuje, zestaw klas/komponentów. Bardziej jak PEAR niż np. Mojavi, albo zapowiadany Zend Framework (chociaż i ten ma być bardzo "luźny" i zostawiać programiście duże pole manewru w tym jak ma korzystać z dostarczonych "gotowców").

A co do ezComponents - zdążyłem tylko pobieżnie rzucić okiem: póki co wygląda fajnie.

Spróbuj tak:

[PHP] pobierz, plaintext 
<?php
$time = time() - mktime (13,10,0,11,22,2005);
echo $time.' '.gmdate("zd Gh im ss", $time);
?>
[PHP] pobierz, plaintext 

Uważam, że PDO jest proszte i szybsze od ADOdb, ale PDO nie zastąpi ADOdb, będzie po prostu kolejnym driverem dla niego. PDO wprowadza wspólny interfejs dostępu do różnych RDBMSów, co z pewnością ułatwi pisanie "abstraction layerów" i sprawi, że będą szybsze - nie zastąpi ich jednak całkowicie. W poprzednim php|architect jest nawet artykuł jak napisać własny abstraction layer w oparciu o PDO.


Tu jest wszystko wyjaśnione: http://ilia.ws/archives/95-php-5.1.1-Released!.html

Nie do końca, bo PDO to nie jest prawdziwa wartswa abstrakcji bazy danych, zapewnia tylko wspólny interfejs do dostępu do różnych baz. Wprowadza pewne ułatwienia, ale coś takiego jak ADOdb, MDB2, czy PEAR::DB ciągle będzie potrzebne, choć pewnie prostsze i szybsze.

Najwięksi i najlepsi polscy providerzy (home.pl, netart.pl/nazwa.pl) już mają php5. Jako, że wersja 5.1 wnosi wiele usprawnień spodziewam się że szybko go zaadoptują. Także ze skryptami powinno być teraz co raz lepiej, bo jak człowiek zobaczy te wszystkie dobrodziejstwa jakie daje mu 5 to do 4 się wracać nie chce - i wiele nowych skryptów/frameworków jest już pisana pod 5.

A za rok, półtora to będziemy mieli już php6, które to zapowiada się na naprawdę świetną rzecz. Lista zapowiadanych zmian i usprawnień

wywoływanie w całości PEAR? O so chodzi?
PEAR ma po prostu kilka sytsemów do obsługi baz danych, PEAR::DB, PEAR::MDB i PEAR::MDB2. Wszystkie są bardzo dobre, jeżeli chodzi o możliwości, a najlepsze jest MDB2, bo oprócz tego, że ma możliwości to ma jeszcze szybkość. Nie ma jeszcze wersji finalnej, choć w zasadzie nie wiadomo dlaczego - wg. mnie można już spokojnie tego używać.
Poza tym polecam AdoDB_Lite - odchudzoną wersję AdoDB.
Można spróbować też z Solarem (link), który jest czymś w rodzaju PEARa tylko dla php5. Jest tam klasa do obsługi SQL, oparta na PDO nastawiona na przenośność - ma np. wbudowaną obsługę LIMIT dla różnych baz danych. Problem w tym, że jest to jeszcze w powijakach.

I jeszcze jedno: może spróbować z ORM - Propel, albo ezPDO.

Faktycznie, tu tkwił problem - ale okazało się, że nie trzeba wywalać tego znacznika meta z HTMLa a jedynie wysłać takie samo kodowanie za pomocą funkcji header(). Można to też ustawić na serwerze zapewne.
Dzięki.

Pewnie w php:

[PHP] pobierz, plaintext 
<?php
header(&#092;"Content-Type: text/html; charset=UTF-8;\");
?>
[PHP] pobierz, plaintext 

Mam problem ze skryptem polegający na tym, że pod Internet Explorerem często zdarza się, że strony się w ogóle nie pojawiają - nie to, że nie można było znaleźć strony, czy coś w tym stylu - po prostu biały ekran i pustka w źródle. Wystarczy dać odśwież i wszystko jest w porządku. Dzieje się tak jedynie pod IE, czy ktoś orientuje się co może być tego przyczyną: sesje, Smarty, czas wykonania skryptu, serwer?

Pomogło, choć zupełnie nie wiem czemu poprzednio nie działało - wydaje się to mieć jakiś związek z konfiguracją serwera, bo lokalnie wszystko jest jak należy. A na serwerze działo się np. takie coś:

[PHP] pobierz, plaintext 
<?php
print_r($_SESSION);
print_r($_SESSION['lang']);
?>
[PHP] pobierz, plaintext 

dało następujący rezultat:

Stworzyłem obiekt i chcę umieścić go w tablicy sesji ($_SESSION, żeby była jasność).
Obiekt wygląda w ten sposób:

Serializuje i zapisuje do sesji:

[PHP] pobierz, plaintext 
<?php
$_SESSION['lang'] = serialize($lang);
?>
[PHP] pobierz, plaintext 

Zaraz potem, daję

[PHP] pobierz, plaintext 
<?php
print_r($_SESSION['lang'])
?>
[PHP] pobierz, plaintext 

co daje spodziewany efekt:

Teraz najważniejsze, odświeżam stronę, tudzież przechodzę na inną, pozostając w tej samej sesji.
print_r tablicy sesji i co?

$SESSION['lang'] raczyło zniknąć, inne zmienne sesji są na swoim miejscu, ktoś wie gdzie tkwi przyczyna?

Co do pierwszego to zgadzam się w zupełności. Są co prawda przypadki, kiedy takie coś wystarcza, ale generalnie nie jest to idealne rozwiązanie - jak wobec tego zrobić to lepiej?
Co do drugiego, to faktycznie, do ideału temu rozwiązaniu wiele brakuje, ale chodziło jedynie o generalną zasadę co można z tym robić. Filtrowanie należałoby zrobić bardziej rozbudowane, przy wyciąganiu to w zasadzie bardziej logiczne byłoby addslashes (jeżeli dane z sesji umieszczamy w zapytaniach SQL), ale to również jedynie jako opcja. Możliwości jest tu mnóstwo, ale wiadomo, że chodzi o to, żeby te dane łatwo walidować.

Np. możemy się pozbyć problemu z niezainicjowanymi zmiennymi, np.

[PHP] pobierz, plaintext 
<?php
$foo = $_SESSION['foo'];
?>
[PHP] pobierz, plaintext 

Okazuje się, że nie ma w sesji takiej zmiennej i pojawia się błąd:

Jeśli zrobimy to w ten sposób:

[PHP] pobierz, plaintext 
<?php
$foo = $session->get('foo');
?>
[PHP] pobierz, plaintext 

To możemy wszystko ładnie załatwić w metodzie get():

[PHP] pobierz, plaintext 
<?php
function get($var) {
if (!isset($_SESSION[$var]) 
	return NULL;
else
	return stripslashes($_SESSION[$var]);
}
?>
[PHP] pobierz, plaintext 

To tylko prosty przykład, pokazujący również kolejną zaletę tego rozwiązania, a mianowicie możliwość wprowadzenia łatwego filtrowania danych. To tylko początek: możliwości jest o wiele więcej.

Funkcja Iconv

W poszukiwaniu dobrego skryptu do współpracy z systemami baz danych skierowałem się na stronę PEAR. Jest tam kilka paczek, z pozoru (albo i nie) bardzo podobnych. Czy ktoś wie, może nie tyle, która z nich jest lepsza, a czym się one różnią?

Coś mi się tu nie zgadza - sprawdzałem moje arkusze w http://jigsaw.w3.org/css-validator/validator-upload ustawiając Medium na handheld i Profile na mobile (oraz kombinacje tych ustawień) i nie wskazało żadnych błędów. Nie słyszałem nigdy o kłopotach ze skalą szarości.

Jeśli chcesz tam wstawić nie więcej niż jedną linijkę tekstu to posłuż się parametrem line-height. Dopisz po prostu line-height: 100px; Przy bardziej skomplikowanych rzeczach musisz używać marginesów (odradzam padding)

Zamknij wszystko w dodatkowy <div> i ustal dla niego margin: 0 auto 0 auto oraz(żeby działało w IE) text-align: center. Dla divów wewnątrz musisz wtedy dać text-align: left.

Problem tkwi w przeglądarce - jeżeli wielkość tekstu jest ustawiona w piksleach to w IE nie da się zmienić jego rozmiaru (tak naprawdę się da, ale trzeba zastosować pewne triki). W innych przeglądarkach (Mozilla, Opera) nie ma z tym problemu.

Jako nowy użytkownik zacznę od przywitania się ze wszystkimi.

Teraz do rzeczy. Przymierzam się do napisania - UWAGA, UWAGA! - własnego CMSa. Tak jest - "kolejny niepotrzebny nikomu CMS". Niektórzy już pewnie ziewają. Ma to być system napisany przejrzyście, szybki i prosty w prowadzaniu zmian (coś jak dawne phpBB 1.4.x) .
Zastanwiam się więc, czy jest sens wprowadzania do niego systemu template'ów - własnego, bo system ma mieć jak najbardziej przenośny charakter (a więc tylko AMP).

Skąd moje wątpliwości? Templaty działaja w ten sposób, że najpierw sprawdzaja dane wejściowe (COOKIE POST GET SESSION) i na tej podstawie decydują jaką stronę wyświetlić. Przygotowują tą stronę pobierając odpowiednie dane, np. z bazy danych, wykonują obliczenia, itd. Potem otwierają plik szablonu i sprawdzają, które z tych danych wlać do strony.
Zalety:
grafik i programista mogą pracować osobno

Wady:
kod mniej przejrzysty
istnieje duże prawdopodobieństwo, że pobierzemy więcej danych niż potrzeba (bo grafik, uzna którąś z funkcji za niepotrzebną i wyrzuci z szablonu)
trudno sterować układem strony - co jeśli grafik będzie chciał, aby menu było dwu, a nie trzy poziomowe, żeby wyświetlało się 10, a nie 5 ostatnich nagłówków - z poziomu szablonu trudno robić takie rzeczy, chyba, że wcześniej przygotujemy wszystkie możliwości (tj. pobierzemy maksymalną liczbę danych) co jest raczej rozwiązaniem nieefektywnym.

Pomyślałem, że może lepiej zacząć działać od drugiej strony - najpierw sprawdzamy szablon, a potem pobieramy potrzebne dane i wlewamy je w ramy naszego HTML-a. To miałoby sens, tyle, że przecież tak działa php - więc po co od nowa wymyślać koło. Aby ułatwić pracę można przecież wprowadzić zamiast szablonowych aliasów, zmienne i odpowiednie funkcje.

Poza tym i tak całą grafikę można (i powinno) się robić w CSS.

Jeżeli szerzę tu jakąs herezję proszę o natychmiastowe wyprowadzenie mnie z błędu.