I just found out about Speedment, a Java 8 Stream-based OR/M library, and have to say that I love the idea of it. No more crazy configurations or spending time sifting through 900 pages of Hibernation docs to find the right way to annotate my classes: Speedment just reads your database, generates Java classes for you and gives you a stream-based API to run DDL statements against them. Wicked cool.
However, the one big deal breaker is that it seems like you have to use the Speedment UI for configuring your DB connection. Furthermore, the docs don't seem to specify how you can do things like:
Specify which tables you want code generated against (maybe there's a few tables inside a database that you don't want models generated for
Execute stored procedures
Configure in-memory caches
etc. Looking on GitHub I can't seem to find how the code is wired together from the UI to produce a configuration object. Just wondering if there's a way to configure Speedment sans UI (perhaps via JSON or YAML), and if so, what configurations are available.
It is possible to configure Speedment without the UI, but it requires some tinkering. Basically, to generate code from a database, you need to manually create a speedment.json-file and specify which schema to generate from manually.
Create a new Maven Project (a pom.xml-file and a src/main/java-directory).
Create a file /src/main/json/speedment.json
Enter the following:
{
"config" : {
"name" : "yourproject",
"packageName" : "com.yourcompany",
"packageLocation" : "src/main/java/",
"dbmses" : [{
"name" : "db0",
"typeName" : "MySQL",
"ipAddress" : "127.0.0.1",
"port" : 3306,
"schemas" : [{
"name" : "your_db_schema"
}]
}]
}
}
Run the Maven goal: mvn speedment:reload -Ddbms.username=root -Dbms.password=password (with the credentials for your database)
Finally, run the Maven goal: mvn speedment:generate
The first goal connects to the database and fills in any missing configuration details in the .json file. The second goal generates .java-code.
To disable a specific table, set the json-property "enabled" to false. Youc an also disable individual columns this way.
If you want, you can now configure the generation directly in the .json-file and then regenerate.
Related
I am trying to write a script that launches an app if not running or activates the window if already visible in the current activity.
Using xdotool or wmctrl I am able to get the list of windows and activate them. If they are not open, then I can launch them. But the problem comes with KDE Activities. These tools list windows from all the activities even if they are not visible in current activity.
I am going through various qdbus methods but not finding anything close.
have anyone created such scripts? how one could get the windows visibility with respect to the activities?
Edits:
as shown in the picture below , I was able to see the activity IDs that the window is attached to. But I am not able to find any way to get it programmatically.
An alternative aproach was given in kde forum. But it is not completely clear if it can help solve your issue.
The recommendation is as follows:
On the activity level you can make use of URI > Activity relations and
query dbus for further scripting. For example:
Link a directory to an activity in dolphin.
Add an application "dolphin-directive" to application launcher and make it run a custom script to conditionally start dolphin instances.
Set "dolphin-directive" as default filemanager
A similar workflow is possible for each filetype via File Association
Settings
As far as I could figure out through experiments it is not possible to link windows to activities and query relations via ActivityManager. I guess the multiple-screen-workspace-uri-activity-window-rule architecture is supposed to setup workflows to solve the problem in a more holistic manner. But hopefully someone can give a better answer here.
I wrote a script to regex inspect the whole session bus tree for related and usefull methods. You can simply use it by ./query-dbus.py --pattern "^.*activit.*$". So the answer is work in progress.
EDIT: some services do have the method isMonitorActivity, isOnActivity
"org.kde.konsole": {
"/Sessions/1": {
"org.kde.konsole.Session": {
"method": [
"setMonitorActivity",
"isMonitorActivity"
]
}
}
}
"org.kde.kate": {
"/MainApplication": {
"org.kde.Kate.Application": {
"method": [
"isOnActivity"
]
}
}
}
}
Did you already file a feature request?
Currently, we are able to use #Property(unbounded=PropertyUnbounded.ARRAY) to create a property in OSGi Configuration with Multiple-Values.
Is it possible to create a property in OSGi Configuration that behaves same as that of multifield functionality of AEM authoring dialogs? On click of Add button, the property field with all its-sub fields gets increased. So that we can add multiple entries of key/value pair.
[
{
"path":"/content/demo/page1",
"date":"20-12-2018",
"language":"english"
},
{
"path":"/content/demo/page2",
"date":"23-10-2019",
"language":"french"
}
]
The same key/value pair to be configured using OSGi Configuration and fetched as required.
The felix console allows you to add multi-value properties. however, they are typically a single field value. Meaning, you cannot create the complex data structure in your question. However, I have seen implementations that allowed you to enter an ordered CSV. For example, you could have a multivalued String OSGI property where each property is of the format:
<path>,<date>,<language>
your first entry then becomes:
/content/demo/page1,20-12-2018,english
Or, you could even enter the whole JSON as a string value, then parse it when you need it. But that becomes ugly to enter very quickly.
You can use the above with any serializable data structure, but the more complex it gets, the harder it is to enter in a single input field.
Another option would be to create a page with a component that has a multifield and just point your OSGI config to the path of that page/component, then in your OSGI service, lookup that path and extract the configuration.
I'm making good progress on creating a generic javascript to build a task list/tree that ultimately be run on a wiki. The challenge is that I would like to have multiple instances of this script running pointing the various subprojects that are layered under different projects in a workspace. Is there a way to pass the context parameters (Parent Project,Project, Iteration, Release etc.) via the Rally.launchapp/bootstrap? That way there is a quick common spot to tune this via the wiki markup. Thanks! Mark
Rally.launchApp('CustomApp', {
name: "RallyGrid",
parentRepos: " "
});
});enter code here
I would like perform some size optimization on generated files by qooxdoo. 800Ko is quite huge... For information, it is based on a desktop approach.
I'm using this configuration :
"OPTIMIZE" : ["basecalls", "comments", "privates", "strings", "variables", "variants", "whitespace"]
Without success...
Any idea ?
Client optimisation
It's the easy way. Set up gzip compression in your web-server. It'll make your build ~ 200-300 kB. You can even pre-compress your build and serve app.js.gz directly.
Then set up your web-server cache. On way is to configure reasonable cache expiration time, e.g. a week or a month. For more aggressive caching, expiration is set to forever (years) and your build URL looks like /static/app.js?v=123. You can use simple incrementing number, VCS revision or file hash.
Partial build
Harder but more flexible way is to use parts and combine it with client optimisation described above. This way you can build your application in the way that it loads its components on-demand and won't require loading everything upfront. This however requires changing your application, making in more modular and less coupled, which is generally something good though.
In your config.json you need to define parts, the components of your application that usually correspond to different functionality. I usually extent common job like this:
"common" :
{
"packages" :
{
"sizes" :
{
"min-package" : 64,
"min-package-unshared" : 16
},
"additional-merge-constraints" : true,
"parts" :
{
"boot" :
{
"include" : ["${QXTHEME}", "${APPLICATION}.Application"]
},
"functionality1" :
{
"include" : ["${APPLICATION}.controller.Functionality1"]
},
"functionality2" :
{
"include" : ["${APPLICATION}.controller.Functionality2"]
},
...
}
}
}
Boot part here contains minimal Qooxdoo dependencies required for bootstrapping the application. Note that unlikely your boot part will be less than 500 kB (uncompressed).
Then when you want to use some functionality you do:
qx.io.PartLoader.require(['functionality1'], function()
{
new (qx.Class.getByName('app.controller.Functionality1')).doSomething();
}, this);
Note that the part loader resolves dependencies for you, as part functionality1 may have its dependencies. In fact, partial build with 3 defined parts above may lead to less or more than 3 files in result. The generator uses sophisticated dependency management so it can split and collapse parts if it benefits the load performance.
The optimization config you are using is the default one. So you should already get an optimized build, when you run ./generate.py build. Look into build/script/{myNamespace}.js. The first part of the script (the managing or loading code so to speak) isn't optimized, but the framework code and your app code is optimized (one long line at the end, which is minified etc.).
The manual has more details:
How to configure the optimizations?
Which optimization does what?
Does anybody know what if direct update updates everything that lives in the common directory structure. I used the same code base for multiple apps, the only change being certain settings within a js file that tells the application how to act. Is there a directory i can put that js file that would be safe from the direct update feature?
I cant seen to find any specific information on IBM's website.
I think you guys need to be careful which terms you are using in order to not confuse people who may be looking for similar help.
Environments are specific to the OS you are using. iOS, Blackberry, Android, and etc. environments.
Skins are based on the environment, and aren't generic to all platform. When you create a skin you must choose which environment you are running in.
So to correct some, direct updates will update all skin resources in targeted environments.
For example: You have an app with Android and iOS versions
When you create skins, you are creating essentially a responsive type of design to your parameters. For instance, if you have a 2.3 vs 4.2 Android OS, you can set a look and feel for both. However, these utilize a single web resource base. The APK would be the same for both versions of the app (by default) and have 2 available skins. On runtime utilizing IBM Worklight's 'Runtime Skinning' (hence the name) it goes through the parameter check for the OS and loads that skins overriding web code.
You could technically override all of the web code to be completely different for both skins, but that would be bulky and inefficient.
When you direct update you are updating all the resources of that particular environment (to include both skins), not the common folder/environment.
So an updated Android (both skins) would have updated web resources (if you deployed the android wlapp) and an iOS version would stay the same.
If you look at the Android project after build (native -> assets -> www -> default or skin) you can find the shared web resources generated by the common environment. However that is only put there every time you do a new build.
In the picture, I have an older version of the Android built for both skins on the left. On the right is a preview of the newer common resources after deploying only the common.wlapp. So you can see that they are separate.
Sorry if it was long winded, but I thought I would be thorough.
To answer the original question, have you thought of having all the parameters of the store loaded from user input or a setup? If you are trying to connect to 3 different store, create some form for settings control that will access different back ends or specific adapters. You could also create 3 different config.js that load depending on the parameters that you set so that you set. The other option is to set different versions of your apps specific to the store.
Example. Version 1.11, 1.12,1.13 can be 3 versions of the same app for store 1, 2, & 3. They can be modified and change and have 3 sets of web resources. When you need to update, jump up to version 1.21, 1.22,1.23. It seems a bit of a work around, but it may be your best bet at getting 3 versions of the same app to fall within the single application category. (keep 3 config.js types for modifying for the 3 stores).
To the best of my knowledge Direct Update will update every web resource of the skin you're using (html, css, js). However, I'm no expert with it.
If you're supporting only Android and iOS applications and need a way to store settings I recommend JSONStore. Otherwise look into Cordova Storage, Local Storage or IndexedDB.
Using a JSONStore collection called settings will allow you to store data on disk inside the app's directory. It will persist until you call one of the removal methods like destroy or until the application is uninstalled. There are also ways of linking collections to Worklight Adapters to pull/push data from/to a server. The links below will provide further details.
the only change being certain settings within a js
Create a collection for your settings:
var options = {};
options.onSuccess = function () {
//... what to do after init finished
};
options.onFailure = function () {
//... what to do if init fails
}
var settings = WL.JSONStore.initCollection('settings',
{background: 'string', itemsPerPage: 'number'}, options);
You can add new settings after initCollection onSuccess has been called:
settings.add({background: 'red', itemsPerPage: 20}, options);
You can find settings stored after initCollection onSuccess has been called:
settings.findAll({onSuccess: function (results) {
console.log(JSON.stringify(results));
}});
You can read more about JSONStore in the Getting Started Modules. See Modules: 7.9, 7.10, 7.11, 7.12. There is further information inside the API Documentation in IBM InfoCenter. The methods described above are: initCollection, add and findAll.
Since version 5.0.3 I think, direct update will not update all the webresources, only those of the skin you are using.
say you have skin def and skin skin2
you are on def
make change to def on the server -> you will get a direct update for
def only
make change to skin2 on server-> no direct update for you.
you are on skin2:
make change to skin2 on server -> direct update for skin2 only
make change to def javascript which also resides on skin2 ( and therefor end result is def+skin2 concatination), update only skin2
make change to def,just to a picture(also checking pic extension from application-descriptor: ") -> no direct update
Thats how direct update works.
Please also share some more details about what is the problem, I see you use a js file, where do you change it? what do you mean excatly, give a better (simplified) real life example, because it is unclear what you are trying.