cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Alexandre Losson <>
Subject Webapp formalization and code generation (long)
Date Sat, 04 May 2002 09:16:18 GMT
Hi all,

I've been reading the cocoon-dev list and using Cocoon2 with great
interest and success for almost 4 month now and I wanted to share the
following thoughts with you.

As web developers, I am sure, we spent a grat amount of time rewriting
stuff over and over again. The code is not always the same (nor the
language sometime). But the way we structure things, the way we
integrate database data and formalize business rules are more and more
the same over ad over again.

I spent much time developing frameworks or even using existing framework
like Struts, Turbine, and now Cocoon. They all help, but what keeps
bothering me is that once you finished your application there's no
*abstract* or formalization of what you just wrote that you can extract
from the finished application. 

There is an incredible amount of knowledge, structure, formalization
that resides in the just developped application. You can feel it, but
you don't really know how to get a grip on it.

The closest I came to formalizing the application I was writing (with
the idea of reusing this formalization) was with Cocoon using the

Now you might ask, what the point is of trying to get a grip on this
formalization ? 
My opinion on this (but one might not agree and that's why I would like
your opinion on this) is that can lead to 2 things: 

- formalization (specification, description, etc ..) can garantee that
your application is correct to a certain degree. You are sure that only
what you specify is indeed present and done.

- formalization is the base of code generation or at least generation of
the structure of an   application.

I have used this technique once using PHP (no comments :-)). I describe
the data in my app, and the different screen and a code generator
generates a complete php structure with base classes. I than just had to
extend and implement what I needed. One thing that might appear as
stupid, but appeared as very time saving is that this code generator
prepared the directory structure and created empty .php files with basic

That's why instead of spending time writing little components and
*linking* them together and fit them all together in a web app, I think
time would be better spent formalizing/specifying what you want to do
instead of doing it. Why ? Reuse and independance on how effectively it
is going to be done.

Now the difficult thing here, is to find a formalism to specify these
interactions and application structure. I've tried many times but I am
not convinced of my findings .. but I know this formalism must exist ..
when you see 10 webapps, you can feel what they have in common .. you
just feel it .. but I can't express it or abstract it yet .. 

The sitemap was a revelation for me .. because it expresses one side of
the formalism .. URL mappings. It links a URL like /account/edit to
effective actions to be taken (actions,transformation,serlization etc

But what I would like to formalize as well is for example that
/account/edit uses 1 parameter: an account number. And that
/account/edit has 2 "exit" points, one that will be triggered when the
edit is succesfull, the other when the edit is cancelled. 

This can be expressed in rough XML as :

<page url="/account/edit">
	<param type="use" name="accountno"/>
	<exit label="confirm"/>
	<exit label="cancel"/>

But that's not all, now that I've defined how individual URL's (or page
elements) function, what constitutes my web app, is how these URL's link
to each other.

For example, how do you get to /account/edit ? Where do you get when
/account/edit trigger it's confirm exit ? Where does account/edit get
the parameter it needs.

So what I need is some kind of linking formalism like :

	<link type="parameter" srcpage="/account/list" 
		srcpar="accountno" destpar="accountno"/>
	<link type="exit" srcpage="/account/edit" srclabel="confirm"

This would express that my account/list page will *provide* the
account/edit page the accountno parameter and that when the account/edit
page triggers the cancel exit, this will result in going back to
account/list page.

Based on this formalism I think it would be possible to generate a
skeleton application. 

I have not read much about the new flowmap in cocoon, but can it be used
to express the formalism I describe above ?
And further to generate code or code structure ? 

I am waiting for your comments and thoughts on all this (I you managed
to stay awake up to here :-))


To unsubscribe, e-mail:
For additional commands, email:

View raw message