AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition)

[Sylvain Wallez <sy...@anyware-tech.com>]

Andreas Hochsteger wrote:

> Hi!
>
> A short question comes to my mind, while reading your RT:
> Is it possible to use data types which are composed of several HTML 
> input fields?
> We are currently using three input fields for dates (day, month, year) 
> at our current form solution.
>
> Thanks for clearification! 


Marc explained how this can technically occur using AggregatedField.

Now from a more semantical point of view, AggregateField is something 
I'm not very comfortable with. Let's consider its two use cases :

1/ Phone number example
In this example, the displayed form shows only one input box, and its 
value is split into several non-visual subfields used by the application 
(country code, area code, number). Do these non-visual subfields really 
belong to the form definition if it never displays them ? Doesn't this 
split belong to the binding more than to the form definition ?

2/ Date split in several inputs
The day/month/year inputs are just a particular visual implementation of 
a date widget (in the GUI meaning of "widget"). What if we finally 
decide to use a calendar popup instead of 3 inputs ? Do we have to 
change all form definitions ?

Maybe that's just nitpicking, but I find this somewhat breaks Woody's 
clean SoC.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: [RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))

[Sylvain Wallez <sy...@anyware-tech.com>]

Andreas Hochsteger wrote:

> Sylvain Wallez wrote:
>
>> Shared neurons again : re-thinking to my previous post, I realized 
>> exactly what you say. The various model extensions needed by each 
>> layer need to be physically separated (different people, different 
>> files), but must be assembled into a single runtime model.
>>
>> So actually, what we need is a way for people to organise this global 
>> model into various files that correspond to their team organisation, 
>> so that they don't step on each other's toes. Hence the need for 
>> different separations depending on the context.
>
>
> Just to be sure:
> By various files you also mean pipelines, which can dynamically 
> produce the needed data?
> This would allow many extensions without hacking into woody itself! 
> See authentication framework and portal framework, where many parts 
> are produced by pipelines.


Dynamic form definitions are a way to handle more complicated case, and 
could even be used to handle the results of this long threads without 
touching a single line of the current Woody.

But what we want with the proposed refactoring, is avoid the need for 
dynamic form definitions for the most frequent use cases. But this 
possibility will still be available for specific use cases.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: [RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))

[Andreas Hochsteger <e9...@student.tuwien.ac.at>]

Sylvain Wallez wrote:
> Shared neurons again : re-thinking to my previous post, I realized 
> exactly what you say. The various model extensions needed by each layer 
> need to be physically separated (different people, different files), but 
> must be assembled into a single runtime model.
> 
> So actually, what we need is a way for people to organise this global 
> model into various files that correspond to their team organisation, so 
> that they don't step on each other's toes. Hence the need for different 
> separations depending on the context.

Just to be sure:
By various files you also mean pipelines, which can dynamically produce 
the needed data?
This would allow many extensions without hacking into woody itself! See 
authentication framework and portal framework, where many parts are 
produced by pipelines.

> 
> Sylvain
> 

Bye,
	Andreas

Re: [RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))

[Sylvain Wallez <sy...@anyware-tech.com>]

Marc Portier wrote:

> Sylvain,
>
> A bit short on time ATM, I don't want to leave you waiting on some 
> full lenght reply, so I'm jotting down my wild 
> catched-while-under-the-shower-thoughts:
>
> I'ld like to make some consensus proposal which in my head (current 
> vague idea) could be hooked up by making distinction between the 
> run-time and the design-time:
>
> at design time the distinct roles should be able to write up their 
> seperated view of the reality that hooks up to an agreed least common 
> denominator (as you describe it) version of the model
>
> at runtime I really would like the unified information (i.e. with all 
> granularity brought in from both sides) to be present in the (single) 
> Woody widget-model since I realy believe such would simplify and 
> streamline things
>
> this might bring us the best of both worlds?
> and it somewhat fits in with your upcoming mixing work?
> (and maybe this is just what you tried to tell me all this time :-p) 


Shared neurons again : re-thinking to my previous post, I realized 
exactly what you say. The various model extensions needed by each layer 
need to be physically separated (different people, different files), but 
must be assembled into a single runtime model.

So actually, what we need is a way for people to organise this global 
model into various files that correspond to their team organisation, so 
that they don't step on each other's toes. Hence the need for different 
separations depending on the context.

> Still on the unease-feel part of things: I have the feeling your 
> target mix envisions a shift from model-designer role to take up some 
> of the template-designer role (or vice versa) which leads you to 
> bring-in the layout-designer to gain a new separation in the now 
> accumulated (too much) work...
>
> I do see your use case, but there is still some red flag waving at the 
> back of my brain about how the mix should be possible the other way 
> around as well (ie towards the back-end)...


I told it already: on the front-end side, this can go through catalogues 
of macro-widgets, and this can go through the binding on the back-end side.

> -marc=
> PS: your reply got me surfin' on the anywhere site: am I the only one 
> dreaming of seeing some of this supported in the webappstudio? (would 
> be way out cool, starting to drool already)


It's not anywhere, but *anyware* ;-). As for the webapp studio, it 
effectively currently supports strong separation between the different 
layers, but there's no equivalent to Woody's aggregate fields as it 
requires the same data granularity on all layers. But shhh... woody will 
be part of the next version. Shhhh... ;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: [RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))

[Marc Portier <mp...@outerthought.org>]

Sylvain,

A bit short on time ATM, I don't want to leave you waiting on 
some full lenght reply, so I'm jotting down my wild 
catched-while-under-the-shower-thoughts:

I'ld like to make some consensus proposal which in my head 
(current vague idea) could be hooked up by making distinction 
between the run-time and the design-time:

at design time the distinct roles should be able to write up 
their seperated view of the reality that hooks up to an agreed 
least common denominator (as you describe it) version of the model

at runtime I really would like the unified information (i.e. with 
all granularity brought in from both sides) to be present in the 
(single) Woody widget-model since I realy believe such would 
simplify and streamline things

this might bring us the best of both worlds?
and it somewhat fits in with your upcoming mixing work?
(and maybe this is just what you tried to tell me all this time :-p)


Still on the unease-feel part of things: I have the feeling your 
target mix envisions a shift from model-designer role to take up 
some of the template-designer role (or vice versa) which leads 
you to bring-in the layout-designer to gain a new separation in 
the now accumulated (too much) work...

I do see your use case, but there is still some red flag waving 
at the back of my brain about how the mix should be possible the 
other way around as well (ie towards the back-end)...


-marc=
PS: your reply got me surfin' on the anywhere site: am I the only 
one dreaming of seeing some of this supported in the 
webappstudio? (would be way out cool, starting to drool already)
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org

RE: [RT] Cubist WebApp Team Organization

[Robert Koberg <ro...@koberg.com>]

Hi,

Very cool stuff on all of these threads! I have another way to throw into
the mix. Perhaps it can spark some ideas?

I have been playing around with removing our apps dependence on the MSXML
SOM on client (to gain browser independence) and replacing it with (what I
call in my head) JSAXB. I started using JAXB and have really enjoyed it
which led me to think of how it could be done with JavaScript. Then along
come these threads and made me think that JSAXB could be used on both the
client in the browser and on the server with the flow.

I wonder what you guys think. 

I transform an XML Schema into a form instance and setup the form to call JS
methods on submit. I also transform the schema to JS objects and methods.
ComplexTypes become superclasses and the elements that extend the
complexType becomes the subclass. 

I am having troubles with datatyping. Some are easy, like determining if
something is a String or Boolean or not. But some leave me perplexed as to
how to check if something isValid. I have transformed the W3C Datatype
schema to give me a shell of objects to handle datatyping but not able to
create the methods. Any ideas? Any interest?

Here is a trimmed down example that handles modifying a folder site node in
our site.xml file (similar to forrest's site.xml):

/**
A base object to be extended.
*/
function _superclass_SiteNode() 
{
  _id = new _datatype_ID();
  _css = new _datatype_NCName();
  _onnav = new _datatype_boolean();

  this.set_id = set_id;
  function set_id(id) {
    _id.set(id);
    if (!_id.isValid()) {
      _id = new _datatype_ID();
      alert("Invalid ID entry!");
    }
  }
  
  this.get_id = get_id;
  function get_id() {
    return _id.get();
  }
  
  this.set_css = set_css;
  function set_css(css) {
    _css.set(css);
    if (!_css.isValid()) {
      _css = new _datatype_NCName();
      alert("Invalid CSS entry!");
    }
  }
  
  this.get_css = get_css;
  function get_css() {
    return _css.get();
  }
  
  this.set_onnav = set_onnav;
  function set_onnav(_onnav) {
    _onnav.set(_onnav);
    if (!_onnav.isValid()) {
      _onnav = new _datatype_boolean();
      alert("Invalid Show on Navigation entry!");
    }
  }
  
  this.get_onnav = get_onnav;
  function get_onnav() {
    return _onnav.get();
  }
}


/**
Superclass the folder object
*/
_folder.prototype = new _superclass_SiteNode();
_folder.prototype.constructor = _folder;
_folder.superclass = _superclass_SiteNode.prototype;

function _folder() 
{
  _index_page = new _datatype_IDREF();
  
  this.set_index_page = index_page;
  function set_index_page(index_page) {
    _index_page.set(index_page);
    if (!_index_page.isValid()) {
      _index_page = new _datatype_IDREF();
      alert("Invalid Index Page entry!");
    }
  }
  
  this.get_index_page = get_index_page;
  function get_index_page() {
    return _index_page.get();
  }
}

Best,
-Rob

Re: [RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))

[Sylvain Wallez <sy...@anyware-tech.com>]

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)


<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 }

Re: [RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))

[Stefano Mazzocchi <st...@apache.org>]

On Saturday, Aug 2, 2003, at 13:06 Europe/Rome, Marc Portier wrote:

> IMO, SoC is more about colaboration then it is about separation?

Absolutely. This is indeed so: once you start the path of enforcing SoC 
and you start measuring your architectures in terms of concern overlap 
and contract solidity, you understand that without some collaboration 
between the two sides to come up with the contract, things cannot be 
achieved.

And you start realizing, by planning the contract and understanding how 
to evolve it, on how to do

> SoC == CoS: Colaboration of Specialists?

Yes, collaboration at contract design, but don't forget that SoC is 
created to parallelize development and firewall problems in one domain 
from entering the other.

--
Stefano.

[RT] Cubist WebApp Team Organization (was Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition))

[Marc Portier <mp...@outerthought.org>]

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)

<snip />

>> as explained my feeling is that woody's model should be as decoupled 
>> from the 'template' as it is from the 'backend-model' 
> 
> Agree. But the date-with-3-fields use case if the perfect example where 
> GUI decisions (using these 3 fields instead of a single input) have an 
> impact on the Woody model.
> 

of course.
However it is my strong believe that they _should_.

I didn't want to guarantee full decoupling!
but rather equal or at least balanced decoupling/influence

That is where the phone-number example comes around of course...
there you have the db-admin decision to split up over different 
fields instead of just one...

On the grounds of datatype-checking and validity (ie the service 
Woody wants to offer for easier back-end integration) we seem to 
be comfortable with adding it to the model?

 From that POV, Woody should not feel any unease in supporting 
some of the features brought on the table by the front-end design 
either.

                             -o0o-

Actually we are touching the subject of how to organise the 
webapp project team more then anything else, and I'm really 
afraid there is not ONE best strategy to do so..
(but we both feel that some technical decision in one way or the 
other will have a social impact on how the team will end up 
working together so we keep feeling the urge to defend our view)

Actually it's quite nice to see how we both are understanding 
each others view, and are just adding more people to the show to 
stress a bit our own nuance on the subject...

you: focus on template-designer
RE me: stressing model-designer
RE RE you: yes, but: layout-designer
RE RE RE me: sure, but equally: db-admin (back-end specialist)

Playing the honest scientist from both sides we are likely to end 
up seeing that the number of responsibilities is reaching 
infinity and ranging them on a linear scale results in a 
continuum of stages smeared out into each other.

The hard task of defining the SoC is all about *sampling* this 
responsability domain (i.e. mapping the continuum onto sensible 
discrete layers)

                             -o0o-

I understand that this domain is not linear at all, but has a lot 
of dimensions (aspects to be taken into account), however the 
linear view is one that we people tend to like a lot when 
thinking about projects in general and the technical setup of the 
web is somewhat inforcing that view:

- indeed: a drawing of a web-request being processed tends to 
result in an arrow-line starting at the browser, and passing 
whatever set of layers end up at the back-end logic (and vice 
versa for building up the response) (this applies for close to 
all software solutions I think, maybe inference engines escape 
this when looked upon from high enough)

- from a planning POV all projects tend to be measured against 
the universal linear dimension that is ruling our human lifes 
more then just a bit: TIME

By mapping this eternal linear dimension onto the team 
organization we are bound to fall into the waterfall: this has to 
be ready, for that to be started, etc etc (we like this cause it 
appeals to our human built-in cause-consequence thinking and 
really allows for a rather easy milestone management of the project)

                             -o0o-

No matter where you 'start' to tackle the problem, taking the 
linear view is likely to leave you with the so called 
"Boa-indigestion":

This is a story I once heard from a person making educational and 
entertainment cd-roms in C++ (this is back quite some time: I was 
doing perl cgi's at the time and fealt some high match level)
In his industry the typical approach would be to let conceptual 
people (story-board authors) think up something that was smashed 
into great drawings and sketches making up the 'visual 
experience'...
He compared this to a boa with a very flexible mounth that can 
stretch so far as to the moment where it could actually swallow 
an elephant (at this time you should take your copy of 'le petit 
prince' and look at the first two drawings ;-) 
http://www.statesman.com/specialreports/content/specialreports/ransom/photos/photo24.html) 


The catch of his comparison was this: the actual C++ development 
team was completely at the end of the digestion-process: the 
complete elephant needed to pass there (ouch)

Reversing the chain is not a real help: then you end up with 
frustrated front-end designers that are tied down enormously by 
everything that has been technically/formally streamlined with 
totally different goals then the ones they want to achieve.

                             -o0o-

I'm afraid I'm falsy leading the reader to this point:
   "Please tell us: How to escape the linear thinking?"

I honestly think the goal is a false one: we can't go by at our 
human nature: we think in cause-consequence and our very 
existence is measured in terms of elapsed time and endured 
change-cause-consequence-more_change over that time.

IMO even strategies like RUP's iterative development and XP's 
refactoring are (while being most valuable) only touching the 
surface, and can't go by at this baked-in fundamental human 
common sense: such and such needs to be before such and such can 
exist...

So we are doomed either way?
Sure: the law of constant misery is not to be set asside (not 
without more misery at least :-))

However while I used the 'touching the surface' in a very 
disrespectful manner, there is in fact something that it can achieve:

Let us read 'touching the surface' as 'agreeing upon the 
contracts' and 'defining the interfaces' and we see how this can 
result in something real (the interface) that can launch two 
parallel development tracks to escape the boa-digestion (into two 
smaller ones)

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


Q: Will this approach guarantee a shorter (time) trajectory to 
completion for my project?
A: The introduced parallelism suggests this, but I wouldn't bet 
on it. (a bit like the discussions on XP's pair programming model?)

The main advantage I see brought in by this approach is that the 
introduced moment of contract-negotiation and (re-negotiation) is 
a formal point where the requests and needs from the both sides 
can collide and come to a consensus.

This of course assumes that both parties are prepared, have the 
time, and the knowledge(!) to enter as peers into this discussion.

I find this discussion-as-peers-process something that very 
naturally goes about in OSS communities, but are often hidden 
away in a dedicated architectural team in large corporations: 
thus defeating the actual COMMUNICATION goal and getting us back 
into a strictly linear model. (and honestly: I disliked the 
'architect' character in the Matrix Reloaded right away :-))

                             -o0o-

Coming back to the discussion at hand the above reasoning would 
lead me to sustain to the model-designer role that Woody 
introduced, but urge us all to map it not onto one specific 
person but see it as the result of the team-effort to actively 
understand both sides of the issue.

IMO, SoC is more about colaboration then it is about separation?
SoC == CoS: Colaboration of Specialists?

                             -o0o-

General disclaimer:
I enjoyed dumping my current state of brain here (introduced by 
our thread), still hoping to achieve more then just my personal 
pleasure.
Being my own personal view of the moment I tend to use a wording 
that tries to persuade, the reality is that I'm always in doubth :-)


<on the side>
I agree on leaving out the technical decisions for now on the 
'date' stuff (however: we kind of do need the (already existing 
in woody) reciprocal 'phone' thing on short notice)
</on the side>


regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org

Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition)

[Sylvain Wallez <sy...@anyware-tech.com>]

Marc Portier wrote:

>
>
> Sylvain Wallez wrote:
>
>> Marc Portier wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> Andreas Hochsteger wrote:
>>>>
>>>>> Hi!
>>>>>
>
> <snip />
>
>>>>
>>>> Maybe that's just nitpicking, but I find this somewhat breaks 
>>>> Woody's clean SoC.
>>>>
>>>
>>> Touché. 
>>
>>
>>
>>
>> ;-) Actually, this is something I was uncomfortable with right from 
>> the beginning, but did not want to throw on the table immediately as 
>> it's rather peripheral.
>>
>
> hehe, I needed some time to come up with a sensible defense for the 
> aggregate-existence towards myself and Bruno as well, so this is not a 
> real surprise :-)
>
> however once you get into the view that 'Woody needs to know the most 
> details from both sides' this aggregatefield isn't that big of hack IMO
>
>>> Indeed: The aggregatefield was only introduced when we started 
>>> thinking about binding... however, by now I have learned to 
>>> appreciate the concept as having its own value in the woody-model
>>>
>>> You are right: it does somewhat hook up some back-end business-model 
>>> vision onto the form-fields...but then again the (other) discussion 
>>> we are having on the business-model-specific datatyping and even 
>>> business-model-specific-validation does introduce the same level of 
>>> mixing, no? 
>>
>>
>> Yes and no. Yes, because business-model-specific-validation 
>> introduces the application into the form definition, but no as it 
>> does not impact the structure of the form (i.e. the number of widgets 
>> it contains).
>>
>
> agree, specially on the no-yes-no grey area about this :-)
>
> <snip me explaining the 'imposed-granularity'-theory for holding onto 
> the aggregate-field/>
>
>>> What do you think? 
>>
>>
>> This technically makes sense, but I'm not comfortable with the actual 
>> widget implementation having an impact on the form definition...
>>
>
> maybe that feeling has more to do with the fact that the basic 
> woody-model building block is called WIDGET, and not something more 
> decoupled from its visual representation on the (HTML) form? 
>  Something like 'INFORMATION-NODE' or even 'SUBMIT-ARGUMENT' (I don't 
> like nor propose these, but I hope it helps you understand how I look 
> at them as they live in the woody-model-definition)
>
> as explained my feeling is that woody's model should be as decoupled 
> from the 'template' as it is from the 'backend-model' 


Agree. But the date-with-3-fields use case if the perfect example where 
GUI decisions (using these 3 fields instead of a single input) have an 
impact on the Woody model.

> (note: the above is the conceptual view I have, it does not come back 
> on me supporting your effort into defining a sensible mix of the 
> definition/config files to make specific usage patterns easier fit 
> onto using woody in real life) 


I understood it clearly.


>>> I also like the practical consequences introduced by the 
>>> aggregate-field notion:
>>>
>>> - it becomes a template-designer choice to present the date as one 
>>> field or as separate fields 
>>
>>
>> In fact, I think there can be various interpretation of the 
>> "template-designer" role. It seems like you consider the template 
>> designer more like an HTML-guy, while I my experience shows that he's 
>> more an application-domain-related guy.
>>
>
> I think the main thing I wanted to say was about the 'model-designer' 
> role: he is the one that defines which http-request parameters can be 
> sent to the form.
>
> The template-designer will need to live by the rules he set. 


Sure. But in my experience, the model designer and template designer are 
the same person (knowledged about the application domain), while the 
"layout designer" is a webdesigner that defines the formatting XSLs 
according to the project graphical requirements.

This is what I've seen on most projects we've done here. And for the 
current one, the customer has to be able to modify the forms (both model 
and template) without knowing html (or very roughly).

> Using the aggregateField in the model will leave some option to the 
> template-designer to actually choose for a form-layout that is to 
> ask/submit either the aggregated or the split-part params.


In my experience (again), this is the layout-designer that will take 
this decision.

>> What I'd like to achieve is to have the form template define the 
>> overall form layout (fieldsets, columns, etc) but not the details of 
>> the layout, 
>
>
> I think the form-model-designer is the one that defines the details of 
> the HTTP-API (which request-params can be sent) - not the details of 
> the form-layout
>
> the latter is I'm afraid the role of the template-designer (who might 
> cooperate with a nifty client-side-javascript designer but that is a 
> different story)
>
>> especially for low-level widgets. IMO, the form designer should not 
>> have to worry about the fact that the date input is actually 
>> implemented using a combination of 3 popups instead of a single 
>> input. Moreover, requiring the form designer to explicitely write 
>> these 3 popups in the template each time a date input is needed will 
>> certainly lead to inconsistencies in the GUI.
>>
>
> How the defined HTTP-API-request params are mapped onto actual (HTML) 
> form layout (and granularity in the case of the aggregate-field) is up 
> to the template-designer
>
> the issue of consistency between the different layouts is up to the 
> template-designer to tackle (but we could help him of course, as you 
> are proposing below?)
>
>> So actually, what I'd like to see in the form template for this date 
>> example is :
>> <wt:field id="startDate"><date/></wt:field>
>> <wt:field id="endDate"><date/></wt:field>
>>
>> Which should be expanded into :
>> <wi:field id="birthDate">
>>  <wi:style><date/></wi:style>
>>  <wi:field id="birthDate.year"/>
>>  <wi:field id="birthDate.month"/>
>>  <wi:field id="birthDate.day"/>
>> </wi:field>
>>
>> <wi:field id="endDate">
>>  <wi:style><date/></wi:style>
>>  <wi:field id="birthDate.year"/>
>>  <wi:field id="birthDate.month"/>
>>  <wi:field id="birthDate.day"/>
>> </wi:field>
>
>
> hm, would like it more if the template transformer would be able to 
> make the decission that was handed to him by the template-hint  handed 
> in the template file...


You mean a hint that tells the transformer if children of the aggregate 
field should be propagated or not ?

> this would leave the xslt sheet following unchanged (which is not a 
> goal per se, but having nested wi:field feals unnatural) 


Is this still unnatural if you consider the aggreagate field as a group 
(XMLForm has this) ?

> this probably would ask for the styling decission to be added to the 
> wt:field as an attribute.
>
>>
>> This can be easily achieved if we consider two types of 
>> AggregateField that are SAXed differently :
>> - app-related aggregation (phone-number) : child fields are 
>> non-visual, and only the aggregating widget is output
>> - GUI-related aggregation (date) : child fields are visual, but not 
>> explicitely written in the template, and the aggregating widet SAXes 
>> them as part of it's own SAX production.
>>
>
> your classification is correct, but I don't think these types need to 
> be assigned to the form-model 'explicitly'
>
> this knowledge comes implicitly from how the template or binding are 
> "using" this form-model.. in fact their usage my change over time 
> without the need to change the model?
>
>> Now we still have a problem on the form-definition part : just as it 
>> would be painful to write all 3 subfields in the template each time 
>> we have a date, it is also painful to write them in the form 
>> declaration. Plus the usual consistency problems.
>>
>> After the datatype and format catalogues, what is coming here is a 
>> catalogue for reusable field definitions !
>> Catalogue :
>> <wd:aggregate-field id="date-template">
>>  <wd:field id="year"/>
>>  <wd:field id="month"/>
>>  <wd:field id="day"/>
>> </wd:aggregate-field>
>>
>
> yep, like it
>
> since this is in the form-model realm I can't help thinking about 
> these as quite close to composite-datatypes? 


That's what came to my mind at first, but the childrens need to be named 
widgets, so I think they should be kept in the widget realm. Moreover, 
considering the date example, the aggregated field is not only a 
container, but also has a value of a base type (a Date object).

> (only) difference being that these introduce additional request-params 
> acceptable... 


Yep.

>> Form definition :
>> <wd:field id="startDate" extends="date-template">
>>  <wi:label>Start date</wi:label>
>> </wd:field>
>>
>> </wd:field id="endDate" extends="date-template">
>>  <wi:label>End date</wi:label>
>> </wd:field>
>>
>
> see above for questioning if @extends could be just @basetype
>
> looking at it as composed datatypes might be allowing us to logically 
> jot down the validation rules in there as well? 


Yep.

>> ... or should both the form definition and template go through and 
>> transformation (XSL or STX) that "expands" the widgets ? That's a 
>> more immediate solution, but introduces new pipelines and "cocoon:" 
>> sources for the definition and template.
>
>
> I like dedicated transformers, but sometimes using XSLT can more 
> easily provide a protoype 


That's why I suggest to keep this discussion on aggregated types for 
later (after all, it's peripheral), and come back on it after some real 
experiments using dynamically produced definitions and templates.

>> What do you think ?
>
>
> if what I said above makes sense, and if I heard the pain you want to 
> relieve then we would still need some style-layouting-catalogue that 
> declares a consistent styling tied to the introduced consistency of 
> datatyping?
>
> assuming we are near to having a template-and-definition mixing 
> declaration, I would think that the same kind of mix could exist for 
> the catalogues? 


Actually, I already did something similar with XMLForm : an additional 
XSL in the pipeline "expands" metawidgets which represent composite 
datastructure that are often present in the application model. This 
allows a consistent and painless layout for these recurring composite 
structures, and this works perfectly with XMLForm since it doesn't have 
a model. Woody having this model, the metawidgets must be expanded in 
both the definition and in the template.

But as I said, let's experiment with XSL transformations and see 
afterwards what can be injected back into Woody's core.

> sorry upfront if I overlooked the crux of your posting, coming at the 
> end I think I made the synopsis of both our views but that might be 
> lots of wishful thinking


I think you understood it ;-)

> I'll be glad to take another look through your telescope if you let me 
> ;-) 


[scrolling yellow text] In a galaxy far away... This is Dark Woody ;-D

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition)

[Marc Portier <mp...@outerthought.org>]

Sylvain Wallez wrote:
> Marc Portier wrote:
> 
>> Sylvain Wallez wrote:
>>
>>> Andreas Hochsteger wrote:
>>>
>>>> Hi!
>>>>

<snip />

>>>
>>> Maybe that's just nitpicking, but I find this somewhat breaks Woody's 
>>> clean SoC.
>>>
>>
>> Touché. 
> 
> 
> 
> ;-) Actually, this is something I was uncomfortable with right from the 
> beginning, but did not want to throw on the table immediately as it's 
> rather peripheral.
> 

hehe, I needed some time to come up with a sensible defense for 
the aggregate-existence towards myself and Bruno as well, so this 
is not a real surprise :-)

however once you get into the view that 'Woody needs to know the 
most details from both sides' this aggregatefield isn't that big 
of hack IMO

>> Indeed: The aggregatefield was only introduced when we started 
>> thinking about binding... however, by now I have learned to appreciate 
>> the concept as having its own value in the woody-model
>>
>> You are right: it does somewhat hook up some back-end business-model 
>> vision onto the form-fields...but then again the (other) discussion we 
>> are having on the business-model-specific datatyping and even 
>> business-model-specific-validation does introduce the same level of 
>> mixing, no? 
> 
> Yes and no. Yes, because business-model-specific-validation introduces 
> the application into the form definition, but no as it does not impact 
> the structure of the form (i.e. the number of widgets it contains).
> 

agree, specially on the no-yes-no grey area about this :-)

<snip me explaining the 'imposed-granularity'-theory for holding 
onto the aggregate-field/>

>> What do you think? 
> 
> This technically makes sense, but I'm not comfortable with the actual 
> widget implementation having an impact on the form definition...
> 

maybe that feeling has more to do with the fact that the basic 
woody-model building block is called WIDGET, and not something 
more decoupled from its visual representation on the (HTML) form? 
  Something like 'INFORMATION-NODE' or even 'SUBMIT-ARGUMENT' (I 
don't like nor propose these, but I hope it helps you understand 
how I look at them as they live in the woody-model-definition)

as explained my feeling is that woody's model should be as 
decoupled from the 'template' as it is from the 'backend-model'

(note: the above is the conceptual view I have, it does not come 
back on me supporting your effort into defining a sensible mix of 
the definition/config files to make specific usage patterns 
easier fit onto using woody in real life)


>> I also like the practical consequences introduced by the 
>> aggregate-field notion:
>>
>> - it becomes a template-designer choice to present the date as one 
>> field or as separate fields 
> 
> In fact, I think there can be various interpretation of the 
> "template-designer" role. It seems like you consider the template 
> designer more like an HTML-guy, while I my experience shows that he's 
> more an application-domain-related guy.
> 

I think the main thing I wanted to say was about the 
'model-designer' role: he is the one that defines which 
http-request parameters can be sent to the form.

The template-designer will need to live by the rules he set.

Using the aggregateField in the model will leave some option to 
the template-designer to actually choose for a form-layout that 
is to ask/submit either the aggregated or the split-part params.


> What I'd like to achieve is to have the form template define the overall 
> form layout (fieldsets, columns, etc) but not the details of the layout, 


I think the form-model-designer is the one that defines the 
details of the HTTP-API (which request-params can be sent) - not 
the details of the form-layout

the latter is I'm afraid the role of the template-designer (who 
might cooperate with a nifty client-side-javascript designer but 
that is a different story)

> especially for low-level widgets. IMO, the form designer should not have 
> to worry about the fact that the date input is actually implemented 
> using a combination of 3 popups instead of a single input. Moreover, 
> requiring the form designer to explicitely write these 3 popups in the 
> template each time a date input is needed will certainly lead to 
> inconsistencies in the GUI.
> 

How the defined HTTP-API-request params are mapped onto actual 
(HTML) form layout (and granularity in the case of the 
aggregate-field) is up to the template-designer

the issue of consistency between the different layouts is up to 
the template-designer to tackle (but we could help him of course, 
as you are proposing below?)

> So actually, what I'd like to see in the form template for this date 
> example is :
> <wt:field id="startDate"><date/></wt:field>
> <wt:field id="endDate"><date/></wt:field>
> 
> Which should be expanded into :
> <wi:field id="birthDate">
>  <wi:style><date/></wi:style>
>  <wi:field id="birthDate.year"/>
>  <wi:field id="birthDate.month"/>
>  <wi:field id="birthDate.day"/>
> </wi:field>
> 
> <wi:field id="endDate">
>  <wi:style><date/></wi:style>
>  <wi:field id="birthDate.year"/>
>  <wi:field id="birthDate.month"/>
>  <wi:field id="birthDate.day"/>
> </wi:field>

hm, would like it more if the template transformer would be able 
to make the decission that was handed to him by the template-hint 
  handed in the template file...

this would leave the xslt sheet following unchanged (which is not 
a goal per se, but having nested wi:field feals unnatural)

this probably would ask for the styling decission to be added to 
the wt:field as an attribute.

> 
> This can be easily achieved if we consider two types of AggregateField 
> that are SAXed differently :
> - app-related aggregation (phone-number) : child fields are non-visual, 
> an only the aggregating widget is output
> - GUI-related aggregation (date) : child fields are visual, but not 
> explicitely written in the template, and the aggregating widet SAXes 
> them as part of it's own SAX production.
> 

your classification is correct, but I don't think these types 
need to be assigned to the form-model 'explicitly'

this knowledge comes implicitly from how the template or binding 
are "using" this form-model.. in fact their usage my change over 
time without the need to change the model?

> Now we still have a problem on the form-definition part : just as it 
> would be painful to write all 3 subfields in the template each time we 
> have a date, it is also painful to write them in the form declaration. 
> Plus the usual consistency problems.
> 
> After the datatype and format catalogues, what is coming here is a 
> catalogue for reusable field definitions !
> Catalogue :
> <wd:aggregate-field id="date-template">
>  <wd:field id="year"/>
>  <wd:field id="month"/>
>  <wd:field id="day"/>
> </wd:aggregate-field>
> 

yep, like it

since this is in the form-model realm I can't help thinking about 
these as quite close to composite-datatypes?

(only) difference being that these introduce additional 
request-params acceptable...

> Form definition :
> <wd:field id="startDate" extends="date-template">
>  <wi:label>Start date</wi:label>
> </wd:field>
> 
> </wd:field id="endDate" extends="date-template">
>  <wi:label>End date</wi:label>
> </wd:field>
> 

see above for questioning if @extends could be just @basetype

looking at it as composed datatypes might be allowing us to 
logically jot down the validation rules in there as well?



> ... or should both the form definition and template go through and 
> transformation (XSL or STX) that "expands" the widgets ? That's a more 
> immediate solution, but introduces new pipelines and "cocoon:" sources 
> for the definition and template.
> 

I like dedicated transformers, but sometimes using XSLT can more 
easily provide a protoype

> What do you think ?
> 


if what I said above makes sense, and if I heard the pain you 
want to relieve then we would still need some 
style-layouting-catalogue that declares a consistent styling tied 
to the introduced consistency of datatyping?

assuming we are near to having a template-and-definition mixing 
declaration, I would think that the same kind of mix could exist 
for the catalogues?


sorry upfront if I overlooked the crux of your posting, coming at 
the end I think I made the synopsis of both our views but that 
might be lots of wishful thinking


I'll be glad to take another look through your telescope if you 
let me ;-)

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org

Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition)

[Sylvain Wallez <sy...@anyware-tech.com>]

Marc Portier wrote:

> Sylvain Wallez wrote:
>
>> Andreas Hochsteger wrote:
>>
>>> Hi!
>>>
>>> A short question comes to my mind, while reading your RT:
>>> Is it possible to use data types which are composed of several HTML 
>>> input fields?
>>> We are currently using three input fields for dates (day, month, 
>>> year) at our current form solution.
>>>
>>> Thanks for clearification! 
>>
>>
>>
>>
>> Marc explained how this can technically occur using AggregatedField.
>>
>> Now from a more semantical point of view, AggregateField is something 
>> I'm not very comfortable with. Let's consider its two use cases :
>>
>> 1/ Phone number example
>> In this example, the displayed form shows only one input box, and its 
>> value is split into several non-visual subfields used by the 
>> application (country code, area code, number). Do these non-visual 
>> subfields really belong to the form definition if it never displays 
>> them ? Doesn't this split belong to the binding more than to the form 
>> definition ?
>>
>> 2/ Date split in several inputs
>> The day/month/year inputs are just a particular visual implementation 
>> of a date widget (in the GUI meaning of "widget"). What if we finally 
>> decide to use a calendar popup instead of 3 inputs ? Do we have to 
>> change all form definitions ?
>>
>> Maybe that's just nitpicking, but I find this somewhat breaks Woody's 
>> clean SoC.
>>
>
> Touché. 


;-) Actually, this is something I was uncomfortable with right from the 
beginning, but did not want to throw on the table immediately as it's 
rather peripheral.

> Indeed: The aggregatefield was only introduced when we started 
> thinking about binding... however, by now I have learned to appreciate 
> the concept as having its own value in the woody-model
>
> You are right: it does somewhat hook up some back-end business-model 
> vision onto the form-fields...but then again the (other) discussion we 
> are having on the business-model-specific datatyping and even 
> business-model-specific-validation does introduce the same level of 
> mixing, no? 


Yes and no. Yes, because business-model-specific-validation introduces 
the application into the form definition, but no as it does not impact 
the structure of the form (i.e. the number of widgets it contains).

> And while we try to manage the good SoC here, the reality of the app 
> will always be that people *know* (influenced by their business-domain 
> knowledge on the app they write) about these aggregations when they 
> model the form. And not unlikely the form will need to be able to 
> exploit that knowledge.
> (In fact I guess that the reality vision expressed above is the real 
> drive behind your current effort to make Woody more lightweight and 
> generally usable?)
>
> Purely technical I have also the following argument: I expressed 
> earlier that the Woody model should be seen as the insulation layer 
> between how the end user sees things and how the business-models need 
> to be presented... now, I'm ready to change that into: it is the 
> insulation-POINT where the two worlds are meeting.
>
> The Woody form-model is what sits in between how the end-user consumes 
> and edits his HTML-form and how the back-end presents and expects 
> business data...
>
> On the HTML form there is weak typing (only strings) and weak 
> structuring (only a map-like structure of request-params) compared to 
> the back-end view of things (rigid structure of staticly typed values)
>
> The Woody-form-model takes up the responsibility of making the match 
> between both, therefor it largely needs to know everything about both! 
> (maybe this explains why it is perceived heavy at first glance?)
>
> So it needs
> - datatype knowledge and convertors (doing the string to YourType in 2 
> directions)
> - validation rules (making sure we're not handing over gibberish to 
> the backend-model)
> - mapping pointers into the backend-structure (binding)
> - ...
>
> What the introduction of the Aggregate-field is adding to the show is 
> something I would call 'granularity of information', and to date I'm 
> convinced that the woody-model needs to be aware of the smallest 
> granularity either it be imposed by the end-user view or the back-end 
> structure:
>
> 1/ phone number example:
>      end-user sees 1 field
>      back-end expects 3 distinct ones (ctr, zone, local)
>   --> imposed granularity == 3
>
> 2/ date example
>      end-user sees 3 fields (day, month, year)
>      back-end expects 1
>   --> imposed granularity == 3
>
> The above also illustrates that the usage of the aggregate-field will 
> only be useful to people actually having the intent to map stuff onto 
> a backend-business model.
> (but by now we already aggreed(?) that such is not really tied to 
> actually using the declarative data mapping provided by the binding)
>
> What do you think? 


This technically makes sense, but I'm not comfortable with the actual 
widget implementation having an impact on the form definition...

> I also like the practical consequences introduced by the 
> aggregate-field notion:
>
> - it becomes a template-designer choice to present the date as one 
> field or as separate fields 


In fact, I think there can be various interpretation of the 
"template-designer" role. It seems like you consider the template 
designer more like an HTML-guy, while I my experience shows that he's 
more an application-domain-related guy.

What I'd like to achieve is to have the form template define the overall 
form layout (fieldsets, columns, etc) but not the details of the layout, 
especially for low-level widgets. IMO, the form designer should not have 
to worry about the fact that the date input is actually implemented 
using a combination of 3 popups instead of a single input. Moreover, 
requiring the form designer to explicitely write these 3 popups in the 
template each time a date input is needed will certainly lead to 
inconsistencies in the GUI.

So actually, what I'd like to see in the form template for this date 
example is :
<wt:field id="startDate"><date/></wt:field>
<wt:field id="endDate"><date/></wt:field>

Which should be expanded into :
<wi:field id="birthDate">
  <wi:style><date/></wi:style>
  <wi:field id="birthDate.year"/>
  <wi:field id="birthDate.month"/>
  <wi:field id="birthDate.day"/>
</wi:field>

<wi:field id="endDate">
  <wi:style><date/></wi:style>
  <wi:field id="birthDate.year"/>
  <wi:field id="birthDate.month"/>
  <wi:field id="birthDate.day"/>
</wi:field>

This can be easily achieved if we consider two types of AggregateField 
that are SAXed differently :
- app-related aggregation (phone-number) : child fields are non-visual, 
an only the aggregating widget is output
- GUI-related aggregation (date) : child fields are visual, but not 
explicitely written in the template, and the aggregating widet SAXes 
them as part of it's own SAX production.

Now we still have a problem on the form-definition part : just as it 
would be painful to write all 3 subfields in the template each time we 
have a date, it is also painful to write them in the form declaration. 
Plus the usual consistency problems.

After the datatype and format catalogues, what is coming here is a 
catalogue for reusable field definitions !
Catalogue :
<wd:aggregate-field id="date-template">
  <wd:field id="year"/>
  <wd:field id="month"/>
  <wd:field id="day"/>
</wd:aggregate-field>

Form definition :
<wd:field id="startDate" extends="date-template">
  <wi:label>Start date</wi:label>
</wd:field>

</wd:field id="endDate" extends="date-template">
  <wi:label>End date</wi:label>
</wd:field>

... or should both the form definition and template go through and 
transformation (XSL or STX) that "expands" the widgets ? That's a more 
immediate solution, but introduces new pipelines and "cocoon:" sources 
for the definition and template.

What do you think ?

> - it allows for (maybe easier) validation rules on the split parts 

Sure !

> - it made writing the binding-stuff so easy that I could do it :-) 
> (now you see how I do all effort not to overload Bruno ;-)) 

Which confirms the previous point.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition)

[Marc Portier <mp...@outerthought.org>]

Sylvain Wallez wrote:
> Andreas Hochsteger wrote:
> 
>> Hi!
>>
>> A short question comes to my mind, while reading your RT:
>> Is it possible to use data types which are composed of several HTML 
>> input fields?
>> We are currently using three input fields for dates (day, month, year) 
>> at our current form solution.
>>
>> Thanks for clearification! 
> 
> 
> 
> Marc explained how this can technically occur using AggregatedField.
> 
> Now from a more semantical point of view, AggregateField is something 
> I'm not very comfortable with. Let's consider its two use cases :
> 
> 1/ Phone number example
> In this example, the displayed form shows only one input box, and its 
> value is split into several non-visual subfields used by the application 
> (country code, area code, number). Do these non-visual subfields really 
> belong to the form definition if it never displays them ? Doesn't this 
> split belong to the binding more than to the form definition ?
> 
> 2/ Date split in several inputs
> The day/month/year inputs are just a particular visual implementation of 
> a date widget (in the GUI meaning of "widget"). What if we finally 
> decide to use a calendar popup instead of 3 inputs ? Do we have to 
> change all form definitions ?
> 
> Maybe that's just nitpicking, but I find this somewhat breaks Woody's 
> clean SoC.
> 

Touché.
Indeed: The aggregatefield was only introduced when we started 
thinking about binding... however, by now I have learned to 
appreciate the concept as having its own value in the woody-model

You are right: it does somewhat hook up some back-end 
business-model vision onto the form-fields... but then again the 
(other) discussion we are having on the business-model-specific 
datatyping and even business-model-specific-validation does 
introduce the same level of mixing, no?

And while we try to manage the good SoC here, the reality of the 
app will always be that people *know* (influenced by their 
business-domain knowledge on the app they write) about these 
aggregations when they model the form. And not unlikely the form 
will need to be able to exploit that knowledge.
(In fact I guess that the reality vision expressed above is the 
real drive behind your current effort to make Woody more 
lightweight and generally usable?)


Purely technical I have also the following argument: I expressed 
earlier that the Woody model should be seen as the insulation 
layer between how the end user sees things and how the 
business-models need to be presented... now, I'm ready to change 
that into: it is the insulation-POINT where the two worlds are 
meeting.

The Woody form-model is what sits in between how the end-user 
consumes and edits his HTML-form and how the back-end presents 
and expects business data...

On the HTML form there is weak typing (only strings) and weak 
structuring (only a map-like structure of request-params) 
compared to the back-end view of things (rigid structure of 
staticly typed values)

The Woody-form-model takes up the responsibility of making the 
match between both, therefor it largely needs to know everything 
about both! (maybe this explains why it is perceived heavy  at 
first glance?)

So it needs
- datatype knowledge and convertors (doing the string to YourType 
in 2 directions)
- validation rules (making sure we're not handing over gibberish 
to the backend-model)
- mapping pointers into the backend-structure (binding)
- ...

What the introduction of the Aggregate-field is adding to the 
show is something I would call 'granularity of information', and 
to date I'm convinced that the woody-model needs to be aware of 
the smallest granularity either it be imposed by the end-user 
view or the back-end structure:

1/ phone number example:
      end-user sees 1 field
      back-end expects 3 distinct ones (ctr, zone, local)
   --> imposed granularity == 3

2/ date example
      end-user sees 3 fields (day, month, year)
      back-end expects 1
   --> imposed granularity == 3


The above also illustrates that the usage of the aggregate-field 
will only be useful to people actually having the intent to map 
stuff onto a backend-business model.
(but by now we already aggreed(?) that such is not really tied to 
actually using the declarative data mapping provided by the binding)


What do you think?


I also like the practical consequences introduced by the 
aggregate-field notion:

- it becomes a template-designer choice to present the date as 
one field or as separate fields

- it allows for (maybe easier) validation rules on the split parts

- it made writing the binding-stuff so easy that I could do it 
:-) (now you see how I do all effort not to overload Bruno ;-))


-marc= (in elaboration mode again, you all must think I get paid 
by the word)
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org