[i18n] Remaining issues (updated 2005-06-18)
[A few entries have been removed and a comment has beedn added to the list
of remaining issues previously posted]
Here is a list of what I think needs to be done before i18n is moved to
proper/released as 1.0:
* If the id ("parent") exists, but the entry ("child") does not, the
ResourceBundleMessageProvider throws an exception (erroneously claiming "No
message entries found for bundle with key ..."), while the
XMLMessageProvider returns null.
eturn
null if message is not found and have MessageManager.getText() throw the
Exception instead. We can then remove the try/catch in MessageManager.
Also consider renaming MessageProvider.getText() to
MessageProvider.findText() to make this more obvious for implementors.
* The ResourceBundleMessageProvider and the XMLMessageProvider behave
differently when an entry does not exist in a non-default language. With
ResourceBundles, if there is an entry, say
helloWorld.notTranslated=This entry is not translated to any other languages
the entry will be included
when calling getEntries() for *any* locale. Whereas for XML, only the
entries defined for the given locale will be returned.
Proposed fix: First of all, I am not sure I personally think this needs
fixing, since all the entries should normally be translated. Secondly, I
don't know which behaviour I believe is most correct, but since we cannot
change the implementation of ResourceBundle, the only option would be to
make XMLMessageProvider (and any other MessageProvider) behave the same way
as the ResourceBundleMessageProvider. If we decide this does not need to be
fixed, we need to document the difference in behaviour somewhere (JavaDoc?).
* Consider the semi-circular dependency between MessageManager and the
MessageProvider implementations. The implementations are used, via the
interface, by the MessageManager and the MessageManager is used by the
implementations for install/uninstall through static methods, and for
internal error messages.
Proposed fix(es):
1. Remove the static install/uninstall/update methods on the
MessageProvider implementations.
2. Move the MessageManager.INTERNAL_MESSAGES and the internal message
keys to a utitly class, say I18nUtils. I have ideas for other stuff to put
there too. Another alternative would be to consider whether we actually
need these error messages in the MessageProvider implementations. As of the
at least the use of MessageManager.NO_MESSAGE_ENTRIES_FOUND
should be moved to MessageManager instead.
* Consider the circular depency between the "org.apache.commons.i18n" and
"org.apache.commons.i18n.bundles" packages. For example
org.apache.commons.i18n.LocalizedException uses
org.apache.commons.i18n.bundles.ErrorBundle which is a subclass to
org.apache.commons.i18n.LocalizedBundle.
Proposed fix: Personally I think the org.apache.commons.i18n.bundles
packages is a bit overkill; why not remove it altogether? Otherwise, move
the LocalizedException/RuntimeException/Error into the bundles package (or
another package such as "org.apache.commons.i18n.exceptions").
* Synchronize Maven (project.xml) and Ant (build.xml).
Proposed fix: Add jcoverage test coverage to build.xml. (I have EMMA test
coverage with Ant locally). This might imply adding jcoverage jars to a lib
dir.
* Create a database/JDBC MessageProvider to be used out-of-the-box,
subclassed or as an example.
Proposed fix: I have it in my head, just need to find the time to code it.
Update 2005-06-18: Preliminary version e-mailed to Daniel Florey.
* Consider examples with qualified entries.
Proposed fix: Create code example that use my modification with qualified
provider/namespace/source.
* Consider adding check style plugin in project.xml and fix whatever it
reports.
Addition 2005-06-18:
ces MessageProvider.
Mattias Jiderhamn
Expert Systems
Mail:
[EMAIL PROTECTED]
Web:
Re: Commons-Collections enhanced with Java Generics Support
In summary, I don't think the number of people interested in 1.5 features will increase while Commons Collections developers just sit around waiting... Thats not fair. We do what we can and mostly in our free time. And its also your (contributor) job to push a project forward - for sure what you have done now. Surely I didn't mean "...doing nothing", I just meant not supporting JDK 1.5 features until enough people are likely to want them. My apologies if anybody was offended. But I wonder if we could let the jdk 1.3 behind us and move on to jdk 1.5 by allowing backward compatiblity with retroweaver. AFAIK generics is only a compile time feature, no type checking is done during runtime, so a generics supporting JAR should be possible to use with older JDKs. I have not looked at the Collections API over at sf.net, but possibly other things have changed to be able to add the generics support, which would make this library behave differently than the original one, on an older JDK. /Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons-Collections enhanced with Java Generics Support
At 2005-05-24 17:11, Simon Kitching wrote: There is also the question of how large the generic collections community will be. There aren't yet a whole lot of projects coding to 1.5 as far as I know. Assuming this statement is true (which I am not too sure about), the fact that many Open Source project do not yet support 1.5 features - like generics - might actually be the reason people have not yet upgraded. Put in another way; good and useful Open Source projects (like Jakarta Commons) supporting JDK 1.5 may motivate more people to upgrade to JDK 1.5. From the other perspective, for those of us that *do* use JDK 1.5 (and have done so for a while now...), the fact that Commons Collections does not support generics may motivate us to use the standard java.util.* collections, or some proprietary ones, instead. In summary, I don't think the number of people interested in 1.5 features will increase while Commons Collections developers just sit around waiting... /Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-commons Wiki] Update of "Collections" by MattHall
At 2005-05-23 19:52, you wrote: All users of v2.1 should upgrade to v2.1... This should read 2.1.1 shouldn't it? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Remaining issues
Here is a list of what I think needs to be done before i18n is moved to
proper/released as 1.0:
* If the id ("parent") exists, but the entry ("child") does not, the
ResourceBundleMessageProvider throws an exception (erroneously claiming "No
message entries found for bundle with key ..."), while the
XMLMessageProvider returns null.
Proposed fix: Make all implementations of MessageProvider.getText() return
null if message is not found and have MessageManager.getText() throw the
Exception instead. We can then remove the try/catch in MessageManager.
Also consider renaming MessageProvider.getText() to
MessageProvider.findText() to make this more obvious for implementors.
* The ResourceBundleMessageProvider and the XMLMessageProvider behave
differently when an entry does not exist in a non-default language. With
ResourceBundles, if there is an entry, say
helloWorld.notTranslated=This entry is not translated to any other languages
that only exists in the default locale file, the entry will be included
when calling getEntries() for *any* locale. Whereas for XML, only the
entries defined for the given locale will be returned.
Proposed fix: First of all, I am not sure I personally think this needs
fixing, since all the entries should normally be translated. Secondly, I
don't know which behaviour I believe is most correct, but since we cannot
change the implementation of ResourceBundle, the only option would be to
make XMLMessageProvider (and any other MessageProvider) behave the same way
as the ResourceBundleMessageProvider. If we decide this does not need to be
fixed, we need to document the difference in behaviour somewhere (JavaDoc?).
* Consider the semi-circular dependency between MessageManager and the
MessageProvider implementations. The implementations are used, via the
interface, by the MessageManager and the MessageManager is used by the
implementations for install/uninstall through static methods, and for
internal error messages.
Proposed fix(es):
1. Remove the static install/uninstall/update methods on the
MessageProvider implementations.
2. Move the MessageManager.INTERNAL_MESSAGES and the internal message
keys to a utitly class, say I18nUtils. I have ideas for other stuff to put
there too. Another alternative would be to consider whether we actually
need these error messages in the MessageProvider implementations. As of the
above proposal, at least the use of MessageManager.NO_MESSAGE_ENTRIES_FOUND
should be moved to MessageManager instead.
* Consider the circular depency between the "org.apache.commons.i18n" and
"org.apache.commons.i18n.bundles" packages. For example
org.apache.commons.i18n.LocalizedException uses
org.apache.commons.i18n.bundles.ErrorBundle which is a subclass to
org.apache.commons.i18n.LocalizedBundle.
Proposed fix: Personally I think the org.apache.commons.i18n.bundles
packages is a bit overkill; why not remove it altogether? Otherwise, move
the LocalizedException/RuntimeException/Error into the bundles package (or
another package such as "org.apache.commons.i18n.exceptions").
* The I18nTestSuite is not up to date.
Proposed fix: Remove it altogheter. There is no real use for it, and it is
easy to forget to keep it up to date.
* Synchronize Maven (project.xml) and Ant (build.xml).
Proposed fix: Add jcoverage test coverage to build.xml. (I have EMMA test
coverage with Ant locally). This might imply adding jcoverage jars to a lib
dir.
* Create a database/JDBC MessageProvider to be used out-of-the-box,
subclassed or as an example.
Proposed fix: I have it in my head, just need to find the time to code it.
* Unify XML indentation.
Proposed fix: We decided on 4 spaces, right? Then just use your favorite
IDE to auto-indent *.xml.
* Consider renaming the file with the internal error messages. It is quite
possible a user of the library would like to put their own error messages
in messages.properties.
Proposed fix: Rename src/resources/messages*.properties to
src/resources/i18n-messages*.properties and update corresponding code.
* Consider examples with qualified entries.
Proposed fix: Create code example that use my modification with qualified
provider/namespace/source.
* Consider adding check style plugin in project.xml and fix whatever it
reports.
Mattias Jiderhamn
Expert Systems
Mail:
[EMAIL PROTECTED]
Web:
[i18n] Basic architecture/component usage
[was "Re: [i18n PATCH] Adding provider qualifying"] At 2005-05-19 16:41, you wrote: But, to be honest, I'm a bit disappointed at how this project is being developed. I feel that i18n would benefit tremendously by reusing instead of reinventing. Since Commons Resources and i18n seems to basically solve the same problem, my very first post to this list a month ago included the question whether i18n and Resources were going to continue to co-exist, and what was the relationship between them. After getting the impression they would continue to co-exist i18n was the natural choice because of our prerequisites. In our project we store the language specific texts in a database. Among 60+ tables there are a few that contain several columns to provide - for example - text, abbreviated text and detailed description for a single ID + language/locale entry. So supporting multiple texts per ID is a basic requirement for us. As was pointed out months ago, there's just too much you get for free by leveraging other components and communities. With all do respect to those of you working on i18n, I'm not currently using this component in my own work, but I plan to in the near future. At that time I'll most likely fork the code, strip out the bottom half (dealing with message retrieval) and plug in commons-resources. To be honest I haven't really considered building i18n *on top of* commons-resources before. But - even though I have not studied the Resources API in details - I must disapprove since I do not see an obvious/useful way to handle the above scenario using Resources. For this to be supported by Resources in a useful manner, Resources needs to be extended. And if Resources is extended in such a way, we might just as well move what is left in i18n into the Resources component as well. I have no interest in trying to redo my work from Commons Resources or reimplement the 3 Database-based impls of such. And what about the hundreds of JUnit tests. One thing I've been working on lately is getting Resources to 100% test coverage. I would hate to ask someone to redo their work because I "didn't want to depend on another project". Another idea would be to add a CommonsResourcesProvider wich you could opt to use with i18n. FYI, I have assured i18n has 100% test coverage. The coverage report is not currently included in the build, but if somebody would add emma.jar and emma_ant.jar to the lib dir, I could provide an updated build.xml. /Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n PATCH] Adding provider qualifying
I have previously discussed with Daniel Florey a change that allows the user to
qualify the provider (or source or namespace) to be used for a given text
entry. My main motivation for this is to allow the same entry key in several
different text sources, but this also provides better performance since the API
does not have to loop over the different providers in search for the given
entry.
Thanks to James Mitchell I am now able to create the diff for this change; see
below. I would be happy if Daniel or anybody else would review and commit this
patch.
Included in the patch is also a minor change that allows non-string
ResourceBundle entries to be used (via toString()).
After this there are a few more changes I would like to discuss - conserning
class and package dependencies among others - so Daniel, please tell me when
you are available again. I also hope to find the time to create an example
DatabaseProvider.
Now here is the diff.
(Again, if lines are wrapped in the e-mail, I can provide the diff by personal
e-mail or in a bugzilla entry).
Index: src/test/org/apache/commons/i18n/MockProviderTestBase.java
===
--- src/test/org/apache/commons/i18n/MockProviderTestBase.java (revision
170884)
+++ src/test/org/apache/commons/i18n/MockProviderTestBase.java (working copy)
@@ -30,36 +30,41 @@
* @author Mattias Jiderhamn
*/
public abstract class MockProviderTestBase extends TestCase {
-/**
- * Mock message provider that returns a string made up of the arguments
passed to it.
- */
-final private MessageProvider mockMessageProvider = new MessageProvider() {
-public String getText(String id, String entry, Locale locale) throws
MessageNotFoundException {
-return MockProviderTestBase.getMockString(id, entry, locale);
-}
-public Map getEntries(String id, Locale locale) throws
MessageNotFoundException {
-Map output = new HashMap();
-output.put("entry1",
MockProviderTestBase.getMockString(id,"entry1",locale));
-output.put("entry2",
MockProviderTestBase.getMockString(id,"entry2",locale));
-return output;
-}
-};
-
public void tearDown() {
/* Remove mock provider after each test, to allow for
MessageNotFoundExceptions */
-MessageManager.removeMessageProvider("mock");
-removeThrowingMockProvider();
+MessageManager.clearMessageProviders();
}
/**
* Add mock provider to MessageManager.
*/
protected void addMockProvider() {
-MessageManager.addMessageProvider("mock", mockMessageProvider);
+addMockProvider("mock");
}
/**
+ * Add mock provider to MessageManager.
+ */
+protected void addMockProvider(final String providerId) {
+ // Mock message provider that returns a string made up of the
arguments passed to it.
+MessageProvider mockMessageProvider = new MessageProvider() {
+public String getText(String id, String entry, Locale locale)
throws MessageNotFoundException {
+return MockProviderTestBase.getMockString(providerId, id,
entry, locale);
+}
+
+public Map getEntries(String id, Locale locale) throws
MessageNotFoundException {
+Map output = new HashMap();
+output.put("entry1",
MockProviderTestBase.getMockString(providerId,id,"entry1",locale));
+output.put("entry2",
MockProviderTestBase.getMockString(providerId,id,"entry2",locale));
+return output;
+}
+};
+
+MessageManager.addMessageProvider(providerId, mockMessageProvider);
+}
+
+/**
* Add provider that always throws error to MessageManager.
*/
protected void addThrowingMockProvider() {
@@ -82,10 +87,19 @@
// Utility methods
+public static String getMockString(String providerId, String id, String
entry, Locale locale) throws MessageNotFoundException {
+return ((providerId != null) ? "Source=" + providerId + " " : "") +
+"Id=" + id + " Entry=" + entry + " Locale=" + locale + "";
+}
+
public static String getMockString(String id, String entry, Locale locale)
throws MessageNotFoundException {
-return "Id=" + id + " Entry=" + entry + " Locale=" + locale + "";
+return getMockString("mock", id, entry, locale);
}
+public static String getFormattedMockString(String providerId, String id,
String entry, String[] arguments, Locale locale) {
+return MessageFormat.format(getMockString(providerId, id, entry,
locale), arguments);
+}
+
public static String getFormattedMockString(String id, String entry,
String[] arguments, Locale locale) {
return MessageFormat.format(getMockString(id, entry, locale),
arguments);
}
In
[i18n] Re: Directory dissapeared from SVN
Daniel, something strange must have happened here. First the latest tests but not the refactorings were checked in, so that the tests did not compile. Then the refactorings were checked in, and all the test classes were removed...? Will you re-add the files so that I can create a diff, or should I just send you a ZIP will all the updated sources files? At 2005-05-14 19:00, Martin Cooper wrote: According to the Subversion logs, this change was part of a patch that was supplied by you. Here's the relevant log entry: r168590 | dflorey | 2005-05-06 03:36:38 -0700 (Fri, 06 May 2005) | 1 line Changed paths: M /jakarta/commons/sandbox/i18n/trunk/project.properties M /jakarta/commons/sandbox/i18n/trunk/project.xml M /jakarta/commons/sandbox/i18n/trunk/src/examples/org/apache/i18n/examples/LocalizedExceptionExample.java M /jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/LocalizedBundle.java M /jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/MessageManager.java M /jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/ResourceBundleMessageProvider.java M /jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/XMLMessageProvider.java M /jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/bundles/ErrorBundle.java M /jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/bundles/MessageBundle.java M /jakarta/commons/sandbox/i18n/trunk/src/java/org/apache/commons/i18n/bundles/TextBundle.java D /jakarta/commons/sandbox/i18n/trunk/src/test/org/apache/commons/i18n D /jakarta/commons/sandbox/i18n/trunk/xdocs/downloads.xml M /jakarta/commons/sandbox/i18n/trunk/xdocs/index.xml Incorporated changes proposed by Mattias J -- Martin Cooper On 5/14/05, Mattias J <[EMAIL PROTECTED]> wrote: > I have made some changes to the i18n sandbox project and tried to create a > patch for it to submit, although I noticed the patch did not contain > everything I expected. At first I thought I had done something wrong, but > after several tries I realized the i18n package has dissapeared from the > test source dir in SVN; see > http://svn.apache.org/repos/asf/jakarta/commons/sandbox/i18n/trunk/src/test/org/apache/commons/ > > I have not seen any commit removing this directory (which would also be > rather surprising), so I'm wondering has happened??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Directory dissapeared from SVN
I have made some changes to the i18n sandbox project and tried to create a patch for it to submit, although I noticed the patch did not contain everything I expected. At first I thought I had done something wrong, but after several tries I realized the i18n package has dissapeared from the test source dir in SVN; see http://svn.apache.org/repos/asf/jakarta/commons/sandbox/i18n/trunk/src/test/org/apache/commons/ I have not seen any commit removing this directory (which would also be rather surprising), so I'm wondering has happened??? Thanks in advance, Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-commons Wiki] Update of "JakartaCommonsEtiquette" by SimonKitching
At 2005-05-14 00:51, Simon Kitching wrote: On Thu, 2005-05-12 at 09:44 +0200, Mattias J wrote: > And if I am not currently a Jakarta commiter, but would like sandbox commit > access for existing sandbox projects? If you're not an ASF committer, then I think the current policy is that no, you can't get commit access to the sandbox. However ... they can always nominate you as a commons committer (or any other relevant ASF project) which then gives you access to the sandbox too. So you cannot be a commons sandbox only committer? The main issue with having commit access is that you need to have signed the appropriate legal forms. As understand it, you must sign the CLA before anybody else commits your patches too. Anyway, a link to http://jakarta.apache.org/site/source.html or any of it's "parents" from the etiquette page might be appropriate. /Mattias Jiderhamn
[chain] Pre-conditions
I have just started using Jakarta Chains to refactor and evolve an existing
project. I've had thoughts around this for a long time, and finally got
around to it. When actually working with this API/pattern, a few questions
come to mind, mostly related to the dependencies between different Commands
in a Chain.
The post-conditions of a Command should of course be checked using unit
tests. But what is the best practice for handling pre-conditions (i.e.
context must be of type MyContext, context must contain value for key
"myKey", value for "myKey" must be of type MyClass)?
Naturally pre-conditions should be documented in the JavaDoc of the Command
implementation, but this is not always the best for mainainability and
debugging.
- Should all possible Chain combinations be unit tested?
- Or would it be an idea to create a sub interface to Command to add, say,
checkPreConditions()?
This could of course done using AOP and configuring aspects via
annotations, for example
@ContextType(MyContext.class)
@RequiredKey("myKey")
@ValueType("myKey", MyClass.class)
- Or maybe one could elaborate this even further, creating rule object sets
returned by Commands as pre-conditions and post-conditions, so that a Chain
would be responsible of making sure the different Commands are compatible
when added using addCommand()...?
Does anyone else have any thoughts about this?
/Mattias J
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving code from sandbox to proper - best practice?
I think I agree with this. I believe it is better to remove the entire
sandbox directory, so that people notice it has moved (the website says
where) and can change the SVN repository in use (that can be done; can't it?).
At 2005-05-13 10:10, you wrote:
I disagree, README is just clutter and should be removed.
We send out announcements on the mailing list and if people miss that they
can look at the website.
The complete list of components if on the commons homepage so with one
click you have a full overview.
-- Dirk
Rory Winston wrote:
Good question. We did look at doing a sandbox cleanup when it was
migrated from CVS to SVN. I remember doing a list of dead projects that
were still in sandbox. However, I agree that having a sandbox/{project}
dir with at the very least a README pointing to the new location (for
promoted components) would be useful.
[EMAIL PROTECTED] wrote:
Hi,
The "moving from sandbox to proper" wiki page needs updating, as it is
all CVS based.
http://wiki.apache.org/jakarta-commons/MovingFromSandboxToProper
The main question that needs resolving is:
* should the code be MOVED from sandbox to proper, or COPIED?
Moving the code means that links to the old location break. But copying
the code means that links to the old stuff don't give any indication
that the main development is now happening elsewhere.
What do people think the best practice is for sandbox->proper promotion?
I think my preference would be
* move the existing code to {proj}/tags/sandbox
* copy to {proj}/trunk
* create a new sandbox/{proj} directory, containing just a README
that points to the new project.
That way, all the sandbox code vanishes from its old location, avoiding
any confusion. But users of the sandbox stuff at least get a hint where
the new stuff is.
The main disadvantage is clutter left in the sandbox directory.
Thoughts?
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-commons Wiki] Update of "JakartaCommonsEtiquette" by SimonKitching
SimonKitching wrote: + Any Jakarta committer (not just commons committers) has the right ask for karma (commit access) and have it granted. The right place to ask is on the commons-dev mailing list. + Commit access to the sandbox is unfortunately '''not''' available to people who are not existing Jakarta committers, no matter how good their idea. Such projects are generally encouraged to start somewhere like sourceforge.net. Once a solid community has been established and existing projects are using the component, it may be possible to integrate the project direct into commons if the project developers feel that is appropriate, and the commons community feels the component is a good fit with commons goals. And if I am not currently a Jakarta commiter, but would like sandbox commit access for existing sandbox projects? /Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Meta-issue: multiple mailig lists
Simon Kitching wrote: Often I have struck a problem, and been given advice from committers on quite different projects. So an additional common list - which forwards to all the separate ones - is still a good idea. Simon Kitching wrote: Every email is supposed to contain the name of the subproject in square-brackets, eg [foo] why did the chicken cross the road? so that filtering is reasonably easy to do. Would it be possible to set up the svn commit mails to include this in *the beginning* of the subject line? As I said, all my e-mail client shows is (for example) "svn commit: r169326 -". Simon Kitching wrote: Getting messages that aren't associated with a particular project could be done by simply filtering *out* the projects you aren't interested in rather than filtering *in* the ones you are. Yes, that is probably the best idea. "if subject contains '[uninteresting-project]' or '/proper/uninteresting-project/' move to Trash". Still does not help on the unclassified issue mails though. Elliotte Harold wrote: I suspect some of the less active lists may be so primarily because few people care about those projects enough to wade through all the projects they don't care about. Having separate lists might help the smaller communities to grow a bit. That is a point. The volume of the dev-list might actually make people reluctant to subscribing to it at all. Mario Ivankovits wrote: Mattias J wrote: Then what would be high traffic to you? Take a look at the hibernate forum. This is really high traffic. A forum is a whole different story than a mailing list. Mario Ivankovits wrote: Mattias J wrote: If it was not for all the commits and bug/issue mails there would be no problem. But for those, it's often a lot harder to tell whether this is interesting for you without opening the e-mail (especially since my mail client insists on truncating the subject after "svn commit: rNN -"...) In fact sometimes I dive into those mails to learn. In that case, subscribe to them all! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Meta-issue: multiple mailig lists
Elliotte Harold wrote: Is there any chance or interest in splitting this mailing list up into multiple mailing lists, one per subproject? +1 + 1 common mailing list (commons-common :-) ) - for mails like this. Mario Ivankovits wrote: I do have an easy overlook whats new in other projects, the traffic is not that high. Then what would be high traffic to you? If it was not for all the commits and bug/issue mails there would be no problem. But for those, it's often a lot harder to tell whether this is interesting for you without opening the e-mail (especially since my mail client insists on truncating the subject after "svn commit: rNN -"...) Why not create a e-mail filter to get only those mails you are interested in? I planned to, but haven't decided what to filter on. Apart from the subprojects of interest, I want the general mail (as of above). So maybe "subject contains 'sub-project' [or 'sub-project2' or 'sub-project3' ...] or (subject does not contain '[' and ']' and subject does not contain 'svn commit')"? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Continued development
Daniel, I see you checked in my refactorings now. Thanks. To solve one of the issues previously discussed - with one provider throwing an exception and another one returning null for a particular case - I have the following idea: Let's extend the MessageProvider interface to include both getText() - which throws an exception if not found - and findText() - which returns null if not found. (Something like the difference between Hibernates Session.load() and .find()). Then for the MessageProvider implementations, you will only actually implement one of these - which should be clear by the documentation. Either you implement findText() and have getText() throw an exception if the call to findText() returns null, OR you implement getText() and have findText() return null if the call to getText() throws and exception. This way we will not only solve the inconsequence problems; we will also increase performance by using findText() in MessageManager and thus avoiding throwing and catching exceptions while looping (assuming the MessageProvider implements findText() that does not throw, that is). Therefore, if we only want findText() OR getText(), I would suggest findText(). As to the other issue, that ResouceBundles returns the entry of the default locale if not found for the specific locale while XML does not, I assume the most straight forward would be to have XML behave the same way ResourceBundles does. AFAIK there is no way to change the behaivor of java.util.ResourceBundle and providing our own implementation would not only cost a lot of time, but feel just "wrong". (B.t.w. I have started working on naming/qualifying provider and will post a diff when I'm done) /Mattias J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Missing check-in
Thanks for checking in the unit tests.
Although, you checked in the tests running against the refactored code,
without checking in the refactoring. The test cases does not compile
against the code in the repository. Please commit also the following patch
(which I will also try to attach):
Index: src/java/org/apache/commons/i18n/MessageManager.java
===
--- src/java/org/apache/commons/i18n/MessageManager.java(revision
168095)
+++ src/java/org/apache/commons/i18n/MessageManager.java(arbetskopia)
@@ -20,12 +20,7 @@
package org.apache.commons.i18n;
import java.text.MessageFormat;
-import java.util.ArrayList;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Locale;
-import java.util.Map;
-import java.util.ResourceBundle;
+import java.util.*;
/**
* The MessageManager provides methods for retrieving localized
@@ -46,7 +41,7 @@
*
* You can call [EMAIL PROTECTED]
MessageManager#getText(String,String,Object[],Locale) getText} directly,
* but if you do so, you have to ensure that the given entry key really
- * exists and to deal with the [EMAIL PROTECTED] MessageNotFound} exception that will
+ * exists and to deal with the [EMAIL PROTECTED] MessageNotFoundException} exception
that will
* be thrown if you try to access a not existing entry.
*
*/
@@ -61,28 +56,33 @@
public static final ResourceBundle INTERNAL_MESSAGES =
ResourceBundle.getBundle("messages", Locale.getDefault());
-private static List messageProviders = new ArrayList();
+private static Map messageProviders = new LinkedHashMap();
-static {
-// Add default message providers
-messageProviders.add(new XMLMessageProvider());
-messageProviders.add(new ResourceBundleMessageProvider());
-}
-
/**
* Add a custom [EMAIL PROTECTED] MessageProvider} to the
* MessageManager. It will be incorporated in later calls of
* the [EMAIL PROTECTED] MessageManager#getText(String,String,Object[],Locale)
getText}
* or [EMAIL PROTECTED] #getEntries(String,Locale) getEntries}methods.
- *
+ *
+ * @param providerId Id of the provider used for uninstallation and
+ * qualified naming.
* @param messageProvider
*The MessageProvider to be added.
*/
-public static void addMessageProvider(MessageProvider messageProvider) {
-messageProviders.add(messageProvider);
+public static void addMessageProvider(String providerId,
MessageProvider messageProvider) {
+messageProviders.put(providerId, messageProvider);
}
/**
+ * Remove custom [EMAIL PROTECTED] MessageProvider} from the
+ * MessageManager. Used for tearing down unit tests.
+ *
+ * @param providerId The ID of the provider to remove.
+ */
+static void removeMessageProvider(String providerId) {
+messageProviders.remove(providerId);
+}
+/**
* Iterates over all registered message providers in order to find
the given
* entry in the requested message bundle.
*
@@ -104,8 +104,10 @@
*/
public static String getText(String id, String entry, Object[] arguments,
Locale locale) throws MessageNotFoundException {
+if(messageProviders.isEmpty())
+throw new MessageNotFoundException("No MessageProvider
registered");
MessageNotFoundException exception = null;
-for (Iterator i = messageProviders.iterator(); i.hasNext();) {
+for (Iterator i = messageProviders.values().iterator();
i.hasNext();) {
try {
String text = ((MessageProvider) i.next()).getText(id, entry,
locale);
@@ -140,10 +142,9 @@
public static String getText(String id, String entry, Object[] arguments,
Locale locale, String defaultText) {
try {
-String text = getText(id, entry, arguments, locale);
-return MessageFormat.format(text, arguments);
+return getText(id, entry, arguments, locale);
} catch (MessageNotFoundException e) {
-return defaultText;
+return MessageFormat.format(defaultText, arguments);
}
}
@@ -155,12 +156,12 @@
*/
public static Map getEntries(String id, Locale locale)
throws MessageNotFoundException {
+if(messageProviders.isEmpty())
+throw new MessageNotFoundException("No MessageProvider
registered");
MessageNotFoundException exception = null;
-for (Iterator i = messageProviders.iterator(); i.hasNext();) {
+for (Iterator i = messageProviders.values().iterator();
i.hasNext();) {
try {
-Map entries = ((MessageProvider) i.next()).getEntries(id,
-locale);
-return entries;
+return ((MessageProvider) i.next()).getEntries(id, locale);
} catch (Me
[i18n] Unit tests
Daniel, have you had time to study the unit tests and refactoring proposal I sent you? From what I can tell, nothing has been checked in. Do you want me to make modifications? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta-commons Wiki] Update of "BeanUtils/FAQ" by SimonKitching
At 2005-04-28 13:53, you wrote: Simply because different regions of the world use different date layouts. There isn't any date format that is a reasonable built-in default. I don't agree. -mm-dd is the ISO (8601) standard. http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html It is used, among others, in the XML Schema date type and for database representation. * USA: mm-dd-, mm/dd/ * Europe/Pacific: dd-mm- (In Sweden, which is part of Europe for those who don't know, we rarely use dd-mm-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Providers behave different
I have now e-mailed the test cases and the proposed refactoring (to make
each data source have it's own provider instance, in preparation for
qualified entries). I also have some ideas for further refactoring, which
might make it easier to solve the problems below.
My suggestion is that you first have a look at my tests and refactorings
and incorporate it into the SVN, after that we discuss my new ideas and
then we solve these problems.
At 2005-04-24 12:05, Daniel Florey:
This really needs to be changed. What is the most desirable behaviour for
these cases?
I'd suggest including the missing entries defined for the default locale if
the entries for another language are requested. So the XMLMessageProvider
needs to be changed. Or makes it sense to have two different methods for
this?
For the latter issue I need to have a closer look at the code.
Thanks for reporting these important issues!
Daniel
BTW: I'm back home. If you want me to add your testcases just mail the zip
file to me.
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Im Auftrag von Mattias J
> Gesendet: Donnerstag, 21. April 2005 15:41
> An: commons-dev@jakarta.apache.org
> Betreff: [i18n] Providers behave different
>
> It seems that the ResourceBundleMessageProvider and the XMLMessageProvider
> behaves differently when an entry does not exist in a non-default
> language.
> With ResourceBundles, if I have an entry, say
>helloWorld.notTranslated=This entry is not translated to any other
> languages
> that only exists in the default locale file, the entry will be included
> when calling getEntries() for *any* locale.
>
> Whereas for XML, only the entries defined for the given locale will be
> returned.
>
> Furthermore if the id ("parent") exists, but the entry ("child") does not,
> the ResourceBundleMessageProvider throws an exception (erroneously
> claiming
> "No message entries found for bundle with key ..."), while the
> XMLMessageProvider returns null.
>
> Daniel, I assume the first issue is not intended but only a consequence of
> the most obvious implementation?
> Does either need to be changed?
>
>Mattias Jiderhamn
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Providers behave different
It seems that the ResourceBundleMessageProvider and the XMLMessageProvider
behaves differently when an entry does not exist in a non-default language.
With ResourceBundles, if I have an entry, say
helloWorld.notTranslated=This entry is not translated to any other languages
that only exists in the default locale file, the entry will be included
when calling getEntries() for *any* locale.
Whereas for XML, only the entries defined for the given locale will be
returned.
Furthermore if the id ("parent") exists, but the entry ("child") does not,
the ResourceBundleMessageProvider throws an exception (erroneously claiming
"No message entries found for bundle with key ..."), while the
XMLMessageProvider returns null.
Daniel, I assume the first issue is not intended but only a consequence of
the most obvious implementation?
Does either need to be changed?
Mattias Jiderhamn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
So I ended up configuring EMMA with Ant. The coverage of the test cases I have written so far (all classes except XMLMessageProvider) is now 100%. (While setting up EMMA with Ant, I ran into the ClassNotFoundError again, and remembered this occurs when the EMMA instrumentation does not take interfaces - which are not instrumented - into account. So I assume the EMMA maven plugin needs to be reconfigured somehow. However that is done...) At 2005-04-21 07:10, you wrote: At 2005-04-20 23:05, you wrote: There were server errors earlier today. Did you ever get this to run? Nope. Tried Maven + Emma too, without luck. It either produced coverage data OR an empty report; never used the data to create a report. I should probably read up on how Maven works (or simply add Emma to Ant), but I would prefer to spend my time on the code rather than the setup. Mattias Jiderhamn At 2005-04-20 09:47, Mattias J wrote: B.t.w James: Thought I'd run your new Maven config to see the coverage of the tests I've added. Though I have not checked out .../commons-build/sandbox-project.xml and currently I cannot access the SVN server. Sorry if this is because I'm a newbie with Maven, but I am not able to get this to work. I have downloaded the commons-build SVN-files and can build and test with Maven. But if i run "maven jcoverage" all the tests fail, most with java.lang.NoClassDefFoundError, assumably because either the instrumented classes or some jcoverage libraries are not on the classpath. What do I need to do to my environment to get this working? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
At 2005-04-20 21:49, you wrote: Seems like i18n is reinventing the wheel over and over. I see we are using of Sax, when Digester is the most viable choice, given the typical clients of this framework. I see where ResourceBundle is used, yet a much more robust solution is already provided through Commons Resources. Any chance we can change this to use the above frameworks? My primary goal was to keep this component simple. It has no dependencies to other jars and that is a big plug for the daily use. Remember my thread about the missing ability in the java world to deal with different versions of the same class. So using digester/resources could cause a lot of trouble to bigger projects using a different version of these components. I know that we have some overlapping with Commons Resources, but the I18n is dealing with bundles of messages and introduces LocalizedExceptions using these bundles. As I needed this already in different projects seriously dealing with internationalization, personally I still think this component is reasonable. I'm sorry that you feel that way. I disagree, but not enough to discuss it any further. I know this is your (your == "you guys") baby, and I'm not looking to rock the boat. So, I'll put this effort on the back burner for now. Not that I'm disinterested, I've just got tons of other items on my hot-list that are begging for me to work on. Or... MessageProviders depending with external dependencies such as Digester and Commons Resources could get into the before mentioned i18n-contrib.jar...? Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
At 2005-04-20 23:05, you wrote: There were server errors earlier today. Did you ever get this to run? Nope. Tried Maven + Emma too, without luck. It either produced coverage data OR an empty report; never used the data to create a report. I should probably read up on how Maven works (or simply add Emma to Ant), but I would prefer to spend my time on the code rather than the setup. Mattias Jiderhamn At 2005-04-20 09:47, Mattias J wrote: B.t.w James: Thought I'd run your new Maven config to see the coverage of the tests I've added. Though I have not checked out .../commons-build/sandbox-project.xml and currently I cannot access the SVN server. Sorry if this is because I'm a newbie with Maven, but I am not able to get this to work. I have downloaded the commons-build SVN-files and can build and test with Maven. But if i run "maven jcoverage" all the tests fail, most with java.lang.NoClassDefFoundError, assumably because either the instrumented classes or some jcoverage libraries are not on the classpath. What do I need to do to my environment to get this working? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
At 2005-04-20 09:47, Mattias J wrote: B.t.w James: Thought I'd run your new Maven config to see the coverage of the tests I've added. Though I have not checked out .../commons-build/sandbox-project.xml and currently I cannot access the SVN server. Sorry if this is because I'm a newbie with Maven, but I am not able to get this to work. I have downloaded the commons-build SVN-files and can build and test with Maven. But if i run "maven jcoverage" all the tests fail, most with java.lang.NoClassDefFoundError, assumably because either the instrumented classes or some jcoverage libraries are not on the classpath. What do I need to do to my environment to get this working? Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [i18n] Entry qualifier
At 2005-04-20 12:06, you wrote: > Shall we add an i18n-contrib.jar that contains all the > optional extensions? I'd like to keep the core i18n.jar as > small as possible... Then you'll need some definition for this. IMHO MBeanInfoDescriptionBundle is as light as the rest without any deps and this does normally qualify an inclusion into the core. I agree. Current jar is only 16k. Even twice the size should be small enough for most people. Another beast is the proposed DatabaseMessageProvider of Mattias. If it uses external deps it is qualified for a separate contrib package ... but just my 2c. I intend to avoid external dependencies by using pure java.sql.* with the option of javax.sql.DataSource. Though the test cases will certainly have other dependencies. Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
At 2005-04-20 09:23, you wrote: > Seems like i18n is reinventing the wheel over and over. I see we are using > of Sax, when Digester is the most viable choice, given the typical clients > of this framework. I see where ResourceBundle is used, yet a much more > robust solution is already provided through Commons Resources. Any chance > we can change this to use the above frameworks? My primary goal was to keep this component simple. It has no dependencies to other jars and that is a big plug for the daily use. +1 Even though I am quite fond of Digester, I also see the benefits of zero runtime dependencies. I suggest sticking with pure SAX. I know that we have some overlapping with Commons Resources, but the I18n is dealing with bundles of messages and introduces LocalizedExceptions using these bundles. The way i18n bundles several "submessages" under a common key is what makes it so great. I hope to be able to add a DatabaseMessageProvider, which gets different messages (title, details etc) from different columns in the database table. Hopefully the benefits will be even more clear then. B.t.w James: Thought I'd run your new Maven config to see the coverage of the tests I've added. Though I have not checked out ../commons-build/sandbox-project.xml and currently I cannot access the SVN server. Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
I have now added more tests to ResourceBundleMessageProviderTest. If I find time tomorrow, I might look at adding coverage or more XMLMessageProvider tests. Though I do not have commit access to SVN, so I assume I cannot get hold of the Clover license. Daniel: Since you are not home until next week, I will continue work and then mail you what I've got. Mattias Jiderhamn At 2005-04-19 15:22, Mattias J wrote: What I currently need is better unit tests in ResourceBundleMessageProviderTest.java and XMLMessageProviderTest.java. After those are set up, I will begin some refactoring. If you would like to help out on those unit tests it would be great. Please inform me if you get your hands at it, and which one you start with, so I don't do the same thing. Also please e-mail them to me if you are done before Daniel is back and able to check it in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Code coverage
At 2005-04-19 15:22, you wrote: Please, sorry by my ignorance but, what is "unit test code coverage"?? This is different than the traditional unit test? Those are not separate tests, but tools that help you see how much of your code that is actually tested by your unit tests. Testing is pretty useless, if they are not testing what needs to be tested. Google for any of the tools I mentioned for more info. Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
What I currently need is better unit tests in ResourceBundleMessageProviderTest.java and XMLMessageProviderTest.java. After those are set up, I will begin some refactoring. If you would like to help out on those unit tests it would be great. Please inform me if you get your hands at it, and which one you start with, so I don't do the same thing. Also please e-mail them to me if you are done before Daniel is back and able to check it in. At 2005-04-19 15:13, you wrote: If I can help ... I still alive Woody '>'-- Mensagem Original -- '>'Reply-To: "Jakarta Commons Developers List" '>'Date: Tue, 19 Apr 2005 13:34:41 +0200 '>'From: "Daniel Florey" <[EMAIL PROTECTED]> '>'To: "Jakarta Commons Developers List" '>'Subject: Re: [i18n] Entry qualifier '>' '>'> I have created unit tests for MessageManager and '>'> LocalizedBundle/-Error/-Exception/-RuntimeException. '>'> Should I post them to the list? '>'> Would you like them in a ZIP archive Daniel? '>' '>'I'm back home next week, so if you would pass them to me in a ZIP this would '>'be the easiest way yo go. '>'Thanks '>'Daniel '>' '>'> '>'>Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
At 2005-04-19 10:35, Daniel Florey wrote: We should keep both (ant/maven) working. There is a maven task that will automatically generate an ant script, but I've never used it. Maven is a great tool as it can also handle website generation, test reports, changelog etc. So it's worth to have a look at it! I probably should, some day, but right now I want to focus on the tests and changes so I'll stick with Ant meanwhile. > What indentation do you use for XML? I find both tabs and 2 spaces, even in > the same file. (There is also a tab on line 80 in LocalizedBundle.java) Uuups, this should be fixed. What do you prefer for indenting xml files? I prefer spaces. Personally I use 2 spaces to save up on columns/width. Keep on your great work, I look forward to incorporate your changes. I have created unit tests for MessageManager and LocalizedBundle/-Error/-Exception/-RuntimeException. Should I post them to the list? Would you like them in a ZIP archive Daniel? Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Code coverage
Is there an Apache standard for unit test code coverage? It seems some projects use Clover and others jcoverage. Personally I have experience with Emma (http://emma.sourceforge.net/). If I want to add code coverage to a Commons project, is either of these preferrable? Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
Will Ant be abandoned in favor of Maven or should I update the Ant script
to include the unit tests? (I have no experience with Maven)
What indentation do you use for XML? I find both tabs and 2 spaces, even in
the same file. (There is also a tab on line 80 in LocalizedBundle.java)
I have set up the environment and started working on some unit tests. I
think one of them caught a bug in MessageHandler. My guess is
try {
String text = getText(id, entry, arguments, locale);
return MessageFormat.format(text, arguments);
} catch (MessageNotFoundException e) {
return defaultText;
}
should read
try {
return getText(id, entry, arguments, locale);
} catch (MessageNotFoundException e) {
return MessageFormat.format(defaultText, arguments);
}
right?
(B.t.w. is there a tutorial on creating SVN patches somewhere?)
Mattias Jiderhamn
At 2005-04-18 13:24, Daniel Florey wrote:
"Jakarta Commons Developers List" schrieb
am 18.04.05 11:29:38:
>
> At 2005-04-18 11:11, Daniel Florey wrote:
> > > My though was to re-use the basename or id used when "installing"
> > > ResourceBundle or XML providers. For example, after issuing
> > >ResourceBundleMessageProvider.install("errorMessages");
> > > I would like to be able to qualify the newly installed messages with
> > >MessageBundle msg = new MessageBundle("errorMessages",
> > "unexpectedError");
> > > but also keep the existing alternative with
> > >MessageBundle msg = new MessageBundle("unexpectedError"); //
> > > "unexpectedError" from any source
> >
> >Do you want this to be able to install different resources with the same
> >message key or is it mainly because of implementation details
(performance)?
>
> Primarily multiple entries with same key, secondarily performance.
>
> > > This may seem like a minor change at a first glance, but to also
improve
> > > performance my thought was to to change the MessageManager class from
> > > holding a list of provider instances - which in turn can contain
multiple
> > > resources (and thus assumes one instance per provider class) - to
> > holding a
> > > Map from basename/id/namespace/qualifier to provider instance,
where each
> > > instance only contains a single resource (i.e.
XML-file/ResourceBundle).
> > > Though I planned on backwards compatibilty, by looping over the Map
values
> > > - instead of the List entries - in the current
MessageManager.getText()
> > method.
> > > (Did I make myself clear?)
> >
> >I try my best to get your point...
> >At the moment there is only one MessageProvider holding many resources.
> >You want to change this to many MessageProviders holding one resource
each
> >in order to improve performance?
>
> Yes. Instead of having to loop through the providers - catching exceptions
> from those who do not contain the entry, which is quite costly performance
> wise - and get the first match, I want to be able to point out the source
> which I expect to hold the entry. But then again, todays behaviour should
> be kept as the default behaviour when not using a basename/namespace
> qualification.
>
> >I currently don't have access to the sources as I'm on a project in Jordan
>
> (You can browse them online,
> http://jakarta.apache.org/commons/sandbox/i18n/xref/index.html is quite
> easy to navigate)
>
> >but as soon as I'm back home I'll try to have a closer look at this.
>
> Should I try to create a patch suggestion which you could look at then?
Yes, this would be great!
It would be very (very) appreciated, if you could provide some
testcases... I started to write some a while ago, but never managed to
complete them. If we would have a complete testsuite we could refactor
without the fear to break something ;-)
If we get the testsuite done and improve the documentation, we hopefully
can move the component to commons proper soon...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Entry qualifier
At 2005-04-18 11:11, Daniel Florey wrote:
> My though was to re-use the basename or id used when "installing"
> ResourceBundle or XML providers. For example, after issuing
>ResourceBundleMessageProvider.install("errorMessages");
> I would like to be able to qualify the newly installed messages with
>MessageBundle msg = new MessageBundle("errorMessages",
"unexpectedError");
> but also keep the existing alternative with
>MessageBundle msg = new MessageBundle("unexpectedError"); //
> "unexpectedError" from any source
Do you want this to be able to install different resources with the same
message key or is it mainly because of implementation details (performance)?
Primarily multiple entries with same key, secondarily performance.
> This may seem like a minor change at a first glance, but to also improve
> performance my thought was to to change the MessageManager class from
> holding a list of provider instances - which in turn can contain multiple
> resources (and thus assumes one instance per provider class) - to
holding a
> Map from basename/id/namespace/qualifier to provider instance, where each
> instance only contains a single resource (i.e. XML-file/ResourceBundle).
> Though I planned on backwards compatibilty, by looping over the Map values
> - instead of the List entries - in the current MessageManager.getText()
method.
> (Did I make myself clear?)
I try my best to get your point...
At the moment there is only one MessageProvider holding many resources.
You want to change this to many MessageProviders holding one resource each
in order to improve performance?
Yes. Instead of having to loop through the providers - catching exceptions
from those who do not contain the entry, which is quite costly performance
wise - and get the first match, I want to be able to point out the source
which I expect to hold the entry. But then again, todays behaviour should
be kept as the default behaviour when not using a basename/namespace
qualification.
I currently don't have access to the sources as I'm on a project in Jordan
(You can browse them online,
http://jakarta.apache.org/commons/sandbox/i18n/xref/index.html is quite
easy to navigate)
but as soon as I'm back home I'll try to have a closer look at this.
Should I try to create a patch suggestion which you could look at then?
Always keep in mind that it should be very simple to use the component.
Sure. As I said, I intend to be backwards compatible with currenty usage.
Though possibly the installation of resources may look slightly different.
Do you have sandbox commit access?
Nope.
Mattias Jiderhamn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Entry qualifier (was Re: Status?)
At 2005-04-18 10:33, Daniel Florey wrote:
> i18n is appealing to me because it allows for multiple properties (such as
> title and details) under a common key. We solve very similar problems in
> our project, but I would like to use a generic API reusable among several
> projects. Although I see some changes I would like to make ti i18n. For
> example, I'd like the ability to qualify the entry with a source (i.e.
base
> name). This requires some other changes of the internal structure.
Do you want to introduce something like a namespace for message keys? I've
been thinking of something comparable in the past but dropped it as it
would introduce addintional complexity.
You can add namespaces by prefixing the message-keys.
My though was to re-use the basename or id used when "installing"
ResourceBundle or XML providers. For example, after issuing
ResourceBundleMessageProvider.install("errorMessages");
I would like to be able to qualify the newly installed messages with
MessageBundle msg = new MessageBundle("errorMessages", "unexpectedError");
but also keep the existing alternative with
MessageBundle msg = new MessageBundle("unexpectedError"); //
"unexpectedError" from any source
This may seem like a minor change at a first glance, but to also improve
performance my thought was to to change the MessageManager class from
holding a list of provider instances - which in turn can contain multiple
resources (and thus assumes one instance per provider class) - to holding a
Map from basename/id/namespace/qualifier to provider instance, where each
instance only contains a single resource (i.e. XML-file/ResourceBundle).
Though I planned on backwards compatibilty, by looping over the Map values
- instead of the List entries - in the current MessageManager.getText() method.
(Did I make myself clear?)
I'm also considering adding a DatabaseMessageProvider as a starting point
for database resouces (which is what I will be using primarily).
Mattias Jiderhamn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[i18n] Status?
The i18n sandbox project seems to be quite similar to Commons Resources. What is the relationship between the two? Will they continue to co-exist? i18n is appealing to me because it allows for multiple properties (such as title and details) under a common key. We solve very similar problems in our project, but I would like to use a generic API reusable among several projects. Although I see some changes I would like to make ti i18n. For example, I'd like the ability to qualify the entry with a source (i.e. base name). This requires some other changes of the internal structure. Is somebody actively working on this project, or can I try some refactoring and additions and contribute suggestions? Thanks in advance, Mattias Jiderhamn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
