Google Summer of Code proposal: Unified expression handling and unified object model

Abstract

As for any other web application framework, one of Cocoon's core functionality is expression handling. Simple yet powerful expression languages (ELs) enable developers creating Cocoon applications query for data they need in clean manner. Even though several ELs are already present in Cocoon their use is now incoherent and they operate on inconsistent Object Model (OM, discussed below). This is a serious obstacle for novice users and makes Cocoon applications more difficult to maintain. In order to address these issues I propose to:

• revise EL handling implemented in Cocoon's template block and find out if improvements are needed
• get rid of Avalon dependencies in EL and OM handling code
• provide consistent, complete object model for expressions everywhere they are used
• implement converter concept and provide basic converters' implementations
• refactor at least portion of Cocoon samples so they use new ELs implementation
• document new architecture, create migration guides and promote the use of new implementation across the community

Project Description

While talking about ELs it will be assumed that also Object Model is considered even not mentioned explicitly. Object Model is what ELs operate on so this two things are tightly coupled.

Revision of current ELs implementation and analysis on ELs usage

This is first phase which is more reconnaissance of current situation than actual coding. During this phase I'm going to revise current applications of ELs across the Cocoon both from the user's and implementation point of view. This is a list of possible areas I will look into:

• sitemaps
• flow implementations (flowscript and javaflow)
• templates
• forms

This should give me clear understanding of possible implementation, and detailed goals. At this phase community discussion could be led but it's not mandatory because most concepts were already broadly discussed before:

• http://article.gmane.org/gmane.text.xml.cocoon.devel/47854

• http://article.gmane.org/gmane.text.xml.cocoon.devel/42968

Removing dependencies on Avalon and moving ELs into seperate block/module

It's long-term Cocoon's goal to get rid of Apache Avalon dependencies and use Spring Framework instead. Doing this is also profitable from EL's usage point of view. My goal is to minimize the need of configuration in order to use EL's and/or extend them. Preferred situation would be if there is no configuration needed.
Move to the separate block/module is quite obvious and natural given that ELs are going to be used outside template block.

Object Model

Object Model is set of objects that provide access to the environmental data which includes:

• session and request data (attributes, request headers etc.)
• configuration data for application
• data passed down by flow implementation
• context information provided by various sitemap components (e.g. matchers)

The list is far from being complete but there is not point to provide a such. Current problem is that Object Model available in e.g. flowscript and template is different. This difference does not come from the fact that we consider two different context where some data available in flowscript is not relevant to template's context and vice versa. Taking as example request attributes, they should be available under the same path across all ELs applications which is not case now. The goal is to make expressions accessing the same data literally the same. Some work is needed to ensure it actually takes place and automatic, context-aware Object Model construction is to be implemented.

Converters

The concept that lays behind converters is really simple. Basically, converter for certain type is a class that provides bidirectional conversion between character string and given type. It's very usual that we need textual representation of the object that expression returns. Converters are going to be completely separated from expressions at implementation level but their usage is going to be tightly coupled.
The goal is to provide default converters for basic types (like dates) and easy way to provide own converters (preferably with no configuration again). Particular type will be able to have few converters - one default and other optional used on user's demand.

Deliverables

• new module cocoon-expression-api
  • ELs and OM API (already exists but must be moved from template block)
  • converters API
• new module cocoon-expression-impl
  • implementation for expression langauges for JS, JXPath, JEXL (most code already exists but needs clean up), possibly XReporter would be implemented if time permits
• implementation of automatic, context-aware Object Model creation
• default converters, basically the same as in org.apache.cocoon.forms.datatype.convertor package
• refactor code of following modules in order to use new ELs implementation:
  • sitemaps
  • flowscript
  • javaflow
  • templates
  • possibly forms, only if time permits
• refactored samples
  • cocoon-ajax-sample
  • cocoon-forms-sample
  • cocoon-core-additional-sample
  • possibly new module cocoon-expression-sample with stuff focused only on ELs
• documentation in Daisy
  • design documents
  • tutorials on explaining how to create own EL or converter implementation and how to extend OM
  • migration guide

Timeline

Remark: I set quite loose plan for the beginning because I'm going to have an exams in mid of June.

Development methodology and community involvement

Obviously, refactored expression languages are in scope of every Cocoon developer and user interest. It is core functionality that must be easy to use, bug-free and reliable. In order to ensure good code quality and community involvement I would like to choose one week-round during GSoC period. Complete work will be broken into several smaller, focused tasks suitable for one week period. This will enable community evaluate the progress of my work and find out if I'm leaning towards right direction. Moreover, this way community will be able to test and comment my work as early as possible and see how it evolves thus better understand what actually happens.
During completion of particular task I would like to write tests for the functionality first I want to implement and then start implementing. It will ensure good quality of code and easier, possible, future refactorings. Also, such tests provide good examples how the code should be used.

About me

Grzegorz Kossakowski, grek.at.tuffmail.com

I'm first-year Mathematics student at Faculty of Mathematics, Informatics and Mechanics, Warsaw University. I've been around Apache Cocoon for four years and elected as Cocoon committer, lately. I have good Cocoon understanding and it's community dynamics. Contributions that I've made to the Cocoon's code proof to date that my Java skills are enough to accomplish the task.
I'm highly devoted to Cocoon and would love to work during GSoC!