Objekty
Objekty jsou základním datovým prvkem platformy.
Přístup k objektům
K objektům se bude přistupovat buď atomicky pomocí URL ve tvaru
///<identifikátor>
nebo kontejnerově ve tvaru
//
a seznam identifikátorů se bude odesílat v parametru _ids, který bude polem. V případě kontejnerového přístupu se bude operace týkat všech definovaných objektů.
U kontejnerového přístupu bude možné zároveň definovat filtrační podmínky. Ty budou definovány v objektu _filter(jak se odlišuje objekt _filter od jineho objektu?Kde budou ulozeny informace o relacich – uvinitr objektu, v jinych objektech?), který bude umožňovat po zpracování sestavit podmínku pro SQL dotaz.
Relace mezi objekty
Pro vytváření vztahů mezi objekty musí existovat relace. Pro relace existuje speciální metoda rel, která umožňuje tyto relace použít. Přístup se provádí tedy pomocí URL ve tvaru
//rel/<identifikátor>
ke kterému je nutné poslat ještě argument _key(_key bude urcovat co presne - nestaci identifikator? Nebo specifikuje, podle ktereho atribubutu objektu se maj vyhledavat relacni objekty?), který specifikuje, který klíč se má použít. Dále je možné poslat objekt _filter, se specifikací filtrace objektů. Relace vždy vrací kontejner objektů.
Filtrace objektů
Pro specifikaci filtrů se používá filtrační objekt. Ten je definován pomocí operátoru a operandů. Operandy jsou uloženy ve sekvenčním poli, které musí být indexováno od nuly a operátor je uložen v prvku jménem operator.
Jako operand může být použit další filtrační objekt. Níže je uveden příklad.
Je odeslán filtrační objekt s operátorem OR. Jedním operadnem je hodnota 'is_readed' a druhým operandem je další filtrační objekt. Tento vnořený objekt obsahuje operátor '=' a dva operandy, které jsou 'user_id' a '2'.
Z těchto dvou objektů se poté složí SQL podmínka
is_read OR (user_id = 2)
To sekvenci pole bude nejakej retezec, kterej bude atribut toho filtracniho dotazu?
Funkce
Funkce slouží pro komplikovanější operace s objekty, kdy je nutné zpracovat více objektů. Každá funkce musí být definována ve jmenném prostoru. K jednotlivým funkcím se přistupuje pomocí URL ve tvaru
/fn/<jmenný prostor>/
Parametry jsou odeslány metodou POST nebo GET. Formát těchto parametrů není definován a záleží na funkci v jakém formátu tyto parametry vyžaduje.
Formát návratové hodnoty také není pevně stanoven (měl by být popsán v dokumentaci funkce).
souhlas
Systémový objekt
Vyhrazený objekt je systém, který slouží pro nastavování systému a práci s ním (přihlašování uživatelů a podobně).
Prozatím si vystačíme s tímto obsahem systémového objektu, který se později bude rozšiřovat
user
get
put
post
delete
signin
signout
ok,jak presne to mas s postem?
Nemeli by byt vsechny objekty si rovnocene. Myslim to tak jestli by nemel nosit stejny objekt i usera i jiné objekty..proc to neudelat jednoobjektove a jen to ridit parametrama objektu?
Cele by to mělo fungovat co nejjednouduseji při co nejmensim poctu objektu, funkci a metod..klasickej CRUD ne?..
Stejne tak filtrovaci objekt je zbytecnej a relacni balik je zbytecnej ne?..
cim min funkci a objektu tim transparentnejsi a narustat a nabobtnavat bych to nechal az na vyssich urovnich..
Doporučení k implementaci
V následující části dokumentu je výpis doporučení k implementaci serverové části platformy. Tyto doporučení nejsou v žádném případě zavazující a v případě lepšího nápadu se samozřejmě použije nové řešení.
Objekty
Každý objekt by měl být odvozen od abstraktního objektu. Abstraktní objekt bude umět přímo načíst objekty definované požadavkem (atomicky i kontejnerově) a následně je také uložit.
Taktéž by bylo vhodné, aby metody implementované objektem byly odvozeny od nějaké abstraktní třídy. Ta by mohla například definovat metodu init nebo cleanup, které by se volaly před, respektive po, zpracování dané metody. Metoda by vracela kontejner s objekty, které by se dále předaly klientovi (viz obrázek).
Souhlas...tohle je podle me idea Javy
Pro uchovávání dat navrhuji vytvořit dvě datové struktury. Jedna obsahující právě jeden datový objekt a druhá by sloužila jako kontejner. První objekt by měl zároveň uchovávat informaci o tom, zda byla data modifikována. ano
Při tvorbě filtračních objektů by se opět dle mého názoru mělo vycházet z abstraktní třídy. Tato abstraktní třída by mohla definovat konstruktor, který by nastavil parametry operandů a operátor. Nebylo by špatné, kdyby třída operátoru implementovala kromě vypisující metody (v bázové třídě abstraktní) také magickou metodu __toString, která by sestavený výraz umístila do závorek. To by značně zjednodušilo sestavování.
Funkce
U funkce by mohly být uvedené typy vstupních parametrů a nebylo by špatné, kdyby při inicializaci funkce byly vstupní parametry rovnou převedeny na vstupní objekty. Samozřejmě by šlo nadefinovat, že vstupní parametr je například skalár (nebo tak nějak), aby se nekonvertoval na datový objekt.
Urcite ano, sice na to php nemá zvykle, ale ke slusnemu programu to patri a Big Brother by mel dodrzovat jak se rika ŠTÁBNÍ KULTURU:)
MartinProkop
commented
13 years ago
Objekty Objekty jsou základním datovým prvkem platformy. Přístup k objektům K objektům se bude přistupovat buď atomicky pomocí URL ve tvaru ///<identifikátor>
nebo kontejnerově ve tvaru
//
a seznam identifikátorů se bude odesílat v parametru _ids, který bude polem. V případě kontejnerového přístupu se bude operace týkat všech definovaných objektů.
U kontejnerového přístupu bude možné zároveň definovat filtrační podmínky. Ty budou definovány v objektu _filter(jak se odlišuje objekt _filter od jineho objektu?Kde budou ulozeny informace o relacich – uvinitr objektu, v jinych objektech?), který bude umožňovat po zpracování sestavit podmínku pro SQL dotaz.
Relace mezi objekty
Pro vytváření vztahů mezi objekty musí existovat relace. Pro relace existuje speciální metoda rel, která umožňuje tyto relace použít. Přístup se provádí tedy pomocí URL ve tvaru
//rel/<identifikátor>
ke kterému je nutné poslat ještě argument _key(_key bude urcovat co presne - nestaci identifikator? Nebo specifikuje, podle ktereho atribubutu objektu se maj vyhledavat relacni objekty?), který specifikuje, který klíč se má použít. Dále je možné poslat objekt _filter, se specifikací filtrace objektů. Relace vždy vrací kontejner objektů.
Filtrace objektů
Pro specifikaci filtrů se používá filtrační objekt. Ten je definován pomocí operátoru a operandů. Operandy jsou uloženy ve sekvenčním poli, které musí být indexováno od nuly a operátor je uložen v prvku jménem operator.
Jako operand může být použit další filtrační objekt. Níže je uveden příklad.
Je odeslán filtrační objekt s operátorem OR. Jedním operadnem je hodnota 'is_readed' a druhým operandem je další filtrační objekt. Tento vnořený objekt obsahuje operátor '=' a dva operandy, které jsou 'user_id' a '2'.
Z těchto dvou objektů se poté složí SQL podmínka
is_read OR (user_id = 2)
To sekvenci pole bude nejakej retezec, kterej bude atribut toho filtracniho dotazu?
Funkce
Funkce slouží pro komplikovanější operace s objekty, kdy je nutné zpracovat více objektů. Každá funkce musí být definována ve jmenném prostoru. K jednotlivým funkcím se přistupuje pomocí URL ve tvaru
/fn/<jmenný prostor>/
Parametry jsou odeslány metodou POST nebo GET. Formát těchto parametrů není definován a záleží na funkci v jakém formátu tyto parametry vyžaduje.
Formát návratové hodnoty také není pevně stanoven (měl by být popsán v dokumentaci funkce).
souhlas
Systémový objekt
Vyhrazený objekt je systém, který slouží pro nastavování systému a práci s ním (přihlašování uživatelů a podobně).
Prozatím si vystačíme s tímto obsahem systémového objektu, který se později bude rozšiřovat
user
get
put
post
delete
signin
signout
ok,jak presne to mas s postem?
Nemeli by byt vsechny objekty si rovnocene. Myslim to tak jestli by nemel nosit stejny objekt i usera i jiné objekty..proc to neudelat jednoobjektove a jen to ridit parametrama objektu?
Cele by to mělo fungovat co nejjednouduseji při co nejmensim poctu objektu, funkci a metod..klasickej CRUD ne?..
Stejne tak filtrovaci objekt je zbytecnej a relacni balik je zbytecnej ne?..
cim min funkci a objektu tim transparentnejsi a narustat a nabobtnavat bych to nechal az na vyssich urovnich..
Doporučení k implementaci
V následující části dokumentu je výpis doporučení k implementaci serverové části platformy. Tyto doporučení nejsou v žádném případě zavazující a v případě lepšího nápadu se samozřejmě použije nové řešení.
Objekty
Každý objekt by měl být odvozen od abstraktního objektu. Abstraktní objekt bude umět přímo načíst objekty definované požadavkem (atomicky i kontejnerově) a následně je také uložit.
Taktéž by bylo vhodné, aby metody implementované objektem byly odvozeny od nějaké abstraktní třídy. Ta by mohla například definovat metodu init nebo cleanup, které by se volaly před, respektive po, zpracování dané metody. Metoda by vracela kontejner s objekty, které by se dále předaly klientovi (viz obrázek).
Souhlas...tohle je podle me idea Javy
Pro uchovávání dat navrhuji vytvořit dvě datové struktury. Jedna obsahující právě jeden datový objekt a druhá by sloužila jako kontejner. První objekt by měl zároveň uchovávat informaci o tom, zda byla data modifikována. ano Při tvorbě filtračních objektů by se opět dle mého názoru mělo vycházet z abstraktní třídy. Tato abstraktní třída by mohla definovat konstruktor, který by nastavil parametry operandů a operátor. Nebylo by špatné, kdyby třída operátoru implementovala kromě vypisující metody (v bázové třídě abstraktní) také magickou metodu __toString, která by sestavený výraz umístila do závorek. To by značně zjednodušilo sestavování. Funkce U funkce by mohly být uvedené typy vstupních parametrů a nebylo by špatné, kdyby při inicializaci funkce byly vstupní parametry rovnou převedeny na vstupní objekty. Samozřejmě by šlo nadefinovat, že vstupní parametr je například skalár (nebo tak nějak), aby se nekonvertoval na datový objekt. Urcite ano, sice na to php nemá zvykle, ale ke slusnemu programu to patri a Big Brother by mel dodrzovat jak se rika ŠTÁBNÍ KULTURU:)