• Overview
• Download
• Japano Online Demo
• Developing with japano
  • Writing custom tags
  • Writing actions
  • Action lifecycle
  • Japano Session Handling
  • Setting up a project
• Annotation Reference
  • @JapanoTag
  • @JapanoAction
  • @JapanoBean
  • @JapanoValidation
  • @JapanoFunction
  • Java 1.4 compatibility
• Javascript API
• Japano Configuration
• API Documentation
• JSP Engine
• Japano Project page
• Contact / Support

JSP Engine Tech

The java sources japano generates out of JSP Document have another structure than usual. Japano uses the JSP document elements to create a tree of page node instances and Strings. The full tree is created when the page instance is created. It is initialized with constant attributes (included constant expressions) once. When the page is generated the page is first initialized with the current scopes and the current buffer. The tree nodes is visited recursively to dump their children to the current buffer. After all page nodes have dumped their children successfully, the content of the buffer is sent back to the client.

The buffer just doesn't have a normal buffer but collects the string instances the page nodes give him or creates new string objects where the page node output is not a string with new string creation being the exception. ( If you want to grok this in detail take a look at the source of org.japano.PageNode and the generated JSP java sources under WEB-INF/scratch )

EL expression compiler

Japano converts the EL expressions into equivalent java expressions at JSP compilation time:

• Logical EL operators are converted to java operators.
• Arithmetical EL operators are converted to java operators where this is possible.
• The . and [] operator is resolved to a normal method call where this is possible.
• EL functions are converted to normal method calls.
• Non-optimizable EL operations are converted into calls to EL runtime operator methods.

org.japano.el.JavaExpressionGenerator offers a main method which takes an el expression as arguments and dumps the parser tree of this el expression and the generated code.

JSP compatibility

One of the reason japano was started was a dissatisfaction with JSP and the way custom tags are implemented in it. In this regard japano does not even aspire to be 100% JSP compatible. Apart from that I tried to follow the JSP path but japano is still a very young project. So the current feature set of the JSP engine is mainly determined by how much I like a certain feature and how easy it is to implement.

I like to keep the JSP document only declarative with no code embedded in them but only html tags, custom tags and el expressions and static includes or tag files. These elements are sufficient for the vast majority of pages. In cases where that is not sufficient I usually found it better to write the page functionality completely in java code. japano allows you to write your own view generators which can be very helpfull for that. If the content you are using is string based you can use japano's org.japano.Buffer class as a helper to create the content. (See org.japano.util.JSON for an example of this). If your content is binary you can use the HttpSerlvetResponse you receive as argument of your action to answer the request yourself. The separation achieved by using only declarative elements in the documents gives your project an stable interface of tag and element names. While this separation is even usefull when only one persion is developing the website,its main benefits are to be able to let differently abled people collaborate on a website. The developers define the declarative interface and are free to rearrange code or functionality. web designers are able to design the website around a clean tag oriented functionality without syntactic noise.

These features are supported in the current state:

• Custom tags using the japano API
• Tag files. ( They are mapped to the japano custom tag API though)
• Static includes
• EL expressions.
  The EL implementation also differs in that there is not really a EL expression parser, no function mapper and no variable resolver. The EL implementation instead transforms the EL expressions into normal, optimized java expressions embedded in the java source resulting from the JSP document. As far as it is possible the EL operators are replaced by java operators while still achieving the standard result. property chains using the . and [] operators are resolved to normal method calls where possible. EL compilation also takes advantage of the declared session type so that EL expressions e.g. in the sample application an expression like ${pageContext.session.user.alias} is compiled to "((SampleSession)pageContext.getSession()).getUser().getAlias()".
• traditional JSP expressions
• traditional scriptlets as long as they close all braces they open. This limitation is thought be solved soon.

Not supported are:

• <jsp:fallback>
• <jsp:forward> 
• <jsp:getProperty>
• <jsp:include> 
• <jsp:param>
• <jsp:params>
• <jsp:plugin>
• <jsp:setProperty>
• <jsp:usebean>