Pages JSP

Why using JSP pages in a plugin ?

When you are dealing with the standard back-office, you might want to customize for a customer the standard behaviour of a page.

You can use the "monkey-patching" technique, by duplicating the standard JSP in you _perso folder, and adding your customized code in that duplicated JSP. But this technique cannot isolate a particular functionality in your _perso : all customization are mixed, which can lead to quite a mess. You cannot easily activate / deactivate a customization either.

The plugin customization of JSP aims at solving this issue : the customizations are all gathered in the Plugin, which can be activated / deactivated at will.

This will also work for front-offices created with JSP : you will be able to modify their standard behaviour by hooking you code from a plugin.

Where are located the customized JSPs ?

In the plugin folder, there is a page directory : this is where all JSP created for your plugin are located.

When are these JSP called ?

The JSP in a plugin are called automatically if the "standard" page uses the noheto:include tag.

There is a catch : the pages are called only before or after the standard page.

For example,

if in the _san there is a page that includes the /foo/bar.jsp with <noheto:include page="/foo/bar.jspz" />,
the engine will scan for all plugins that have a :
- page/foo/bar_before.jsp or
- page/foo/bar_after.jsp

And will include them before or after the /foo/bar.jsp

Should the /foo/bar.jsp actually exist ?

No, the entry point is the <include> tag, not the /foo/bar.jsp page.

Let’s imagine that you have the following code in a JSP :

Copy<noheto:include page="/foo/bar.jspz">
    <noheto:include page="/foo/foobar.jspz">
    </noheto:include>
</noheto:include>

But neither /foo.bar.jsp nor /foo/foobar.jsp exist.

You may have plugins that have in their page directory :

/foo/bar_before.jsp
/foo/bar_after.jsp
/foo/foobar_before.jsp
/foo/foobar_after.jsp

Sidenote: If /foo/bar.jsp exists, then /foo/foobar.jsp won’t be executed

Example of _before / _after inclusion

In your plugin directory, in the page directory, create this folder hierarchy : bov3/dataindex/content/blocs

This is pointing to a back-office (bov3) section that handles the dashboard (dataindex) content display, for every dahboard block (blocs)

We would like to add a message before the blocks.

So we will create into our plugin / page / bov3/dataindex/content / directory a new "hook" page : blocs_before.jsp

And fill it with basic content :

Copy<%@page pageEncoding="ISO-8859-15" %>
<%@taglib prefix="noheto" uri="/WEB-INF/noheto.tld" %>
<%@taglib prefix="c" uri="/WEB-INF/c.tld" %>
<noheto:skipPage test="${not pageContext.request.included}" />
<h1>Hello World</h1>

This page will be called before each bloc is displayed, and will output a big Hello World.

Multiple plugins using the same hook

When multiple plugins are using the same hook, you might want to choose in which order they are called : the admin interface for the plugins provides a way to arrange the active plugins that hook on the same include :

Where you can sort plugins : in our example, the plugins that are hooking on the head CSS call :

Direct call to a JSP : AJAX or REST call

You might want to create a page that may be called by an external entry point. This can be useful to quickly develop web services, or endpoints for AJAX calls, or REST endpoints.

For example, let’s imagine we need to return a JSON list of images from the DAM in response to a query.

Let’s create this "image.jsp" page into the page directory of a plugin named IMAGE_LIST:

Copy<%@page contentType="application/json" pageEncoding="UTF-8" import="wsnoheto.engine.*"%>
<%@taglib prefix="c" uri="/WEB-INF/c.tld" %>
<%@taglib prefix="noheto" uri="/WEB-INF/noheto.tld" %>
<%@taglib prefix="json" uri="/WEB-INF/json.tld" %>
<%@taglib prefix="fn" uri="/WEB-INF/fn.tld" %>

<%--
Values expected in the URL query string :
o = Name is the dam object name to use, if absent the value from a plugin parameter named defaultObject will be used
q = the full text query received in the query string
w = the maximum width of previews that are returned as links in the JSON (there is a defaultWidth parameter in the plugin)
m = the maximum image count to return in the JSON array (there is a maxImages parameter in the plugin)
--%>

<%
response.addHeader("Access-Control-Allow-Origin", "*");
%>
<json:object>
  <json:property key="images">
    <json:array>
      <noheto:objectsList var="img"
        objectName="${not empty param.o ? param.o : plugin.parameters['defaultObject'].value}"
        fullText="${param.q}"
        nbrmax="${not empty param.m ? param.m : plugin.parameters['maxImages'].value}"
        orderby="pmodified desc">
        <noheto:imageUrl var="preview" src="${img.CTObject.thumbnailUrlFull}"
        width="${not empty param.w ? param.w : plugin.parameters['defaultWidth'].value}"
        suffix="${plugin.parameters['imageSuffix'].value}"/>
        <noheto:applicationVariablesReplace var="preview" value="{server.http.scheme}://{server.http.name}:{server.http.port}${preview}" />

        <json:object>
          <json:property key="title" value="${img.properties[8]}" />
          <json:property key="image" value="${preview}" />
        </json:object>

      </noheto:objectsList>
    </json:array>
  </json:property>
</json:object>

By calling from an external javascript file the URL

http://url:port/yoursandirectoryname/_plugins/IMAGE_LIST/page/images.jspz?q=blue"

We will get a JSON list of images that match the full text search "blue".

Direct call to a JSP : complete web page

In the same fashion, JSP pages from your plugin may be totally standalone.

Let’s create in the page directory of your plugin the following page "entrypoint.jsp"

Let’s create another page into our plugin / page / bov3/dataindex/content / directory a new "hook" page : blocs_before.jsp

Note : getPagePath will return path part containing page directory name and trailing '/', that’s why we wrote <c:url value="${plugin.pagePath}entrypoint.jspz"/>

The dashboard blocks will display a link to the standalone page hosted by the plugin "Entry Point" we defined previously.