This component, intended for use with Apache Isis's Wicket viewer, renders events for a collection of entities within a fullpage calendar. Underneath the covers it uses this fullcalendar widget.
The following screenshots show an example app’s usage of the component.
The todo item’s collection contains a list of Calendarable entities (also todo items); this is indicated through a button to switch the view:
Clicking the button shows the same entities on a fullpage calendar:
Invoking an action that returns a list of Calendarable entities:
/… also results in the button to view in a fullpage calendar:
Each item is shown in the calendar view:
Each entity can provides dates to either a single calendar or to multiple calendars. In the example app each todo item
exposes its dueBy date to a single calendar, named after its category:
@Programmatic
@Override
public String getCalendarName() {
return getCategory().name();
}
@Programmatic
@Override
public CalendarEvent toCalendarEvent() {
if(getDueBy() == null) {
return null;
}
return new CalendarEvent(getDueBy().toDateTimeAtStartOfDay(), getCalendarName(), container.titleOf(this));
}The full page calendar uses colour coding to indicate the calendars, as well as checkboxes to show/hide each calendar. Unchecking the calendar toggle hides all events in that calendar:
The prerequisite software is:
-
Java JDK 8 (>= 1.9.0) or Java JDK 7 (⇐ 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-fullcalendar2.git
mvn clean installTo run the demo app:
mvn antrun:run -P self-hostThen log on using user: sven, password: pass
Each entity must implement either the CalendarEventable interface or the Calendarable interface:
Of the two interfaces, CalendarEventable interface is the simpler, allowing the object to return a single CalendarEvent:
public interface CalendarEventable {
String getCalendarName(); // (1)
CalendarEvent toCalendarEvent(); // (2)
}-
groups similar events together; in the UI these correspond to checkboxes rendered near the top.
-
returns a
CalendarEventvalue type representing the data to be rendered on the calender.
CalendarEvent itself is:
public class CalendarEvent implements Serializable {
private final DateTime dateTime;
private final String calendarName;
private final String title;
private final String notes;
public CalendarEvent(
final DateTime dateTime,
final String calendarName,
final String title) {
this(dateTime, calendarName, title, null);
}
public CalendarEvent(
final DateTime dateTime,
final String calendarName,
final String title,
final String notes) {
this.dateTime = dateTime;
this.calendarName = calendarName;
this.title = title;
this.notes = notes;
}
...
}In the demo app, the ToDoItem implements CalendarEventable.
While the CalendarEventable interface will fit many requirements, sometimes an object will have several dates associated with it. For example, one could imagine an object with start/stop dates, or optionExercise/optionExpiry dates.
The Calendarable interface therefore allows the object to return a number of CalenderEvents; each is qualified (identified) by a calendarName:
public interface Calendarable {
Set<String> getCalendarNames();
ImmutableMap<String, CalendarEventable> getCalendarEvents();
}Sometimes the domain object that implements Calendarable or CalendarEventable will be a supporting object such as
a Note attached to an Order, say. When the marker is clicked in the calendar, we would rather that the UI opens
up the Order rather than the associated Note (in other words, saving a click).
This requirement is supported by providing an implementation of the CalendarableDereferencingService:
public interface CalendarableDereferencingService {
@Programmatic
Object dereference(final Object calendarableOrCalendarEventable);
}for example, one might have:
public class LocationDereferencingServiceForNote implements CalendarableDereferencingService {
@Programmatic
public Object dereference(final Object calendarableOrCalendarEventable) {
if (!(locatable instanceof Note)) {
return null;
}
final Note note = (Note) calendarableOrCalendarEventable;
return note.getOwner();
}
}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 extension "out-of-the-box", or you can fork this repo and extend to your own requirements.
To use "out-of-the-box", add this component to your project’s dom module’s pom.xml, eg:
<dependency>
<groupId>org.isisaddons.wicket.fullcalendar2</groupId>
<artifactId>isis-wicket-fullcalendar2-cpt</artifactId>
<version>1.14.0</version>
</dependency>Check for later releases by searching Maven Central Repo.
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.15.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.14.0- released against Isis 1.14.0 -
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;CalendarableDereferencingService -
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.1- (breaking change) changed package names for API toorg.isisaddons.wicket.fullcalendar2.cpt.applib -
1.6.0- re-released as part of isisaddons, changed package names for API toorg.isisaddons.wicket.fullcalendar2.applib
Copyright 2013~2016 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.In addition to Apache Isis, this component depends on:
-
net.ftlines.wicket-fullcalendar:wicket-fullcalendar-core(ASL v2.0 License) -
http://arshaw.com/fullcalendar/ (MIT License)
-
http://jquery.com (MIT 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
popdThe 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.14.0.20170227-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 originwhere
-
1.15.0is the base release -
originis 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.xmlto 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.xmlto a specified release version
For example:
sh release.sh 1.14.0 \
1.15.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.14.0If 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.