A Pagination service with AngularJS and Bootstrap CSS

In this post, I propose an implementation of an AngularJS service to handle pagination on injected views (via the angular route service and the ng-view directive).

  1. This pagination service has the advantage to be specific to each controller (via instances creation per controller).
  2. Per page data are loaded and refreshed via asynchronous calls to a back-end service (through angular events), you have not to load the entire data and handle pagination on the client side. This service decouples entirely the pagination service with the back end service as you will see later.

follow this link to view and try it on jsFiddle

The Pagination service

A working implementation of the pagination service might seem like this

var Pagination = function(maxCount, $rootScope) {
    this.maxCount = maxCount;
    this.counter = 1;
    
    this.max = function() {
        return this.maxCount;
    };
    this.current = function() {
        return this.counter;
    };
    this.next = function() {
        if (this.hasNext()) {
            this.counter++;
            $rootScope.broadcast("pagination:next");
        }
    };
    this.previous = function() {
        if (this.hasPrevious()) {
            this.counter--;
            $rootScope.broadcast("pagination:previous");
        }
    };
    this.hasPrevious = function() {
        return this.counter > 1;
    };
    this.hasNext = function() {
        return this.counter < this.maxCount;
    };
};

Each time the service is asked to go forth (next) or back (previous), it notifies all registered listeners for page navigation events via rootScope.$broadcast. This will allow us to bind this events to a Back-end service in order to refresh the data for the new displayed page.

The service has two key parameters:

  • maxCount (constructor parameter) is the total number of data that will be handled. This is generally provided by a Back-end service (count all).
  • counter is the current displayed page number.
Return the service through a factory

Since AngularJS services are singleton per application, in order to make the pagination service controller specific, we have to provide it through a factory like service :

// the Pagination service
angular.module('project.services', [])
   .factory('PaginatonService', function($rootScope) {
     return {
       Pagination: function(maxCount, $rootScope) {
         return new Pagination(maxCount);
       }
     };
});
Injecting the service into the controller

The service is then simply declared and instantiated on each controller that requires pagination feature

// injecting the Pagination service into the application module
var myapp = angular.module('project', ['project.services']);
myapp.controller('Controller1', function ($scope, PaginatonService) {
    // here the max count of 10 can be provided by a Backend service through an API
    $scope.pagination = PaginatonService.Pagination(10);
});
myapp.controller('Controller2', function ($scope, PaginatonService) {
    // here the max count of 20 can be provided by a Backend service through an API
    $scope.pagination = PaginatonService.Pagination(20);
});

View Binding

Once the pagination service is added to the controller scope, the binding with AngularJS is straight forward. Here is an example with the Bootstrap CSS Pagination component:

<ul class="pagination">
   <li class="{{pagination.hasPrevious()?'':'disabled'}}"><a href="" ng-click="pagination.previous()">&laquo;</a></li>
   <li ng-show="pagination.hasPrevious()"><a href="">{{pagination.current() - 1}}</a></li>
   <li ng-hide="pagination.hasPrevious()"><span>&nbsp;</span></li>
   <li class="active"><a href="">{{pagination.current()}}</a></li>
   <li ng-show="pagination.hasNext()"><a href="">{{pagination.current() + 1}}</a></li>
   <li class="{{pagination.hasNext()?'':'disabled'}}"><a href="" ng-click="pagination.next()">&raquo;</a></li>
</ul>

I make use of the ng-show AngularJS directive to hide/show navigation on lower and upper data borders/limits.

References

Solving the “Plugin execution not covered by lifecycle configuration” error in Eclipse

In a recent project, we were using the “xmlbeans-maven-plugin” for XML parsing with the “xmlbeans” goal configured on the plugin. However we get this annoying error message about lifecycle configuration on Eclipse “Plugin execution not covered by lifecycle configuration”!

To fix this, one solution consists of adding an ignore configuration to the pom.xml file that says to eclipse to ignore that goal on validation. I personally don’t like this solution because It pollutes the project pom.xml file with IDE specific stuff; and this solution is specific to the project, i.e. you could have this problem on other projects and you just want to fix once for all.

The other solution, that I personally advise, is to add that same configuration to the lifecycle mappings file of the m2e eclipse plugin:

    1. Open the Eclipse preferences window and open the maven preferences page:

2014-05-14_1135

  1. Open the mapping file with “Open workspace lifecycle mappings metadata” and add the following configuration (actually this configuration is the same as the one that is inserted into the project pom file with the help of the “quick-fix” menu):
<?xml version="1.0" encoding="UTF-8"?>
<lifecycleMappingMetadata>
	<pluginExecutions>
		<pluginExecution>
			<pluginExecutionFilter>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>xmlbeans-maven-plugin</artifactId>
				<versionRange>2.3.3</versionRange>
				<goals>
					<goal>xmlbeans</goal>
				</goals>
			</pluginExecutionFilter>
			<action>
				<ignore />
			</action>
		</pluginExecution>
	</pluginExecutions>
</lifecycleMappingMetadata>

This solution will fix the problem for all the projects in your workspace.

Context

  • Eclispe 3.7
  • Maven 2.x
  • m2e eclispe plugin

 

The Reactive Manifesto

I recently read an article about “Reactive Applications” on the Reactive Manifesto website and I wanted to share this small paragraph with you. I found this part particulary interesting and give the main direction architects and developers should emphasize on when developing new applications:

“New requirements demand new technologies. Previous solutions have emphasized managed servers and containers. Scaling was achieved through buying larger servers and concurrent processing via multi-threading. Additional servers were added through complex, inefficient and expensive proprietary solutions.

But now a new architecture has evolved to let developers conceptualize and build applications that satisfy today’s demands. We call these Reactive Applications. This architecture allows developers to build systems that are event-driven, scalable, resilient and responsive: delivering highly responsive user experiences with a real-time feel, backed by a scalable and resilient application stack, ready to be deployed on multicore and cloud computing architectures. The Reactive Manifesto describes these critical traits which are needed for going reactive.”

Visit the original website of the Reactive Manifesto.

Spring MVC along with Spring Security 3.1 maven archetype

In a previous post I posted an article on a Spring MVC (with Apache Tiles) maven archetype project and I explained how to initiate such a Maven project using the supplied archetype.

In this post, I come with a new archetype that allows you initiate, via a single command line, a maven web project that is configured to use Spring MVC 3.1.4 along with Spring Security. Knowing how it can be sometimes painful to configure such a project and to overcome dependencies issues (version conflicts, missing dependencies issues and configuration issues), I wanted to share that with you.

The project is configured to use:

  • Spring MVC 3.1.4
  • Spring Security 3.1.4
  • Apache Tiles 2.2.2
  • Servlets API 2.5 (as provided)
  • jstl 1.2

The project comes up with the following configuration:

  1. Spring MVC is configured to Intercept /spring context requests: locate the file spring-servlet.xml
  2. Spring security is configured with two users, a regular user role user and an admin role user: locate the file spring-security.xml, it contains the two users logins and passwords
  3. (JSP) Tiles pages (view parts) are in the WEB-INF/jsp: users folder contains user role jsp pages and admin folder contains admin role jsp pages
  4. As examples, two servlets are pre-configured for each of the two users: the AdminPage1Controller.java and the Page1Controller.java
  5. The sidebar menu.jsp contains an example on how to filter content so that some content is only displayed when admin is connected

In order to use the archetype to initiate such a new maven project:

  1. Download the archetype maven project here and install it to your local repository using the following command
    mvn install:install-file -Dfile=springmvc3.1-security-archetype-1.0.0.jar -DgroupId=com.michir.projects -DartifactId=springmvc3.1-security-archetype -Dversion=1.0.0 -Dpackaging=jar -DgeneratePom=true [-DlocalRepositoryPath=[path to your local repository]]
    
  2. Once installed, generate your Spring MVC – Security project using the following maven command
    mvn archetype:generate -DarchetypeGroupId=com.michir.projects -DarchetypeArtifactId=springmvc3.1-security-archetype -DarchetypeVersion=1.0.0 -DgroupId=com.mycompany -DartifactId=myproject -Dversion=1.0.0-SNAPSHOT
    

It’s done … import your project into your favorite IDE as a maven project, compile and install on your favorite Web Application server and enjoy!

maven jaxb plugin configuration to generate XSD schema files

Here is how to configure your project in order to generate XSD schema files from Java JAXB annotated classes

<plugin>
 <groupId>org.codehaus.mojo</groupId>
  <artifactId>jaxb2-maven-plugin</artifactId>
  <version>1.5</version>
  <executions>
   <execution>
    <goals>
     <goal>schemagen</goal>
    </goals>
    <phase>generate-sources</phase>
    <configuration>
     <outputDirectory>${project.build.directory}/schemas</outputDirectory>
     <workDirectory>${project.build.directory}/generated-sources/jaxb</workDirectory>
    <includes>
     <include>${path_to_pojo_package}/*.java</include>
    </includes>
    <transformSchemas>
     <transformSchema>
      <uri>${namespace}</uri>
      <toFile>${xsd_filename}</toFile>
     </transformSchema>
    </transformSchemas>
   </configuration>
  </execution>
 </executions>
</plugin>

This will generate an XSD file named ${xsd_filename} in the target/schemas folder.

We chose the generate-source phase in order to make the schema file available for the sources (particularly for the test sources), in conjunction with the following resources configuration to add the schema to the generated artifact:

<resources>
 <resource>
  <directory>src/main/resources</directory>
 </resource>
 <resource>
 <directory>${project.build.directory}/schemas</directory>
  <targetPath>schemas</targetPath>
 </resource>
</resources>

A Maven configuration for a Java Webstart (JNLP) application – 2

In a previous post I detailed the Maven configuration to generate a Java Webstart application using the webstart-maven-plugin along with the maven-shade-plugin (the shade plugin allows to generate auto-executable jars).

I faced some troubles when I tried to use this configuration in another application requiring access to system resources (accessing files and directories for read and write operations) and using third party trusted libraries:

When the application needs grant access system resources, you must ask for that grant through the all-permissions configuration element in the jnlp file

<security>
     <all-permissions/>
</security>

However, to do this, you must sign all the jars: the application jar and the third party jars the application needs, and generally the third party jars you are using are signed and this makes the maven-shade-plugin fail when processing the whole. Even more, if the whole application is not signed with the same certification authority, it will fail executing on the client side.

So I ended up with this webstart-maven-plugin configuration (which happens to be even simpler than the one on my previous post):

<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>webstart-maven-plugin</artifactId>
 <version>1.0-beta-3</version>
 <executions>
  <execution>
  <id>package</id>
  <phase>package</phase>
  <goals>
   <goal>jnlp</goal>
  </goals>
  <configuration>
   <codebase>${jnlp.URL}</codebase>
   <jnlp>
    <mainClass>${mainClass}/mainClass>
   </jnlp>
   <pack200>true</pack200>
   <sign>
    <keystore>${jks.filPath}</keystore>
    <keypass>${jks.keyPass}</keypass>
    <storePass>${jks.storePass}</storepass>
    <alias>${jks.alias}</alias>
    <verify>false</verify>
    </sign>
    <unsignAlreadySignedJars>true</unsignAlreadySignedJars>
   </configuration>
  </execution>
 </executions>
</plugin>

Note also that there is no need to the maven-shade-plugin.

The unsignAlreadySignedJars property allows to unsign the third party libraries you are using, and signing them again with your signing configuration.

Replace in the above plugin configuration the ${jnlp.URL}, ${mainClass} and ${jks.X} parameters with yours.

Follow

Get every new post delivered to your Inbox.