Web applications: Java vs Javascript

We position Kauri as a REST-centric Java web application framework, and ourselves as Java developers, but the reality is that we are doing more and more with Javascript.

Web-applications moved from being “thin client” to “fat client“: every web-page can be a complete application downloaded into your browser. Web development is now about exposing server-side resources in a RESTful way, and developing fat clients using Javascript.

Previously web-frameworks focused on the thin client model. They offered solutions for managing transient application state: sessions, conversations and the like. Often they helped developers by hiding HTTP, URIs and HTML (not a bad thing per se). All UI-logic was on the server, sometimes enhanced with some optional client-side Javascript.

But this is more and more a thing of the past. Kauri counts on the browser to keep interaction state. As a consequence, for UI work the balance is moving from Java to Javascript. Major parts of application front-ends are now developed as Javascript running in the browser (cfr. Kauri Forms). Interestingly, this also means there is more shared ground between web-frameworks that employ different server-side base technologies.

For completeness, I should mention that there is still a lot of Web-centric server-side work. Neither does the focus on Javascript mean that I’m talking about Gmail-style single-URI applications.

While we can now develop richer applications, it did not necessarily become easier. But if you are interested in working on a platform focusing on RESTful web application development, with a broad scope, and rich browser-based clients, check out Kauri.

Daisy 2.3 preview

A lot has been happening in Daisy-land, but since I have only been involved from a long distance, I have neglected to report on it. With Daisy 2.3 on its way, it is high time summarize some of the major new features.

Search & replace

Search & replace is a new feature allowing to perform a search & replace across an arbitrary set of documents.

You start by making a selection of documents through a query or the document basket, and then specify the parameters:

The sensible case setting will perform a case-unsensitive search, and smartly replace the word keeping the original word casing.

After pressing search, the system searches through all documents (keeping you updated on progress), and displays what it has found. You can then review the found occurrences and confirm what needs to be replaced:

Both the ’search’ and the ‘replace’ actions are implemented as document tasks. Document tasks have existed for a long while in Daisy, and allow to reliably execute a task across a set of documents and track the progress.

Upload control

Uploading binary files in Daisy, authored with other applications, is easy. However it is rather complicated if you want to edit the uploaded content: you need to download it somewhere, open that file in your editor, when you’re done go in the Daisy document editor, and upload the new file, which means you’ll have to browse for it again in the file system.

Now there is the upload control, a Java applet, which removes all these steps. When editing a document with uploaded content, you’ll see a new edit button:

Pressing that button will launch the applet:

You simply need to press a button to open the file in the native application, and when you’re done press Save to upload it again to Daisy. That’s all there is to it.

Inline editing

Next to the normal Daisy document editor, there is now a new inline editor. The inline editor allows to edit documents right where they are displayed, without losing the (navigation) context. The document is styled as usual, with parts and fields arranged as defined by your own styling XSL, but the parts and fields become editable. As a consequence, parts and fields can be edited on the same page, without switching tabs.

The way it works is that in the document-styling XSL, you add some attributes on HTML elements which contain a part or field, to indicate that in edit mode, the element should be replaced with an editor for that part or field. When you’re viewing the document, everything is as before, except there will be an edit button. When you press the edit button, the inline editor is launched, which will execute the same XSL, but elements having the inline editing attributes will be replaced by the respective field or part editors. The field and part editors share the same code as with those in the normal Daisy editor.

Partial write access

In Daisy 2.2, partial read access was introduced. This made it possible that someone can read a document without necessarily being able to read all fields and parts of it.

Now, we have also added partial write access. Using the ACL, you can control which document properties a user can update. This is how the ACL write detail permissions screen looks like:

The document editor will of course only allow you to edit those things for which you have write permission.

Partial write access can be combined with partial read access. Previously, having write access on a document implied that you have full read access.

Customizable document browser

When creating a link in Daisy to other Daisy documents, you use the document browser dialog to look up the document you want to link to. This dialog is used in various locations: in the HTML editor, in the navigation tree editor, for link fields, in the workflow task screens, etc.

For Daisy 2.3, the document browser gained a lot of new functionality, and became completely configurable. You can for example create a specific document browser configuration for editing a certain type of link field. For multi-value link fields, the document browser is now used for editing all links, rather than only adding new links.

You can configure which search fields are visible and which columns are displayed in the result table. You can show and hide the document preview. New query features include the ability to embed the faceted browser and to create predefined named queries.

Chunked query styling

The same query result browser as used in the document browser, is also available as a query styling. This means that by adding a simple style_hint option to a query, the query results will be displayed in a table with chunk navigation.

In the editor:

In the rendered document:

Other

We replaced the proprietary PDF formatter used for the books with FOP, which we already used for on-the-fly single document PDFs, but at the time did not work good enough for the books. The full-text search screen is now configurable (you can hide certain fields from the form) and gained new possibilities (e.g. selection of arbitrary collections). Improvements were made to repository namespaces, workflow (among others, the possibility to edit parts and fields inline on the workflow task screens), the document editor (editor height is adjusted automatically to the window height, no “Change editor height” button anymore). The access rights of the document owner can now be defined in the ACL, instead of being hard-coded to ‘full access’.

Within a few weeks, the 2.3 release candidate will be available. We hope you will give it a try and are looking forward to your feedback.