In Spring it is possible to define string values (eg: server names, user names, passwords etc.) in an application context XML file. These can be modified per deployment (eg: testing, production etc). Can I do the same in CDI? If not, what is the accepted pattern for handling the deployment time specification of values?
You would need to create a portable extension to do that, there isn't anything out of the box for it.
Related
we have domain models described in some xml format. Given the domain models I want to generate tooling that helps the testers/domain experts to express data in text (and a domain specific test framework later). IDE support is mandatory (IDEA or eclipse).
say, i have this pseudo model
User
fn string 120 chars mandatory
ln string 120 chars mandatory
address not-mandatory
Address
street mandatory
city mandatory
A typical usage scenario:
user opens the IDE
creates a new file
when content assist invoked, should give options 'user', 'address' etc
If I choose user, furthur ctrl-space should give 'fn', 'ln', 'address' as options.
I know this can be done by xtext or jetbrains mps etc. But, I want to understand which technology lends for the following requirements.
the models are fed to the system at run time (new, updates, deletes etc).
so, I cannot have static set of grammars. How can I structure it so that the model/property assist is resolved at run time or at least the grammar is generated (may be a part of it)
when I am working with one set of 'grammars' , if I point my target server to a different version (which may have different set of models) , I want the editor validate my existing files and flag errors.
I get the data files in xml, text or via server lookups.
It is very important for me to transform the models into some other format or interpret them in java/groovy.
for ex,
I may have the following data file
user {
fn : Tom
ln : Jill
hobby : movies
}
but, when I validate this file against a server which does not know 'hobby' property, I want the editor to mark error on that property.
I have plans to add much more functionality to this dsl/toolkit.
Any hints which technology is more suitable ?
thanks
I know this can be done by xtext or jetbrains mps etc. But, I want to understand which technology lends for the following requirements.
I think Xtext is good for your requirements under the condition that you have (or can create) an XML schema for your XML domain models.
the models are fed to the system at run time (new, updates, deletes etc). so, I cannot have static set of grammars. How can I structure it so that the model/property assist is resolved at run time or at least the grammar is generated (may be a part of it)
If I understand you correctly, you don't really need specific grammar rules for each XML data model but only cross references to the data model.
EMF has support for generating EMF Java classes from XSD files and Xtext can reference XML files conforming to the XSD schema if you add them to the Xtext index using your custom indexer (Xtext interface IDefaultResourceDescriptionStrategy).
So you can create a normal Xtext project with grammar etc. for your DSL and use cross references that refer to your XML domain model.
when I am working with one set of 'grammars' , if I point my target server to a different version (which may have different set of models) , I want the editor validate my existing files and flag errors.
I get the data files in xml, text or via server lookups.
EMF uses URIs to identify resources so if you generate an Ecore model like I described, it should be possible to import the XML domain models using http:// or file:// (or whatever, it's extensible) URIs, or something that you internally resolve to URIs.
It is very important for me to transform the models into some other format or interpret them in java/groovy.
Here you have the choice between making an interpreter, an Xbase inferrer or a generator (each of which can be implemented well using Xtend), depending on your requirements.
(Disclaimer: I am an employee at itemis, which is one of the main contributors to Xtext)
Which table in Liferay stores the predefined values given for a structure.
Also is there a facility in Liferay to populate these values dynamically using webservices?
The API used to be JournalStructureService, however, as the documentation states, this has been replaced with the Dynamic Data Display API, which, for example, you can find under DDMStructureService in version 6.2.
This gives you a hint where to find the underlying data, however, you don't want to manually write to the database. You do want to use the API to change values. Trust me. Consider the database to be an implementation detail and leave it alone - if nothing else to make your next upgrade experience easier. You should never change any values in the database manually without knowing exactly what you're doing. And, trust me, the keyword here is "exactly", and you'll fail to know all the possible side effects. Don't touch it.
As said #Olaf, depends on Liferay version you will need to use the JournalStructureService or the DDMStructureService. So, if you want to use the Liferay Service by web api you have two options the Axis api where you can obtain WSDL (domain:port/api/axis) or you can use the Json api (domain:port/api/axis). In many cases you are going to need a token to use this services.
Does anybody know, if in Liferay is possibility to use default value in ui message ? I mean I have two files .properties with translations, for example: en.properties:
welecome=Hallo everybody
someKey=
,and default.properites
welecome=Hallo everybody
someKey=value of some key
I want to achieve, that if I use:
<liferay-ui:message key="welcome" />
<liferay-ui:message key="someKey" />
with English language (where there is no translation for key 'someKey'), the displayed value will be:
Hallo everybody
value of some key
I mean, when there is no translation for some key, liferay portlet will use value from default properties file.
regards
With the standard naming conventions, you typically have files like Language.properties and Language_en.properties. When english language is displayed, but the entry is not contained in Language_en.properties, I expect the value from Language.properties to be shown.
However, in your case you define someKey as an empty value, which means that it's defined as exactly this.
Moreover, Liferay offers a "Language Builder" tool that you can run during development time (in the plugins-sdk just run ant build-lang. It will create configured language files automatically, automatically copying the values from the original file if they are not yet contained in the translated file.
If you have api credentials for bing, it can also use these to get an automatically translated value for various languages, but I'm not a big fan of these. Actually, I'm quite annoyed by automatic translations.
In terms of strings I understand the need to have strings am going to reuse overname wrapped away somewhere in an XML file or configuration section for strings such as Company Name.
The problem am having with this is where to draw the line on using configuratioh or locally expressed strings?
What decides whether to have the string content wrapped away in a configuration file or to just have the string assigned there and then in a method?
Where am corporate branding a site then yes any corporate aspect strings I will put in a configuration file. Other aspects such as file locations etc will also go in a configuration file.
However, I have found myself discussing with others when I do this as oppose to having an explicit string defined within a method.
Do you have certain criteria that define when to use strings from a configuration section as opposed to being explicitly defined in a method?
Use configuration when you need to be able to change functionality without redeploying/recompiling.
If your string is reused within your application but the functionality involved is not something you want to be configurable, use a constant.
I am new to MFC and I need to build a multi-language application that should be able to change the language at runtime.
AFAIK the common way for internationalization with MFC is to create resource-only DLLs. But there seems to be no simple way (that means, load DLL, call some function, and MFC updates all stuff automatically or something like that) to switch resource-DLLs at runtime, right?
So I will have to update all controls and so on manually. I already managed to load strings from the string-table of a DLL but since captions of controls like buttons are stored in the corresponding dialog (if I trust my resource-hacker :)) I thought there must be a way to load them and avoid storing an additional string in the string-table manually.
Or is there another way I don't know about?
If it makes any difference...I have to use MS embedded visual c++ 4
I work on a large localized MFC project. Here is our strategy:
A dictionary of key -> localized string, specific to each language. There are a few ways to implement this, more later.
Control IDs or captions in the dialog resource are set to the key used to look up the translation
Create a base CDialog, CFormView, etc and in at init call ::EnumChildWindows. In the callback, look up the translation and replace the control's caption with the translation.
For your dictionary, you can go a few ways.
If you want to rely on the built-in localized resource selection and string tables, you have to somehow match the control to the string ID. You can carefully ensure that the control ID matches the string ID, or you can ASCII-encode the ID in the caption and then use atoi to parse the int value.
You can forgo the built-in localized string table deal and maintain your own string -> string dictionary for each language. This lets you set the caption to the non-localized string in the resource which makes layout easier (although you'll still need to test in all languages.) It will require you to do your own "dependency injection" to make sure you load up the right dictionary. You want to be able to release updated/additional languages without rebuilding the core binaries.
If you don't want to require a restart of the application (by far the easiest solution, and the one you should use IMO), you can use resource dll's and recreate the main windows when the user switches languages. That way MFC will recreate the menus etc. in the new language. New dialogs will be displayed in the new language already anyway, from the moment you've switched the resource handle around.
I'm not sure how this relates to the embedded world, my experiences are from the desktop MFC.