This component, intended for use with Apache Isis's Wicket viewer, allows an entity or collection of entities to be rendered within a map (using google’s gmap3 API).
The following screenshots show the example app’s usage of the component with some sample fixture data:
The todo item’s collection contains a list of Locatable
entities (also todo items); this is indicated through a button to switch the view:
Clicking the button shows the same entities on a gmap3:
The previous screenshot shows the todo item also provides an "update location" action:
public Gmap3WicketToDoItem updateLocation(
@ParameterLayout(named="Address")
final String address) {
final Location location = this.locationLookupService.lookup(address);
setLocation(location);
return this;
}
When invoked:
... it updates the location:
Invoking an action that returns a list of Locatable
entities:
... also results in the button to view in a gmap3:
... which then renders the items in a map. Note the tooltips:
The prerequisite software is:
-
Java JDK 8 (>= Isis 1.9.0) or Java JDK 7 (⇐ Isis 1.8.0)
-
note that the compile source and target remains at JDK 7
-
-
maven 3 (3.2.x is recommended).
To build the demo app:
git clone https://github.com/isisaddons/isis-wicket-gmap3.git
mvn clean install
To run the demo app:
mvn -pl webapp jetty:run
Then log on using user: sven
, password: pass
In order to use the component an API key is required. See the google documentation for instructions as to how to do this; a free key (with quite generous daily limits) can be used.
Configure the key in WEB-INF/viewer_wicket.properties
(or WEB-INF/isis.properties
):
isis.viewer.wicket.gmap3.apiKey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-XXXXXX
Make your entity implement org.isisaddons.wicket.gmap3.applib.Locatable
, such that it provides a Location
property of type org.isisaddons.wicket.gmap3.applib.Location
.
This property will need to be annotated as @javax.jdo.annotations.Persistent
.
For example:
import org.isisaddons.wicket.gmap3.cpt.applib.Locatable; import org.isisaddons.wicket.gmap3.cpt.applib.Location; public class ToDoItem implements Locatable { ... @javax.jdo.annotations.Persistent private Location location; @MemberOrder(name="Detail", sequence = "10") @Optional public Location getLocation() { return location; } public void setLocation(Location location) { this.location = location; } }
You should then find that any collections of entities that have Locatable
properties (either returned from an action, or as a parented collection) will be rendered in a map.
By injecting the provided LocationLookupService
domain service, you can write an action to lookup Location
s.
For example:
public void lookupLocation(
@ParameterLayout(named="Description")
final String description) {
setLocation(locationLookupService.lookup(description));
}
To use this the LocationLookupService
needs to be registered; see below.
Note
|
Alternatively, the |
Sometimes the domain object that implements Locatable
will be a supporting object such as an Address
, belonging to a Customer
, say.
When the location marker is clicked in the map, we would rather that the UI opens up the Customer
rather than the
associated Address
(in other words, saving a click).
This requirement is supported by providing an implementation of the LocationDereferencingService
:
public interface LocationDereferencingService {
@Programmatic
Object dereference(final Object locatable);
}
for example, one might have:
public class LocationDereferencingServiceForAddress implements LocationDereferencingService {
@Programmatic
public Object dereference(final Object locatable) {
if (!(locatable instanceof Address)) {
return null;
}
final Address address = (Address) locatable;
return address.getCustomer();
}
}
Note that there can be multiple implementations of this service; the component will check all that are available.
The order in which they are checked depends upon the @DomainServiceLayout(menuOrder=…)
attribute.
You can either use this component "out-of-the-box", or you can fork this repo and extend to your own requirements.
To use "out-of-the-box", add the component to your project’s dom
module’s pom.xml
:
<dependency>
<groupId>org.isisaddons.wicket.gmap3</groupId>
<artifactId>isis-wicket-gmap3-cpt</artifactId>
<version>1.13.1</version>
</dependency>
Check for later releases by searching Maven Central Repo.
If you wish to use this the LocationLookupService
, this needs to be registered:
*
if using AppManifest
, then update its getModules()
method:
@Override
public List<Class<?>> getModules() {
return Arrays.asList(
...
org.isisaddons.wicket.gmap3.cpt.applib.Gmap3ApplibModule.class,
org.isisaddons.wicket.gmap3.cpt.service.Gmap3ServiceModule.class,
...
);
}
-
otherwise, update the
isis.properties
file:
isis.services-installer=configuration-and-annotation
isis.services.ServicesInstallerFromAnnotation.packagePrefix=\
...,
org.isisaddons.wicket.gmap3.cpt,
...,
And if you have integration tests then register the services' package using IsisSystemForTest.Builder#withServicesIn(…)
method.
If you want to use the current -SNAPSHOT
, then the steps are the same as above, except:
-
when updating the classpath, specify the appropriate -SNAPSHOT version:
<version>1.14.0-SNAPSHOT</version>
-
add the repository definition to pick up the most recent snapshot (we use the Cloudbees continuous integration service). We suggest defining the repository in a
<profile>
:
<profile>
<id>cloudbees-snapshots</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<repositories>
<repository>
<id>snapshots-repo</id>
<url>http://repository-estatio.forge.cloudbees.com/snapshot/</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
</profile>
If instead you want to extend this component’s functionality, then we recommend that you fork this repo. The repo is structured as follows:
-
pom.xml
- parent pom -
cpt
- the component implementation -
fixture
- fixtures, holding sample domain object classes and fixture scripts -
webapp
- demo webapp (see above screenshots)
Only the cpt
project is released to Maven central. The versions of the other modules
are purposely left at 0.0.1-SNAPSHOT
because they are not intended to be released.
-
1.13.1
- released against Isis 1.13.2, now require an API key. Also uses mavenmixins (to simplifypom.xml
configuration) and as a consequence now runs only on JDK 1.8. -
1.13.0
- released against Isis 1.13.0 -
1.12.0
- released against Isis 1.12.0 -
1.11.0
- released against Isis 1.11.0 -
1.10.0
- released against Isis 1.10.0;LocationDereferencingService
, issues #8 and #9. -
1.9.0
- released against Isis 1.9.0 -
1.8.0
- released against Isis 1.8.0 -
1.7.0
- released against Isis 1.7.0 -
1.6.0
- re-released as part of isisaddons, with classes under packageorg.isisaddons.wicket.gmap3
Copyright 2013~2017 Dan Haywood
Licensed under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
Only the cpt
module is deployed, and is done so using Sonatype’s OSS support (see
user guide).
To deploy a snapshot, use:
pushd cpt
mvn clean deploy
popd
The artifacts should be available in Sonatype’s Snapshot Repo.
If you have commit access to this project (or a fork of your own) then you can create interim releases using the interim-release.sh
script.
The idea is that this will - in a new branch - update the dom/pom.xml
with a timestamped version (eg 1.13.0.20161017-0738
).
It then pushes the branch (and a tag) to the specified remote.
A CI server such as Jenkins can monitor the branches matching the wildcard origin/interim/*
and create a build.
These artifacts can then be published to a snapshot repository.
For example:
sh interim-release.sh 1.14.0 origin
where
-
1.14.0
is the base release -
origin
is the name of the remote to which you have permissions to write to.
The release.sh
script automates the release process. It performs the following:
-
performs a sanity check (
mvn clean install -o
) that everything builds ok -
bumps the
pom.xml
to a specified release version, and tag -
performs a double check (
mvn clean install -o
) that everything still builds ok -
releases the code using
mvn clean deploy
-
bumps the
pom.xml
to a specified release version
For example:
sh release.sh 1.13.1 \
1.14.0-SNAPSHOT \
dan@haywood-associates.co.uk \
"this is not really my passphrase"
where
* $1
is the release version
* $2
is the snapshot version
* $3
is the email of the secret key (~/.gnupg/secring.gpg
) to use for signing
* $4
is the corresponding passphrase for that secret key.
Other ways of specifying the key and passphrase are available, see the `pgp-maven-plugin’s documentation).
If the script completes successfully, then push changes:
git push origin master && git push origin 1.13.1
If the script fails to complete, then identify the cause, perform a git reset --hard
to start over and fix the issue
before trying again. Note that in the cpt’s `pom.xml
the nexus-staging-maven-plugin
has the
autoReleaseAfterClose
setting set to true
(to automatically stage, close and the release the repo). You may want
to set this to false
if debugging an issue.
According to Sonatype’s guide, it takes about 10 minutes to sync, but up to 2 hours to update search.