The managed provider uses TCP/IP.

The confusion probably stems from XEP (eXtreme Event Persistence).

XEP for dotNet still has an in-memory and a TCP/IP connection mode.  As Bill indicated we are moving away from the in-memory mode, as we are improving the throughput of the TCP/IP mode. We already deprecated the in-memory connection mode for XEP for Java where the performance is already pretty much the same. The in-memory connection mode has two issues as a) crashes on the client can interfere with the server and b) it does not allow the client to run on a different machine, which is a problem for scaling up.

Personally, I would not go for 4) and 1).

4) Allows invalid data to be entered and a class definition helps you to query users based on user data later on. This approach just limits your options in the future.

1) I don't like this approach just because it does not separate the concerns and it requires privileges.

2) and 3) are both good approaches. 2) Includes a sanity check because of the reference, but you have to be aware of this if you want to move user data between servers in case the users are not in sync.

I guess you are asking for ways to persist user data, but just in case: If you are building a CSP/Zen/Zen Mojo application you can store session data for a user in %session.Data. As soon as a transaction is complete and you want to store it you can go with approach 2) and 3) and persist the relevant data in your own class structure. 

Hi Tim,

$compose works with deep structures but it replaces values of key-value pairs at the top level. It does not merge sub-arrays or sub-objects by default. Consider the following code:

SAMPLES>set o1 = {"a":1,"c":2,"deep":{"f":1,"g":1}}
SAMPLES>set o2 = {"b":1,"c":1,"deep":{"f":3,"j":1}}
SAMPLES>s o3 = o2.$compose({"returnValue":o1})
SAMPLES>w o3.$toJSON()

You can easily spot, that the path "deep" in o3 has the value from o2 and completely misses "deep.g" from o1. We just copied the path "deep" from o2 into o1. We do provide a way  to override this behavior if you want to, but in a future release, we plan to ease this by introducing compose maps. I will cover this topic in more detail in an upcoming post.

Sure. The best way to achieve this is to build your own custom theme using the jQM ThemeRoller application:

Add a swatch with a custom letter (e.g. "f") and define your theme by setting colors, fonts and so on for all elements. When you are done you can download the theme zip file and extract it in the directory where you serve your static files from.

Include your CSS file, instead of the default jQM CSS file and finally just set the defaultTheme of your jQMPageManager to the swatch you designed (e.g. "f") and you are done.

Hi Fabio and Bernd,


is really just a shortcut for 


Both only work on standard control elements, and only *if* the library rendering the widget in question don't add special logic. jQueryMobile implements their own styles and behavior for disabling and enabling elements, therefore, it is the most stable approach to leverage the jQM logic.

A long discussion regarding this topic can be found here:

Let's walk through this in the ZM.jQM145.HomePage.cls demo and disable/enable the main button with the caption "Start demo".

var view = zen('mainView');

var button = view.getItemByKey('start-show');

var id = button.$findElement().id;



Line 1 retrieves the documentView component while line 2 retrieves the button layout object. This is pretty basic. 

In order to run jQM logic we have to find the HTML DOM element we want to disable/enable with the $() method from jQuery. As it requires the physical id that Zen Mojo generated for us we store that in a local variable id in line 3.

Line 4 now looks up the jQM widget and disables it with the supported jQM library call. Line 5 enables the button again.

In the future, we may add support for $disable and these special library calls as we have done for $show and $hide. $show and $hide work on any widget from any supported plugin.