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)
<large-snip/>
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 http://www.anyware-tech.com/home/prod_architecture.html : 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 files.
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
