Menu
▾
▴
digi-developer — DiGi Developer Mailing List
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(37) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
(2) |
|
From: Chris G. N. <cg...@gl...> - 2004-12-11 19:39:17
|
My point of reference for this class of problem is: http://www.gridlab.org/WorkPackages/wp-4/ Chris Nicholas -----Original Message----- From: Chris G. Nicholas Sent: Sat 12/11/2004 10:19 AM To: dig...@li... Cc:=09 Subject: [Digi-developer] greetings - JSR168 compatibility strategy? Greetings -=20 A numer of folks are working on architecture for agricultural and = environmental decision support portal, outlined at: = http://iserver1.ciat.cgiar.org/mms/CGIAR_prop.html . We are working with = the folks of http://www.earthsystemgrid.org for the 'heavy lifting' = computationally, and folks like: http://www.fews.net and = http://www.pecad.fas.usda.gov/cropexplorer/ for foundation data feeds. Our initial thoughts were to build out on either the eXo platform, = http://www.exoplatform.org, or follow along with the new JBoss portal = effort. But clearly working with you guys has a lot of advantages, in = that you have thought through the JAAS and multisite/multilingual = aspects a lot more than anyone else. Is there any strategy for writing digi TILE applications in such a way = that they might also be JSR 168 compliant, and/or that the TILE engine = might some day also support portlets? Or are these two concepts = unreconcilable? thanks -=20 Chris Nicholas GlobeXplorer ------------------------------------------------------------------------ From: Aku...@wo... [Aku...@wo...] =20 Sent: Fri 9/3/2004 7:29 PM To: Chris G. Nicholas Cc: Jme...@wo...; rk...@wo...; = Mbr...@wo...; gdi...@wo...; Is...@wo...; = Vma...@wo...; Jm...@wo...; Rc...@wo...; = Ak...@wo...; Vts...@wo...; Lha...@wo...; = Donald Deering; Garik Gutman; Sergey Bartalev Subject: Forest and Agri. Monitoring=20 =20 Chris: Many thanks for your email that touches upon a subject of great and = increasing interest to us. I am currently traveling and cannot quickly access the = websites that you mentioned, but even so, I can assure you that the = issues of strengthening capacity for decentralized and independent monitoring of environmental and natural resources management is a significant priority = area for many of our projects in this area. Since I am traveling, I would recommend that - while you are in = Washington next week - you try to set up an appointment with my = colleague Robert Kirmse (202-458-8509, rk...@wo...), who has a good professional = knowledge and understanding of forest inventory and monitoring systems. I would also be interested personally in learning more about your = activities and proposals in this area, so I would appreciate you keeping = me in the loop. Best regards, Andrey ~~~~~~~~~~~~~~~~ Andrey V. Kushlin, Ph.D. Senior Forestry Specialist, ECSSD The World Bank, Mail Stop H-5-503 1818 H St., NW, Washington, DC 20433, USA Tel.: (+1-202) 458-7268; Fax: (+1-202) 614-0005 Email: AKu...@wo... http://www.worldbank.org/forestry =20 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.=20 http://productguide.itmanagersjournal.com/ _______________________________________________ Digi-developer mailing list Dig...@li... https://lists.sourceforge.net/lists/listinfo/digi-developer |
|
From: Chris G. N. <cg...@gl...> - 2004-12-11 18:20:01
|
Greetings -=20 A numer of folks are working on architecture for agricultural and = environmental decision support portal, outlined at: = http://iserver1.ciat.cgiar.org/mms/CGIAR_prop.html . We are working with = the folks of http://www.earthsystemgrid.org for the 'heavy lifting' = computationally, and folks like: http://www.fews.net and = http://www.pecad.fas.usda.gov/cropexplorer/ for foundation data feeds. Our initial thoughts were to build out on either the eXo platform, = http://www.exoplatform.org, or follow along with the new JBoss portal = effort. But clearly working with you guys has a lot of advantages, in = that you have thought through the JAAS and multisite/multilingual = aspects a lot more than anyone else. Is there any strategy for writing digi TILE applications in such a way = that they might also be JSR 168 compliant, and/or that the TILE engine = might some day also support portlets? Or are these two concepts = unreconcilable? thanks -=20 Chris Nicholas GlobeXplorer ------------------------------------------------------------------------ From: Aku...@wo... [Aku...@wo...] =20 Sent: Fri 9/3/2004 7:29 PM To: Chris G. Nicholas Cc: Jme...@wo...; rk...@wo...; = Mbr...@wo...; gdi...@wo...; Is...@wo...; = Vma...@wo...; Jm...@wo...; Rc...@wo...; = Ak...@wo...; Vts...@wo...; Lha...@wo...; = Donald Deering; Garik Gutman; Sergey Bartalev Subject: Forest and Agri. Monitoring=20 =20 Chris: Many thanks for your email that touches upon a subject of great and = increasing interest to us. I am currently traveling and cannot quickly access the = websites that you mentioned, but even so, I can assure you that the = issues of strengthening capacity for decentralized and independent monitoring of environmental and natural resources management is a significant priority = area for many of our projects in this area. Since I am traveling, I would recommend that - while you are in = Washington next week - you try to set up an appointment with my = colleague Robert Kirmse (202-458-8509, rk...@wo...), who has a good professional = knowledge and understanding of forest inventory and monitoring systems. I would also be interested personally in learning more about your = activities and proposals in this area, so I would appreciate you keeping = me in the loop. Best regards, Andrey ~~~~~~~~~~~~~~~~ Andrey V. Kushlin, Ph.D. Senior Forestry Specialist, ECSSD The World Bank, Mail Stop H-5-503 1818 H St., NW, Washington, DC 20433, USA Tel.: (+1-202) 458-7268; Fax: (+1-202) 614-0005 Email: AKu...@wo... http://www.worldbank.org/forestry =20 |
|
From: Mikheil K. <mi...@po...> - 2004-09-17 09:18:19
|
Hello Ameel, To get DiGi source code, please follow steps described in the document: http://jira.digijava.org:9023/confluence/display/DRD/2.+Getting+Source+Co= de To get username/password for CVS server please contact to Denisa Popescu = (dpopescu at worldbank dot org) Thank you, Mikheil ----- Original Message -----=20 From: Ameel Zia Khan=20 To: dig...@li...=20 Sent: Thursday, September 16, 2004 9:54 PM Subject: [Digi-developer] Location of DiGi Source Code Hello, I've just joined the Pakistan Country Gateway Network team and need to = start working on DiGi as soon as possible. I've searched the = documentation (digi-java.org, sourceforge.net, etc.) and downloaded the = source code from the CVS repository on SourceForge.net but only found = digi-commons.jar and winLN.exe there. How do I download the rest of the = source code? Do I need to sign on as a developer, get an account on = SourceForge.net, or apply somewhere for a login/password? Or am I = missing something completely? :) Please help quickly! Thanks! - Ameel P.S. Should I have posted this one the digi-cgnet mailing list, = instead? If so, I apologize. -- Ameel Zia Khan cmd...@ya... Some days you are the bug, some days you are the windshield. |
|
From: Ameel Z. K. <cmd...@ya...> - 2004-09-16 17:55:02
|
Hello, I've just joined the Pakistan Country Gateway Network team and need to = start working on DiGi as soon as possible. I've searched the = documentation (digi-java.org, sourceforge.net, etc.) and downloaded the = source code from the CVS repository on SourceForge.net but only found = digi-commons.jar and winLN.exe there. How do I download the rest of the = source code? Do I need to sign on as a developer, get an account on = SourceForge.net, or apply somewhere for a login/password? Or am I = missing something completely? :) Please help quickly! Thanks! - Ameel P.S. Should I have posted this one the digi-cgnet mailing list, instead? = If so, I apologize. -- Ameel Zia Khan cmd...@ya... Some days you are the bug, some days you are the windshield. |
|
From: Mauro A. M. M. <mmo...@re...> - 2004-08-30 16:46:51
|
What is username to download source of digi ?. I want to probe an testing this software, but i can't download. For your responses, thanks. Best regards, --=20 Mauro A. Morales M. mailto:mmo...@re... Corporacion Reuna http://www.reuna.cl |
|
From: <ben...@id...> - 2004-05-22 12:06:06
|
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: Andrei S. <as...@so...> - 2003-12-28 02:49:03
|
Gentlemen,
I wonder if there is any way to change the module instance directly in Action
class?
Let me give you an example:
suppose we have many radio boxes with module instances (declared for
one site) on a page. By clicking on submit button I'd like the
RequestProcessor to enable the respective instance.
One solution would be changing the form action with JavaScript, but I
don't really like this approach.
Another would be HTTP redirection in the Action class something like :
return new ActionForward("/gmdp/instance/page.do?"+params,true); but
this might be problematic when using POST.
I've tried using the above method with false (internal redirection)
but without success.
Also something like :
ComponentContext context = ComponentContext.getContext(request);
if (context == null) {
request.setAttribute(Constants.MODULE_INSTANCE,
moduleInstance);
}
else {
context.putAttribute(Constants.MODULE_INSTANCE,
moduleInstance);
wasn't lucky for me.
Any ideas?
Thanx,
Andrei.
P.S. Marry Christmas to everybody.
|
|
From: Andrei S. <as...@so...> - 2003-12-28 02:11:56
|
Guys,
Has anybody tried to make a link from one instance (let's say "foo")
of module to another ("bar") using <digi:link> tag.
Or making link from one module (let's say "news") to another (let's
say "faq").
Any help appreciated.
Thanx,
Andrei,
|
|
From: Shamanth M. <sha...@mp...> - 2003-12-23 12:57:27
|
Is it possible to make um module redirect to a custom URL on successful = login? It seems like a rfr parameter is being used to carry the url(to be = redirected to) once I click on submit button of login teaser. This is = being currently setup in the FormTag.java This parameter is always set to the URL where the login teaser is = displayed. I tried having a hidden field named rfr in the logon teaser jsp with the = custom URL as its value. This doesn't seem to work. Is there any other = way of doing this? Thanks Shamanth Murthy Systems Engineer =09 MphasiS BFL India=20 Bangalore=20 Ph: 5522714 Ext 2389=20 Mobile: 9844224551 |
|
From: <ina...@wo...> - 2003-12-21 12:55:56
|
The country information is already normalized and contained in the
DG_COUNTRIES
table. Which means - none of the modules should be using it directly, but
all of them
through a foreign key referring to DG_COUNTRIES. This means that if
there's really
a need to change ISO code - it will only be changed in one place, hence
there's no
problem.
Very important point here is what J2SE is using as part of its
internationalization framework
as the main architectural point for us is to use standard Java I18N.
Creating an ad-hoc imple-
mentation for this would be a great architectural mistake.
Actually, there's already a misusage in Digi, which came from copying
approaches taken
in ACS-TCL and because of that we now have problems representing thing
like:
Castilian Spanish and Latin-American Spanish, the same goes for
Portuguese, English
etc. Java has a clean solution for this but unfortunately, not enough
effort was put, or
there was not enough time to, when our translation system was implemented.
Fortunately, by using ISO2, we still fall in the simple scenario of Java
I18N, even though
we do not use it to the full extent. As part of the Kernel refactoring,
there will be effort
dedicated to fix the problem.
Using ISO2 (and not ISO3 or, God forbid us, some ad-hoc country code ) is
absolutely
crucial fot the framework architecture as a whole.
Any application-specific problems, like codes coming differently from
different sources
should be solved in the application logic.
thanks
Irakli
P.S. Country codes and politics is a complicated science. There will
always be cases
that can not be pre-addressed and will have to be addressed when those
take place.
It does not only happen that countries change code but countries also fall
apart from
time to time - e.g. Soviet Union, or the same - former Yugoslavia. No
numeric country
id can help with that.
So I think, while it is good to think and know about the issues, I do not
think it is relevant
to try, for the sake of partial solution of the problem, to re-implement
what is fundamentally
standard in Java - the platform we use.
vam...@wo...
Sent by: dig...@li...
12/18/2003 03:19 PM
To: <dig...@li...>
cc:
Subject: [Digi-developer] Country codes change!
folks, did you know that country codes change.
Right, not that often but this is what just happened to Yugoslavia.
and those who is using iso codes for mappings have a small problem now.
solution with using custom country IDs though now seems to be smart.
agree?
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...
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Digi-developer mailing list
Dig...@li...
https://lists.sourceforge.net/lists/listinfo/digi-developer
|
|
From: <vam...@wo...> - 2003-12-18 20:44:31
|
iteresting, so it means that the iso-to-code mapping is becoming one-to-multiple and not one-to-one as was before in the ACS. 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... Nader Aghili To: vam...@wo... 12/18/2003 03:33 cc: dig...@li..., dig...@li... PM Subject: Re: [Digi-developer] Country codes change!(Document link: Vahan Amirbekyan) 88465 ISGIF For AIDA, we know how to proceed, it has to be implemented. The codes are ISO standard, but the problem is for AIDA that our data providers use both old and new codes for ex. Romania that is ROU now and was ROM before. look at: http://unstats.un.org/unsd/methods/m49/m49alpha.htm also the other country is former East Timor that is now called: Timor-Leste We need to add the codes absolutely. Sincerely Nader Aghili Development Gateway/World Bank Mail Stop I 4 - 058 1818 H St. N.W. Washington DC 20433 PHONE: (202) 458-8465 FAX: (202) 522-7479 EMAIL: na...@wo... VISIT: www.developmentgateway.org |---------+------------------------------------------> | | vam...@wo... | | | Sent by: | | | dig...@li...ur| | | ceforge.net | | | | | | | | | 12/18/2003 03:19 PM | | | | | | | |---------+------------------------------------------> >--------------------------------------------------------------------------------------------------------------| | | | To: <dig...@li...> | | cc: | | Subject: [Digi-developer] Country codes change! | | | >--------------------------------------------------------------------------------------------------------------| folks, did you know that country codes change. Right, not that often but this is what just happened to Yugoslavia. and those who is using iso codes for mappings have a small problem now. solution with using custom country IDs though now seems to be smart. agree? 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... ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Digi-developer mailing list Dig...@li... https://lists.sourceforge.net/lists/listinfo/digi-developer |
|
From: <Na...@wo...> - 2003-12-18 20:33:34
|
For AIDA, we know how to proceed, it has to be implemented. The codes are ISO standard, but the problem is for AIDA that our data providers use both old and new codes for ex. Romania that is ROU now and was ROM before. look at: http://unstats.un.org/unsd/methods/m49/m49alpha.htm also the other country is former East Timor that is now called: Timor-Leste We need to add the codes absolutely. Sincerely Nader Aghili Development Gateway/World Bank Mail Stop I 4 - 058 1818 H St. N.W. Washington DC 20433 PHONE: (202) 458-8465 FAX: (202) 522-7479 EMAIL: na...@wo... VISIT: www.developmentgateway.org vam...@wo... Sent by: To: <dig...@li...> dig...@li...ur cc: ceforge.net Subject: [Digi-developer] Country codes change! 12/18/2003 03:19 PM folks, did you know that country codes change. Right, not that often but this is what just happened to Yugoslavia. and those who is using iso codes for mappings have a small problem now. solution with using custom country IDs though now seems to be smart. agree? 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... ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Digi-developer mailing list Dig...@li... https://lists.sourceforge.net/lists/listinfo/digi-developer |
|
From: <vam...@wo...> - 2003-12-18 20:19:55
|
folks, did you know that country codes change. Right, not that often but this is what just happened to Yugoslavia. and those who is using iso codes for mappings have a small problem now. solution with using custom country IDs though now seems to be smart. agree? 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... |
|
From: <pan...@wo...> - 2003-12-12 22:19:18
|
Once again: we don't use language inheritance, nor do we have any use f= or DgUtil.getCurrSiteTransLangs() and DgUtil.getCurrSiteUserLangs() BECAUS= E they use language inheritance. We do have use for getTranslationLanguages() = though. I would also appreciate it if you could stop interferring with use of k= ernel or non-kernel functions in dgMarket (and org.digijava.module.eproc.action.NavigationListAction is one of dgMarke= t specific classes, which is easy to see from org.digijava.module.eproc p= refix). That's my job :-). You're welcome to give an advice on use of kernel fu= nctions, though, and I will gladly review it and decide whether to accept or rej= ect it. Thank you, Philipp. P.S. Some documentation or at least code comments for functions like DgUtil.getCurrSiteTransLangs() explaining non-obvious detailes (like la= nguage inheritance used by the function) also would be very welcomed. |---------+------------------------------------------> | | ina...@wo... | | | Sent by: | | | dig...@li...ur| | | ceforge.net | | | | | | | | | 12/12/2003 01:33 PM | | | | | | | | | | |---------+------------------------------------------> >--------------------------------------------------------------------= ---------------------------------------------------------| | = | | To: dig...@li... = | | cc: = | | Subject: Re: [Digi-developer] Getting language settings for = the current site | | = | >--------------------------------------------------------------------= ---------------------------------------------------------| Once again, getTranslationLanguages() is Site object's method for its internatl usa= ge, while traslation settings logic is a unified, kernel functionality in Digi. A= ny module developer should use DgUtil.getCurrSiteTransLangs() and DgUtil.getCurrSiteUserLan= gs(). It does not matter if the module is dgMarket or some Tic Tac Toe. Capisce? Verstehen Sie? Comprend? =BFEntiende? Entenda? (this is the part, Philip, where you say "si") cheers Irakli = =20 Philipp = =20 Anokhin To: ina...@wo... = =20 cc: dig...@li...urceforge.n= et, =20 dig...@li... = =20 12/12/2003 Subject: Re: [Digi-developer] Getting = =20 12:39 PM language settings for the current siteLink = =20 34571 ISGIF = =20 = =20 = =20 That's the correct use of the functions for dgMarket. We don't use lang= uage inheritance. Philipp. = =20 ina...@wo... = =20 Sent by: To: = =20 dig...@li...u dig...@li... = =20 rceforge.net cc: = =20 Subject: [Digi-develop= er] =20 Getting language settings for the cur= rent =20 12/12/2003 10:52 AM site = =20 = =20 = =20 = =20 FYI It was noticed that some code is tryin to use: DgUtil.getSiteDomain(request).getSite().getTranslationLanguages() to get translation languages for the current site. This is an incorrect approach. getTranslationLanguages returns the sett= ings in the database (Site is a hibernate-persisted class) and does not take= into account language-setting inheritance that should be in place by the tra= nslation specifications. The method to be used instead is: DgUtil.getCurrSiteTransLangs() The usage of incorrect method was noticed, for example in: org.digijava.kernel.translator.action.TranslatorNavigation org.digijava.module.eproc.action.NavigationListAction getTranslationLanguages() in Site will not be set to deprecated because= it has its own meaning, but all the code trying to get Translator languages sh= ould use getCurrSiteTransLangs() The same is true for user languages DgUtil.getCurrSiteUserLangs() shou= ld be used. thank you Irakli = |
|
From: <ina...@wo...> - 2003-12-12 18:33:58
|
Once again,
getTranslationLanguages() is Site object's method for its internatl usage, =
while
traslation settings logic is a unified, kernel functionality in Digi. Any=20
module developer
should use DgUtil.getCurrSiteTransLangs() and=20
DgUtil.getCurrSiteUserLangs().
It does not matter if the module is dgMarket or some Tic Tac Toe.
Capisce?=20
Verstehen Sie?=20
Comprend?=20
=BFEntiende?=20
Entenda?=20
(this is the part, Philip, where you say "si")
cheers
Irakli=20
Philipp Anokhin
12/12/2003 12:39 PM
34571 ISGIF
To: ina...@wo...
cc: dig...@li...,=20
dig...@li...
Subject: Re: [Digi-developer] Getting language settings for =
the current site
That's the correct use of the functions for dgMarket. We don't use=20
language inheritance.
Philipp.
ina...@wo...
Sent by: dig...@li...
12/12/2003 10:52 AM
=20
=20
To: dig...@li...
cc:=20
Subject: [Digi-developer] Getting language settings for the =
current site
FYI=20
It was noticed that some code is tryin to use:=20
DgUtil.getSiteDomain(request).getSite().getTranslationLanguages()=20
to get translation languages for the current site.=20
This is an incorrect approach. getTranslationLanguages returns the=20
settings=20
in the database (Site is a hibernate-persisted class) and does not take=20
into=20
account language-setting inheritance that should be in place by the=20
translation=20
specifications.=20
The method to be used instead is: DgUtil.getCurrSiteTransLangs()=20
The usage of incorrect method was noticed, for example in:=20
org.digijava.kernel.translator.action.TranslatorNavigation=20
org.digijava.module.eproc.action.NavigationListAction=20
getTranslationLanguages() in Site will not be set to deprecated because it =
has=20
its own meaning, but all the code trying to get Translator languages=20
should use=20
getCurrSiteTransLangs()=20
The same is true for user languages DgUtil.getCurrSiteUserLangs() should=20
be used.=20
thank you=20
Irakli=20
|
|
From: <pan...@wo...> - 2003-12-12 17:40:23
|
That's the correct use of the functions for dgMarket. We don't use language inheritance. Philipp. |---------+------------------------------------------> | | ina...@wo... | | | Sent by: | | | dig...@li...ur| | | ceforge.net | | | | | | | | | 12/12/2003 10:52 AM | | | | | | | | | | |---------+------------------------------------------> >-----------------------------------------------------------------------------------------------------------------------------| | | | To: dig...@li... | | cc: | | Subject: [Digi-developer] Getting language settings for the current site | | | >-----------------------------------------------------------------------------------------------------------------------------| FYI It was noticed that some code is tryin to use: DgUtil.getSiteDomain(request).getSite().getTranslationLanguages() to get translation languages for the current site. This is an incorrect approach. getTranslationLanguages returns the settings in the database (Site is a hibernate-persisted class) and does not take into account language-setting inheritance that should be in place by the translation specifications. The method to be used instead is: DgUtil.getCurrSiteTransLangs() The usage of incorrect method was noticed, for example in: org.digijava.kernel.translator.action.TranslatorNavigation org.digijava.module.eproc.action.NavigationListAction getTranslationLanguages() in Site will not be set to deprecated because it has its own meaning, but all the code trying to get Translator languages should use getCurrSiteTransLangs() The same is true for user languages DgUtil.getCurrSiteUserLangs() should be used. thank you Irakli |
|
From: <ina...@wo...> - 2003-12-12 15:52:11
|
FYI
It was noticed that some code is tryin to use:
DgUtil.getSiteDomain(request).getSite().getTranslationLanguages()
to get translation languages for the current site.
This is an incorrect approach. getTranslationLanguages returns the
settings
in the database (Site is a hibernate-persisted class) and does not take
into
account language-setting inheritance that should be in place by the
translation
specifications.
The method to be used instead is: DgUtil.getCurrSiteTransLangs()
The usage of incorrect method was noticed, for example in:
org.digijava.kernel.translator.action.TranslatorNavigation
org.digijava.module.eproc.action.NavigationListAction
getTranslationLanguages() in Site will not be set to deprecated because it
has
its own meaning, but all the code trying to get Translator languages
should use
getCurrSiteTransLangs()
The same is true for user languages DgUtil.getCurrSiteUserLangs() should
be used.
thank you
Irakli |
|
From: <vam...@wo...> - 2003-12-12 05:48:34
|
great news, thank you I know many of us have spend a lot of time trying to make it working. 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... ina...@wo... Sent by: dig...@li... 12/12/2003 12:38 AM To: dig...@li... cc: Subject: [Digi-developer] FIXED - Problem with images on absolute-referenced pages FYI There was a problem with tiles included through absolute reference - images, css and other external page elements were not properly displayed due to incorrect compuration of the path for them. The bug is fixed and you whould be able to use absolute references without any tricks or hacks. Please, let me know if you see any issues. thanks Irakli |
|
From: <ina...@wo...> - 2003-12-12 05:39:10
|
FYI There was a problem with tiles included through absolute reference - images, css and other external page elements were not properly displayed due to incorrect compuration of the path for them. The bug is fixed and you whould be able to use absolute references without any tricks or hacks. Please, let me know if you see any issues. thanks Irakli |
|
From: <ako...@wo...> - 2003-12-09 16:42:30
|
Having ability to log e.g. search queries (in all languages) if required seems to be quite nice. Am I missing something here? Sincerely, Alexander Korolyov Business Development Development Gateway The World Bank 1818 H Street, NW, I4-408 Washington, DC 20433, USA Tel. +1 (202) 473 4990 ako...@wo... www.dgMarket.com dh...@wo... Sent by: To: ina...@wo... dig...@li...ur cc: dig...@li..., ceforge.net dig...@li... Subject: Re: [Digi-developer] Second thoughts about internationalized logging. 2003-12-08 23:20 Dropping the i18n requirement for our logging is ok with me. Can anybody convince me otherwise? I'm also all for this if it means that it'll be that much easier for people to use "logger.debug()" instead of System.out.println. Doug --- Doug Harris (202) 473-3118 dh...@wo... ina...@wo... Sent by: To: dig...@li... dig...@li... urceforge.net cc: Subject: [Digi-developer] Second thoughts about internationalized 12/08/2003 10:22 PM logging. 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 |
|
From: <dh...@wo...> - 2003-12-09 04:31:45
|
Dropping the i18n requirement for our logging is ok with me. Can anybody
convince me otherwise?
I'm also all for this if it means that it'll be that much easier for
people to use "logger.debug()" instead of System.out.println.
Doug
---
Doug Harris (202) 473-3118 dh...@wo...
ina...@wo...
Sent by: dig...@li...
12/08/2003 10:22 PM
To: dig...@li...
cc:
Subject: [Digi-developer] Second thoughts about internationalized logging.
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
|
|
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 |
|
From: <ina...@wo...> - 2003-12-09 03:26:09
|
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
|
|
From: Andrei S. <as...@so...> - 2003-12-08 21:25:17
|
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 |
|
From: <ina...@wo...> - 2003-12-08 16:25:38
|
Kernel provides the ability to define, for each module instance,
number_of_items_in_teaser parameter, that can be used by a module
developer. Most of the modules need one such parameter per module, but not
all - as in the example described by you.
When a module has several teasers and each needs to have different number
of items in it, such
customization features need to be implemented in the module application
logic itself. The behaviour
is too specific to the module.
Once this feature is implemented on the module level, there's no need to
retreive "ID of teasers" or anything
like that - module logic will take care of everything.
Irakli
vam...@wo...
Sent by: dig...@li...
12/07/2003 11:33 PM
To: dig...@li...
cc:
Subject: [Digi-developer] Re: Digi-developer digest, Vol 1
#8 - 3 msgs
dgTopics have a use case when different teasers for the case module have
different number of items to display.
If you go to any of the topic pages you will two sections: Key Issues and
Latest Additions. Both are teasers of the same RC module.
If you go to the Guides Overview page you will see two separate dropdowns
for "Show Latest" and "Show Key Issues"
So, the RC module should have a settings structure that would allow
setting up preferences on the base of particular teasers for particular
module instance.
Similar tye of setting is implemented for the News and Calendar modules
for module instances only. In this particular case with the RC module
every teaser of the same instance may have different settings.
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/07/2003 11:05 PM
Please respond to digi-developer
To: dig...@li...
cc:
Subject: Digi-developer digest, Vol 1 #8 - 3 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. How to retreave unique IDs of teasers for a module by API?
(vam...@wo...)
2. Re: How to retreave unique IDs of teasers for a module by
API? (ina...@wo...)
--__--__--
Message: 1
To: dig...@li...
From: vam...@wo...
Date: Sun, 7 Dec 2003 10:07:48 -0500
Subject: [Digi-developer] How to retreave unique IDs of teasers for a
module by API?
This is a multipart message in MIME format.
--=_alternative 00531B3585256DF5_=
Content-Type: text/plain; charset="us-ascii"
to the kernel team again. please asnwer as soon as possible.
Is there any API call to retreave unique identifiers of teasers that
belong to a particular module instance?
if the queston is not clear let me know I can explain.
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...
--=_alternative 00531B3585256DF5_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="sans-serif">to the kernel team again. please asnwer
as soon as possible.</font>
<br><font size=2 face="sans-serif">Is there any API call to retreave
unique identifiers of teasers that belong to a particular module
instance?</font>
<br>
<br><font size=2 face="sans-serif">if the queston is not clear let me know
I can explain.</font>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Vahan Amirbekyan<br>
The World Bank<br>
1850 I Street, NW, Washington, DC 20433<br>
Tel: 202 / 473-3114 (office)<br>
vam...@wo...<br>
VISIT: www.developmentgateway.org<br>
Sign up for our free monthly e-mail newsletter:
gat...@de...<br>
</font>
--=_alternative 00531B3585256DF5_=--
--__--__--
Message: 2
To: dig...@li...
Subject: Re: [Digi-developer] How to retreave unique IDs of teasers for a
module by
API?
From: ina...@wo...
Date: Sun, 7 Dec 2003 17:36:40 -0500
This is a multipart message in MIME format.
--=_alternative 007BF36385256DF5_=
Content-Type: text/plain; charset="US-ASCII"
What are you trying to do? What is your use-case?
Irakli
vam...@wo...
Sent by: dig...@li...
12/07/2003 10:07 AM
To: dig...@li...
cc:
Subject: [Digi-developer] How to retreave unique IDs of
teasers for a module by API?
to the kernel team again. please asnwer as soon as possible.
Is there any API call to retreave unique identifiers of teasers that
belong to a particular module instance?
if the queston is not clear let me know I can explain.
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...
--=_alternative 007BF36385256DF5_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">What are you trying to do? What is your
use-case?</font>
<br>
<br><font size=2 face="sans-serif">Irakli </font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>vam...@wo...</b></font>
<br><font size=1 face="sans-serif">Sent by:
dig...@li...</font>
<p><font size=1 face="sans-serif">12/07/2003 10:07 AM</font>
<br><font size=2 face="sans-serif"> </font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
dig...@li...</font>
<br><font size=1 face="sans-serif"> cc:
</font>
<br><font size=1 face="sans-serif"> Subject:
[Digi-developer] How to retreave unique
IDs of teasers for a module by API?</font>
<br></table>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
to the kernel team again. please asnwer as soon as possible.</font><font
size=3>
</font><font size=2 face="sans-serif"><br>
Is there any API call to retreave unique identifiers of teasers that
belong
to a particular module instance?</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
if the queston is not clear let me know I can explain.</font><font size=3>
<br>
<br>
<br>
<br>
</font><font size=2 face="sans-serif"><br>
Vahan Amirbekyan<br>
The World Bank<br>
1850 I Street, NW, Washington, DC 20433<br>
Tel: 202 / 473-3114 (office)<br>
vam...@wo...<br>
VISIT: www.developmentgateway.org<br>
Sign up for our free monthly e-mail newsletter:
gat...@de...</font>
<br>
<br>
<br>
--=_alternative 007BF36385256DF5_=--
--__--__--
_______________________________________________
Digi-developer mailing list
Dig...@li...
https://lists.sourceforge.net/lists/listinfo/digi-developer
End of Digi-developer Digest
|
2 messages has been excluded from this view by a project administrator.
