Pionowy podział uzyskamy komendą:

(tryb komend) :new tab nazwa pliku

lub

(tryb komend):split

Przechodzimy między oknami:

(tryb komend)Ctrl+W+strzałka w zależności do którego okna chcemy przejść

(tryb komend) yyp

Usuwanie linii w której znajduje się kursor:

(tryb komend) yyd

Wyświetlenie pomocy kontekstowej

(tryb edycji) Ctrl+N

Rozwiązaniem by po nawiązaniu połączenia zadeklarowanie używanego kodowania, w taki sposób:

$dbh->query('SET NAMES "utf8"');

Kod stworzenia kopi tabeli, gdzie n jest zadaną ilością wierszy kopiowanych:

create table tablica_kopia as
 select * from tablica_orginalna
 where rownum <=n;

A oto kod gotowego zapytania wyciągającego n losowych rekordów z zadanej tabeli:

select * from table_name where row_id in (
select row_id from(
select row_id, dbms_random.value  from table_name order by 2)
where rownum<=n);

php_flag magic_quotes_gpc Off

Rozwiązanie problemu okazało się banalne:

SetEnv MAGIC_QUOTES 0

create or replace function czy_spelnione_wymagania(
 pesel IN varchar2,
 temat IN varchar2)
 return boolean
 is

....

Funkcja się skompilowała poprawnie, więc cały szczęśliwy chciałem ją przetestować korzystając z zabawnej tablicy DUAL.

SELECT czy_spelnione_wymagania('8089123243','Oaza Nowego Zycia 1') FROM DUAL;

I tu mnie spotkało niemiłe zaskoczenie:

ORA-06552: PL/SQL: Statement ignored
ORA-06553: PLS-382: expression is of wrong type

Zasięgnąłem informacji o błędzie i byłem dość  zaskoczony tym co było przyczyną. A mianowicie poczciwy SQL nie obsługuje udostępnianego przez PL/SQL typu BOOLEAN! Więc trzeba to obejść jakoś ładnie i poniżej przedstawiam moją propozycje rozwiązania tego problemu za pomocą bloku PL/SQL.

DECLARE
VAR_BOOL BOOLEAN;
BEGIN
VAR_BOOL :=czy_spelnione_wymagania();
IF( VAR_BOOL = TRUE ) THEN
DBMS_OUTPUT.PUT_LINE( ‘TRUE’ );
END IF;
END;

Tak więc nie jesteśmy zmuszeniu do modyfikacji formatu zwracanych danych przez naszą funkcje składowaną, ale oczywiście jak ktoś bardzo lubi to może sobie przyjąć, że będzie zwracał int, gdzie FALSE = 0 a TRUE = 1.

W domyślnie wygenerowanym projekcie za pomocą narzędzia Zend_Tool, czyli wpisujemy w konsoli tak:

zf create project nazwa_projektu sciezka_projektu

Oprócz fajnej struktury katalogów otrzymujemy plik konfiguracyjny naszego projektu w prezencie. Znajduje się on w .\application\configs\application.ini i wygladajakoś tak:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

Mając taki ładny czysty projekt, każdy pewnie chce go wyposażyć w dostęp do bazy danych. I tu czeka nas miła, bo ustawienie adaptera do naszej bazy jest banalnie prosta i polega tylko na dodaniu małej wstawki w plik konfiguracyjny widoczny powyżej.
...
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.db.adapter = PDO_MYSQL
resources.db.params.host = adres_bazy
resources.db.params.username = nazwa_konta
resources.db.params.password = haslo_dostepu
resources.db.params.dbname = nazwa_tablicy_w_bazie
[staging : production]
...

Powyższa czynność gwarantuje nam, bezproblemowy dostęp do tak skonfigurowanej bazy przy pomocy wszystkich klas z rodziny Zend_Db, w całym projekcie za wyjątkiem bootstrapera (.\application\Bootstrap.php). I tu właśnie się okazało, że w niektórych przypadkach i tam ten dostęp by był przydatny. Aby go uzyskać wystarczy przed naszym kodem korzystającym z dostępu do bazy ustawić domyślny adapter bazy danych, a raczej powiedzieć Zendowi gdzie leży jego konfiguracja. Pomoże nam w tym poniższy kawałek kodu:
...
$config = new Zend_Config_Ini('../application/configs/application.ini', 'production');
$db = Zend_Db::factory($config->resources->db);
Zend_Db_Table::setDefaultAdapter($db);
...

I można już odpytywać bazę danych i tu  
]]>
			http://netija.pl/wpis/46/feed
		0
		
		
		
		http://netija.pl/wpis/36
		http://netija.pl/wpis/36#comments
		Mon, 11 Jan 2010 00:18:59 +0000
		Marek
				
		
		
		

		http://netija.pl/?p=36
		
			Zend jako dość porządny framework PHPowy wypracował sobie bardzo ciekawy sposób ładowanie klas, który wywodził się z banalnego pomysłu na autoloadera. Mianowicie nazwa klasy zawierała w sobie częściową ścieżkę do pliku zawierającą kod naszego obiektu. Kolejne nazwy folderów i na końcu również samego pliku z klasą były odseparowane od siebie podkreślikiem „_” (chyba tak to się nazywa  ), tak więc przykładowa nazwa klasy wyglądała tak:

Core_Db_Connector co przenosiło się bezpośrednio na lokację /Core/Db/Connector.php.
Pomysł stary i dość powszechnie stosowany choć przeciwników też ma. Programiści Zenda jednak zaadoptowali ten pomysł, lecz gdy zauważyli, że co programista to inna wizja rozłożenia standardowych elementów systemu po katalogach, to pomogli nam to również uporządkować. Dlatego właśnie powstały prefixy dla najważniejszych i często stosowanych elementów systemu.
Poniżej przedstawiam taką podręczną liste, która każdemu początkującemu programiście Zend Frameworka się przyda  



Katalog
Prefix
Przykład zastosowania


api
Api_
Api_Resetuj


forms
Form_
Form_Dodaj


models
Model_
Model_Wpisy


models/DbTable
Model_DbTable_
Model_DbTable_Imiona


plugins
Plugin_
Plugin_Kolorowanie



Ostatnimi czasy dłubie trochę przy pomocy tego rozwiązania, więc sądzę, że będzie tu więcej artykułów o Zendzie  
]]>
			http://netija.pl/wpis/36/feed
		0