I’ve just created the Hogan Template Compiler module which makes it easier to implement the entire process. It’s a simple framework-agnostic npm module which:

• Pre-Compiles mustache templates and partials on the server.
• Stringifies partials for use in the browser.

How the module works

1. The Hogan Template Compiler  reads the templates and partials
2. The browser requests the complete HTML page (including server-rendered partials).
3. The browser loads the pre-compiled partials (in the form of a simple JavaScript file).
4. The browser renders additional pre-compiled partials when needed.

Why pre-compiling and sharing templates is a good idea

There are heaps of benefits to pre-compiling and sharing templates! The biggest is performance.

Performance

Ajax onDomReady is suboptimal. It’s faster for the browser to display your web page if your server renders the entirety of every HTML response. This frees the browser from doing any additional ajax requesting or template compiling and rendering.

As an example, as it stands currently, if you go to someone’s twitter page then the static HTML file you’re served from the server is your own tweet stream, not of the user you’ve requested. The other user’s tweets are fetched via ajax and rendered over the top. This results in the pop you see when you first load the page.

Now, I’m not second-guessing Twitter’s choice in this matter as obviously there’s heaps of technical limitations running at their scale. However, if they could return the static HTML of the page you’ve requested, then your browsing experience would be better.

The Hogan Template Compiler allows you to render the entirety of your templates on the server making it possible to totally deliver every page of your site as quickly as possible. Subsequent rendering can be done in the browser with the shared pre-compiled partials which are created for you. They’re simply loaded as a JavaScript file.

SEO

Another benefit of having the entire page rendered server-side is that Google and other search engines can easily index all of your content.

One Template To Rule Them All

Using the very same templates for rendering on the server and in the browser means that there’s one source of truth for how your pages are rendered. Some of the sites I’ve worked on have had fragmented templating systems meaning I’d be forced to update the server-side and client-side templates separately.

Caching

Since the pre-compiled partials are delivered as a static JavaScript file, the browser will cache this for as long as you want it to.

How to use it

$npm install hogan-template-compiler

Load the module and point it to your partials directory:

var HoganTemplateCompiler = require('hogan-template-compiler'),

    templateDirectory = __dirname + "/views",
    hoganTemplateCompiler = HoganTemplateCompiler({
        partialsDirectory: templateDirectory + "/partials"
    });

Compile a template manually:

var compiledTemplate = hoganTemplateCompiler.compileTemplateFile(templateSourcePath);

Setup a route (in Express) to send the pre-compiled templates to the browser:

app.get("/templates.js",  function(req, res) {
    res.contentType(".js");
    res.send(hoganTemplateCompiler.getSharedTemplates());
});

For a working example with Express; try the following:

$ git clone https://dave-elkan@github.com/dave-elkan/pre-compiled-hogan-templates.git
$ cd pre-compiled-hogan-templates
$ npm install -d
$ node app.js

Get the Source

Grab yourself a copy at https://github.com/dave-elkan/hogan-template-compiler

1. it relieves the browser of having to compile your templates
2. you don’t have to clutter your markup with template source and
3. you can render on the client and server with exactly the same template without sending HTML down the wire.

The last point offers a significant SEO benefit: By combining server rendered markup for the first page a user visits and client-rendered pushState delivered markup thereafter, you satisfy both your own desire to have a dynamic web app and also Google’s desire to read static HTML.

I was surprised there wasn’t any immediately obvious equivalent to Closure Templates for node.js. I went as far as trying (in vain) to get ejs to export stringified functions. I quickly threw out that pursuit when I found Hogan.js.

Hogan.js, from Twitter, is an implementation of the mustache templating language for use in the browser and on the server with node.js.

An example of creating and using shared templates with Hogan.js

This example will render a simple article page using a mustache template which can be used by the server and the client. All of the snippets below are taken from a working Express app available on github.

Loading and compiling the shared templates

The following function loads templates to share between the server and client from a specified directory and compiles them to a stringified javascript function.

/**
 * Reads and compiles hogan templates from the shared template
 * directory to stringified javascript functions.
 */
function readSharedTemplates() {
    var sharedTemplateFiles = fs.readdirSync(sharedTemplateDirectory);

    // Here we'll stash away the shared templates compiled script (as a string) and the name of the template.
    app.sharedTemplates = [];

    // Hogan like it's partials as template contents rather than a path to the template file
    // so we'll stash each template in a partials object so they're available for use
    // in other templates.
    app.sharedPartials = {};

    // Iterate over each sharedTemplate file and compile it down to a javascript function which can be
    // used on the client
    sharedTemplateFiles.forEach(function(template, i) {
        var functionName = template.substr(0, template.lastIndexOf(".")),
            fileContents = removeByteOrderMark(fs.readFileSync(sharedTemplateDirectory + template, "utf8"));

        // Stash the partial reference.
        app.sharedPartials[functionName] = fileContents;
        // Stash the compiled template reference.
        app.sharedTemplates.push({
            id: functionName,
            script: hogan.compile(fileContents, {asString: true}),
            // Since mustache doesn't boast an 'isLast' function we need to do that here instead.
            last: i === sharedTemplateFiles.length - 1
        });
    });
}

Delivering the pre-rendered templates

The result of the hogan.compile function when you pass {asString: true} (highlighted above) will return a stringified javascript function which can be sent to the browser. The name of the template file is used as the id of the template.

The output of readSharedTemplates is sent to the following mustache template which renders them as a simple javascript object.

var templates = {
{{#templates}}
    "{{id}}": new Hogan.Template({{{script}}}){{^last}},{{/last}}
{{/templates}}
};

Note the triple mustaches around the script variable. This prevents the javascript being HTML escaped.

The output of this template looks something like this:

var templates = {
    "article": new Hogan.Template(function(c,p,i){i = i || "";var b = i + "";var _ = this;b += "<h2>";b += (_.v(_.f("headline",c,p,0)));b += "</h2>";b += "\n" + i;b += "<p>";b += (_.v(_.f("bodyText",c,p,0)));b += "</p>";b += "\n";return b;;})
};

Handling the requests

The following request handler responds with the template javascript file. You don’t have to do it this way. You could easily add the template javascript as an inline script tag in the HTML response.

/**
 * Request handler for pre-compiled hogan.js templates.
 *
 * This function uses a hogan template of it's own which renders
 * calls to Hogan.Tempate. See views/sharedTemplates.mustache.
 */
app.get("/templates.js", readSharedTemplatesMiddleware, function(req, res, next) {
    var content = sharedTemplateTemplate.render({
        templates: app.sharedTemplates
    });
    res.contentType("application/javascript");
    res.send(content);
});

For each request to this handler the readSharedTemplatesMiddleware function is call which reloads the shared templates in development mode.

The other request handler renders the HTML for the initial page. It uses the contents of the shared article.mustache file as a partial which is in turn loaded by layout.mustache (highlighted below).

/**
 * Request handler for the homepage.
 *
 * Renders a hogan template on the server side which contains a form
 * which will update the article section on the client using the
 * pre-compiled template.
 */
app.get("/", function(req, res, next) {
    res.render("layout.mustache", {
        context: {
            headline: "This is a server-side rendered headline",
            bodyText: "This is some bodytext"
        },
        partials: {
            "article": app.sharedPartials["article"]
        }
    });
});

Rendering the shared template in the browser

On the client we can refer to the pre-rendered template function by calling the templates.article function. i.e.

templates.article({
    headline: "This is a client-generated headline",
    bodyText: "This is a client-generated body"
});

will generate:

<h1>This is a client-generated headline</h1>
<p>This is a client-generated body</p>

Running the example

To illustrate the use of a pre-compiled shared template on the client I’ve put a form in the output of layout.mustache which will update the server-rendered article using the client-side pre-compiled template.

Give it a run for yourself!

$ git clone git://github.com/dave-elkan/pre-compiled-hogan-templates.git
$ cd pre-compiled-hogan-templates
$ npm install -d
$ node app.js

In my previous post A Layered Node.js Architecture using Express I wrote on the benefits of using a layered architecture and how to implement one in a node.js web app. This post goes one step further by introducing Layers, a module which will help automatically load and neatly setup the layers (and routes) of your web app.

Layers currently only supports Express, but adding support for other frameworks is simple. Feel free to submit a pull request!

The following is a description of how Layers works. For the impatient or code-hungry there is the working Layered Express example from which the following snippets are taken.

Layers performs two basic operations:

1. Loads all layer javascript files.
2. Loosely couples the layers and adds routes.

Installing

$ npm install layers

Example app

Simply require it and instantiate with your app, the path to your layers, a function which returns your wiring (more on this in the next section) and, optionally, an options object. i.e.

var Layers = require('layers').Express,
    wiring = require('./layers/wiring');
new Layers(app, __dirname + '/layers', wiring);

File Layout

In this example the layout of the directories is:

__dirname
   - layers
       - controllers
       - services
       - views

Loading Layers

Each directory nested immediately within the layers directory defines a layer.

Each of these layer directories are recursively scanned for javascript files which are imported using require. The result of the require is inspected for two possibilities:

1. An object
2. A function which returns an object.

The object loaded or returned from the function is appended to the app object under the layer’s namespace.

e.g.

/path/to/app/layers/controllers/BookController.js becomes app.controllers.bookController
/path/to/app/layers/services/AuthorService.js becomes app.services.authorService

One exception is made when loading the layer files: Any file whose name begins with “Base” is ignored.
This name can be overriden by specifying the `excludePrefix` option.

Wiring

To wire the layers together you need to create a ‘wiring’ function. This function takes the layer populated app object as it’s only parameter and returns a hash of arrays indexed by the route they service. i.e.

module.exports = function(app) {
    var controllers = app.controllers,
        views = app.views;

    return {

        "/": [{
                action: controllers.homeController.getAuthorAndBookList,
                views: {
                    html: views.homeView
                }
            }
        ],

        "/books": [{
                action: controllers.bookController.getBookIndex,
                views: {
                    html: views.bookIndexView,
                    json: views.jsonView
                }
            }
        ],

        "/book/:key": [{
                action: controllers.bookController.getBookByKey,
                views: {
                    html: views.bookView,
                    json: views.jsonView
                }
            }
        ],

        "/authors": [{
                action: controllers.authorController.displayAuthorList,
                views: {
                    html: views.authorIndexView,
                    json: views.jsonView
                }
            }
        ],

        "/authors/:key": [{
                action: controllers.authorController.displayAuthorByKey,
                views: {
                    html: views.authorView
                }
            }
        ]
    };
};

The format of the wiring object is important. Each route supports many handlers which all have to define action and view properties.

Actions

A handler’s Action is simply a reference to a function which accepts the request and response objects as well as the callback and next functions. They are called in the context of the app object which allows for easy access to all of the other layers.

Action functions generally belong to the Controller layer. They are responsible for pulling variables from the request, their validation and sending them to the Service layer. This contrived example does not allow any ’1s’ in the Author’s key which is silly, but stop and imagine authentication at this point.

You will also notice that this controller simply delegates to the service layer, but at the same time it shields it from the request and response objects.

The callback variable which is owned and created by Layers is passed straight through to the service layer.

module.exports = {

    displayAuthorList: function(req, res, callback) {
        this.services.authorService.getList(callback);
    },

    displayAuthorByKey: function(req, res, callback, next) {
        var authorKey = req.params.key;
        if (authorKey.indexOf("1") > -1) {
            callback(new Error("No ones allowed!"));
        } else {
            this.services.authorService.getAuthorAndTheirBooks(authorKey, callback);
        }
    }
};

Views

Views are wrappers around your favourite templating system. They also accept the request and response objects but also a third object which is the result of the action. This object is the payload sent to the template.

BaseExpressView can be used as a basis for your own Express (jade) Views. You only need to specify the “getTemplate” function.

Conclusion

Layers is a simple way to get your app up and running quickly in something which resembles a scalable way. It allows you to specify all of your routes in one place and to specify an ordered list of actions for each of them. It will load and run your layer code and namespace it on your app object for easy access.

Love to hear some feedback if you have any.

EDIT: Updated to replace gists with local code snippets. Gist wasn’t always loading.

Software used

• Node 0.4.3
• Express 2.0.0
• Expresso 0.7.3
• node-mongodb-native 0.9.1
• generic-pool 1.0.4
• MongoDB 1.6.3

View Layer

1. Accept some data
2. Apply any required formatting
3. Render

View instances wrap a template and supplies additional functions to help take the burdon off the templating system, whichever one you use. For example, text transformations, regular expressions, etc are best done outside of the template in a simple testable function. In the following AuthorView example, whilst being contrived, the format function sets the Authors name to upper case.

Controllers

1. Map a URI
2. Extract some parameters
3. Kick off some work (it’s not concerned what nor how it gets done)
4. Send the result to a View for rendering

This example illustrates the use of Controller.setupGetRoute, a convenience function which takes a route’s path, an action and a hash of Views mapped to the Accept header they respond to. The action property is a function in the current Controller instance which extracts the required parameters from the request and forwards them onto the Service Layer. Note the lack of error handling in the following AuthorController example. All errors resulting from the Service layer are passed from Controller.setupGetRoute directly to the callback, preventing clutter in the Controller instances.

For each request, the the Accept header is used to map the request to a View. If a match is made, the corresponding View’s render function is called with the request and response objects along with the result of the call to the action.

I accept that express middleware can be used instead of this call to the Service layer, however if you do you have to attach the result of the action to the request object. That feels a bit muddled to me.

Service Layer

1. Do something for the Controller
2. Return the result to the Controller

Try to think of the Service layer as the “do anything the Controller wants” layer. It consists of specific use-case functions, as in the following AuthorService gist. This function pull the author requested from the datastore and then grabs their books for good measure and returns the them both (or an error). The most important thing about the Service layer is that it separates the Controllers from the datastore or other sources of complexity. This ensures that writing (and testing) Controllers remains a simple task.

Services are inter-dependent singletons and are attached to the app. i.e. In the example below, the AuthorService uses the BookService to get the Author’s Books.

Data Access Layer

1. Put, Get, Update and Delete datastore entries.

The Data Access Layer is our last layer. It is hard-tied to the datastore of your choice and manages every interaction with it. Once again, encapsulation is the key. Having all of your database code decoupled from your Controllers and Services makes them easier to test. It also makes moving from one datastore to another a much less painful process.

In the example code, each dao is tied to its own collection. In so, calling getList from AuthorDao will return a list of authors, from BookDao, books and so on. For now the example only handles Put and Get operations to keep the example from growing too large. Feel free to send a pull request!

Working Example

Pull a clone of the working example here: https://github.com/dave-elkan/layered-express

Notes on Models

Mongoose is making great strides to becoming the ORM for node. It does a wonderful job of taking care of the heavy lifting of MongoDB abstraction, validation, defaults, etc. However I don’t use it in this example as one of my main goals with using a layering technique is that sources of Error are centralised and handled in as few places as possible. Mongoose uses an “enriched model” pattern (where every model object has a save, update and delete function). Whilst this is very convenient, I wanted to enforce my database transactions to take place from one central point.

After (OCZ Vertex II 120GB)

To say the least I’m more than happy. The over all score went from 165.24 to 260.85.

Next stop. 8GB of RAM.

So, being the inquisitive type, why wouldn’t I try r8 of the same ROM? I used ROM Manager to make a backup and install the ROM, but upon rebooting, something went wrong. I got a new Android splash screen, but it just kept on splashing, with no actual Android goodness at the end!

eep! Lucky I made a backup!

So my phone was borked, but I didn’t panic (yet) and got on to fixing it.

In the end, I’m still not sure what happened, but here’s my solution:

1. I eventually got the system to boot by choosing “Wipe cache partition” from Recovery mode only to find that the SD Card and USB had been disabled! This is where I panicked as that means no adb, no shell, no nothing!
2. My first step was to do as I usually do when something goes wrong and go back to step 1 and start again. This involved attempting to use the recovery script that came with my original rooting pack. This was a mistake and complete waste of time as my phone was already rooted.
3. I fixed the lack of SD Card by following some of the steps in this post:
   1. Enter fast boot mode with the USB cable attached.
   2. Type fastboot oem enableqxdm 0 at the command line (I used fastboot-mac from the guide linked at the top of this post)
4. I fixed the lack of USB connectivity by following the steps in this post.
5. I then made the mistake of restoring an old version of  Android (1.21). I put this down to a little bit of panic and having to multitask on other equally engaging tasks (i.e. work). Android 1.21 was great at crashing. I couldn’t even load the market place to install ROM Manager to restore my previous backup.
6. I eventually managed to restore my backup by using the recovery-update.zip file which is automatically packaged up with your ROM Manager backups by renaming it to update.zip and placing it at the root of my SD Card. I then performed the usual restore update.zip method in recovery mode.
   1. Loading this update.zip loads Clockworkmod, the brains behind ROM Manager. From here I was able to restore my backup.

Now, if only that burning desire to try again would go away…

Here’s 5 hints to help you get your LAN up and running and making the most of it.

1. Anonymous file server and DHCP
   99.9% of time spent at a LAN, especially one where you play old games not designed to run on modern operating systems, is stuffing around trying to get them to work. It is absolutely imperative that you have a dedicated anonymous file server upon which people can share the files required to run the games. This will eliminate unnecessary ”sharing” setup time. It will also prevent file server downtime as it will not need to be rebooted unlike client computers busy installing games.
   Another thing to make it easier is to have a local DNS server. I have a Mac Mini server which comes bundled with Mac OSX Server. Even a novice home networker can setup a local domain. Coupling this with a DHCP server setup with a default search domain means your guests can enter something like \\servername into their windows explorer or smb:\\servername in OSX to connect. No IP addresses!

2. Sustenance
   Gamers at LANs have highly very active brains and therefore need a high carb, high protein meal to allow them extreme accuracy with the Rail Gun. Contrary to modern belief, Pizza and Coke do NOT constitute any of these very important ingredients.
   If you’ve organised a LAN in the past you’ll know that as soon as it starts and you have your first coke / Jolt cola (or bourbon and coke if you’re so inclined) that everything goes CRAZY. As a part of the LAN setup process, construct, in a large pot, a large stew using gravy beef and vegetables. Put this in a slow cooker up to 10 hours ahead of dinner time and walk away. When the hunger calls simply dish up with some rice (can also be pre-prepared). This will keep your gamers alert and happy until the wee hours of the morning. Most importantly, it’s bloody cheap, ready when you want it and doesn’t involve picking up the phone!

   
   

3. Research
   The older a game gets the harder it is to run.
   Make sure you’re up to speed with DosBox (Boxer on Mac) and it’s ability to host IPX Tunnelling (IPX over TCP/IP).
   Experiment with the games you intend on playing ahead of time on your own. It took me a week of stuffing around to get Carmageddon running with 3DFX using a special version of DosBox with Glide support.

4. Power
   I’m sure you all know this, but ensure you spread your power load evenly across your wall sockets. Don’t go crazy with power boards hanging off power boards. Make sure extension cords are straight and not coiled when in use.

5. Do what you came to do. Have fun!
   Personally, when I go to a LAN, I get so excited and busy trying to fix all of the problems that all of my plans go out the window. It’s best to keep a list somewhere handy, say as your desktop background, which lists the games you want to play or things you want to do or share.
   So many times it’s 10 hours in and everyone’s thinking about going home that you remember you wanted to play Total Annihilation (a notoriously long game). So annoying!

]]> http://www.edave.net/2010/07/26/5-hints-on-holding-an-old-school-lan/feed/ 3 http://www.edave.net/2010/07/15/two-months-with-swype/ http://www.edave.net/2010/07/15/two-months-with-swype/#comments Thu, 15 Jul 2010 00:30:03 +0000 dave http://www.edave.net/?p=129 I’m writing this review on my Android powered HTC Desire using a new, custom keyboard called Swype.

Swype allows you to type whilst barely lifting your finger from the screen. As the name suggests, you swype your finger from letter to letter instead of tapping. This constructs a sort of letter trail which, once you lift your finger is inspected and the top ranking word from the letters you swyped is inserted. If there is more than one match, it will offer up a list of suggested words.
Other ham-fisted, clumsy typers like me will be happy to know that the trail by no means has to pass directly over each letter. Rather, as long as the trail is roughly near a letter it will be added to the mix, albeit with less priority (I think). When you experience this for the first time you realise that there’s a lot more going on behind the scenes than you might first think.

The experience of swyping is not second nature to anyone and there is a period of time where you find yourself wanting to revert to the default keyboard. However, for the persistent and forgiving, the reward with sticking with it will deliver a faster typing speed. How much faster? Fast enough to win a place in the Guiness Book of Records for the fastest text message typed, that’s how fast!

Speed, though, goes hand in hand with inaccuracy. At times I’ve found myself swyping in the wrong direction or blindly selecting the top most (and also wrong) suggestion, which is done automatically when you start swyping the next word.

So despite Swype being a totally different experience to a conventional on screen keyboard it’s easily withstood the hardest test of all. Not being noticed.

I’ve had Swype as my keyboard for over two months now and haven’t even thought of turning it off.

The beta has closed, but judging by the total lack of crashes I’ve experienced, the full version should be out shortly.

It took over at least two years, but I finally got a smart phone. An HTC Desire.

The iPhone, whilst appealing, never really seemed to end up in my possession for one reason or another. Adopting early or following the masses has never been my way. In fact, I’ll happily go the other way, with all of it’s bumps and bruises, just to show it can be done.

The HTC Desire is a fantastic phone. It’s smooth to touch and, being powered by a 1ghz snapdragon processor running Android, is also very smooth to interact with. The UI (powered by HTC’s Sense) flows from one state to the next. Nothing catches you by surprise.

Comparison to iPhone
I’m no seasoned iPhone user, however we do have one in the family which I am more than guilty of pinching for my own benefit quite a bit. The HTC Desire is in some ways a better experience.

First and foremost is that Android works on a different level to iPhone OS. Android supports multi-tasking out of the box, whereas iPhone OS will not offer this until version 4.0 is release later this year. Android phones, by design, also have 4 more hardware buttons than the iPhone’s 1. I can hear simplicity purists out there shifting in their seats as they read this, but it actually makes the phone more versatile.

Apple use a software review process to ensure that all of the guidelines (including ui guidelines) are adhered to. Google, through the use of physical buttons, have designed a contract with the developer that cannot be broken. Let me explain (from left-most button to the right-).

The home button
As on the iPhone, the home button will snap you straight back to your home screen no matter what you’re currently doing. It also doubles as a “open processes” button when held down allowing you to swap between applications which are open in the background.

The menu button
The menu button opens a contextual menu offering more options for the current application or screen.

The scrolly thing
The scrolly thing, which is also the “click” button, is an optical mouse turned up-side-down. It functions in the same way a track-ball does, albeit with no moving parts. It’s another part of this phone which feels smooth to touch.

The back button
The back button is easily the best and most used button. I love this button as much as it is legal to love a button as it releases the full power of the multi-tasking ability of the phone.
Say I am reading my twitter feed and someone has posted a link which I want to follow. In the Apple world hitting this link would either a) close the current application and open Safari or b) open an instance of safari within the current application displaying the page (which is simply more work for the developer). From a legal standpoint it can also allow people to view websites in your application that you don’t want associated with it.
In instance a the user, once they have finished reading the contents of the webpage, cannot get back to the Twitter stream without first closing Safari and re-opening the Twitter application.

However, on the Desire a simple click of the back button will instantly take you back to the Twitter stream. This is something the iPhone can never do due to it’s lack of a back button.

The back button also closes open dialogues or modal windows and takes you back when browsing websites.

The search button
Being a Google connected device, search is obviously quite prevalent in the design of this operating system. That said, I don’t actually use it that much.
The search button will open a search dialogue which pertains to the current application (if the application supports it or the whole phone if done if otherwise). If done from the web browser, the search context is obviously the web, if done from the calendar, the calendar will be searched.

The Internet
The web browser named simply “Internet” is an intuitive web-kit based app. It has a number of positives over Apple’s Mobile Safari.

1. Zooming.
   When zooming, for example, into the text of an article the enlarged text is reformatted to fit to the width of the phone. This prevents the need for excessive side-ways scrolling as is required on the iPhone.
   This saves your eyes and fingers from excessive wear.
2. Flash.
   Nuf said.

Freedom
When using an Android powered phone like the HTC Sense you can do this amazing thing called “choosing for one’s self”. That is, you are not locked into anything. For example, a simple download from the Market (app store equivalent) will give you a totally different keyboard implementation. Hell, you don’t even have to distribute your apps through the Market.

Down sides
There is only one bug that I’ve suffered from with the Android operating system. There’s a known bug with switching from Wifi to 3G. For some reason sometimes the 3G just doesn’t initialise again. The solution is to turn the phone onto Airplane mode and off again.

Conclusion
This phone has changed my life. I’m very happy with it even if it does give me an excuse to play pointless tower defence games on the bus.

Rather than have a new object defined with the single property, I used the @JsonSerialiser annotation to serialise only the property I was interested in.

I will use a ‘PublicFile’ Object as an example.

public class PublicFile {
  private String path;
 
  public String getPath() {
    return path;
  }
 
  public void setPath(String path) {
    this.path = path;
  }
}

If we were to serialise the an instance of this PublicFile Object using the Jackson Json processor, the result would be:

{
    "publicfile": {
        "path": "file path value"
    }
}

To return only the path property when serialising the instance to JSON, create a serialiser like:

public class PublicFilePathJsonSerialiser extends JsonSerializer<PublicFile> {
	@Override
	public void serialize(PublicFile file, JsonGenerator jgen,
			SerializerProvider provider) throws IOException,
			JsonProcessingException {
		jgen.writeString(file.getPath());
	}
}

And then reference it in your class:

@JsonSerialize(using = PublicFilePathJsonSerialiser.class)
public class PublicFile {
  private String path;
 
  public String getPath() {
    return path;
  }
 
  public void setPath(String path) {
    this.path = path;
  }
}

This produces:

{
    "publicfile": "file path value"
}