:%!tidy -i -xml -q

The -i option tells tidy that it needs to indent the content, -xml tells tidy that the content is well-formed XML, and -q puts tidy into “quiet mode” where extraneous information is suppressed. You can also specify ranges like so:

:40, 74!tidy -i -xml -q

This indents content between lines 40 and 74 (both lines inclusive). You can also do:

:., .+50!tidy -i -xml -q

This indents the current line and the next 50 lines. You can also do the same for HTML:

:%!tidy -i -xml -q

You can of course, supply additional parameters to tidy to customize the indenting.

:%!tidy -i -q

As I mentioned before, getting zoom to work was pretty easy. Implementing panning/dragging was the hard part. The major issues I encountered and subsequently fixed were the following:

1. Panning continues indefinitely in all directions.
2. When you zoom and then pan, stop, and then start again, the view jerks to a new position instead of panning from the existing position.
3. Excessive panning towards the left and top can be constrained, but panning towards the right and bottom is not so easily constrained.

Once I fixed all the problems, I figured that it would be nice to document it for future reference, and I also think it would be a useful resource for others who have the same problem. Now a little disclaimer before I go any further: I’m not an Android expert and I’m really not that great with graphics; I just started it learning to program for Android this semester for one of my Masters electives. So there might be a better way of doing all this, and if there is, please let me know! Also, if you want to skip all the explanations and just see the code, you can skip to the last page.

Let’s start with the simple stuff first, that is implementing pinch-zoom. To implement pinch-zoom, we make use of the ScaleGestureDetector class. This class helps you detect the pinch-zoom event. Using it is pretty simple:

public class ZoomView extends View {

    private static float MIN_ZOOM = 1f;
    private static float MAX_ZOOM = 5f;

    private float scaleFactor = 1.f;
    private ScaleGestureDetector detector;

    public ZoomView(Context context) {
        super(context);
        detector = new ScaleGestureDetector(getContext(), new ScaleListener());
    }

    @Override
    public boolean onTouchEvent(MotionEvent event) {
        detector.onTouchEvent(event);
        return true;
    }

    @Override
    public void onDraw(Canvas canvas) {
        super.onDraw(canvas);

        canvas.save();
        canvas.scale(scaleFactor, scaleFactor);

        // ...
        // your canvas-drawing code
        // ...

        canvas.restore();
    }

    private class ScaleListener extends ScaleGestureDetector.SimpleOnScaleGestureListener {
        @Override
        public boolean onScale(ScaleGestureDetector detector) {
            scaleFactor *= detector.getScaleFactor();
            scaleFactor = Math.max(MIN_ZOOM, Math.min(scaleFactor, MAX_ZOOM));
            invalidate();
            return true;
        }
    }
}

Your view class has four private members: MIN_ZOOM, MAX_ZOOM, detector, and scaleFactor. The first two are static constants that define the maximum and minimum zoom allowed. The third is of type ScaleGestureDetector and does all the heavy lifting as far as zooming is concerned. The fourth member holds the scaling factor i.e., a number that represents the amount of “zoom”.

Now what does this do?

In the constructor, you initialize the detector. The constructor to ScaleGestureDetector takes two parameters: the current context, and a listener. Our listener is defined inside the class ScaleListener which extends the abstract class ScaleGestureDetector.SimpleOnScaleGestureListener. Inside the onScale method, we get the current scale factor from the detector. We then check to see if it is greater or smaller than our upper and lower bounds. If so, we make sure that it we limit the value to be between those bounds. We then call invalidate() which forces the canvas to redraw itself.

The actual scaling happens inside the onDraw method. There, we save the canvas, set its scaling factor (which is the one we got from the detector), draw anything we need to draw, and then restore the canvas. What happens now is that anything you draw on the canvas is now scaled by the scaling factor. This is what gives you the “zoom” effect.

The end result was Akṣi, a neural network that recognizes hand-written digits. I’ve hosted it using Google’s App Engine. Please check it out!

Initially I was going to call the render(…) method of MappingJacksonJsonView but that didn’t work because the content-type had already been set to application/json. The solution I came up with was to duplicate some of the code (ugh) inside MappingJacksonJsonView to get the JSON as a string and to then write that to the response:

@RequestMapping
public void processFileUpload(HttpServletResponse response, Model model, ...) {

    ...

    //Set the content-type and charset of the response
    response.setContentType("text/plain");
    response.setCharacterEncoding("UTF-8");

    //I need to use another OutputStream here; I cannot use the response's OutputStream because that will cause errors
    //later on when the JSP needs to render its content (recall that getOutputStream() can only be called exactly once
    //on a response). Therefore I'm writing the data to a ByteArrayOutputStream and then writing the byte array from
    //the ByteArrayOutputStream to the response manually.

    ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
    ObjectMapper objectMapper = new ObjectMapper();
    JsonGenerator generator = objectMapper.getJsonFactory().createJsonGenerator(byteArrayOutputStream, JsonEncoding.UTF8);

    //Before I can convert the data into JSON, I will need to filter some attributes out of the model (namely BindingResult)
    Map<String, Object> result = new HashMap<String, Object>();

    for(Map.Entry<String, Object> entry : model.asMap().entrySet()) {
        if(!(entry.getValue() instanceof BindingResult)) {
            result.put(entry.getKey(), entry.getValue());
        }
    }

    objectMapper.writeValue(generator, result);
    response.getWriter().write(new String(byteArrayOutputStream.toByteArray(), "UTF8"));
}

This still seems a little hacky to me. A possible improvement is to annotate the action with @ResponseBody and return the JSON as a string without involving the response at all. If anyone has a better solution, I’m all ears!

$str .= '<img src="'.site_url('?ak_action=api_record_view&#38;id='.$post->ID.'&#38;type=feed').'" alt="" />';

The whole story: At work we use Maven to build our project. Over the last few months, we started noticing a disparity in build times between different developers even though the hardware they were using was similar to each other (Core i7′s with 6 Gb RAM). Initially we suspected that it might have to do with SSD performance-degradation. Some of us were using SSD’s that didn’t support TRIM and others didn’t have TRIM enabled. I was one of the few with the former problem. I secure-erased my drive but still saw no performance benefits. I even got a new drive and even with that I didn’t see much of an improvement either.

We finally realized that the build-time disparity was related to the version of maven some developers were using. On maven 3.0b1, build times are much faster compared to 3.0.3. In 3.0.3 there is a performance regression when maven tries to build the dependency graph. For example, using 3.0b1 our project built in 3 minutes and 30 seconds, whereas using 3.0.3, the build times were upwards of 9 minutes. Long build-times take away from the amount of productive coding-time a developer has.

I was determined to find the reason for this performance regression and did some investigation by looking at the source for 3.0b1 and 3.0.3. In 3.0b1, maven uses its own code to resolve dependencies and build the dependency graph, whereas in 3.0.3 it uses the aether library. For more background information on the matter, take a look at this post on the maven developer’s mailing list and this JIRA issue.

Long story short, to get better build times, maven needs to use version 1.12 of aether. I downloaded the maven source and edited the pom.xml file to use version 1.12 of aether. I then built maven from source and got a deployable version that uses the newer aether library. When I tested it out, the build times were comparable to 3.0b1.

I initially thought that version 3.0.4 of maven would include version 1.12 of aether. But it turns out that there were licensing changes and so the maven developers are discussing whether to include it. In the meantime, you can use this version of maven that I built from source, which includes version 1.12 of aether. It’s a zip file and you can install it like you would normally install maven.

Here’s an example of what I had to work with, from the XML document (this is not the exact document; it’s just an example that follows the structure):

<tables>
 <table name="Contact" access="EDAR">
  <fields>
   <field name="FirstName" />
   <field name="LastName" />
   ...
   <field name="LastUpdated" type="DateTime" access="R" />
  </fields>
 </table>
</tables>

As you can see, the structure is pretty simple. As far as the resulting API documentation was concerned, what I wanted was an index.html that contained links to other pages. These other pages should be structured so that there is an HTML page for each table. This page will contain information about the table fields, as well as their access modes (E: Edit, D: Delete, A: Add, R: Read). As it turns out, in XSLT 1.0, you cannot create separate documents. You can only transform one document into another document. In XSLT 2.0 however, you can transform one document into multiple documents using the xsl:result-document instruction.

The XSLT that I’ve written is pretty straightforward (if you know XSLT; even if you don’t, you can kinda get the gist of it from the instructions). The only thing I had trouble with was translating the access-mode letters into their expanded forms. To do this, I had to write a recursive template that looks at each character (there are other ways). This is where the functional aspect of XSLT comes into play. Once I started thinking of XSLT like Lisp, it became much easier to write my solution because I wasn’t fighting the language. Anyway, here is my solution:

<?xml version="1.0"?>
<xsl:stylesheet version="2.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

 <!--
  XSLT document that transforms Infusionsoft's API Field-Access XML into HTML pages
  Author: Vivin Suresh Paliath
  Date: 4/11/2011
 -->

 <xsl:output method="text" />
 <xsl:output method="html" indent="yes" name="html" />

 <xsl:template name="translateAccessModes">

  <xsl:param name="accessModes" />

  <xsl:if test="string-length($accessModes) > 0">

   <xsl:variable name="accessMode" select="substring($accessModes, 1, 1)" />
   <xsl:choose>
    <xsl:when test="$accessMode='E'">Edit </xsl:when>
    <xsl:when test="$accessMode='D'">Delete </xsl:when>
    <xsl:when test="$accessMode='A'">Add </xsl:when>
    <xsl:when test="$accessMode='R'">Read </xsl:when>
    <xsl:otherwise>Unrecognized Access Mode: <xsl:value-of select="$accessMode" /> </xsl:otherwise>
   </xsl:choose>

   <xsl:call-template name="translateAccessModes">
    <xsl:with-param name="accessModes" select="substring($accessModes, 2, string-length($accessModes))" />
   </xsl:call-template>

  </xsl:if>

 </xsl:template>

 <xsl:template match="/">
  <xsl:result-document href="tables/index.html" format="html">
   <html>
    <xsl:comment> Generated via XSLT on <xsl:value-of select="format-dateTime(current-dateTime(), '[F], [MNn] [D], [Y] at [h]:[m01] [P]')" /> </xsl:comment>
    <head>
     <title>Infusionsoft Table-Access Documentation</title>
     <link rel="stylesheet" href="styles.css" />
    </head>
    <body>
     <h2>Database Tables &amp; Fields</h2>
     <div id="tables">
      <ul>
       <xsl:for-each select="//table">
        <xsl:variable name="filename" select="concat('tables/', @name, '.html')" />
        <xsl:variable name="tableAccessModes">
         <xsl:choose>
          <xsl:when test="@access!=''">
           <xsl:call-template name="translateAccessModes">
            <xsl:with-param name="accessModes" select="@access" />
           </xsl:call-template>
          </xsl:when>
          <xsl:otherwise>Edit Delete Add Read</xsl:otherwise>
         </xsl:choose>
        </xsl:variable>
        <li>
         <xsl:element name="a">
          <xsl:attribute name="href"><xsl:value-of select="concat(@name, '.html')" /></xsl:attribute>
          <xsl:value-of select="@name" />
         </xsl:element>
        </li>

        <xsl:result-document href="{$filename}" format="html">
         <html>
          <xsl:comment> Generated via XSLT on <xsl:value-of select="format-dateTime(current-dateTime(), '[F], [MNn] [D], [Y] at [h]:[m01] [P]')" /> </xsl:comment>
          <head>
           <title><xsl:value-of select="@name" /> Table (Access Modes: <xsl:value-of select="substring($tableAccessModes, 1, string-length($tableAccessModes) - 1)" />)</title>
           <link rel="stylesheet" href="styles.css" />
          </head>
          <body>
           <h2><xsl:value-of select="@name" /></h2>
           <table>
            <tr>
             <th>Field Name</th>
             <th>Type</th>
             <th>Access</th>
            </tr>

            <xsl:for-each select="./fields/field">

             <xsl:variable name="fieldType">
              <xsl:choose>
               <xsl:when test="@type!=''"><xsl:value-of select="@type" /></xsl:when>
               <xsl:otherwise>String</xsl:otherwise>
              </xsl:choose>
             </xsl:variable>

             <xsl:variable name="accessModes">
              <xsl:choose>
               <xsl:when test="@access!=''">
                <xsl:call-template name="translateAccessModes">
                 <xsl:with-param name="accessModes" select="@access" />
                </xsl:call-template>
               </xsl:when>
               <xsl:otherwise><xsl:value-of select="$tableAccessModes" /></xsl:otherwise>
              </xsl:choose>
             </xsl:variable>

             <xsl:variable name="rowClass">
              <xsl:choose>
               <xsl:when test="(position() mod 2) = 0">even</xsl:when>
               <xsl:otherwise>odd</xsl:otherwise>
              </xsl:choose>
             </xsl:variable>

             <xsl:element name="tr">
              <xsl:attribute name="class"><xsl:value-of select="$rowClass" /></xsl:attribute>
              <td><xsl:value-of select="@name" /></td>
              <td><xsl:value-of select="$fieldType" /></td>
              <td><xsl:value-of select="$accessModes" /></td>
             </xsl:element>
            </xsl:for-each>

           </table>

           <h2><a href = "index.html">Back to list of tables</a></h2>

          </body>
         </html>
        </xsl:result-document>

       </xsl:for-each>
      </ul>
     </div>
    </body>
   </html>
  </xsl:result-document>
 </xsl:template>
</xsl:stylesheet>

That’s all there is to it! To actually use the XSLT document to generate the API HTML files, I used Saxon, which supports XSLT 2.0. This is how I used it:

java -cp saxon9he.jar net.sf.saxon.Transform -t -s:api_field_access.xml -xsl:api_doc.xslt

So if you’re an Infusionsoft customer or a developer who is reading the API documentation, you now know how it was generated!

Although I pulled my hair out for an hour or two (I was getting a 404 when hitting my controller with with a .jsonp extension; I’ll explain why, later), the resulting solution is actually pretty simple. First, you need to extend MappingJacksonJsonView to create your own view. Since MappingJacksonJsonView already handles the creation of JSON, all we need to do is pad it with our callback. The way to do this is to override the MappingJacksonJsonView#render(Map model, HttpServletRequest request, HttpServletResponse response) method (This method is actually defined in AbstractView, a Spring-provided abstract class that you can override in your own view). The full source is below:

package net.vivin.mvc.spring.view.jsonp;

import org.springframework.web.servlet.view.json.MappingJacksonJsonView;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.util.Map;

public class MappingJacksonJsonpView extends MappingJacksonJsonView {

	/**
	 * Default content type. Overridable as bean property.
	 */
	public static final String DEFAULT_CONTENT_TYPE = "application/javascript";

    @Override
    public String getContentType() {
        return DEFAULT_CONTENT_TYPE;
    }

 	/**
	 * Prepares the view given the specified model, merging it with static
	 * attributes and a RequestContext attribute, if necessary.
	 * Delegates to renderMergedOutputModel for the actual rendering.
	 * @see #renderMergedOutputModel
	 */
    @Override
	public void render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception {

        if("GET".equals(request.getMethod().toUpperCase())) {
            @SuppressWarnings("unchecked")
            Map<String, String[]> params = request.getParameterMap();

            if(params.containsKey("callback")) {
                response.getOutputStream().write(new String(params.get("callback")[0] + "(").getBytes());
                super.render(model, request, response);
                response.getOutputStream().write(new String(");").getBytes());
                response.setContentType("application/javascript");
            }

            else {
                super.render(model, request, response);
            }
        }

        else {
            super.render(model, request, response);
        }
    }
}

The DEFAULT_CONTENT_TYPE public static property and the getContentType() method are important. Spring uses this method (among other things) to find the best candidate view. I spent at least an hour trying to figure out why I was getting 404′s. It was because I hadn’t overridden the property and the accessor to return the correct content-type. Going back to the render method itself, you can see that it’s pretty simple. First I make sure that the request method is GET. Then I get the request parameter-map and check for the callback parameter. If this parameter exists, I write out the name of the callback with an open parenthesis. Then I call the parent class’s render method. This method belongs to MappingJacksonJsonView and will write out JSON to the response. Finally, I write out a closing parenthesis and a semicolon to the response and set the content type to application/javascript. So as you can see, I’ve converted JSON into JSONP.

The next thing you need to do is include an entry for your new view in the springmvc-servlet.xml file. This part also took a little work. I wasn’t sure how to include my new view within the ContentNegotiatingViewResolver bean. But this post proved to be remarkably helpful. The post actually talks about returning XML or JSON (based on the extension), but I was able to adapt it to return JSON or JSON. Here’s what it looks like:

    <bean class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver">
        <property name="favorPathExtension" value="true"/>
        <property name="mediaTypes">
            <map>
                <entry key="json" value="application/json"/>
                <entry key="jsonp" value="application/javascript"/>
            </map>
        </property>
        <property name="defaultViews">
            <list>
                <bean class="org.springframework.web.servlet.view.json.MappingJacksonJsonView"/>
                <bean class="net.vivin.mvc.spring.view.jsonp.MappingJacksonJsonpView"/>
            </list>
        </property>
    </bean>

If you notice, the value property for jsonp has been set to application/javascript. Spring uses this value and checks it against the view class to figure out the best candidate view. If you didn’t override the DEFAULT_CONTENT_TYPE property and the associated getter, you would get a 404.

Finally, you need a url-pattern entry under servlet-mapping in your web.xml file so that the new .jsonp extension is recognized:

    <servlet-mapping>
        <servlet-name>springmvc</servlet-name>
        <url-pattern>*.json</url-pattern>
        <url-pattern>*.jsonp</url-pattern>
        ...
    </servlet-mapping>

That’s pretty much it. With this code in place, you can hit your controller with http://my.domain.com/controllerName/actionName.jsonp?callback=myCallback and you’ll get your data back as JSONP! I thought this solution was pretty simple and a little less invasive than creating a filter. Comments/suggestions/criticisms for improvement are welcome!

The source for the integration is also hosted on GitHub. My approach towards translating validation constraints from the server-side to the client-side was two-fold: gather validation constraints from the object and represent it in a canonical form. Using the canonical form, generate Javascript code that uses Regula for validation. To do this, I created a service that examines a domain object and gathers all information regarding its properties and validation constraints. The service returns this information in a canonical form, that I then inserted into the model. On the client-side, I had a tag that used the canonical form and outputted Javascript that uses the Regula framework. Initially, I was calling the service explicitly from an action in the controller. Later, in an effort to make the integration less-invasive and more seamless, I used an aspect-oriented approach with interceptors. In fact, that’s where I’d like to start.

I created an annotation called @ValidateClientSide that marks a domain object as requiring client-side validation. Then, I created an interceptor called ClientSideValidationInterceptor that will call the validation service and gather validation information:

If you’re trying to distribute tag files in a JAR, you need to put them under /META-INF/tags. You then need to create a TLD file that you also put under /META-INF/tags. If you have tags or functions that you created in Java, and want to distribute them alongside the tag files, you need to reference them in the TLD and package them in the same JAR (goes without saying).

If you want to do the same thing in maven, the location for the tag files and the tld file is different; you need to put them in src/main/resources/META-INF/tags. Then you can run mvn package and maven will create a JAR with your tags.

My directory structure in my maven project looks like this:

src
`-- main
    |-- java
    |   `-- net
    |       `-- vivin
    |           `-- regula
    |               `-- validation
    |                   `-- util
    |                       `-- TagStringUtils.java
    `-- resources
        `-- META-INF
            `-- tags
                |-- generate-validation.tag
                `-- regula-spring.tld

And my TLD file looks like this:

<taglib>
 <tlib-version>1.0</tlib-version>
 <short-name>regula-spring</short-name>
 <uri>http://regula-spring</uri>
 <jsp-version>2.0</jsp-version>

 <tag-file>
   <name>generate-validation</name>
   <path>/META-INF/tags/generate-validation.tag</path>
 </tag-file>

 <function>
   <name>matches</name>
   <function-class>net.vivin.regula.validation.util.TagStringUtils</function-class>
   <function-signature>boolean matches(java.lang.String, java.lang.String, java.lang.String)</function-signature>
 </function>

 <function>
   <name>replaceUsingRegex</name>
   <function-class>net.vivin.regula.validation.util.TagStringUtils</function-class>
   <function-signature>java.lang.String replaceUsingRegex(java.lang.String, java.lang.String, java.lang.String, java.lang.String)</function-signature>
 </function>
</taglib>