You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@isis.apache.org by da...@apache.org on 2015/05/28 15:03:46 UTC

[20/29] isis git commit: ISIS-1133: fixing references, breaking out annotation pages for each attribute (for more consistent cross-referencing).

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_security_usage-by-isis-viewers.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_security_usage-by-isis-viewers.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_security_usage-by-isis-viewers.adoc
index 6b58509..9e43660 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_security_usage-by-isis-viewers.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_security_usage-by-isis-viewers.adoc
@@ -6,7 +6,7 @@
 
 
 
-By and large the security mechanisms within Isis are transparent to the rest of the framework (the xref:_wicket_viewer[Wicket Viewer] and xref:_restful_objects_viewer[Restful viewer], and the overall xref:_runtime[runtime]).
+By and large the security mechanisms within Isis are transparent to the rest of the framework (the xref:_ug_wicket-viewer[Wicket Viewer] and xref:_ug_restfulobjects-viewer[Restful Objects viewer], and the overall xref:_ug_runtime[runtime]).
 
 That said, it is the responsibility of the viewers to ensure that there is a viewers to ensure that for each request there is a valid user session present.  The sections below explain how this works.
 
@@ -15,7 +15,7 @@ That said, it is the responsibility of the viewers to ensure that there is a vie
 
 == Wicket Viewer
 
-The xref:_wicket_viewer[Wicket viewer] defines a relatively small number of pages (by which we mean subclasses of link:http://ci.apache.org/projects/wicket/apidocs/6.0.x/org/apache/wicket/markup/html/WebPage.html[`org.apache.wicket.markup.html.WebPage`]):
+The xref:_ug_wicket-viewer[Wicket viewer] defines a relatively small number of pages (by which we mean subclasses of link:http://ci.apache.org/projects/wicket/apidocs/6.0.x/org/apache/wicket/markup/html/WebPage.html[`org.apache.wicket.markup.html.WebPage`]):
 
 * about page
 * action prompt page
@@ -37,7 +37,7 @@ which means that they can only be accessed by a user with an authenticated sessi
 
 [TIP]
 ====
-The sign-in page to render is pluggable; see xref:_custom_pages[extensions chapter] for details.
+The sign-in page to render is pluggable; see xref:_ug_extending_wicket-viewer_custom-pages[extensions chapter] for details.
 ====
 
 In the sign-in page the viewer calls to the Isis Authenticator API, and obtains back a user/role.  It also adds in its special reserved role (per the annotation above) and then continues on to whichever page the user was attempting to access (usually the home page).
@@ -53,7 +53,7 @@ As well as providing a sign-in screen, the Wicket viewer also provides the abili
 
 [TIP]
 ====
-The sign-in verification page to render is pluggable; see xref:_custom_pages[extensions chapter] for details.
+The sign-in verification page to render is pluggable; see xref:_ug_extending_wicket-viewer_custom-pages[extensions chapter] for details.
 ====
 
 User registration is only available if the xref:_user_registration_service[`UserRegistrationService`] is configured; this is used by the framework to actually create new instances of the user as accessed by the corresponding (Shiro) realm.
@@ -66,7 +66,7 @@ If you are using an LDAP realm and want to enable user-self registration then yo
 
 == Restful Objects Viewer
 
-Unlike the Wicket viewer, the xref:_restful_objects_viewer[Restful Objects viewer] does _not_ provide any sort of login page; rather it provides a pluggable authentication strategy, delegated to by the `IsisSessionFilter` filter defined in `web.xml`.  The authentication strategy is responsible for ensuring that a session is available for the REST resource.
+Unlike the Wicket viewer, the xref:_ug_restfulobjects-viewer[Restful Objects viewer] does _not_ provide any sort of login page; rather it provides a pluggable authentication strategy, delegated to by the `IsisSessionFilter` filter defined in `web.xml`.  The authentication strategy is responsible for ensuring that a session is available for the REST resource.
 
 The API of `AuthenticationSessionStrategy` is simply:
 

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_aaa.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_aaa.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_aaa.adoc
index 9f4a248..2b688a4 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_aaa.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_aaa.adoc
@@ -52,7 +52,7 @@ When we talk about integration tests/specs here, we mean tests that exercise the
 
 For most other frameworks that would require having to test the application in a very heavy weight/fragile fashion using a tool such as link:http://seleniumhq.org[Selenium], driving a web browser to navigate .  In this regard though, Isis has a significant trick up its sleeve.  Because Isis implements the naked objects pattern, it means that the UI is generated automatically from the UI.  This therefore allows for other implementations of the UI.
 
-The xref:_wrapper_factory[`WrapperFactory`] domain service allows a test to wrap domain objects and thus to interact with said objects "as if" through the UI:
+The xref:_ug_reference-services-api_manpage-WrapperFactory[`WrapperFactory`] domain service allows a test to wrap domain objects and thus to interact with said objects "as if" through the UI:
 
 image::{_imagesdir}testing/integ-tests.png[width="700px"]
 
@@ -125,7 +125,7 @@ In the previous section we discussed using given/when/then as a form of organizi
 
 For integration tests though it can be difficult to keep the "given" short; there could be a lot of prerequisite data that needs to exist before you can actually exercise your system.  Moreover, however we do set up that data, but we also want to do so in a way that is resilient to the system changing over time.
 
-The solution that Isis provides is a domain service called xref:_fixture_scripts[Fixture Scripts], that defines a pattern and supporting classes to help ensure that the "data setup" for your tests are reusable and maintainable over time.
+The solution that Isis provides is a domain service called xref:_ug_reference-classes_super_manpage-FixtureScripts[Fixture Scripts], that defines a pattern and supporting classes to help ensure that the "data setup" for your tests are reusable and maintainable over time.
 
 
 

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_key-classes.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_key-classes.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_key-classes.adoc
index 5efa877..d562401 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_key-classes.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_key-classes.adoc
@@ -9,7 +9,7 @@
 
 There are some key framework classes that make up the spec support; these are discussed below.
 
-NOTE: some of these are also used by Isis' xref:_integration_test_support[Integration Test support].
+NOTE: some of these are also used by Isis' xref:_ug_testing_integ-test-support[Integration Test support].
 
 
 

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_writing-a-bdd-spec.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_writing-a-bdd-spec.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_writing-a-bdd-spec.adoc
index 2651d04..7b2348d 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_writing-a-bdd-spec.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_bdd-spec-support_writing-a-bdd-spec.adoc
@@ -21,7 +21,7 @@ For example, given a feature that involves `Customer` and `Order`, have the step
 +
 The `glue` attribute of the Cucumber-JVM JUnit runner eallows you to indicate which package(s) should be recursively searched to find any glue.
 
-* a system initializer class.  You can reuse the  system initializer from any integration tests (as described in xref:_integration_test_support[Integration Test Support], bootstrapping section).
+* a system initializer class.  You can reuse the  system initializer from any integration tests (as described in xref:_ug_testing_integ-test-support[Integration Test Support], bootstrapping section).
 
 
 Here's an example of a feature from the xref:_ug_getting-started_simpleapp-archetype[SimpleApp archetype]:

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_fixture-scripts_api-and-usage.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_fixture-scripts_api-and-usage.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_fixture-scripts_api-and-usage.adoc
index e6542e7..d2c0f43 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_fixture-scripts_api-and-usage.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_fixture-scripts_api-and-usage.adoc
@@ -198,7 +198,7 @@ public class SimpleObjectCreate extends FixtureScript {       // <1>
 <3> output property: the created simple object
 <4> the mandatory execute(...) API
 <5> the `checkParam(...)` (inherited from `FixtureScript`) will check that the "name" property has been populated (using Java's Reflection API) and throw an exception if not
-<6> wrap the injected `SimpleObjects` domain service (using the xref:_wrapper_factory[`WrapperFactory`]) to simulate interaction through the UI...
+<6> wrap the injected `SimpleObjects` domain service (using the xref:_ug_reference-services-api_manpage-WrapperFactory[`WrapperFactory`]) to simulate interaction through the UI...
 <7> .. and actually create the object using the "create" business action of that service
 <8> add the resulting object to the execution context; this makes the object available to access if run from the UI
 <9> inject the domain service into the fixture script
@@ -276,7 +276,7 @@ With the composite style, we rely on each fixture script to set up its own prere
 
 image::{_imagesdir}testing/fixture-scripts/composite.png[width="550px",link="_imagesdir}testing/fixture-scripts/composite.png"]
 
-Back in the earlier xref:_fixturescripts[`FixtureScripts`] section we noted the `MultipleExecutionStrategy` setting.  We can now explain the meaning of this: the enum value of `EXECUTE` is designed for the flat style (where every fixture script will be called), whereas the enum value of `IGNORE` is designed for the composite style, and ensures that any fixture scripts visited more than once (eg TearDown) are only every executed the first time.
+Back in the earlier section we noted the `MultipleExecutionStrategy` setting.  We can now explain the meaning of this: the enum value of `EXECUTE` is designed for the flat style (where every fixture script will be called), whereas the enum value of `IGNORE` is designed for the composite style, and ensures that any fixture scripts visited more than once (eg TearDown) are only every executed the first time.
 
 As already noted , the app generated by the xref:_ug_getting-started_simpleapp-archetype[SimpleApp archetype] uses the flat structure, and we feel that it's a better at separating out the "how" (how we set up some graph of domain objects into a known state, eg a customer with shipped placed orders and a newly placed order) from the "what" (what data should we actually use for the customer's name, say).
 

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_bootstrapping.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_bootstrapping.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_bootstrapping.adoc
index 407a572..8bacf80 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_bootstrapping.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_bootstrapping.adoc
@@ -49,7 +49,7 @@ private static class SimpleAppSystemBuilder extends IsisSystemForTest.Builder {
 <1> subclass the framework-provided `IsisSystemForTest.Builder`.
 <2> equivalent to `isis.persistor=datanucleus` in `isis.properties`
 <3> specify the `isis.services` key in `isis.properties` (where "domainapp" is the base package for all classes within the app)
-<4> `IsisConfigurationForJdoIntegTests` has pre-canned configuration for using an in-memory HSQLDB and other standard settings; more on this  xref:_isisconfigurationforjdointegtests[below].
+<4> `IsisConfigurationForJdoIntegTests` has pre-canned configuration for using an in-memory HSQLDB and other standard settings; more on this below.
 <5> equivalent to `isis.persistor.datanucleus.RegisterEntities.packagePrefix` key (typically in `persistor_datanucleus.properties`
 
 
@@ -186,7 +186,7 @@ public abstract class SimpleAppIntegTest {
 ----
 <1> ensure that logging messages don't get swallowed
 <2> initialize the Isis runtime
-<3> primarily exists to support the writing of xref:_bdd_spec_support[BDD specifications], but also enables finer-grained management of sessions/transactions (discussed below).
+<3> primarily exists to support the writing of xref:_ug_testing_bdd-spec-support[BDD specifications], but also enables finer-grained management of sessions/transactions (discussed below).
 
 
 
@@ -221,7 +221,7 @@ Although not mandatory, this provides a number of helper/convenience methods and
 <1> ensures an Isis session/transaction running for each test
 <2> sets up a JMock context (using Isis' extension to JMock as described in <<JMock Extensions>>
 <3> standard JUnit rule for writing tests that throw exceptions
-<4> to capture messages that require translation, as described in xref:_i18n_support[i18 support].
+<4> to capture messages that require translation, as described in xref:_ug_more-advanced_i18n[i18 support].
 
 All of these rules could be inlined in your own base class; as we say, they are a convenience.
 

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_typical-usage.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_typical-usage.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_typical-usage.adoc
index dbf198e..c6575e6 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_typical-usage.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_typical-usage.adoc
@@ -58,7 +58,7 @@ public class ToDoItemIntegTest extends AbstractToDoIntegTest {
     ...
 }
 ----
-<1> the xref:_fixture_scripts[`FixtureScripts`] domain service is injected, providing us with the ability to run fixture scripts
+<1> the xref:_ug_reference-classes_super_manpage-FixtureScripts[`FixtureScripts`] domain service is injected, providing us with the ability to run fixture scripts
 <2> likewise, an instance of the `ToDoItems` domain service is injected.  We'll use this to lookup...
 <3> the object under test, held as a field
 <4> the fixture script for this test; it deletes all existing todo items (for the current user only) and then recreates them

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_wrapper-factory.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_wrapper-factory.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_wrapper-factory.adoc
index 50170f2..db7803f 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_wrapper-factory.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_testing_integ-test-support_wrapper-factory.adoc
@@ -86,7 +86,7 @@ If there is a supporting `addTo...()` or `removeFrom...()` method, then these ca
 +
 [NOTE]
 ====
-In this respect the wrapper is more functional than the xref:_wicket_viewer[Wicket viewer] (which does not expose the ability to mutate collections directly).
+In this respect the wrapper is more functional than the xref:_ug_wicket-viewer[Wicket viewer] (which does not expose the ability to mutate collections directly).
 ====
 
 * for *_object actions_* the test can call the action method itself.
@@ -145,7 +145,7 @@ public void subscriberReceivesEvents() throws Exception {
     then(evHolder[0].getIdentifier().getMemberName()).isEqualTo("completed");
 }
 ----
-<1> inject xref:__code_EventBusService_code[`EventBusService`] into this test
+<1> inject xref:_ug_reference-services-api_manpage-EventBusService[`EventBusService`] into this test
 <2> holder for subscriber to capture event to
 <3> subscriber's callback, using the guava subscriber syntax
 <4> invoking the domain object using the wrapper

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_pet-clinic.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_pet-clinic.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_pet-clinic.adoc
index b4ed133..0dc0bee 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_pet-clinic.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_pet-clinic.adoc
@@ -166,7 +166,7 @@ Go back to the splash screen, and quit the app. Note that the database runs in-m
 
 == Dev environment
 
-Set up xref:_setting_up_a_development_environment[an IDE] and import the project to be able to run and debug the app.
+Set up xref:_ug_appendices_dev-env[an IDE] and import the project to be able to run and debug the app.
 
 Then set up a launch configuration so that you can run the app from within the IDE. To save having to run the fixtures
 every time, specify the following system properties:

http://git-wip-us.apache.org/repos/asf/isis/blob/2af3ad9a/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_stop-scaffolding-start-coding.adoc
----------------------------------------------------------------------
diff --git a/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_stop-scaffolding-start-coding.adoc b/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_stop-scaffolding-start-coding.adoc
index 8337a09..38a460e 100644
--- a/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_stop-scaffolding-start-coding.adoc
+++ b/adocs/documentation/src/main/asciidoc/user-guide/_ug_tutorials_stop-scaffolding-start-coding.adoc
@@ -5,9 +5,9 @@
 :_imagesdir: images/
 
 
-This is a half-day tutorial on developing domain-driven apps using Apache Isis.  Actually, you could probably spend a full day working through this tutorial if you wanted to� so pick and choose the bits that look interesting.
+This is a half-day tutorial on developing domain-driven apps using Apache Isis.  Actually, you could probably spend a full day working through this tutorial if you wanted to, so pick and choose the bits that look interesting.
 
-There's a bit of overlap with the xref:_pet_clinic[Pet Clinic] tutorial initially, but it then sets off on its own.
+There's a bit of overlap with the xref:_ug_tutorials_pet-clinic[Pet Clinic] tutorial initially, but it then sets off on its own.
 
 
 
@@ -90,13 +90,13 @@ Go back to the splash screen, and quit the app. Note that the database runs in-m
 
 == Dev environment
 
-Set up xref:_setting_up_a_development_environment[an IDE] and import the project to be able to run and debug the app.
+Set up xref:_ug_appendices_dev-env[an IDE] and import the project to be able to run and debug the app.
 
 Then set up a launch configuration and check that you can:
 
 * Run the app from within the IDE
 * Run the app in debug mode
-* Run with different deploymentTypes; note whether prototype actions (those annotated xref:__code_action_code[`@Action(restrictTo=PROTOTYPING`]) are available or not:
+* Run with different deploymentTypes; note whether prototype actions (those annotated xref:_ug_reference-annotations_manpage-Action_restrictTo[`@Action(restrictTo=PROTOTYPING`]) are available or not:
 * `--type SERVER_PROTOTYPE`
 * `--type SERVER`
 
@@ -202,8 +202,8 @@ Most domain objects in Apache Isis applications are persistent entities. In the
 ** eg rename to `Pet`
 * if required, rename the `SimpleObject` class' `name` property
 ** for `Pet`, can leave `name` property as is
-* specify a xref:_how_to_specify_a_title_for_a-domain-entity[title]
-* specify an xref:_how_to_specify_an_icon_for_a-domain-entity[icon]
+* specify a xref:_ug_how-tos_ui-hints_object-titles-and-icons[title]
+* specify an xref:_ug_how-tos_ui-hints_object-titles-and-icons[icon]
 * make the entity bookmarkable by adding the <<__code_domainobjectlayout_code,@DomainObjectLayout(bookmarking=...)` annotation
 * confirm is available from bookmark panel (top-left of Wicket UI)
 
@@ -219,15 +219,15 @@ In the simpleapp archetype the `SimpleObjects` service is a factory/repository f
 * rename the `SimpleObjects` class
 ** eg rename to `Pets`
 * review `create` action (acting as a factory)
-** as per the docs describing xref:_how_to_create_or_delete_objects_within_your_code[how to create or delete objects]
+** as per the docs describing xref:_ug_how-tos_crud[how to create or delete objects]
 * rename if you wish
 ** eg `newPet(...)` or `addPet(...)`
 * review `listAll` action (acting as a repository)
-* as per the docs describing xref:_how_to_write_a_custom_repository[how to write a custom repository]
+* as per the docs describing xref:_ug_how-tos_crud[how to write a custom repository]
 * note the annotations on the corresponding domain class (originally called `SimpleObject`, though renamed by now, eg to `Pet`)
 * rename if you wish
 ** eg `listPets()`
-* note the xref:__code_domainservice_code[`@DomainService`] annotation
+* note the xref:_ug_reference-annotations_manpage-DomainService[`@DomainService`] annotation
 * optional: add an action to a return subset of objects
 ** use the JDO `@Query` annotation
 ** see for example the Isisaddons example https://github.com/isisaddons/isis-app-todoapp[todoapp] (not ASF), see https://github.com/apache/isis/blob/b3e936c9aae28754fb46c2df52b1cb9b023f9ab8/example/application/todoapp/dom/src/main/java/dom/todo/ToDoItem.java#L93[here] and https://github.com/apache/isis/blob/b3e936c9aae28754fb46c2df52b1cb9b023f9ab8/example/application/todoapp/dom/src/main/java/dom/todo/ToDoItems.java#L63[here]
@@ -241,7 +241,7 @@ Fixture scripts are used to setup the app into a known state. They are great for
 
 * rename the `SimpleObjectsTearDownFixture` class
 * and update to delete from the appropriate underlying database table(s)
-* use the injected xref:__code_isisjdosupport_code[`IsisJdoSupport`] domain service.
+* use the injected xref:_ug_reference-services-api_manpage-IsisJdoSupport[`IsisJdoSupport`] domain service.
 * refactor/rename the fixture script classes that create instances your entity:
 * `RecreateSimpleObjects`, which sets up a set of objects for a given scenario
 * `SimpleObjectCreate` which creates a single object
@@ -255,9 +255,9 @@ Fixture scripts are used to setup the app into a known state. They are great for
 Most business functionality is implemented using actions� basically a `public` method accepting domain classes and primitives as its parameter types. The action can return a domain entity, or a collection of entities, or a primitive/String/value, or void. If a domain entity is returned then that object is rendered immediately; if a collection is returned then the Wicket viewer renders a table. Such collections are sometimes called "standalone" collections.
 
 * write an action to update the domain property (originally called `SimpleObject#name`, though renamed by now)
-* use the xref:__code_parameterlayout_code[`@ParameterLayout(named=...)`] annotation to specify the name of action parameters
-* use the xref:__code_action_code[`@Action(semanticsOf=...)`]  annotation to indicate the semantics of the action (safe/query-only, idempotent or non-idempotent)
-* annotate safe action as bookmarkable using xref:__code_actionlayout_code[`@ActionLayout(bookmarking=...)`]
+* use the xref:_ug_reference-annotations_manpage-ParameterLayout_named[`@ParameterLayout(named=...)`] annotation to specify the name of action parameters
+* use the xref:_ug_reference-annotations_manpage-Action_semantics[`@Action(semanticsOf=...)`]  annotation to indicate the semantics of the action (safe/query-only, idempotent or non-idempotent)
+* annotate safe action as bookmarkable using xref:_ug_reference-annotations_manpage-ActionLayout_bookmarking[`@ActionLayout(bookmarking=...)`]
 * confirm is available from bookmark panel (top-left of Wicket UI)
 * optional: add an action to clone an object
 
@@ -285,7 +285,7 @@ As well as exposing the Wicket viewer, Isis also exposes a REST API (an implemen
 
 The semantics of an action (whether it is safe/query only, whether it is idempotent, whether it is neither) can be specified for each action; if not specified then Isis assumes non-idempotent. In the Wicket viewer this matters in that only query-only actions can be bookmarked or used as contributed properties/collections. In the RESTful viewer this matters in that it determines the HTTP verb (GET, PUT or POST) that is used to invoke the action.
 
-* experiment changing xref:__code_action_code[`@Action(semantics=...)`] on actions
+* experiment changing xref:_ug_reference-annotations_manpage-Action_semantics[`@Action(semantics=...)`] on actions
 * note the HTTP methods exposed in the REST API change
 * note whether the non-safe actions are bookmarkable (assuming that it has been annotated with `@ActionLayout(bookmarking=...)`, that is).
 
@@ -296,12 +296,12 @@ The semantics of an action (whether it is safe/query only, whether it is idempot
 
 Domain entities have state: either values (primitives, strings) or references to other entities. In this section we explore adding some value properties
 
-* add some xref:_how_to_add_a_property_to_a_domain_entity[value properties]; also:
+* add some xref:_ug_how-tos_class-structure_properties[value properties]; also:
 * for string properties
-** use the xref:__code_Property_code[`@Property(multiLine=...)`] annotation to render a text area instead of a text box
-** use the xref:__code_Property_code[`@Property(maxLength=...)`] annotation to specify the maximum number of characters allowable
+** use the xref:_ug_reference-annotations_manpage-PropertyLayout_multiLine[`@Property(multiLine=...)`] annotation to render a text area instead of a text box
+** use the xref:_ug_reference-annotations_manpage-Property_maxLength[`@Property(maxLength=...)`] annotation to specify the maximum number of characters allowable
 ** use joda date/time properties, bigdecimals and blob/clob properties
-* use the xref:__code_Property_code[`@Column(allowsNull=...)`] annotation specify whether a property is optional or mandatory
+* use the xref:_ug_reference-annotations_manpage-Property_optionality[`@Column(allowsNull=...)`] annotation specify whether a property is optional or mandatory
 * use enums for properties (eg as used in the Isis addons example https://github.com/isisaddons/isis-app-todoapp[todoapp], see https://github.com/apache/isis/blob/b3e936c9aae28754fb46c2df52b1cb9b023f9ab8/example/application/todoapp/dom/src/main/java/dom/todo/ToDoItem.java#L207[here] and https://github.com/apache/isis/blob/b3e936c9aae28754fb46c2df52b1cb9b023f9ab8/example/application/todoapp/dom/src/main/java/dom/todo/ToDoItem.java#L266[here])
 * update the corresponding domain service for creating new instances
 * for all non-optional properties will either need to prompt for a value, or calculate some suitable default