You could also hide the property and create a separate getter for display
purposes only:
private MyProperty myProperty;
@Hidden
public MyProperty getMyProperty() {...}
public void setMyProperty(...) {...}
public String getMyPropertyName() {
getMyProperty.getName();
}
On 29 July 2015 at 13:18, Stephen Cameron <[email protected]>
wrote:
> On Wed, Jul 29, 2015 at 6:38 PM, Dan Haywood <[email protected]
> >
> wrote:
>
> > You are right, they will be displayed as links; there's no way to disable
> > it currently.
> >
> > We could add a bit of metadata perhaps for this, eg
> > @DomainObjectLayout(suppressLink=true) or similar.
> >
> > Please raise a ticket.
> >
>
> OK https://issues.apache.org/jira/browse/ISIS-1180
>
> >
> > Thx
> > Dan
> >
> > PS: these entities wouldn't be value types, rather regular entities. But
> > you are right... what we really want is full-class support for value
> types.
> > We're just not there yet...
> >
> >
> >
>
> >
> >
> > On 29 July 2015 at 09:34, Stephen Cameron <[email protected]>
> > wrote:
> >
> > > Thanks, but surely such object properties always end up being displayed
> > as
> > > links? Clicking on the link to go to such an object page is
> meaningless,
> > as
> > > it only has one name property, that was displayed in the link. Can I
> > > disable that default behaviour for value types?
> > >
> > >
> > >
> > > On Wed, Jul 29, 2015 at 5:47 PM, Dan Haywood <
> > [email protected]
> > > >
> > > wrote:
> > >
> > > > On 29 July 2015 at 08:08, Stephen Cameron <
> [email protected]>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I want to do have some properties that are essentially String
> types,
> > > but
> > > > > which have a limited range of values (code-lists or restricted
> > > > > vocabularies). I want to allow these lists to be administered
> > > centrally,
> > > > so
> > > > > to add them to a single Administration menu item for admin users.
> > > > >
> > > > > For most users these codes should appears as lists of strings not
> as
> > > > > objects, but making them objects seems to be the logical OO way to
> > deal
> > > > > with them in Isis. So they are basically objects with one 'name'
> > > property
> > > > > (and maybe an id added by datanucleus). All users need to see is
> the
> > > name
> > > > > property, no icon is needed.
> > > > >
> > > > > Also, if I make them objects I also will get referencial integrity
> > > > > constraints applied in the database.
> > > > >
> > > > >
> > > > +1, do it this way. That way they can also hold behaviour in the
> > future.
> > > >
> > > >
> > > >
> > > >
> > > > > I wonder there is a simple recipe for this?
> > > > >
> > > >
> > > > No magic recipe for the domain entities... basically copy-n-paste the
> > > > SimpleObject that's in our archetype as many times as needed, and
> tweak
> > > as
> > > > required.
> > > >
> > > > If you want to use the code as the primary key, then use DN
> application
> > > > identity
> > > >
> > > > @javax.jdo.annotations.PersistenceCapable(
> > > > identityType=IdentityType.APPLICATION,
> > > > schema = "simple",
> > > > table = "SimpleObject"
> > > > )
> > > >
> > > > and add @PrimaryKey to the "name" property. Also add @Title to that
> > > 'name'
> > > > property (it is in SimpleObject already).
> > > >
> > > >
> > > > You would probably want to remove the version column, ie remove:
> > > >
> > > > @javax.jdo.annotations.Version(
> > > > strategy=VersionStrategy.VERSION_NUMBER,
> > > > column="version")
> > > >
> > > >
> > > > In addition, if you annotate the class as "bounded"
> > > > (@DomainObject(bounded=true)) then you are telling the framework that
> > > > there's a limited - ie bounded - set of instances, and so it will
> > display
> > > > all instances in a drop-down for you.
> > > >
> > > >
> > > > HTH
> > > > Dan
> > > >
> > >
> >
>
