Remove "ClientState" parameter from Core API

[jri]

The ClientState parameter is omnipresent in the Core API but rarely used by plugin developers. It bloats the API signatures and render them non-intuitive.

The ClientState parameter should be completely removed from the Core API. Instead ClientState should be injectable to where it is needed.

[Jörg Richter]

Remove ClientState? parameter from Core API (#696).

BREAKING CHANGES

The clientState parameter is completely removed from all APIs.
So, just drop it from all your method calls.

If your plugin needs access to the cookies inject HttpHeaders and construct a Cookies object on it.
Cookies is a new class which is call compatible to the former ClientState (which is dropped).

Example:

import de.deepamehta.core.service.Cookies;

import javax.ws.rs.Path;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;

@Path("...")
public class YourPlugin ... {

    @Context
    private HttpHeaders httpHeaders;

    void someMethod() {
        Cookies cookies = new Cookies(httpHeaders);
        ...
    }
}

Note: injecting the HTTP headers only works in a root resource class, that is a class which has a @Path annotation.

IMPORTANT: the DM standard distro is not yet working, in particular the Workspaces plugin. This is because we can't cheat anymore by passing null as clientState. The Workspace plugin did this to avoid the vicious circle that occurs when an workspace assigment (an Aggregation) gets itself an workspace assignment, which gets itself ...

To solve this situation we aim to solve #341 ("Association Definitions with custom Association Types") first. We will introduce a dedicated association type Workspace Assignment then. This allows the Workspace plugin to skip workspace assignment in case a Workspace Assignment association is detected. A generic Aggregation in contrast can not be distinguished ... ooh, hey, let's wait a minute ... while I'm writing this the solution becomes evident: of course an Aggregation can be recognized as a workspace assignment: by checking the involved players! OK, lets go this way. Lets wait #341 a little.

See #696.

• Changeset: 45ed15548dfa79f3d25b18f7a8d8231d78c7e2ad
• URL: ​https://github.com/jri/deepamehta/commit/45ed15548dfa79f3d25b18f7a8d8231d78c7e2ad

[Jörg Richter]

Adapt plugins to Core changes (#696).

Remove ClientState? parameter from all methods.

See #696.

• Changeset: 43f2c57d7606bce637d4e7829056ca20b53163c4
• URL: ​https://github.com/jri/deepamehta/commit/43f2c57d7606bce637d4e7829056ca20b53163c4

[Jörg Richter]

Remove ClientState?: fix Workspaces plugin (#696).

Remove vicious circle that would occur when assigning a workspace to an workspace assignment (association of type Aggregation).

See #696.

• Changeset: 657f854bfa8fbfe2f315648695fb0827541ae8ba
• URL: ​https://github.com/jri/deepamehta/commit/657f854bfa8fbfe2f315648695fb0827541ae8ba

[Jörg Richter]

Remove ClientState? parameter from Core API (#696).

BREAKING CHANGES

The clientState parameter is completely removed from all APIs.
So, just drop it from all your method calls.

If your plugin needs access to the cookies inject HttpHeaders and construct a Cookies object on it.
Cookies is a new class which is call compatible to the former ClientState (which is dropped).

Example:

import de.deepamehta.core.service.Cookies;

import javax.ws.rs.Path;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;

@Path("...")
public class YourPlugin ... {

    @Context
    private HttpHeaders httpHeaders;

    void someMethod() {
        Cookies cookies = new Cookies(httpHeaders);
        ...
    }
}

Note: injecting the HTTP headers only works in a root resource class, that is a class which has a @Path annotation.

IMPORTANT: the DM standard distro is not yet working, in particular the Workspaces plugin. This is because we can't cheat anymore by passing null as clientState. The Workspace plugin did this to avoid the vicious circle that occurs when an workspace assigment (an Aggregation) gets itself an workspace assignment, which gets itself ...

To solve this situation we aim to solve #341 ("Association Definitions with custom Association Types") first. We will introduce a dedicated association type Workspace Assignment then. This allows the Workspace plugin to skip workspace assignment in case a Workspace Assignment association is detected. A generic Aggregation in contrast can not be distinguished ... ooh, hey, let's wait a minute ... while I'm writing this the solution becomes evident: of course an Aggregation can be recognized as a workspace assignment: by checking the involved players! OK, lets go this way. Lets wait #341 a little.

See #696.

• Changeset: 45ed15548dfa79f3d25b18f7a8d8231d78c7e2ad
• URL: ​https://github.com/jri/deepamehta/commit/45ed15548dfa79f3d25b18f7a8d8231d78c7e2ad

[Jörg Richter]

Adapt plugins to Core changes (#696).

Remove ClientState? parameter from all methods.

See #696.

• Changeset: 43f2c57d7606bce637d4e7829056ca20b53163c4
• URL: ​https://github.com/jri/deepamehta/commit/43f2c57d7606bce637d4e7829056ca20b53163c4

[Jörg Richter]

Remove ClientState?: fix Workspaces plugin (#696).

Remove vicious circle that would occur when assigning a workspace to an workspace assignment (association of type Aggregation).

See #696.

• Changeset: 657f854bfa8fbfe2f315648695fb0827541ae8ba
• URL: ​https://github.com/jri/deepamehta/commit/657f854bfa8fbfe2f315648695fb0827541ae8ba

[Jörg Richter]

Core API: easify cookie access (#696).

BREAKING CHANGE

If your plugin needs access to the current request's cookies just call Cookies.get().
This works in any class.
Internally the Core stores the current request (and thus the cookies) in a thread-local variable.

Example:

import de.deepamehta.core.service.Cookies;

public class YourPlugin ... {

    void someMethod() {
        Cookies cookies = Cookies.get();
        ...
    }
}

This is much more easy than the recently introduced approach (which worked in root resource classes only):

import de.deepamehta.core.service.Cookies;

import javax.ws.rs.Path;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;

@Path("...")
public class YourPlugin ... {

    @Context
    private HttpHeaders httpHeaders;

    void someMethod() {
        Cookies cookies = new Cookies(httpHeaders);
        ...
    }
}

See #696.

• Changeset: 72811f78b5dbc2ad1caa74ba30e7164218cee9ac
• URL: ​https://github.com/jri/deepamehta/commit/72811f78b5dbc2ad1caa74ba30e7164218cee9ac

[Jörg Richter]

Adapt plugins to Core change (cookies) (#696).

Easify cookie access.

See #696.

• Changeset: bf5fe75d24d0f452751203642d855f9697ba29f5
• URL: ​https://github.com/jri/deepamehta/commit/bf5fe75d24d0f452751203642d855f9697ba29f5

[Jörg Richter]

Remove ClientState? parameter from Core API (#696).

BREAKING CHANGES

The clientState parameter is completely removed from all APIs.
So, just drop it from all your method calls.

If your plugin needs access to the cookies inject HttpHeaders and construct a Cookies object on it.
Cookies is a new class which is call compatible to the former ClientState (which is dropped).

Example:

import de.deepamehta.core.service.Cookies;

import javax.ws.rs.Path;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;

@Path("...")
public class YourPlugin ... {

    @Context
    private HttpHeaders httpHeaders;

    void someMethod() {
        Cookies cookies = new Cookies(httpHeaders);
        ...
    }
}

Note: injecting the HTTP headers only works in a root resource class, that is a class which has a @Path annotation.

IMPORTANT: the DM standard distro is not yet working, in particular the Workspaces plugin. This is because we can't cheat anymore by passing null as clientState. The Workspace plugin did this to avoid the vicious circle that occurs when an workspace assigment (an Aggregation) gets itself an workspace assignment, which gets itself ...

To solve this situation we aim to solve #341 ("Association Definitions with custom Association Types") first. We will introduce a dedicated association type Workspace Assignment then. This allows the Workspace plugin to skip workspace assignment in case a Workspace Assignment association is detected. A generic Aggregation in contrast can not be distinguished ... ooh, hey, let's wait a minute ... while I'm writing this the solution becomes evident: of course an Aggregation can be recognized as a workspace assignment: by checking the involved players! OK, lets go this way. Lets wait #341 a little.

See #696.

• Changeset: 45ed15548dfa79f3d25b18f7a8d8231d78c7e2ad
• URL: ​https://github.com/jri/deepamehta/commit/45ed15548dfa79f3d25b18f7a8d8231d78c7e2ad

[Jörg Richter]

Adapt plugins to Core changes (#696).

Remove ClientState? parameter from all methods.

See #696.

• Changeset: 43f2c57d7606bce637d4e7829056ca20b53163c4
• URL: ​https://github.com/jri/deepamehta/commit/43f2c57d7606bce637d4e7829056ca20b53163c4

[Jörg Richter]

Remove ClientState?: fix Workspaces plugin (#696).

Remove vicious circle that would occur when assigning a workspace to an workspace assignment (association of type Aggregation).

See #696.

• Changeset: 657f854bfa8fbfe2f315648695fb0827541ae8ba
• URL: ​https://github.com/jri/deepamehta/commit/657f854bfa8fbfe2f315648695fb0827541ae8ba

[Jörg Richter]

Core API: easify cookie access (#696).

BREAKING CHANGE

If your plugin needs access to the current request's cookies just call Cookies.get().
This works in any class.
Internally the Core stores the current request (and thus the cookies) in a thread-local variable.

Example:

import de.deepamehta.core.service.Cookies;

public class YourPlugin ... {

    void someMethod() {
        Cookies cookies = Cookies.get();
        ...
    }
}

This is much more easy than the recently introduced approach (which worked in root resource classes only):

import de.deepamehta.core.service.Cookies;

import javax.ws.rs.Path;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;

@Path("...")
public class YourPlugin ... {

    @Context
    private HttpHeaders httpHeaders;

    void someMethod() {
        Cookies cookies = new Cookies(httpHeaders);
        ...
    }
}

See #696.

• Changeset: 72811f78b5dbc2ad1caa74ba30e7164218cee9ac
• URL: ​https://github.com/jri/deepamehta/commit/72811f78b5dbc2ad1caa74ba30e7164218cee9ac

[Jörg Richter]

Adapt plugins to Core change (cookies) (#696).

Easify cookie access.

See #696.

• Changeset: bf5fe75d24d0f452751203642d855f9697ba29f5
• URL: ​https://github.com/jri/deepamehta/commit/bf5fe75d24d0f452751203642d855f9697ba29f5

[Jörg Richter]

Core: fix cookie access (#696).

When Cookies.get() is called outside a request scope no exception is thrown. Instead an empty Cookies object is returned.

See #696.

• Changeset: 9ff801e4034e8a4e81ad8601169133dd36ed4e3f
• URL: ​https://github.com/jri/deepamehta/commit/9ff801e4034e8a4e81ad8601169133dd36ed4e3f

[Jörg Richter]

Core: fix cookie access (#696).

When Cookies.get() is called outside a request scope no exception is thrown. Instead an empty Cookies object is returned.

See #696.

• Changeset: 9ff801e4034e8a4e81ad8601169133dd36ed4e3f
• URL: ​https://github.com/jri/deepamehta/commit/9ff801e4034e8a4e81ad8601169133dd36ed4e3f

[Malte]

On a sidenote to changes affecting "ClientState?" (since I remember there was some connection to Workspaces):

• How can plugin developers control to which workspace their objects (topics ro assocs) are assigned when using 'createTopic()' or 'createAssiocation' calls in 4.4?

• By which means can plugin developers currently update an objects workspace assignment (e.g. changing the workspace)?

I am aware that all this might very well change with 4.5 but I want to know how it is 4.4.

Thankful for any explanation.

[jri]

Replying to Malte:

On a sidenote to changes affecting "ClientState?" (since I remember there was some connection to Workspaces):

In DM 4.4 just the access to a ClientState object has changed. The underlying cookie mechanics has not. Also the handling of workspaces has not changed.

• How can plugin developers control to which workspace their objects (topics ro assocs) are assigned when using 'createTopic()' or 'createAssiocation' calls in 4.4?

Just as in DM 4.3 and before: add a dm4_workspace_id cookie to your request.

• By which means can plugin developers currently update an objects workspace assignment (e.g. changing the workspace)?

Workspaces API (not changed in DM 4.4):

void assignToWorkspace(DeepaMehtaObject object, long workspaceId)
void assignTypeToWorkspace(Type type, long workspaceId)

The workspace assignment is added to existing assignments. Workspace is a multi-facet.

At the moment the Workspaces service lacks 2 things:

• removing a workspace assignment. As a workaround you could use the Facets service directly.
• REST API

I am aware that all this might very well change with 4.5 but I want to know how it is 4.4.

At least 2 things will change in DM 4.5

• Each object is assigned to one workspace only
• Technically the workspace assignment is stored as an object property. The Aggregations remain there but become cosmetic.

[Malte]

Replying to jri:

Replying to Malte:

On a sidenote to changes affecting "ClientState?" (since I remember there was some connection to Workspaces):

In DM 4.4 just the access to a ClientState object has changed. The underlying cookie mechanics has not. Also the handling of workspaces has not changed.

• How can plugin developers control to which workspace their objects (topics ro assocs) are assigned when using 'createTopic()' or 'createAssiocation' calls in 4.4?

Just as in DM 4.3 and before: add a dm4_workspace_id cookie to your request.

When writing "createTopic()" I referred to using "dms" directly (in a non resource method/without request scope). So how one can control the workspace assignment here, e.g. when calling another plugins service-methods without having a cookie but with knowing that topics created via this plugin *must* stay within one specific workspace.

Case: The wikidata plugin creates its own workspace and all wikidata-topics shall be (initially) assigned to that wikidata workspace (which happens in a non-resource method).

Thanks for your help.

[jri]

When you call dms.createTopic() or dms.createAssociation() outside a request scope your topic/association gets no workspace assignment automatically. You have to do the assignment manually.

There is one exception (but presumably not applying to your case): Types whose URI have a dm4. prefix are assigned to the standard "DeepaMehta" workspace automatically. (This applies only to types, not to regular topics/associations). These types are regarded part of the DM Standard Distribution.

The best way to do the workspace assignment manually is using the Workspaces service:

void assignToWorkspace(DeepaMehtaObject object, long workspaceId)
void assignTypeToWorkspace(Type type, long workspaceId)

Use the former for regular topics/associations and the latter for types.

But I fear in your case -- you're in a migration, right? -- you don't have access to the Workspaces service. In that case my recommended workaround is: don't use a migration but the init() and/or postInstall() hooks. The former is triggered each time your plugin starts, the latter is triggered only once in the life-time of your plugin. In both cases the plugin services are already available.

These circumstances have not changed in 4.4 and are not related to DM 4.4's ClientState redesign.

Your question is rather related to #371 and #324. I definitely see need for action regarding these tickets. However, not a high priority as a workaround exists. But the more you insist ... :-)