zobrazovanie informacnych listov.

zobrazovanie informacnych listov.

[tomi.belan, 2011-04-17 00:35:22]

finally done. ked vo fajre pojdes na adresu
http://localhost/fajr.php?action=predmety.InformacnyList&code=1-INF-150
tak to stiahne z AISu dany informacny list a zobrazi ho.

okrem stiahnuteho HTML zobrazujem aj trace, ak je zapnuty. trace potrebuje kopu
CSS a to CSS meni aj vzhlad informacneho listu, vypni trace a uvidis originalny
AISovy look.

ziaden outward-facing user interface vo fajre samotnom (ziaden tab "informacne
listy", "vyhladavanie predmetov" apod). toto je myslene ako sluzba na ktoru sa
mozu odkazovat ine veci typu candle.

zatial treba byt v aise (aj fajre) prihlaseny, aj ked ta aisova aplikacia vraj
funguje aj bez toho (treba checknut). toto sa odklada na followup patch, lebo si
to vyzaduje vacsie zmeny vo fajr architekture.

security concerns: "code" sa pastuje dovnutra CDATA, takto:
<![CDATA[1-INF-150]]>. zvlada toto fajr StringValidator osetrit? (aka je vlastne
oficialna syntax CDATA - funguju vnutri entity alebo nejaky escaping?)

XSS concerns: nijako nekontrolujeme to co AIS vrati, proste raw HTML vypisem.
keby bol AIS zakerny (prip. keby niekto s privilegiami na pridavanie inf. listov
vyuzil existujucu AIS XSS dieru), vie nam nieco spravit.

----

[velky rant]

ok, tolko konstruktivna cast tohto descriptionu - teraz si potrebujem dost silno
zarantovat. prilis sa neurazte, prosim :-) (alebo ak mate prave zlu naladu, tak
to zatial preskocte;)

tento patch pridava do fajru jediny AISovy feature, ktory normalne v AISe
zaberie cca 5 kliknuti. napriek tomu bolo treba zmenit _17 suborov_ a dokopy do
nich pridat cca _500 riadkov_.

zistit, ake AIS requesty treba spravit, bolo trivialne - drvivu vacsina casu som
stravil presviedcanim fajrovej architektury, nech robi to co ma. jediny subor,
co v celom patchi aj nieco fakt robi, je RegisterPredmetovScreenImpl.php (120
riadkov, z coho prvych 50 je tiez generickych) (dalej "RPSI"). skoro _vsetko
ostatne_ je iba boilerplate a overhead okolo. (plus, implementovat toto cele v
shellskripte pomocou curl, bez akejkolvek fajr architektury, by zabralo max 100
riadkov.)

kodenie som zacal od samotneho RPSI, ale dostat sa do faze, kde som to mohol
fakt spustit a debugovat samotne AIS requesty, trvalo absurdne dlho, a vzdy sa
vynoril nejaky skryty dependency - aby som mohol vyrobit RPSI, treba najprv
interfacy a tovarne, na to sa treba zahakovat do injectora (ktory ma BTW
neprijemne tendencie pri parse erroroch v php suboroch hadzat white screen of
death), ale existujuci studium controller je prilis prepojeny s VSES017 takze
treba vyrobit novy, a to tiez treba dat do injectora, a injector whitescreenuje
a whitescreenuje, a ten controller nemoze proste vratit to HTML co dostane ale
treba vyrobit templates, atd atd atd. WTF, fajr? WTF?

(ironicky uz mi zacali napadat myslienky ze lepsie pouzivat ais ako developovat
fajr... sigh)

[/velky rant]

----

koniec skaredeho nekonstruktivneho rantu. hmm, je mozne aj, ze som narazil na
nejaky lokalny overhead worst-case (pridavanie noveho controllera sa predsalen
tak casto nestane), alebo je mozne, ze to vidim v horsom svetle lebo sa vo fajre
este nevyznam, atd, but still - 500 riadkov na automatizaciu 5 kliknuti?

ok, uz je ten message hrozne dlhy, takze koncim. dobru noc...

[ppershing, 2011-04-17 05:23:12]

> security concerns: "code" sa pastuje dovnutra CDATA, takto:
> <![CDATA[1-INF-150]]>. zvlada toto fajr StringValidator osetrit? (aka je

Oficianla cdata syntax je "obsahuje cokolvek co nie je ]]>"
StringValidtor neosetruje nic (iba to ze je to string), chce to
vlastny validator. Ale este lepsie by bolo sa vysrat na cdata a
normalne to v xml naescapovat.

> ok, tolko konstruktivna cast tohto descriptionu - teraz si potrebujem
> dost silno zarantovat. prilis sa neurazte, prosim :-) (alebo ak mate
> prave zlu naladu, tak to zatial preskocte;)
>
> tento patch pridava do fajru jediny AISovy feature, ktory normalne v
> AISe zaberie cca 5 kliknuti. napriek tomu bolo treba zmenit _17 suborov_
> a dokopy do nich pridat cca _500 riadkov_.
>
> zistit, ake AIS requesty treba spravit, bolo trivialne - drvivu vacsina
> casu som stravil presviedcanim fajrovej architektury, nech robi to co
> ma. jediny subor, co v celom patchi aj nieco fakt robi, je
> RegisterPredmetovScreenImpl.php (120 riadkov, z coho prvych 50 je tiez
> generickych) (dalej "RPSI"). skoro _vsetko ostatne_ je iba boilerplate a
> overhead okolo. (plus, implementovat toto cele v shellskripte pomocou
> curl, bez akejkolvek fajr architektury, by zabralo max 100 riadkov.)
>
> kodenie som zacal od samotneho RPSI, ale dostat sa do faze, kde som to
> mohol fakt spustit a debugovat samotne AIS requesty, trvalo absurdne
> dlho, a vzdy sa vynoril nejaky skryty dependency - aby som mohol vyrobit
> RPSI, treba najprv interfacy a tovarne, na to sa treba zahakovat do
> injectora (ktory ma BTW neprijemne tendencie pri parse erroroch v php
Ehm, si si isty, ze nemas u seba v php nastavene ERROR_REPORTING = none?
Whitescreen je presne znak tohoto! skus si spravit nejaku inu chybu v
normalnom php subore a uvidis ze namiesto chyby dostanes tiez
whitescreen. Alebo je to fakt iba fajr-specificke?

> suboroch hadzat white screen of death), ale existujuci studium
> controller je prilis prepojeny s VSES017 takze treba vyrobit novy, a to
> tiez treba dat do injectora, a injector whitescreenuje a whitescreenuje,
> a ten controller nemoze proste vratit to HTML co dostane ale treba
> vyrobit templates, atd atd atd. WTF, fajr? WTF?

No, pointa je, ze na pridanie jednej featury je to strasne
neprakticke, ale na pridanie celej masinerie featur je to vyrazne
prakticke. Boli casy ked sme vracali html a bolo to dost zle udrzat
dizajn. Boli casy ked neboli controllery. Boli casy ked manipulacia s
AISom bola v jednej velkej triede ... vsetko bolo potrebne
refaktorovat kvoli tomu ze to bolo neudrzatelne.

>
> (ironicky uz mi zacali napadat myslienky ze lepsie pouzivat ais ako
> developovat fajr... sigh)
>
> [/velky rant]
>
> ----
>
> koniec skaredeho nekonstruktivneho rantu. hmm, je mozne aj, ze som
> narazil na nejaky lokalny overhead worst-case (pridavanie noveho
> controllera sa predsalen tak casto nestane), alebo je mozne, ze to vidim
> v horsom svetle lebo sa vo fajre este nevyznam, atd, but still - 500
> riadkov na automatizaciu 5 kliknuti?
Lenze pozor, tych 500 riadkov ma pomerne silnu masineriu. Napriklad,
vsetky tie factory a ine veci sa potrebuju vyrabat kvoli tomu, ze v
demo backende nechces accessovat original AIS ale lokalnu fake
instanciu. A neviem ako by si to vedel robit inak
>
> ok, uz je ten message hrozne dlhy, takze koncim. dobru noc...
>
>
> Description:
> zobrazovanie informacnych listov.
>
> Please review this at http://codereview.appspot.com/4427048/
>
> Affected files:
>  A     src/controller/predmety/PredmetyController.php
>  M     src/libfajr/pub/connection/AIS2ServerUrlMap.php
>  M     src/libfajr/pub/window/AIS2ApplicationEnum.php
>  A
> src/libfajr/pub/window/VSST060_register_predmetov/RegisterPredmetovScreen.php
>  A     src/libfajr/pub/window/VSST060_register_predmetov/VSST060_Factory.php
>  A
> src/libfajr/pub/window/VSST060_register_predmetov/VSST060_FactoryImpl.php
>  A
> src/libfajr/pub/window/VSST060_register_predmetov/VSST060_FakeFactoryImpl.php
>  M     src/libfajr/window/RequestBuilder.php
>  M     src/libfajr/window/RequestBuilderImpl.php
>  M     src/libfajr/window/ScreenRequestExecutorImpl.php
>  A
> src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php
>  A
>
src/libfajr/window/VSST060_register_predmetov/fake/FakeRegisterPredmetovScreenImpl.php
>  M     src/modules/ControllerInjectorModule.php
>  M     src/modules/ControllerModule.php
>  M     src/modules/InputModule.php
>  A     templates/fajr/pages/predmety/informacnyList.xhtml
>  A     templates/fajr/pages/predmety/notAvailable.xhtml
>
>
>

[tomi.belan, 2011-04-17 07:11:15]

[sorry, "reply to all" miesto "reply"]

OK, dakujem za vysvetlenie. Veru, tusim som narazil na nejaky worst-case co
sa tohto tyka, lebo bolo pridavat komplet novu aplikaciu, noveho controllera
atd.

(Also: mozno by bodol nejaky development override rezim typu "na vsetko
hento sa vykasli a proste inicializuj tento screen a zavolaj toto". Lebo
vacsina mojich problemov vznikla z toho, ze som zacal vyrabat samotny
request a hrozne dlho trvalo, kym som to mohol dostat do stavu kde som aj
mohol sledovat co to robi. Ani ta masineria okolo by mi asi tak nevadila,
keby som nemal pocit ze stoji v ceste mojmu normalnemu developmentu.
Nedopeceny napad, neviem presne ako si to predstavujem, ale mozno nieco
taketo.)

Este co sa tych whitescreenov tyka: v php.ini mam E_ALL&~E_DEPRECATED, ale
mam lighttpd miesto apacha, co moze veci zmenit. Lenze padalo to na riadku
$injector->getInstance() a ked som tesne pred neho dal
call_nonexistent_function() tak to do lighttpd error logu korektne reportlo
dany error a na tom getInstance() to nenahlasilo vobec nic.

Tomi

2011/4/17 Perešíni Peter <ppershing@gmail.com>

> > security concerns: "code" sa pastuje dovnutra CDATA, takto:
> > <![CDATA[1-INF-150]]>. zvlada toto fajr StringValidator osetrit? (aka je
>
> Oficianla cdata syntax je "obsahuje cokolvek co nie je ]]>"
> StringValidtor neosetruje nic (iba to ze je to string), chce to
> vlastny validator. Ale este lepsie by bolo sa vysrat na cdata a
> normalne to v xml naescapovat.
>
> > ok, tolko konstruktivna cast tohto descriptionu - teraz si potrebujem
> > dost silno zarantovat. prilis sa neurazte, prosim :-) (alebo ak mate
> > prave zlu naladu, tak to zatial preskocte;)
> >
> > tento patch pridava do fajru jediny AISovy feature, ktory normalne v
> > AISe zaberie cca 5 kliknuti. napriek tomu bolo treba zmenit _17 suborov_
> > a dokopy do nich pridat cca _500 riadkov_.
> >
> > zistit, ake AIS requesty treba spravit, bolo trivialne - drvivu vacsina
> > casu som stravil presviedcanim fajrovej architektury, nech robi to co
> > ma. jediny subor, co v celom patchi aj nieco fakt robi, je
> > RegisterPredmetovScreenImpl.php (120 riadkov, z coho prvych 50 je tiez
> > generickych) (dalej "RPSI"). skoro _vsetko ostatne_ je iba boilerplate a
> > overhead okolo. (plus, implementovat toto cele v shellskripte pomocou
> > curl, bez akejkolvek fajr architektury, by zabralo max 100 riadkov.)
> >
> > kodenie som zacal od samotneho RPSI, ale dostat sa do faze, kde som to
> > mohol fakt spustit a debugovat samotne AIS requesty, trvalo absurdne
> > dlho, a vzdy sa vynoril nejaky skryty dependency - aby som mohol vyrobit
> > RPSI, treba najprv interfacy a tovarne, na to sa treba zahakovat do
> > injectora (ktory ma BTW neprijemne tendencie pri parse erroroch v php
> Ehm, si si isty, ze nemas u seba v php nastavene ERROR_REPORTING = none?
> Whitescreen je presne znak tohoto! skus si spravit nejaku inu chybu v
> normalnom php subore a uvidis ze namiesto chyby dostanes tiez
> whitescreen. Alebo je to fakt iba fajr-specificke?
>
> > suboroch hadzat white screen of death), ale existujuci studium
> > controller je prilis prepojeny s VSES017 takze treba vyrobit novy, a to
> > tiez treba dat do injectora, a injector whitescreenuje a whitescreenuje,
> > a ten controller nemoze proste vratit to HTML co dostane ale treba
> > vyrobit templates, atd atd atd. WTF, fajr? WTF?
>
> No, pointa je, ze na pridanie jednej featury je to strasne
> neprakticke, ale na pridanie celej masinerie featur je to vyrazne
> prakticke. Boli casy ked sme vracali html a bolo to dost zle udrzat
> dizajn. Boli casy ked neboli controllery. Boli casy ked manipulacia s
> AISom bola v jednej velkej triede ... vsetko bolo potrebne
> refaktorovat kvoli tomu ze to bolo neudrzatelne.
>
> >
> > (ironicky uz mi zacali napadat myslienky ze lepsie pouzivat ais ako
> > developovat fajr... sigh)
> >
> > [/velky rant]
> >
> > ----
> >
> > koniec skaredeho nekonstruktivneho rantu. hmm, je mozne aj, ze som
> > narazil na nejaky lokalny overhead worst-case (pridavanie noveho
> > controllera sa predsalen tak casto nestane), alebo je mozne, ze to vidim
> > v horsom svetle lebo sa vo fajre este nevyznam, atd, but still - 500
> > riadkov na automatizaciu 5 kliknuti?
> Lenze pozor, tych 500 riadkov ma pomerne silnu masineriu. Napriklad,
> vsetky tie factory a ine veci sa potrebuju vyrabat kvoli tomu, ze v
> demo backende nechces accessovat original AIS ale lokalnu fake
> instanciu. A neviem ako by si to vedel robit inak
> >
> > ok, uz je ten message hrozne dlhy, takze koncim. dobru noc...
> >
> >
> > Description:
> > zobrazovanie informacnych listov.
> >
> > Please review this at http://codereview.appspot.com/4427048/
> >
> > Affected files:
> >  A     src/controller/predmety/PredmetyController.php
> >  M     src/libfajr/pub/connection/AIS2ServerUrlMap.php
> >  M     src/libfajr/pub/window/AIS2ApplicationEnum.php
> >  A
> >
> src/libfajr/pub/window/VSST060_register_predmetov/RegisterPredmetovScreen.php
> >  A
> src/libfajr/pub/window/VSST060_register_predmetov/VSST060_Factory.php
> >  A
> > src/libfajr/pub/window/VSST060_register_predmetov/VSST060_FactoryImpl.php
> >  A
> >
> src/libfajr/pub/window/VSST060_register_predmetov/VSST060_FakeFactoryImpl.php
> >  M     src/libfajr/window/RequestBuilder.php
> >  M     src/libfajr/window/RequestBuilderImpl.php
> >  M     src/libfajr/window/ScreenRequestExecutorImpl.php
> >  A
> >
> src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php
> >  A
> >
>
src/libfajr/window/VSST060_register_predmetov/fake/FakeRegisterPredmetovScreenImpl.php
> >  M     src/modules/ControllerInjectorModule.php
> >  M     src/modules/ControllerModule.php
> >  M     src/modules/InputModule.php
> >  A     templates/fajr/pages/predmety/informacnyList.xhtml
> >  A     templates/fajr/pages/predmety/notAvailable.xhtml
> >
> >
> >
>

[anty, 2011-04-17 16:22:44]

On 2011/04/17 07:11:15, tomi.belan wrote:
> Este co sa tych whitescreenov tyka: v php.ini mam E_ALL&~E_DEPRECATED, ale
> mam lighttpd miesto apacha, co moze veci zmenit. Lenze padalo to na riadku
> $injector->getInstance() a ked som tesne pred neho dal
> call_nonexistent_function() tak to do lighttpd error logu korektne reportlo
> dany error a na tom getInstance() to nenahlasilo vobec nic.
Hm. Bud je to nejaky bug, ze sa chyta nejaka vynimka a nepise.
Inac mozno nie je zly napad si zapnut aj display_errors, ak nemas.

> 
> 2011/4/17 Perešíni Peter <mailto:ppershing@gmail.com>
> 
> > > security concerns: "code" sa pastuje dovnutra CDATA, takto:
> > > <![CDATA[1-INF-150]]>. zvlada toto fajr StringValidator osetrit? (aka je
> >
> > Oficianla cdata syntax je "obsahuje cokolvek co nie je ]]>"
> > StringValidtor neosetruje nic (iba to ze je to string), chce to
> > vlastny validator. Ale este lepsie by bolo sa vysrat na cdata a
> > normalne to v xml naescapovat.
Tiez by sa dalo pouzit strip_tags, alebo nieco take a povolit len take bezne
tagy typu div,span,p,table,tr,th,td,b,i,u
(myslim, ze ine ani netreba - linky sa tam tusim tiez nenachadzaju...)


> >
> > > ok, tolko konstruktivna cast tohto descriptionu - teraz si potrebujem
> > > dost silno zarantovat. prilis sa neurazte, prosim :-) (alebo ak mate
> > > prave zlu naladu, tak to zatial preskocte;)
> > >
> > > tento patch pridava do fajru jediny AISovy feature, ktory normalne v
> > > AISe zaberie cca 5 kliknuti. napriek tomu bolo treba zmenit _17 suborov_
> > > a dokopy do nich pridat cca _500 riadkov_.
Ano, toto ma tiez stvalo, ked som robil prehlad kreditov - pridany dialog etc.
som mal za chvilu, ale pridat podporu pre fake backend trvalo najviac (esp. ked
to bola fakt velka tabulka...).


> > >
> > > zistit, ake AIS requesty treba spravit, bolo trivialne - drvivu vacsina
> > > casu som stravil presviedcanim fajrovej architektury, nech robi to co
> > > ma. jediny subor, co v celom patchi aj nieco fakt robi, je
> > > RegisterPredmetovScreenImpl.php (120 riadkov, z coho prvych 50 je tiez
> > > generickych) (dalej "RPSI"). skoro _vsetko ostatne_ je iba boilerplate a
> > > overhead okolo. (plus, implementovat toto cele v shellskripte pomocou
> > > curl, bez akejkolvek fajr architektury, by zabralo max 100 riadkov.)
> > >
> > > kodenie som zacal od samotneho RPSI, ale dostat sa do faze, kde som to
> > > mohol fakt spustit a debugovat samotne AIS requesty, trvalo absurdne
> > > dlho, a vzdy sa vynoril nejaky skryty dependency - aby som mohol vyrobit
> > > RPSI, treba najprv interfacy a tovarne, na to sa treba zahakovat do
> > > injectora (ktory ma BTW neprijemne tendencie pri parse erroroch v php
> > Ehm, si si isty, ze nemas u seba v php nastavene ERROR_REPORTING = none?
> > Whitescreen je presne znak tohoto! skus si spravit nejaku inu chybu v
> > normalnom php subore a uvidis ze namiesto chyby dostanes tiez
> > whitescreen. Alebo je to fakt iba fajr-specificke?
> >
> > > suboroch hadzat white screen of death), ale existujuci studium
> > > controller je prilis prepojeny s VSES017 takze treba vyrobit novy, a to
> > > tiez treba dat do injectora, a injector whitescreenuje a whitescreenuje,
> > > a ten controller nemoze proste vratit to HTML co dostane ale treba
> > > vyrobit templates, atd atd atd. WTF, fajr? WTF?
> >
> > No, pointa je, ze na pridanie jednej featury je to strasne
> > neprakticke, ale na pridanie celej masinerie featur je to vyrazne
> > prakticke. Boli casy ked sme vracali html a bolo to dost zle udrzat
> > dizajn. Boli casy ked neboli controllery. Boli casy ked manipulacia s
> > AISom bola v jednej velkej triede ... vsetko bolo potrebne
> > refaktorovat kvoli tomu ze to bolo neudrzatelne.
> >
> > >
> > > (ironicky uz mi zacali napadat myslienky ze lepsie pouzivat ais ako
> > > developovat fajr... sigh)
> > >
> > > [/velky rant]
> > >
> > > ----
> > >
> > > koniec skaredeho nekonstruktivneho rantu. hmm, je mozne aj, ze som
> > > narazil na nejaky lokalny overhead worst-case (pridavanie noveho
> > > controllera sa predsalen tak casto nestane), alebo je mozne, ze to vidim
> > > v horsom svetle lebo sa vo fajre este nevyznam, atd, but still - 500
> > > riadkov na automatizaciu 5 kliknuti?
> > Lenze pozor, tych 500 riadkov ma pomerne silnu masineriu. Napriklad,
> > vsetky tie factory a ine veci sa potrebuju vyrabat kvoli tomu, ze v
> > demo backende nechces accessovat original AIS ale lokalnu fake
> > instanciu. A neviem ako by si to vedel robit inak
Tiez tie classy zabezpecuju, ze sa zatvaraju resources na strane AIS-u.
Controllery su robene tak, ze ich nepridavas moc casto (ale az tak zlozite to
nie je).
Pridat akciu je oproti tomu zalezitost pridania jednej metody.

[anty, 2011-04-17 16:35:19]

inak som to pozeral a lgtm, az na tu security concern, ale to by nemal byt
problem tam pridat nejake strip_tags alebo nieco (plus, akonahle AIS generuje
nejaku XSS, tak je asi aj on vulnerable, co vsak neznamena, ze by sme nemali
robit safety precautions)

[OT]mal by som konecne spravit to testovanie fajru s roznymi evil vstupmi +
testovanie templatov[/OT]

[majak, 2011-04-17 19:39:13]

http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
File
src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php
(right):

http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php:33:
* Trieda reprezentujúca jednu obrazovku so zoznamom predmetov.
Zabudol si upravit doccomment.

http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php:75:
// asi sa defaultne pouzije prvy - je to OK?
Myslim, ze by bolo lepsie mu povedat, ze naozaj chcem prvy.
To sa v XML requeste AISu hovori takto (cast):

<objName>zoznamPredmetovTable</objName>
<propertyValues>
<nameValue>
 <name>dataView</name>
 <isXml>true</isXml>
 <value><![CDATA[
  <root> <selection>
   <activeIndex>0</activeIndex>
   <selectedIndexes>0</selectedIndexes>
  </selection> </root>
 ]]></value>

http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php:75:
// asi sa defaultne pouzije prvy - je to OK?
Mozno by nebolo zle vyhodit chybu, ak kod matchne viac ako jeden predmet?

http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php:77:
$data = $this->executor->doRequest(
Vyber parametrov informacnych listov (CM024) je dialog.
Preto by bolo lepsie, ak by si pren spravil novu dialogovu triedu, pomocou
ktorej vytiahnes tie data.
Inspiraciou moze byt napriklad par TerminyHodnoteniaScreenImpl a
TerminyDialogImpl.

http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php:116:
return $this->executor->doFilesRequest($trace, array('file' => '', 'contentType'
=> ''));
Overil som ze tieto parametre su naozaj nanic.
Aj ked si dam vygenerovat iny informacny list,
tak v tabe s predchadzajucim sa mi na tej istej url po refreshi otvori ten iny
novy:-).

[anty, 2011-04-17 19:52:28]

http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
File
src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php
(right):

http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php:75:
// asi sa defaultne pouzije prvy - je to OK?
On 2011/04/17 19:39:13, majak wrote:
> Mozno by nebolo zle vyhodit chybu, ak kod matchne viac ako jeden predmet?
V prvej verzii podla mna moze byt ak vyhodime vynimku. V nejakej dalsej mozno
budeme chciet zobrazit zoznam vsetkych matchnutych predmetov (podla toho, ako to
ten AIS joinuje. Jeden predmet na dvoch roznych pracoviskach asi bude mat dva
zaznamy).

[majak, 2011-04-17 20:04:21]

On 2011/04/17 19:52:28, anty wrote:
>
http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
> File
> src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php
> (right):
> 
>
http://codereview.appspot.com/4427048/diff/1/src/libfajr/window/VSST060_regis...
>
src/libfajr/window/VSST060_register_predmetov/RegisterPredmetovScreenImpl.php:75:
> // asi sa defaultne pouzije prvy - je to OK?
> On 2011/04/17 19:39:13, majak wrote:
> > Mozno by nebolo zle vyhodit chybu, ak kod matchne viac ako jeden predmet?
> V prvej verzii podla mna moze byt ak vyhodime vynimku. V nejakej dalsej mozno
> budeme chciet zobrazit zoznam vsetkych matchnutych predmetov (podla toho, ako
to
> ten AIS joinuje. Jeden predmet na dvoch roznych pracoviskach asi bude mat dva
> zaznamy).

Mas pravdu, jeden predmet na dvoch pracoviskach ma naozaj dva zaznamy.
Napr. 2-AIN-503, lisi sa len "strediskom".

[anty, 2011-08-10 15:37:15]

idem pouzit tento patch, predpokladam, ze toto je najnovsia verzia, vsak?

[tomi.belan, 2011-08-10 20:50:28]

Tusim ano, mozem to este checknut ked budem na development stroji. Pri tej
prilezitosti aj skusim vyhrabat ten TODO list ze ktore veci boli nedokoncene
resp. s vyhradami. Tie mozme spravit v neskorsom commite, aj ked neviem ci
to bude mojou rukou, lebo ak si dobre pamatam, v niektorych castiach som mal
pocit ze ich moze lepsie/efektivnejsie spravit niekto kto sa vo fajre uz
vyzna. Uz neviem detaily ale tiez pohrabem.
Tomi

2011/8/10 <anty.sk@gmail.com>

> idem pouzit tento patch, predpokladam, ze toto je najnovsia verzia,
> vsak?
>
>
http://codereview.appspot.com/**4427048/<http://codereview.appspot.com/4427048/>
>