Menu
▾
▴
[Digi-developer] Re: Digi-developer digest, Vol 1 #10 - 2 msgs
|
From: <vam...@wo...> - 2003-12-09 04:16:00
|
Irakli, look at in whoat format I receive messages from the digi-developer list below. And it is not me only. At lest Ranjith gets them like that also. please do something with it. I was receiving them in a normal way in the beginning. Something changed in the configuration of the list I am sure. Also, lack of the archive makes difficult to track responses. I am sure you have not replied to a few of my questions, about inheritance and security documentation as at minimum. Vahan Amirbekyan The World Bank 1850 I Street, NW, Washington, DC 20433 Tel: 202 / 473-3114 (office) vam...@wo... VISIT: www.developmentgateway.org Sign up for our free monthly e-mail newsletter: gat...@de... dig...@li... Sent by: dig...@li... 12/08/2003 11:03 PM Please respond to digi-developer To: dig...@li... cc: Subject: Digi-developer digest, Vol 1 #10 - 2 msgs Send Digi-developer mailing list submissions to dig...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/digi-developer or, via email, send a message with subject or body 'help' to dig...@li... You can reach the person managing the list at dig...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Digi-developer digest..." Today's Topics: 1. List of childs for a site (Andrei Sereda) 2. Second thoughts about internationalized logging. (ina...@wo...) --__--__-- Message: 1 Date: Mon, 8 Dec 2003 21:55:23 +0100 From: Andrei Sereda <as...@so...> Reply-To: Andrei Sereda <as...@so...> To: "dig...@li..." <dig...@li...> Subject: [Digi-developer] List of childs for a site Hi Arvind, please take a look at package org.digijava.module.admin.util; getChildSites() method. I think this will return only first level children. In case if you want to retrieve all children (for instance grand children) the class org.digijava.module.gmdpbenchmark.worker.IndicatorGroupWorker with methods getChildren() might be of particular interest for you since, it uses the same hierarchical logic like in Site class. Hope it helps, Andrei. ddrlsn> Message: 2 ddrlsn> Date: Mon, 8 Dec 2003 14:22:48 +0530 ddrlsn> From: "Arvind Kumar S" <arv...@mp...> ddrlsn> To: <dig...@li...> ddrlsn> Subject: [Digi-developer] Is there an API to get a List of child Sites for a given Site ddrlsn> ddrlsn> This is for the kernel team. In dgtopics we need to display a List of = ddrlsn> Sites to which items can be contributed to. All these Sites would be = ddrlsn> children of the main dgTopics site. I can get the root of any given = ddrlsn> site. But I dont find an API to get all children for a given site. ddrlsn> ddrlsn> Regards, ddrlsn> Arvind Kumar --__--__-- Message: 2 To: dig...@li... From: ina...@wo... Date: Mon, 8 Dec 2003 22:22:45 -0500 Subject: [Digi-developer] Second thoughts about internationalized logging. This is a multipart message in MIME format. --=_alternative 00125F5385256DF7_= Content-Type: text/plain; charset="US-ASCII" As you remember, in the beginning of the project we decided to internationalize our log messages. It seemed a good thing to do, back then, as we are aiming on a wide international audience. However, looking at the experience, I am inclined to think that we really overdid here and made our code much harder to write, less readable. Internationalized log messaging code is, arguably, way too clumsy and long. Compare two approaches for a simple log: 1) Using i18N: //-- initialize logger, once per class: private static Logger logger = I18NHelper.getKernelLogger(RequestProcessor.class); //-- Put the message in the appropriate resource.porperties file: RequestProcessor.actionFormName=Action form name is {0} //-- Code for each log in the source: if (logger.isDebugEnabled()) { logger.l7dlog(Level.DEBUG, "RequestProcessor.actionFormName", new Object[] {newMapping.getAttribute()}, null); } 2) Using simple logging: //-- initialize logger, once per class: private static Logger log = Logger.getLogger(RequestProcessor.class); //-- Code for each log in the source: log.debug( "Action form name is " + newMapping.getAttribute()); ---------------------------------------------------------------------------------------------------- The second approach is, obviously, simpler, faster and code is much more readable. Do we loose much by not internationalizing logs? Not really. There are open-source projects with far wider outreach and audience than Digi can realistically get in the nearest future (e.g. Hibernate) that do not internationalize their logs. We have our javadocs only in English, our mailing list is in English - pretty much all the resources and documentation are in English, so spending so much effort on internationalizing just logs - does not really seem reasonable, and I am beginning to think we are really doing an overkill here, which is worse - making our code far less readable and that is way worse than having logs only in English. I propose we begin using simple approach to logging with neat and clear log.debug(), log.info(), log.error(), log.fatal() etc. methods. It does not mean anybody needs to spend precious time, now, and change the existing code - switch to the simpler logging, but I think we can use the alternative approach for the future development. thank you Irakli --=_alternative 00125F5385256DF7_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">As you remember, in the beginning of the project we decided to internationalize our</font> <br><font size=2 face="sans-serif">log messages. It seemed a good thing to do, back then, as we are aiming on a wide</font> <br><font size=2 face="sans-serif">international audience.</font> <br> <br><font size=2 face="sans-serif">However, looking at the experience, I am inclined to think that we really overdid here</font> <br><font size=2 face="sans-serif">and made our code much harder to write, less readable. Internationalized log messaging</font> <br><font size=2 face="sans-serif">code is, arguably, way too clumsy and long.</font> <br> <br><font size=2 face="sans-serif">Compare two approaches for a simple log:</font> <br><font size=2 face="sans-serif"><b>1) Using i18N:</b></font> <br> <br><font size=2 face="sans-serif">//-- initialize logger, once per class:</font> <br><font size=2 face="sans-serif">private static Logger logger = I18NHelper.getKernelLogger(RequestProcessor.class);</font> <br> <br><font size=2 face="sans-serif">//-- Put the message in the appropriate resource.porperties file:</font> <br><font size=2 face="sans-serif">RequestProcessor.actionFormName=Action form name is {0}</font> <br> <br><font size=2 face="sans-serif">//-- Code for each log in the source:</font> <br><font size=2 face="sans-serif">if (logger.isDebugEnabled()) {</font> <br><font size=2 face="sans-serif"> logger.l7dlog(Level.DEBUG, "RequestProcessor.actionFormName", new Object[] {newMapping.getAttribute()}, null);</font> <br><font size=2 face="sans-serif">}</font> <br> <br> <br><font size=2 face="sans-serif"><b>2) Using simple logging:</b></font> <br> <br><font size=2 face="sans-serif">//-- initialize logger, once per class:</font> <br><font size=2 face="sans-serif">private static Logger log = Logger.getLogger(RequestProcessor.class);</font> <br> <br><font size=2 face="sans-serif">//-- Code for each log in the source:</font> <br><font size=2 face="sans-serif">log.debug( "Action form name is " + newMapping.getAttribute());</font> <br> <br> <br><font size=2 face="sans-serif">----------------------------------------------------------------------------------------------------</font> <br> <br> <br><font size=2 face="sans-serif">The second approach is, obviously, simpler, faster and code is much more readable.</font> <br><font size=2 face="sans-serif">Do we loose much by not internationalizing logs? Not really. There are open-source projects</font> <br><font size=2 face="sans-serif">with far wider outreach and audience than Digi can realistically get in the nearest future</font> <br><font size=2 face="sans-serif">(e.g. Hibernate) that do not internationalize their logs.</font> <br> <br><font size=2 face="sans-serif">We have our javadocs only in English, our mailing list is in English - pretty much all</font> <br><font size=2 face="sans-serif">the resources and documentation are in English, so spending so much effort on</font> <br><font size=2 face="sans-serif">internationalizing just logs - does not really seem reasonable, and I am beginning</font> <br><font size=2 face="sans-serif">to think we are really doing an overkill here, which is worse - making our code far less</font> <br><font size=2 face="sans-serif">readable and that is way worse than having logs only in English.</font> <br> <br><font size=2 face="sans-serif">I propose we begin using simple approach to logging with neat and clear</font> <br><font size=2 face="sans-serif">log.debug(), log.info(), log.error(), log.fatal() etc. methods.</font> <br> <br><font size=2 face="sans-serif">It does not mean anybody needs to spend precious time, now, and change the existing </font> <br><font size=2 face="sans-serif">code - switch to the simpler logging, but I think we can use the alternative approach for </font> <br><font size=2 face="sans-serif">the future development.</font> <br> <br><font size=2 face="sans-serif">thank you</font> <br> <br><font size=2 face="sans-serif">Irakli </font> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br> --=_alternative 00125F5385256DF7_=-- --__--__-- _______________________________________________ Digi-developer mailing list Dig...@li... https://lists.sourceforge.net/lists/listinfo/digi-developer End of Digi-developer Digest |
