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:

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:

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:

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:

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

Timeline

28.05 - 04.06

discussion on mailing list about converter concept leading to it's clarification

05.06 - 21.06

exploration of the code and samples that are likely to be changed during my work

22.06 - 05.07

move current ELs implementation from cocoon-template to the new module; get rid of Avalon dependencies

06.07 - 19.07

use moved ELs code in template module; implement converters

20.07 - 02.08

implement unified Object Model used everywhere ELs are used; refactoring of sitemap

03.07 - 16.08

more refactoring: flowscript, javaflow and samples

17.08 - 28.08

documentation, reporting the results, more testing, polishing

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!

SummerOfCode2007/cocoon-expression (last edited 2011-05-03 11:31:12 by SebastianBazley)