You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Dan Haywood (JIRA)" <ji...@apache.org> on 2017/02/14 12:25:41 UTC

[jira] [Resolved] (ISIS-1586) Rationalize the way that service instances are referenced by RO vs rest of the framework

     [ https://issues.apache.org/jira/browse/ISIS-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Haywood resolved ISIS-1586.
-------------------------------
    Resolution: Fixed

> Rationalize the way that service instances are referenced by RO vs rest of the framework
> ----------------------------------------------------------------------------------------
>
>                 Key: ISIS-1586
>                 URL: https://issues.apache.org/jira/browse/ISIS-1586
>             Project: Isis
>          Issue Type: Improvement
>          Components: Core, Core: Viewer: RestfulObjects
>    Affects Versions: 1.13.2.1
>            Reporter: Dan Haywood
>            Assignee: Dan Haywood
>            Priority: Minor
>             Fix For: 1.14.0
>
>
> The URLs in Restful Objects viewer are derived from ServiceUtil.id(...), which evaluates the getId() method of the service class, otherwise falls back to the simpleName of the class.
> Meanwhile in the metamodel itself - ie the ObjectSpecId, as used in the first part of the objectType and bookmarks - is always simply the fully-qualified class name.
> In the Wicket viewer (unlike entities) this FQCN doesn't normally manifests as a URL, though it can be seen for bookmarked actions.  It can also be seen for published interactions, as the target object.
> To rationalize things:
> * introduce a new @DomainService#serviceType (analogous to @DomainObject#objectType
> * use the value of this serviceType if present
> * otherwise fallback to getId()
> * otherwise fallback to the fully qualified class name.
> This final fallback is a slight change in default behaviour for any apps just using the RO viewer - its default would have been just the simple class name of the service.  The workaround is to add either serviceType or getId() explicitly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)