Hi David, I was speaking of the values/entries not the catalog or code-list collection object, which as you say will have some behaviour.
On Thu, Jul 30, 2015 at 3:53 PM, David Tildesley <[email protected]> wrote: > Hi Stephen, > Notwithstanding any issues with ISIS, I disagree with your assertion > <quote>In terms of > domain modelling such code-lists are simple types that 'represent' things > on the boundary of the domain of interest.</quote> > > When Peter Coad came up with the 4 domain archetypes and the DNC (Domain > Neutral Component) [1],one of the archetypes was the "Description" > archetype: > The Description class archetype that models a catalog-entry-like > description. It is a collection of values that apply again and again. It > also provides behavior across the collection of all things that correspond > to its description. [Coad99]. - See more at: Peter Coad's 'Modeling in > Color' > > | | > | | | | | | | | > | Peter Coad's 'Modeling in Color'An object modeling technique, 'modeling > in color' helps identify and define robust, extensible, problem domain > classes for a software component, application, or sys... | > | | > | View on www.step-10.com | Preview by Yahoo | > | | > | | > > > > [1] http://www.step-10.com/SoftwareDesign/ModellingInColour/ > > | | > | | | | | | > | Java Modeling In Color With UML: Enterprise Components and Process: > Peter Coad, Jeff de Luca, Er...This is the first book to teach software > design in color. Peter Coad and his co-authors use four colors to represent > four "archetypes": forms that appear repeatedly in effective component and > object models. Given a color, you'll know the kind of attributes, links, > methods, and int... | > | | > | View on www.amazon.com | Preview by Yahoo | > | | > | | > > > > > On Thursday, 30 July 2015 2:17 PM, Stephen Cameron < > [email protected]> wrote: > > > Not so simple, as now the property cannot be updated. > > I have the following (@Hidden is deprecated) > > @Column(allowsNull = "true") > @MemberOrder(sequence = "7") > @PropertyLayout(hidden=Where.EVERYWHERE) > public Region getRegion() { > return this.region; > } > > public void setRegion(Region region) { > this.region = region; > } > > public List<Region> choicesRegion(){ > List<Region> regions = container.allInstances(Region.class); > return regions; > } > > @MemberOrder(sequence = "7.1") > public String getRegionName(){ > return (getRegion() != null) ? getRegion().getName() : null; > } > > Sure enough getRegion doesn't appear in the UI but getRegionName does, but > then setRegion and choiceRegion don't mean anything to the UI, so the > Region property is read-only. > > This issue is maybe more significant than it appears at first, in terms of > domain modelling such code-lists are simple types that 'represent' things > on the boundary of the domain of interest. So we usually want to just > represent them with a name. Presently it makes no sense to go to that thing > via a hyperlink as all we'll find is that name, our model extends no > further. > > However we just might like to allow users to leave the domain model and go > to a resource outside. So, extending the suppressLink=true idea, I would > add that each object could have an implicit link(URL),created by Isis, or > an explicit one and if the explicit one is present it can optionally be > used as an alternative to the implicit one. > > For example, you might create a database to log fish details, species is a > boundary concept, we aren't likely to want to add a new species to the list > of known species, but we'd like to keep such a list handy, but for each > named species in that list, to provide an explicit link to a resource in a > global fish database. It makes more sense to use this link than the > implicit one, as if the implicit one is used we'd navigate to the domain > object page displaying the name and URL, both of which items of data could > have been in the explicit link. > > In the explicit case you might want to warn the user they are navigating > outside the Isis domain application. > > Perhaps all this could be done simply if there was a URI type in Isis, that > would allow it to create 'smart links' automatically. > > > > > > On Wed, Jul 29, 2015 at 9:37 PM, Stephen Cameron < > [email protected] > > wrote: > > > Thanks Jeroen, seems simple enough :) > > > > On Wed, Jul 29, 2015 at 9:28 PM, Jeroen van der Wal <[email protected] > > > > wrote: > > > >> 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 > >> > > > > > >> > > > > >> > > > >> > > >> > > > > > > > >
