Menu
▾
▴
dialogus-developers — Only developers (czech lang.)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(25) |
Apr
(8) |
May
(1) |
Jun
(12) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-22 12:34:33
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: <ta...@we...> - 2003-06-13 11:55:59
|
On Fri, Jun 13, 2003 at 12:39:43PM +0200, Kouba Tomas wrote: > Doplneni: ten jiny zpuisob zpracovani nekritickych chyb je: aplikace se z > chyby zpamatuje a zaloguje ji nebo se z ni nezpamatuje a pak jde o chybu > kritickou. Navrhl jsem DgsError2.java, ktery toto resi. Myslenka prototypu je IMHO spravna. Jenom drobne poznamky: 1) terminate() je lespi volba jmena pro termination() Jmennne konvence by mely vychazet z toho, ze volajici objekt chce, aby volany vykonal cinnost. Proto se pouzivaji jmena typu create(), execute(), setX(), getX(), zkratka provedNeco() misto neco() 2) Projdete si dobre Javadoc k java.lang.Exception . Opravdu si myslite, ze DgsError2 poskytuje maximalni mnozstvi informaci, kter by mohl poskytnout? Mne osobne chybi ex.getLocalizedMessage() ex.printStackTrace() (toto volitelne, na zaklade nastaveni nejake systemove property nebo boolovske konstanty DEBUG) Jeste na zaver: Pri psani o staticke metode jsem mel na mysli ten pripad, kdy vsechny veci, ktere by mohly byt konfigurovatelne, si vytahne Helper z nejakych singletonu ci z kontextu. Oto 'tapik' Buchta |
|
From: <ta...@we...> - 2003-06-13 11:41:45
|
On Fri, Jun 13, 2003 at 12:33:53PM +0200, Kouba Tomas wrote:
> Zdravim a preji pekny den,
Vam take,
> 1. to jste mne prekvapil. Doporuceni staticke metody jsem od Vas necekal :-)
Ze ne! Ja jsem si to myslel. Ale toto je zrovna ten usecase, kdy je to
spravne a ciste.
> 2. V navrzenych design patternech jsem nenasel mnou navrhovanou metodu:
> zavolani metody, ktera aplikaci ukonci pro pripady, kdy jde o kritickou
> chybu. V pripade kdy nejde o kritickou chybu, resi se to jinak. Priznavam,
Je tam. Je to presne o RuntimeException (lepe o jejim vlastnim potomkovi).
To, proc by se nemelo pouzivat System.exit(), jsem psal. Jako dalsi
duvod uvadim JUnit-ove testy. A neodchycena vyjimka zpusobi vypis
StackTrace pri padu aplikace, tedy mate presne lokalizovanou chybu.
> ze napriklad u metody ConfigMode.setValue() se mi kontrolovat navratovou
> hodnotu nechce,
^^^^^^
Ono
if (setValue($VAR$,$VALUE$) != 0)
throw new RuntimeException(
"$CLASS_NAME$.$METHOD_NAME$: Configuration variable "+$VAR$+" has
incorrect value `"+$VALUE$+"' !!!"
);
je naprosto uzasna Live Template pro IDEU :-) (teda doufam, pisu to
zpatra)
> protoze k chybe by melo dochazet velmi vyjimecne a metoda
> bude volana velmi casto - vzdy pro zmene konfiguracni hodnoty, coz u
> nekterych muze byt casto.
No, casto snad ne.
> 3. Zavola <code>throw new
> RuntimeException("ERROR:(message)",exception);</code> take vlakno
> addShutdownHook()? To je kriticke.
Trivialni test prokazal, ze spusti.
Oto 'tapik' Buchta
|
|
From: Kouba T. <to...@ne...> - 2003-06-13 10:37:11
|
Doplneni: ten jiny zpuisob zpracovani nekritickych chyb je: aplikace se z chyby zpamatuje a zaloguje ji nebo se z ni nezpamatuje a pak jde o chybu kritickou. Navrhl jsem DgsError2.java, ktery toto resi. -- Kouba Tomas mailto:to...@ne... |
|
From: Kouba T. <to...@ne...> - 2003-06-13 10:31:21
|
Zdravim a preji pekny den,
1. to jste mne prekvapil. Doporuceni staticke metody jsem od Vas necekal :-)
2. V navrzenych design patternech jsem nenasel mnou navrhovanou metodu:
zavolani metody, ktera aplikaci ukonci pro pripady, kdy jde o kritickou
chybu. V pripade kdy nejde o kritickou chybu, resi se to jinak. Priznavam,
ze napriklad u metody ConfigMode.setValue() se mi kontrolovat navratovou
hodnotu nechce, protoze k chybe by melo dochazet velmi vyjimecne a metoda
bude volana velmi casto - vzdy pro zmene konfiguracni hodnoty, coz u
nekterych muze byt casto.
3. Zavola <code>throw new
RuntimeException("ERROR:(message)",exception);</code> take vlakno
addShutdownHook()? To je kriticke.
--
Kouba Tomas
mailto:to...@ne...
> >
> > je skutecne nutne vzdy vyvolavat vyjimku? Mam zvlastni tridu,
> ktera osetruje
> > chyby (DgsError) a jsou pripady, kdy mi na to staci. Krasny priklad je v
> > ConfigMode.setValue().
>
> Dve veci:
> 1) V pripade DgsError se vam podaril presny opak problemu, nez o kterem
> jsme spolu nekolikrat diskutovali. DgsError je Helper, ktery jenom
> zaridi zalogovani a skonci. Vzhleem k tomu, ze si NEDRZI ZADNY VNITRNI
> STAV, je naprosto zbytecne, aby se pracovalo s instanci. Je totiz
> opravdu jedno, jestli zavolate konstruktor nebo sttaicjkou metodu
> saveMessage().
>
> 2) Ctyri hlavni design patterny pro osetreni chybovych styavu:
> a) vyhodi se obycejna vyjimka
> b) vyhodi se Error ci RuntimeException
> c) vrati se status provedene akce
> d) nevrati se nic a pouze se zaloguje
>
> Bod d) je nejmene casty, protoze se v kodu, ktery volal onen
> test, nejste schopen onu chybu nijak zpracovat. Tato vec se pouziva
> pouze tehdy, jedna-li se o BlackBox a de facto na vysledku testu
> nezavisi, co se bude dal dit.
>
> V klasickem proceduralnim jazyce se pouziva bod c) a i ja jsem
> zastancem tohoto postupu, nebot vyhazovani vyjimek je i pres velke
> optimalizace zbytecne drahe (a drahe je take vytvareni try { } catch
> bloku). Smysl ma tehdy, kdyz zjisteni chyby neni az tak vyjimecne, ale
> spis 50-50 se spravnym pruchodem.
>
> Bod a) je popisovan jako hlavni design-pattern. mel by se ale pouzivat
> tehdy, kdyz selhani testu je skutecnou vyjimkou, nikoli uplne beznym
> jevem. Jinak je dale nutny predpoklad, ze z teto vyjimky se aplikace
> muze zotavit (uzivatel zadal slovo a ma tam byt cislo).
>
> Bod b) ma smysl tehdy, kdyz se predpoklada, ze se z chyby nelze
> zotavit.
>
> Pouzivani System.exit() je nedoporucovano, protoze je zbytecne moc
> agresivni. Stejnou sluzbu zastane
> throw new RuntimeException("ERROR:(message)",exception);
> a navic lze takovou aplikaci spustit s nejakeho invokacniho
> frameworku, pricemz
> catch (RuntimeException re)
> nezpusobi, ze poslete do kytek i tento framework. Jde napriklad o
> spusteni ze servletu. System.exit() pak shodi i server.
>
>
> Zalezi tedy hodne na tom, jak moc casto bude dochatek k chybam. Ja
> osobne bych v tuto chvili preferoval intovy status kod metody
> setValue().
>
> Oto 'tapik' Buchta
>
|
|
From: <ta...@we...> - 2003-06-13 06:15:35
|
On Thu, Jun 12, 2003 at 06:16:27PM +0200, Kouba Tomas wrote:
> Zdravim,
>
> je skutecne nutne vzdy vyvolavat vyjimku? Mam zvlastni tridu, ktera osetruje
> chyby (DgsError) a jsou pripady, kdy mi na to staci. Krasny priklad je v
> ConfigMode.setValue().
Dve veci:
1) V pripade DgsError se vam podaril presny opak problemu, nez o kterem
jsme spolu nekolikrat diskutovali. DgsError je Helper, ktery jenom
zaridi zalogovani a skonci. Vzhleem k tomu, ze si NEDRZI ZADNY VNITRNI
STAV, je naprosto zbytecne, aby se pracovalo s instanci. Je totiz
opravdu jedno, jestli zavolate konstruktor nebo sttaicjkou metodu
saveMessage().
2) Ctyri hlavni design patterny pro osetreni chybovych styavu:
a) vyhodi se obycejna vyjimka
b) vyhodi se Error ci RuntimeException
c) vrati se status provedene akce
d) nevrati se nic a pouze se zaloguje
Bod d) je nejmene casty, protoze se v kodu, ktery volal onen
test, nejste schopen onu chybu nijak zpracovat. Tato vec se pouziva
pouze tehdy, jedna-li se o BlackBox a de facto na vysledku testu
nezavisi, co se bude dal dit.
V klasickem proceduralnim jazyce se pouziva bod c) a i ja jsem
zastancem tohoto postupu, nebot vyhazovani vyjimek je i pres velke
optimalizace zbytecne drahe (a drahe je take vytvareni try { } catch
bloku). Smysl ma tehdy, kdyz zjisteni chyby neni az tak vyjimecne, ale
spis 50-50 se spravnym pruchodem.
Bod a) je popisovan jako hlavni design-pattern. mel by se ale pouzivat
tehdy, kdyz selhani testu je skutecnou vyjimkou, nikoli uplne beznym
jevem. Jinak je dale nutny predpoklad, ze z teto vyjimky se aplikace
muze zotavit (uzivatel zadal slovo a ma tam byt cislo).
Bod b) ma smysl tehdy, kdyz se predpoklada, ze se z chyby nelze
zotavit.
Pouzivani System.exit() je nedoporucovano, protoze je zbytecne moc
agresivni. Stejnou sluzbu zastane
throw new RuntimeException("ERROR:(message)",exception);
a navic lze takovou aplikaci spustit s nejakeho invokacniho
frameworku, pricemz
catch (RuntimeException re)
nezpusobi, ze poslete do kytek i tento framework. Jde napriklad o
spusteni ze servletu. System.exit() pak shodi i server.
Zalezi tedy hodne na tom, jak moc casto bude dochatek k chybam. Ja
osobne bych v tuto chvili preferoval intovy status kod metody
setValue().
Oto 'tapik' Buchta
|
|
From: Kouba T. <to...@ne...> - 2003-06-12 16:13:59
|
Zdravim, je skutecne nutne vzdy vyvolavat vyjimku? Mam zvlastni tridu, ktera osetruje chyby (DgsError) a jsou pripady, kdy mi na to staci. Krasny priklad je v ConfigMode.setValue(). -- Kouba Tomas mailto:to...@ne... |
|
From: <ta...@we...> - 2003-06-12 11:16:46
|
On Thu, Jun 12, 2003 at 10:08:40AM +0200, Kouba Tomas wrote: > Zdravim, > > uz jsem to myslim vyresil. Podivejte se prosim na ConfigTest.java. > Ani nevite, jak mne tesi, ze Vas samotneho napadlo (aniz bych to musel explicitne uvadet jako jednu z moznosti) vyuzit dedicnosti. Toto reseni je myslim velmi pouzitelne, jeste by to chtelo pro vetsi genericnost zavest ConfigHelper, ktery by obsaoval trivialni casto pouzivane testy (isNumber(), isBoolean(), isNumberInInterval(), isFileName()...). No a pak by jiste mohlo byt zajimave primo konvertovat retezcove hodnoty do odpovidajicich typu (Integer, Boolean, Float) a ten pak ukladat do Mapy. No a jako uplne posledni enhancement by mohlo byt zajimave mit checkery, ktere budou testovat urcitou skupinu propert (napr. PIDfile), protoze jinak budete dost casto pouzivat Copy&Paste, coz vzdy ukazuje na nespravny zpusob navrhu kodu. Ale tento enhancement vcetne registrace checkeru by asi melo pockat, az jak se onen zpusob configurace osvedci. To je totiz velka vyhoda enkapsulace a rozhrani, nebot interni rewrite konfigurace vubec neovlivni zbytek sveta. Oto 'tapik' Buchta |
|
From: Kouba T. <to...@ne...> - 2003-06-12 08:06:11
|
Zdravim, uz jsem to myslim vyresil. Podivejte se prosim na ConfigTest.java. -- Kouba Tomas mailto:to...@ne... > -----Original Message----- > From: dia...@li... > [mailto:dia...@li...]On Behalf > Of ta...@we... > Sent: Wednesday, June 11, 2003 5:50 PM > To: dia...@li... > Subject: Re: [Dialogus-develop] Validace hodnot z konfiguracniho souboru > > > On Wed, Jun 11, 2003 at 11:43:00AM +0200, Kouba Tomas wrote: > > Zdravim, > > > > je obvykle validovat hodnoty z konfiguracnho souboru do ktereho by mel > > uzivatel systemu zapisovat manualne pouze vyjimecne? > Samozrejme, pokud se > > validovat nebude je mi jasne, ze muze dojit k nepredvidatelnym > chybam, ale > > nevim, zda je obvykle se tim zabyvat? > > Kamenem urazu je to "vyjimecne". Paklize by to nebylo mozne, vse je bez > problemu. Paklize ale umoznite, aby si to uzivatel editoval (a pokud to > chcete mit v textaku tak to urcite delat bude a verte ci ne, vzdyt vetsina > lidi v Open Source komunite radsi edituje textak nez pouziva klikatko) > > Napriklad dnes bylo pro mne velmi uzitecne, ze jsem mohl v emacsu porovnat > textovou konfiguraci dvou uctu v mem postakovi. > > Takze kdyz uz vime, ze JE NUTNE si drzet konfiguraci v textovych > souborech, je take nutne udelat parser konfigurace ROBUSTNI. > > Oto 'tapik' Buchta > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Dialogus-developers mailing list > Dia...@li... > https://lists.sourceforge.net/lists/listinfo/dialogus-developers > |
|
From: <ta...@we...> - 2003-06-11 15:34:19
|
On Wed, Jun 11, 2003 at 11:43:00AM +0200, Kouba Tomas wrote: > Zdravim, > > je obvykle validovat hodnoty z konfiguracnho souboru do ktereho by mel > uzivatel systemu zapisovat manualne pouze vyjimecne? Samozrejme, pokud se > validovat nebude je mi jasne, ze muze dojit k nepredvidatelnym chybam, ale > nevim, zda je obvykle se tim zabyvat? Kamenem urazu je to "vyjimecne". Paklize by to nebylo mozne, vse je bez problemu. Paklize ale umoznite, aby si to uzivatel editoval (a pokud to chcete mit v textaku tak to urcite delat bude a verte ci ne, vzdyt vetsina lidi v Open Source komunite radsi edituje textak nez pouziva klikatko) Napriklad dnes bylo pro mne velmi uzitecne, ze jsem mohl v emacsu porovnat textovou konfiguraci dvou uctu v mem postakovi. Takze kdyz uz vime, ze JE NUTNE si drzet konfiguraci v textovych souborech, je take nutne udelat parser konfigurace ROBUSTNI. Oto 'tapik' Buchta |
|
From: Kouba T. <to...@ne...> - 2003-06-11 09:40:33
|
Zdravim, je obvykle validovat hodnoty z konfiguracnho souboru do ktereho by mel uzivatel systemu zapisovat manualne pouze vyjimecne? Samozrejme, pokud se validovat nebude je mi jasne, ze muze dojit k nepredvidatelnym chybam, ale nevim, zda je obvykle se tim zabyvat? -- Kouba Tomas mailto:to...@ne... |
|
From: <ta...@we...> - 2003-06-10 20:25:38
|
On Tue, Jun 10, 2003 at 09:54:47AM +0200, Kouba Tomas wrote: > V aplikaci mam nekolik konfiguracnich souboru, kde kazdy konfiguracni > soubor prislusi nejakemu funkcnimu modulu. Cteni a ukladani > konfiguracnich hodnot z/do souboru mam vyreseno a neni predmetem tohoto > dotazu. Vlastni konfiguracni hodnoty jsou ulozeny Mapach (HashTable) - > kazdy konfiguracni soubor ma vlastni Mapu. Paklize tomu rozumim spravne, tak konfiguracni soubor jsou vlastne properties - mnozina dvojic [klic, hodnota] > Pri startu modulu potrebuji do kazde konfiguracni hodnoty v Mape ulozit > nejakou implicitni hodnotu, ktera je casto vypocitavana. Po nacteni > hodnoty z konfiguracniho souboru je vetsinou nutne provest validaci > hodnoty (zda nekdo do konfiguracniho souboru nenapsal nejakou kravinu) a > pokud validace probehne OK, ulozit ji do Mapy. Zde tim prepisi > implicitni hodnotu. Stejnou validaci provadet pri zmene hodnoty v Mape > jinym zpusobem nez nactenim z konfiguracniho souboru. Napriklad zadanim > uzivatele do formulare. Rekl bych, ze je potreba v prve rade rict, kde ma byt ona implicitni hodnota ulozena. Ja osobne vidim tri moznosti a kazda ma dost dobre opodstatneni: 1. jedna trida pro vsechny implicitni hodnoty. Je to pekne pohromade. Ma to ale zasadni problem - neni to vubec delano obecne a zrovna se mapa muze nahradit jendom obrovskym JavaBeanem 2. veskery kod pri ziskavani konfigurace ma svou vlastni defaultni hodnotu. Vyhneme se problemu centralizovanosti a onen holder mapy s konfiguraci je krasne univerzalni. Za otazku ovsem stoji, proc potom nepouzit primo java.util.Properties (ciste z duvodu defaultnich hodnot) 3. Defaultni hodnoty jsou v separatnim souboru. Je to pekne ciste reseni, v konstruktoru se soubor nacte a naplni se daty. Daji se delat figle jako treba ze pokud dato nema implicitni hodnotu, tak ji nejde nastavit atd. Paklize vime, kde jsou defaultni hodnoty, muzeme pristoupit k analyze problemu s validaci dat. Jsou v podstate zase tri moznosti: A) validace je na jednom miste a data nejsou typovana. Pak je vsechno natvrdo napsano v kodu a mame zase bod 1. B) validace je volana aplikacni logikou a neexistuje zadna globalni validace. Potom se konfigurace opet omezuje na java.util.Properties C) Mame univerzalni model, jak validovat data. Zavedeme si do konfigurace typy (cisla, retezce,...). Potom je jeste obohatime o rozsahy cisel, delky retezcu, formaty dat a nakonec se dostaneme ke XML schematu. Nevim, zda existuji nastroje, ktere umi vzit netextovou reprezentaci XML (napr. DOM) a rict o nem, ze odpovida danemu schematu. Kdyby takovy nastroj existoval, nevidim duvod v tomto bode psat neco vlastniho. No a nakonec samozrejme existuji "obskurni" reseni, ktere jsou takovymi kockopsi. Napriklad je mozne nad danou mapou nadefinovat Observery, kteri budou resit validaci vybranych dat. V konfiguraci je receno ktery observer ma zajistovat validitu kterych dat. Toto je tak zhruba na prvni pohled vse podstatne. Oto 'tapik' Buchta |
|
From: Kouba T. <to...@ne...> - 2003-06-10 07:52:29
|
Zdravim a preji pekny den, bohuzel nejsem v objektovem navrhu prilis kovany a proto si dovolim se na Vas obratit s dotazem, jak neco naprogramovat, respektive navrhnout. V aplikaci mam nekolik konfiguracnich souboru, kde kazdy konfiguracni soubor prislusi nejakemu funkcnimu modulu. Cteni a ukladani konfiguracnich hodnot z/do souboru mam vyreseno a neni predmetem tohoto dotazu. Vlastni konfiguracni hodnoty jsou ulozeny Mapach (HashTable) - kazdy konfiguracni soubor ma vlastni Mapu. Pri startu modulu potrebuji do kazde konfiguracni hodnoty v Mape ulozit nejakou implicitni hodnotu, ktera je casto vypocitavana. Po nacteni hodnoty z konfiguracniho souboru je vetsinou nutne provest validaci hodnoty (zda nekdo do konfiguracniho souboru nenapsal nejakou kravinu) a pokud validace probehne OK, ulozit ji do Mapy. Zde tim prepisi implicitni hodnotu. Stejnou validaci provadet pri zmene hodnoty v Mape jinym zpusobem nez nactenim z konfiguracniho souboru. Napriklad zadanim uzivatele do formulare. Priznavam, ze v tom nejak plavu a stale nevim ze ktere strany do toho kousnout. Predem dekuji za pomoc. -- Kouba Tomas mailto:to...@ne... |
|
From: Kouba T. <to...@ne...> - 2003-05-06 14:10:37
|
Zdravim a preji pekny den,
tak jsem nad tim zase hodne premyslel a dospel k nazoru, ze mate pravdu.
Urcite tento zpusob pouziji pro Logger a requesty. Priznavam, ze trochu
plavu v tom, jak zaridit bezproblemovy chod v pripade vicevlaknoveho
pristupu, ale az se k tomu dostanu, tak to snad vyresim.
Jako druhy globalni prvek mam konfiguracni promene. Jde o ruzne typy a druhy
promennych, ktere se casto v programu pouzivaji a meni. Behem chodu programu
jsou ulozeny v HashMap a pri startu jsou nacitana z XML souboru pomoci SAX
parseru. Jejich struktura je jednoducha. Myslim, ze ty by mely byt dostupne
pomoci statickych metod.
Mejte se fajn...
--
Kouba Tomas
mailto:to...@ne...
>
> Kouba Tomas wrote:
> > Mohl bych poprosit o strucny priklad. Dekuji...
> >
>
> Uvedu tedy priklad:
>
> public class Context {
>
> private static final String NO_REQUEST="zadny request nebyl
> nastaven";
>
> //v kazdem threadu je jina hodnota
> private static ThreadLocal requests = new ThreadLocal() {
> protected Object initialValue() {
> return NO_REQUEST;
> }
> };
>
> public static Logger getLog() {
> Logger.getInstance();
> }
>
> public static HttpRequest getRequest() {
> if (requests.get().equals(NO_REQUEST)
> throw new RuntimeException(NO_REQUEST);
> (Request) requests.get();
> }
>
> //seter pro request
> static void setRequest(HttpRequest request) {
> requests.put(request);
> }
>
> public static User getUserId() {
> getRequest().getSession().get("user",new EmptyUser());
> }
> }
>
> No a pouziti je trivialni -
>
> Logger log = Context.getLog();
> Request request = Context.getRequest();
> ...
> Proste vsechno pouziva klasicky Bean pattern, tedy getX a setX metody,
> pricmez setX metody jsou chraneny, a to jak ruznymi testy, tak nativnimi
> bezpecnostnimi pravidly.
>
> Je to o tom, ze vsechno je zabaleno do jednoho objektu.
> Je samozrejme mozne, tak jako jsme to delali my v Dialogusu,
> predavat onen kontext ve volani metod, ale po dukladnych analyzach
> delanych loni lidmi z IBM byl navrzen prave tento staticky pristup.
>
>
> --
> Oto 'tapik' Buchta, ta...@sy...
> R&D team, Systinet Corp. (formerly Idoox)
> http://www.systinet.com
>
>
|
|
From: Kouba T. <to...@ne...> - 2003-04-29 10:31:20
|
Zdravim a preji pekny den, asi vubec netusite, jak strasne tezke je pro mne nad tim takto premyslet. :-) Musim nad tim dale premyslet. Me pripada, ze oproti klasicke staticke metode tady vzdy pri volani Context vznika zbytecne jeden objekt, ktery by pri pouziti staticke metody (s pripadnymi synchronizacnimi bloky) nevznikl. -- Kouba Tomas mailto:to...@ne... > > > > 1. V cem je to lepsi naz klasicka staticka metoda, kterou mohu volat > > odkudkoliv bez instance? > > > V cem je lepsi singleton nez klasicka staticka metoda bez instance > jsem popisoval v design patternu pro Singleton - moznost nestaticke > konfigurace, > coz se oceni obzvlaste pro ladeni, pri vice instancich atd. > > Na takoveto veci je velmi vhodny Context pattern. Kazda trida si pomoci staticke metody Context.initialContext() (viz JNDI, nebo this.getContext(), jak je napriklad pouzito v JSDK) vytahne aktualni kontext, ve kterem jsou patricne objekty nainstanciovany a nakonfigurovany. Neni nutne se tedy starat o to, kde je tento objekt vytvoren, kdo jej vytvoril a kolik jich v aplikaci je. getContext() muze tahat kontext s databaze, mit ho ThreadLocal nebo muze mit statickou implementaci. To je celkem jedno. Context ma pak public metodu getLogger() (!nestatickou!) Jinou moznosti je primo implementovat staticke metody tridy Context, jako napriklad Context.getLogger(). Rozhodnuti je na zvazeni kazdeho implementatora. Ja osobne mam radeji Context s jedinou statickou metodou. |
|
From: Kouba T. <to...@ne...> - 2003-04-28 12:00:52
|
Zdravim a preji pekny den,
diky za odpoved. Mam k tomu jeste dva vicemene dotazy:
1. V cem je to lepsi naz klasicka staticka metoda, kterou mohu volat
odkudkoliv bez instance?
2. V cem je to lepsi nez normalni instance Loggeru?
Pokud jsou me dotazy stupidni, omlouvam se. Mejte se fajn.
P.S. zadna FA neprisla.
--
Kouba Tomas
mailto:to...@ne...
> Kouba Tomas wrote:
> > Mohl bych poprosit o strucny priklad. Dekuji...
> >
>
> Uvedu tedy priklad:
>
> public class Context {
>
> private static final String NO_REQUEST="zadny request nebyl
> nastaven";
>
> //v kazdem threadu je jina hodnota
> private static ThreadLocal requests = new ThreadLocal() {
> protected Object initialValue() {
> return NO_REQUEST;
> }
> };
>
> public static Logger getLog() {
> Logger.getInstance();
> }
>
> public static HttpRequest getRequest() {
> if (requests.get().equals(NO_REQUEST)
> throw new RuntimeException(NO_REQUEST);
> (Request) requests.get();
> }
>
> //seter pro request
> static void setRequest(HttpRequest request) {
> requests.put(request);
> }
>
> public static User getUserId() {
> getRequest().getSession().get("user",new EmptyUser());
> }
> }
>
> No a pouziti je trivialni -
>
> Logger log = Context.getLog();
> Request request = Context.getRequest();
> ...
> Proste vsechno pouziva klasicky Bean pattern, tedy getX a setX metody,
> pricmez setX metody jsou chraneny, a to jak ruznymi testy, tak nativnimi
> bezpecnostnimi pravidly.
>
> Je to o tom, ze vsechno je zabaleno do jednoho objektu.
> Je samozrejme mozne, tak jako jsme to delali my v Dialogusu,
> predavat onen kontext ve volani metod, ale po dukladnych analyzach
> delanych loni lidmi z IBM byl navrzen prave tento staticky pristup.
>
>
> --
> Oto 'tapik' Buchta, ta...@sy...
> R&D team, Systinet Corp. (formerly Idoox)
> http://www.systinet.com
>
>
|
|
From: Kouba T. <to...@ne...> - 2003-04-25 16:55:37
|
Mohl bych poprosit o strucny priklad. Dekuji... -- Kouba Tomas mailto:to...@ne... > > > > celou aplikaci se mi tahne nekolik objektu, napriklad logger > (pro neznale > > zapisuje do log souboru). Vzhledem k tomu, ze bude pouzivany ve > spouste trid > > (zapisuje log zaznamy), myslim, ze je nejlepsi ho udelat jako public > > staticky objekt a potom ho lze bez problemu pouzit v cele > aplikaci. Sice se > > snazim udelat aplikaci modularni s tim, ze kazdy modul ma > vlastni rozhrani > > pomoci ktereho se styka s ostatnimi moduly, ale tohle se mi jevi jako > > nejlepsi. > > > > Ted jsem prisel na to, ze bych se mohl rozhodnout, aby pri > zapisu do logu od > > urcite urovne (napr. warning) byl odeslan email na adresu > administratora. Je > > to zajimava, vypinatelna features a tak jsem premyslel jak na > to. Asi bude > > nejlepsi misto statickeho objektu odelat statickou metodu a v > ni se to da > > snadno rozsirovat o dalsi features. > > Na takoveto veci je velmi vhodny Context pattern. > > Kazda trida si pomoci staticke metody Context.initialContext() (viz > JNDI, nebo this.getContext(), jak je napriklad pouzito v JSDK) vytahne > aktualni kontext, ve kterem jsou patricne objekty nainstanciovany a > nakonfigurovany. Neni nutne se tedy starat o to, kde je tento objekt > vytvoren, kdo jej vytvoril a kolik jich v aplikaci je. > > getContext() muze tahat kontext s databaze, mit ho ThreadLocal nebo muze > mit statickou implementaci. To je celkem jedno. > Context ma pak public metodu getLogger() (!nestatickou!) > > Jinou moznosti je primo implementovat staticke metody tridy Context, > jako napriklad Context.getLogger(). > > Rozhodnuti je na zvazeni kazdeho implementatora. Ja osobne mam radeji > Context s jedinou statickou metodou. > -- > Oto 'tapik' Buchta, ta...@sy... > R&D team, Systinet Corp. (formerly Idoox) > http://www.systinet.com > > |
|
From: Kouba T. <to...@ne...> - 2003-04-09 14:43:50
|
Zdravím a přeji pěkný den, Je možné nějak zapisovat přímo kořenového parenta? Něco jako RootLogger.log(Level.WARNIG,"zapis do logu"); Musím zapisovat do logu a ještě nevím do jakého souboru, tak bych zatím zapisoval do tohoto super-rodiče. -- Kouba Tomas mailto:to...@ne... > -----Original Message----- > From: Oto tapik Buchta [mailto:ta...@sy...] > Sent: Wednesday, April 02, 2003 9:02 AM > To: Kouba Tomas > Subject: Re: Jeste jednou logging > > > Kouba Tomas wrote: > > Zdravim a preji pekny den, > > > > 1. jeste mi od Vas neprislo potvrzeni an ten zitrek na 13:00 na > zastavce 234 > > > > 2. Uz dva dny nemohu prijit na to, proc prilozeny kod zapisuje > i na STDERR a > > ne pouze do logovaciho souboru a jak tomu zabranit, aby zapisoval na > > STDERR -> chci pouze do souboru. > > > > Takze se mi podarilo zvitezit na loggingem! ;-) > > Kazdy logger ma sveho parenta. Korenovym parentem vsech loggeru je > RootLogger (private class LogManagera), ktery ma jediny Handler - > ConsoleHandler. Tomtuto Handleru je treba vnutit spravny level pro > logovani. V kodu to pak vypada takto: > > logger.getParent().getHandlers()[0].setLevel(Level.OFF); > > S pozdravem, > > -- > Oto 'tapik' Buchta, ta...@sy... > R&D team, Systinet Corp. (formerly Idoox) > http://www.systinet.com > > |
|
From: Kouba T. <to...@ne...> - 2003-04-08 16:04:12
|
Zdravim a preji pekny den, aktualne studuji http://www.dom4j.org/ Jsem z toho trochu zmaten. Xerces mi pripada sity prilis univerzalne (nejen pro javu) a JDOM je porad beta. Take studuji vsechny moznosti XML, abych byl schopen efektivne navrhnout optimalni strukturu konfiguracnich souboru. Je v tom zmatek a myslim, ze aktualne idealni reseni pro XML neexistuje. -- Kouba Tomas mailto:to...@ne... > > On Thu, Apr 03, 2003 at 02:35:08PM +0200, Kouba Tomas wrote: > > Zfravim a preji pekny den, > > > > tak jsem studoval jak pristupovat k XML souborum a dospel jsem > k nazoru, ze > > nejvhodnejsi asi bude pomoci http://www.jdom.org. Myslim, ze > pro Javu je to > > to nejlepsi co je aktualne k dispozici. Je to sice beta a ceka se na > > schvaleni, ale pouziva se. > > > > Pise o tom napr. Makub: http://www.ics.muni.cz/~makub/xml > > jDOM je velmi schopny, ma vsak jeden problem. > V tuto chvili nikdo nevi, jak to s nim bude v budoucnu. > DOM je ustaleny standard org.w3c.dom a napriklad Xerces > ho dela velmi hezky. > > Na DOM existuje take spousta helper knihoven, coz se o jDOMu > rict neda. > > Presto je rozhodnuti na Vas. > > S pozdravem, > > Oto 'tapik' Buchta > |
|
From: Kouba T. <to...@ne...> - 2003-04-04 08:11:06
|
Zdravim a preji hezky den, hodim dotaz do plena a treba se neco noveho pekneho dovime... -- Kouba Tomas mailto:to...@ne... > jDOM je velmi schopny, ma vsak jeden problem. > V tuto chvili nikdo nevi, jak to s nim bude v budoucnu. > DOM je ustaleny standard org.w3c.dom a napriklad Xerces > ho dela velmi hezky. > > Na DOM existuje take spousta helper knihoven, coz se o jDOMu > rict neda. > > Presto je rozhodnuti na Vas. > |
|
From: <ta...@we...> - 2003-04-03 16:11:03
|
On Thu, Apr 03, 2003 at 02:35:08PM +0200, Kouba Tomas wrote: > Zfravim a preji pekny den, > > tak jsem studoval jak pristupovat k XML souborum a dospel jsem k nazoru, ze > nejvhodnejsi asi bude pomoci http://www.jdom.org. Myslim, ze pro Javu je to > to nejlepsi co je aktualne k dispozici. Je to sice beta a ceka se na > schvaleni, ale pouziva se. > > Pise o tom napr. Makub: http://www.ics.muni.cz/~makub/xml jDOM je velmi schopny, ma vsak jeden problem. V tuto chvili nikdo nevi, jak to s nim bude v budoucnu. DOM je ustaleny standard org.w3c.dom a napriklad Xerces ho dela velmi hezky. Na DOM existuje take spousta helper knihoven, coz se o jDOMu rict neda. Presto je rozhodnuti na Vas. S pozdravem, Oto 'tapik' Buchta |
|
From: Kouba T. <to...@ne...> - 2003-04-03 12:35:21
|
Zfravim a preji pekny den, tak jsem studoval jak pristupovat k XML souborum a dospel jsem k nazoru, ze nejvhodnejsi asi bude pomoci http://www.jdom.org. Myslim, ze pro Javu je to to nejlepsi co je aktualne k dispozici. Je to sice beta a ceka se na schvaleni, ale pouziva se. Pise o tom napr. Makub: http://www.ics.muni.cz/~makub/xml -- Kouba Tomas mailto:to...@ne... |
|
From: <ta...@we...> - 2003-03-28 07:02:58
|
On Thu, Mar 27, 2003 at 06:12:24PM +0100, Kouba Tomas wrote: > Potrebuji si to osahat a chci zacit s necim co lze snadno zmenit, proto > inicializace a konfigurace. Pak Vas pozadam, aby jste se na to podival a > budem pokracovat. Zatim psat zasadni tridy, ktere ovlivni chod neni spravna > chvile. Souhlas. Oto 'tapik' Buchta |
|
From: Kouba T. <to...@ne...> - 2003-03-27 17:12:38
|
Potrebuji si to osahat a chci zacit s necim co lze snadno zmenit, proto inicializace a konfigurace. Pak Vas pozadam, aby jste se na to podival a budem pokracovat. Zatim psat zasadni tridy, ktere ovlivni chod neni spravna chvile. -- Kouba Tomas mailto:to...@ne... > > > > trochu jste me vydesil. Tak jsem se rozhodl, ze zacnu programovat uvodni > > casti (inicializace, nacteni konfigurace apod.) a potom, po trochu > > zkusenostech, zacnu premyslet nad tentito zasadnimi tridami. > > > > Tak to jsem v zadnem pripade nemel na mysli. Spis jsem si myslel, > ze nebude problem podle toho, co jsem napsal, zacit kodovat. > |
|
From: <ta...@we...> - 2003-03-27 16:35:14
|
On Thu, Mar 27, 2003 at 04:20:35PM +0100, Kouba Tomas wrote: > Zdravim a preji pekny den, > > trochu jste me vydesil. Tak jsem se rozhodl, ze zacnu programovat uvodni > casti (inicializace, nacteni konfigurace apod.) a potom, po trochu > zkusenostech, zacnu premyslet nad tentito zasadnimi tridami. > Tak to jsem v zadnem pripade nemel na mysli. Spis jsem si myslel, ze nebude problem podle toho, co jsem napsal, zacit kodovat. Pokud Vam to pripada tak narocne, asi by stalo za to se treba o vikendu sejit a popovidat si o tom. Jinak pokud teda opravdu chcete zacit programovat, tak zacit s konfiguraci mi pripada jako dobry napad. Ale udelejte si pred tim drobnou delostreleckou pripravu, ktera bude obsahovat zamysleni se nad tim, jak se bude konfigurace pouzivat, jak se bude delat runtimova rekonfigurace. Minimalne na osahani prace s XMLckem. Je velmi vhodne zacit s navrhem tridy, ktera bude konfiguraci enkapsulovat. Minimalne proto, ze je zbytecne na dvaceti mistech kodovat otevirani a parsovani XML. Oto 'tapik' Buchta |
