We are working on an XMPP external component provided by Tinder/Whack and want to preserve the case. For example, if the JID is Bob#myhost.com, we do not want to translate as bob#myhost.com. We see the jids coming across to the external component as Bob#myhost.com, but by the time they reach our specific code, they get folded to bob#myhost.com. We need to preserve the case.
What is the best way of preserving the case of the JID?
The "localpart" of a JID is currently defined in RFC 6122, section 2.3, which refers to Appendix A, which says:
A.3. Mapping
This profile specifies mapping using the following tables from STRINGPREP:
Table B.1
Table B.2
Note that Table B.2 of STRINGPREP is ugly, hard-coded case folding. So no, you can't turn off case folding for comparison of JIDs, and many servers and libraries will modify JIDs that they process to avoid having to perform costly normalization multiple times.
If you would like for this to change, we're working on a new string comparison framework in the précis working group at the IETF, and welcome input - but backward compatibility requirements will make yours a difficult position to argue.
Related
I am working with several external APIs on a business code that would be used by several developers that do not have the deep knowledge required to build meaningful queries to those APIs.
Those API retrieve data. For example, you can retrieve entities either based on their Key (direct access) or based on their Group (lists available entities). But if you choose to query by Key you have to provide an id, and if you query by Group you have to provide a groupName.
The APIs are bigger than that and more complex, with many possible use-cases. The main constraints are that:
Some parameters require the presence of other parameters
Some parameters put with other parameters produce no data at best, wrong data at worst.
I would love to fix the underlying APIs but they are outside our scope.
I think it might be good to enclose a bit those API and produced a APIService that can request(APIQuery query).
The basic thing I could do is to put conditions in the code to check that no developer instantiates the APIQuery with missing/incoherent parameters, however that would only be a runtime error. I would love for the developer to know when building their request that they can/cannot do something.
My two questions are:
Is there an extensible builder-like way to defer the responsibility of building itself to the object? Having 1 constructor per valid query is not a good solution, as there are many variables and "unspoken rules" here.
Is this even a good idea? Am I trying to over-engineer?
I'll answer your second question first:
Is this even a good idea? Am I trying to over-engineer?
The answer is an uncomfortable "it depends". It depends how bad the pain is, it depends how crucial it is to get this right. It depends on so many factors that we can't really tell.
And to your: is this possible?
Yes, a builder pattern can be extended to return specific builders when certain methods are called, but this can become complicated and mis-uses are possible.
For your specific example I'd make the QueryBuilder simply have two methods:
a byGroup method that takes a group value to filter on and returns a GroupQueryBuilder
a bykey method that takes a key value to filter on and returns a KeyQueryBuilder.
Those two classes can then have methods that are distinct to their respective queries and possibly extend a shared base class that provides common properties.
And their respective build methods could either return a APIQuery or distinct APIQueryByGroup/APIQueryByKey classes, whichever is more useful for you.
This can become way more complicated if you have multiple axis upon which queries can differ and at a certain point, it'll become very hard to map that onto types.
We have a rather large application, with a great deal of dynamic content. Is there anyway to force struts to use a database for the i18n lookups, instead of properties files?
I'd be open for other ways to solve this as well, if anyone has ever done i18n with dynamic content.
I don't know of an easy plug-and-play solution for this, so you will probably have to implement it yourself -- plan on spending quite a bit of time just coming to grips with how the localization features of struts 2 (and XWork) are implemented. The key will probably be to provide your own implementation of com.opensymphony.xwork2.TextProvider (and tell struts to use it by providing a <bean> tag in struts.xml). I can think of at least two ways of fitting this into the overall architecture:
Have your TextProvider implementation access the database directly. In the spirit of YAGNI, this is probably the best way to start (you can always refactor later, if necessary).
Alternatively, you could place the database code into an implementation of Java's ResourceBundle interface, which is what XWork uses internally. To me this sounds like an even more design-heavy approach, but on the plus side there are some articles around describing how to do this.
No, there is no built-in way to have Struts2 load localized content from a database. You would need to write that yourself.
What are your requirements? Do you need for users to be able to dynamically change field prompts, error messages, etc.?
You may be able to do something like that by building a custom interceptor. You could have the interceptor read all the key value pairs from your database and inject them into the value stack. The only thing I am not sure about, not really having messed with i18n with struts before, is if the i18n stuff pulls that information from the value stack. If not, I am not sure if maybe you could do something else in the interceptor to load up the information.
Building a custom interceptor is not too terribly complicated. There are plenty of tutorial sites out there, including (brace for self promotion here) my blog: http://ddubbya.blogspot.com/2011/01/creating-custom-struts2-interceptors.html.
Use properties files just for static content, like labels, messages etc.
For dynamic content start with a database table that includes a language-code-id for every language you want to use. All the dynamic content entries that are already translated go with their respective language-code-id added to their primary key. If a translation is missing, you can program your application to fall back to your default language in order to make things easier until the right translation is present.
Let your users provide their contributions in the language they like and store it with the appropriate language-id. Someone should provide the translation to the other languages in order to make the contribution complete.
...
PRIMARY KEY (`subject_id`,`language_id`),
...
We're setting up a Solr to index documents where title field can be in various languages. After googling I found two options:
Define different schema fields for
every language i.e. title_en,
title_fr,... applying different
filters to each language then query
one of title fields with a
corresponding language.
Creating
different Solr cores to handle each
language and make our app query
correct Solr core.
Which one is better? What are the ups and downs?
Thanks
There's also a third alternative where you use a common set of fields for all languages but apply a filter to a field language. For instance if you have the fields text, language you can put text contents for all languages in to the text field and use e.g., fq=language:english to only retrieve english documents.
The downside of this approach is that you cannot use language specific features such as lemmatisation, stemming, etc.
Define different schema fields for every language i.e. title_en, title_fr,... applying different filters to each language then query one of title fields with a corresponding language.
This approach gives good flexibility, but beware of high memory consumption and complexity when many languages are present. This can be mitigated using multiple solr servers.
Creating different Solr cores to handle each language and make our app query correct Solr core.
Definately a nice solution. But whether the separate administration and slight overhead will work for you is probably in relation to the number of languages you wish to use.
Unless the first approach is applicable, I would probably lean towards the second one unless the scalability of cores isn't desired. Either approach is fine though and I think it basicaly comes down to preference.
It all depends on your requirements. I am assuming you dont need to query multiple languages in a single query. In that case splitting them into multiple cores would be a better idea since you can tweak around that core without affecting the other cores & index. With multiple languages there will be some tweaking or the other involved due to stemming, spell check & other features (if you plan to use them).
There is also an option of multiple solr webapps within a servlet container. So that could be an option you can look at.
It all depends on the flexibility that you had with regards to downtime that you could take to fix any issues.
If you use multiple cores and you need sharding, one of the issue I can see is:
you will need to do sharding on each language (core). You won't be able to do sharding on the whole index at once.
If you use a single core, maybe you lose space with text columns that are "not full", not sure about that.
We have a rather large application, with a great deal of dynamic content. Is there anyway to force struts to use a database for the i18n lookups, instead of properties files?
I'd be open for other ways to solve this as well, if anyone has ever done i18n with dynamic content.
I don't know of an easy plug-and-play solution for this, so you will probably have to implement it yourself -- plan on spending quite a bit of time just coming to grips with how the localization features of struts 2 (and XWork) are implemented. The key will probably be to provide your own implementation of com.opensymphony.xwork2.TextProvider (and tell struts to use it by providing a <bean> tag in struts.xml). I can think of at least two ways of fitting this into the overall architecture:
Have your TextProvider implementation access the database directly. In the spirit of YAGNI, this is probably the best way to start (you can always refactor later, if necessary).
Alternatively, you could place the database code into an implementation of Java's ResourceBundle interface, which is what XWork uses internally. To me this sounds like an even more design-heavy approach, but on the plus side there are some articles around describing how to do this.
No, there is no built-in way to have Struts2 load localized content from a database. You would need to write that yourself.
What are your requirements? Do you need for users to be able to dynamically change field prompts, error messages, etc.?
You may be able to do something like that by building a custom interceptor. You could have the interceptor read all the key value pairs from your database and inject them into the value stack. The only thing I am not sure about, not really having messed with i18n with struts before, is if the i18n stuff pulls that information from the value stack. If not, I am not sure if maybe you could do something else in the interceptor to load up the information.
Building a custom interceptor is not too terribly complicated. There are plenty of tutorial sites out there, including (brace for self promotion here) my blog: http://ddubbya.blogspot.com/2011/01/creating-custom-struts2-interceptors.html.
Use properties files just for static content, like labels, messages etc.
For dynamic content start with a database table that includes a language-code-id for every language you want to use. All the dynamic content entries that are already translated go with their respective language-code-id added to their primary key. If a translation is missing, you can program your application to fall back to your default language in order to make things easier until the right translation is present.
Let your users provide their contributions in the language they like and store it with the appropriate language-id. Someone should provide the translation to the other languages in order to make the contribution complete.
...
PRIMARY KEY (`subject_id`,`language_id`),
...
I would like to achieve the following in a configurable manner (that is little or no code modification in order to change behavior) :
Problem Statement :
a) For each part there are a set of key value pairs that can vary
b) The key is a static string label and the value can be one of (text, single select list of values)
c) The system should present an UI to allow entry/modification of values and allow modification(in well defined ways) to the set of key-value pairs allowed for a part
d) The values must be validatable before entry into the database
Constraints :
java(1.4), struts, hibernate, oracle
Are there any open source java based frameworks that can be integrated that could go towards satisfying the problem statement?
I thought that this kind of problem would have been solved but when I research on the web I am not finding any hits - maybe my query is not being properly targeted.
thanks
What I was looking for was a big picture framework that would also solve this mini-problem along the way. Then it might have made sense for me to pick up and learn the framework.
Also frameworks are useful because the patterns are well thought out and cover gotchas that I might encounter if I were to invent my own.
Since I didn't find one, here is the database design for my problem for which I have also developed a partially working prototype for all the technically challenging questions. At the end I have listed areas I have not yet covered in my prototype (I am not providing the code here for that) but which I don't think would be all that difficult to implement.
To recap, I have a set of parts each of which is identified by a number and has varying properties associated with it in the form of a label and a value. An example of such might be the set of SNPs (single nucleotide polymprphisms) and the label and value would be characteristics of each SNP.
I want to capture those characteristics in an extensible manner.
Table1 : SNP_TEMPLATE
Field Name
TEMPLATE_SEQID
CATEGORY_LABEL
CATEGORY_VALUE
ATTRIBUTE_LABEL
ATTRIBUTE_VALUE
ATTRIBUTE_TYPE
ATTRIBUTE_TYPE_VAL_LABEL
SEQUENCE
MANDATORY
Table2 : SNP_PERSIST
ATTRIBUTE_SEQID
SNP_SEQID
CATEGORY_LABEL
ATTRIBUTE_LABEL
VALUE