cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject [RT] towards perfect application framework
Date Tue, 19 Aug 2003 11:00:39 GMT

This will be long.

Here are some of my thought concerning building a proper web application (framework).
Please mind that I started from the position of PHP user that barely knew Java
and MVC concept. The second part is the reason why I wrote this post so if you
do not have time just skip the part one

* Title: How I became a cocoon user * 
First I started to use cocoon in quite a PHP + templates style. I mean I've
been using pipelining in cocoon just to provide the website with a common
look. I've been handling the forms myself, which means managing the whole
state machine with hidded input fields and so on.

The actions at the time were a bliss. Especially when XSP action was
introduced. When you do not know how to work with a bean model XSP action +
ESQL is really a helpful thing.

Then the problems came:
  - there were just too many actions
  - the sitemap language was a nightmare ( as matches, selectors and other
    sitemap components are just enough for document rendering, I think that
    coding "flow" in the sitemap was even a step backward from the ease I had
    in PHP). Especially when action-sets disappeared in 2.1 :)
  - when the SimpleFormTransformer was intruduced it was much easier (and
    cleaner) to fill the form with values but still it was not what tigers
    like the most.
  - my software users (and me really too) would like the software to present
    more advanced GUI - the most simple GUI there is is not usually ergonomic

At the time cocoon flow started to emerge and the potential was (is) huge. It
was really nice to move all the logic to javascript code. I am still at the
stage that I find calling actions from flow very useful. Maybe it should be all
placed in business logic classes but as I said: up till now XSP action + ESQL

Today I am still coding my software the way I described (do not know how to do
it the other way) so I started to fill a little stressed about the fact that
it is not way I should do it.

* Title: toward the perfect web application and why such lame as me couldn't
* achieve it with cocoon in it's current state
* Title 2: a taste for even more

Some of my research thoughts (this is the main purpose of this mail):

flow + persistence + woody is not enough to create a full blown web 
application. Why? Just because web application is (according to me and my 
current knowledge state):

1. data model
2. business logic (in specific database actions)
3. flow (which pages are shown, what actions are being fired)
4. GUI

ad 1. We can build various data models in cocoon (beans, xml). That's fine. 
There is always some "but": the support for persistence is quite none. 
All the samples use the "temporary" solution creating sesions only for
their own purpose. Some Avalon component would be needed I think (I am still
digging into Avalon lifecycle - it's not easy). The rest would be a piece of 

ad 2. We can code business logic in components, actions
ad 3. flow is flow :) we got it


While Woody is nice and a "great leap for mankind" it's not enough to build a 
full blown up GUI.

While looking for Eclipse plugins I have found a commercial package called 
W4Toolkit ( It is i think similar to .NET philosophy 
but coded entirely in Java. Please mind that I do not want to advertise any of 
the products. I am just pointing ideas ( I do not even like both :) ) 

Both .NET and W4Toolkit:
  - abstract coding web applications completely. While in .NET you can use 
  ASP.NET pages which mix HTML with web controls, in W4Toolkit you have only 
  Java objects. Both give user a set of controls like: 
  - menu
  - tree control
  - panel
  - tabbed pane
  - standard form controls like edits, listbox, selects and so on.
This is the first step: provide user with controls that would allow him to build 
a complete GUI ( implementing a tree control, either server side or client side 
is not easy) 

Second thing to do is to provide user with an invensive event model. For those: 

  - .NET uses single hidden input which stores a page state ( binary form ) - 
  really stupid from my point of view - for some pages the page content is a few 
  kilobytes while state takes nearly 50 kB
  - W4Toolkit uses JavaScript intensively. Not a good idea in some environments 
  also, but it allows to do quite anything concerning events - you can render a 
  submit button as an image or a link, you can trigger an event while expanding 
  a tree )
What are the biggest pros of unified GUI framework? 
 - you abstract web programming even more. Writing a web application with a rich 
 GUI would feel like writing a Java Swing application. There are even layout 
 managers in W4Toolkit so you can do panel.add( control, layout.NORTH );

 - you do not respond to "low level" submit names, hidden inputs and other weird 
 techniques but just HANDLE THE EVENT ! It is not so big problem to handle 
 events if all you have is a single form but try to explain somebody new in the 
 team how everything works now if you build your page out of :
	 - menu part pipeline
	 - toolbar pipeline
	 - sidepar pipeline
	 - some treeview
	 - some form view 
	 - some content view
	 - a status bar

I find aggregation to be a breakthrough in generating documents, reports and so 
on. because first you have small parts and then you join them into a bigger 
parth. With GUI it's different. You have to provide some FUNCTIONALITY so you 
design your UI as a whole and then decouple it to smaller pieces. They are very 
tight together. Now you have to do tricks to provide integrations of various GUI 

Some of you would say : use Struts, I say : I have been looking at Scarab 
bugtracker. While it provides some nice guis (not very advanced though - the 
most interesting is a tabbed page) IT'S A MONSTER!

I think we all know what are the cocoon's advantages. I think that it's a lot 
harder to add things to .NET that cocoon can (and to make it so pleasant to 
use) rather than extend cocoon with some GUI functionality. I have the 
impression that all other frameworks work very well for the purposes the 
small group of developers had in mind while in cococon you could do just 

I have learned a lot during last year of struggle with cocoon. A completely new 
philosophy to build web based "things" but I am still not the one that could 
start such big project. 

What do you think ? 
         | /  \ |        Leszek Gawron            //  \\
        \_\\  //_/          _\\()//_
         .'/()\'.     Phone: +48(600)341118     / //  \\ \
          \\  //  recursive: adj; see recursive  | \__/ |

View raw message