Thanks to a high level of browser support and projects like Google's SVGWeb, HTML5 and SVG are well on their way to standardizing many rich web capabilities that were at one time only possible through plugins. SVG is now more of a first-class citizen in ItsNat 0.7. The framework adds more support for SVG in native browsers and even Internet Explorer, with new plugins including Adobe SVG Viewer (v3 and v6), Renesis 1.1, Savarese Ssrc, SVGWeb, and Batik as applet.
SVG along with any other non-XHTML namespace can now be embedded inline with XHTML that is served with MIME "text/html" using a browser with native SVG support. The new SVGWeb and Adobe SVG Viewer plugins can both embed MSIE and MIME SVG code inline in XHTML with dynamic DOM behavior. This feature with Adobe SVG Viewer is only available in ItsNat and it is useful on a single page interface application where there is no page navigation. The support for SVGWeb in ItsNat is special because the SVGWeb API is hidden and many problems with it are avoided because SVG DOM is managed on the server-side.
A few more things that have been added to ItsNat 0.7 include better (X)HTML support, MSIE with the Savarese Ssrc plugin, XUL including Ajax in Gecko browsers, and some support for Google App Engine including Ajax. ItsNat, Vaadin, and ZK are the only server centric frameworks with built-in Ajax support running GAE.
Below are some excepts from Geertjan Wielenga's interview with Jose Maria Arranz, the author of ItsNat. They give some insight into the motivations behind ItsNat's creation.
When I read about these web frameworks, I usually thought: “Oh my God, what a ton of artifacts! Java web development is becoming a nightmare, I think another web framework should be possible”. When I say “artifacts”, what I mean is the custom tags and tag libs that are mixed with tons of XML-based programming, language expressions, XML based navigation, XML descriptors for bindings, and so on.
Arranz was influenced by Wicket, but wanted a truly pure HTML component:
ItsNat was motivated partially by Wicket. But the pure HTML promise is broken in Wicket too, with custom tags like <wicket:extend> <wicket:link> <wicket:panel> and < wicket:head>. And, when you see some components, for instance the tree component, the HTML content of the component is missing in the template and is generated as a typical black boxed component. This is not very different to custom tags generating markup. I am not railing against Wicket, this is the correct way to improve web frameworks (I would do the same) and is a direct consequence of the traditional techniques of templating, that is "dead markup", where the template is basically raw text and only custom "marks" like custom tags and custom attributes are the live elements.
He explains why it is important to keep control of the HTML layout:
Because that is the web culture: the web is an amazing place of visual innovation, including web applications. When anyone develops a Swing application, there is not very much space for visual design, unless you are Romain Guy or Chet Haase... in the web space, anyone can change the visual appearance of a web application. Furthermore, on the web it is not difficult to create a list or a table containing complex forms, while in Swing the JList or JTable is not so easy to customize.
To summarize his message, Arranz says:
ItsNat is a dual licensed under the Affero General Public License v3 for open source, and a commercial license for closed source projects.