cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))
Date Sat, 02 Aug 2003 15:02:50 GMT
Marc Portier wrote:

> Hi again :-)
> just adding some more phylosofical notes on webapp design and 
> modelling (it is week-end after all, hope you all don't mind me 
> getting into the meta levels of things)


Nice stuff, Marc. I went through similar thoughts, but through a less 
philosophical way (I'm not good at that).

> So no more development process that jots down the concepts on one side 
> of the chain.
> either:
> concepts --> front-end-designers --> back-end-engineers
> or:
> front-end-designers <-- back-end-engineers <-- concepts
> but rather:
>             concepts
>                |
>                V
>        middle-tier-contract
>       ( discussed, aggreed,
>     and maintained by both parties)
>            /     \
>          |/_     _\|
>    front-end     back-end
>     design      development

The above drawing totally joins my current thoughts about the two 
categories of aggregate field (front-end related or back-end related) : 
both emerge form something that exist in the woody model (the 
middle-tier) and further extend it.

Now look at the second picture in : this is 
something I've drawn about 3 years ago. The data model (here the woody 
model) is the pivot between the different layers. Now does a layer have 
the right to modify the model for his own needs ? My opinion is no. It 
however has the right to _extend_ the model with private things without 
impacting the model shared by all layers.

How can this translate into Woody ?

Back-end specific extensions exist in Woody : this is the binding. And 
if you remember, I proposed in one of my posts to move aggreate fields 
such as the phone number into the binding, because they have no meaning 
to the view layer.

Front-end specific extensions currently don't exist in Woody : I 
envisioned this as a new composite widget catalogue that would extend 
(by further refining them) model-defined items such as a date in 3 
year/month/day inputs. But symetrically to the previous paragraph, these 
3 inputs have no meaning to the back-end layer.

So I think we agree on the various concerns that exist around woody, but 
we don't agree on how the needs of these different concerns should be 
handled in the woody model.

Your POV is for the model to gather all needs, while my POV is to have 
the model being the smallest common denominator and allow each layer to 
extend this model locally with its own needs.

I agree that communication is important between the various 
responsibilities. But IMO, this communication must be about this common 
denominator. The back-end guy doesn't care if dates a represented by an 
input, 3 popups or a calendar. The GUI designer doesn't care if 
validating a phone number is easier by splitting it in 
country/zone/number. What they all have to agree on is the fact that a 
date and a phone number have to be input. And this is related to the 
application data model.

This may seem somewhat theoretical, but I've learned to be suspicious 
about files that have to me modified by several people at once...

Now the above sentence is totally contradictory with a previous proposal 
of me to include the binding into the form definition. Why did I 
proposed this ? Because in small/medium apps, the one that designs the 
form is often (again, my own experience) the one that does the back-end. 
But it may also be the one that does the view layer. And so allowing the 
files to be merged reduces development time by avoiding cross-referenced 

But _allowing_ these files to be separated when needed (i.e. large 
projects) is IMO something important.

Things are never black or white : there's an infinity of greys inbetween...


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message