You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2003/08/02 13:06:20 UTC
[RT] Cubist WebApp Team Organization (was Re: AggregateField and
SoC (was Re: [RT] Revisiting Woody's form definition))
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: [RT] Cubist WebApp Team Organization (was Re: AggregateField
and SoC (was Re: [RT] Revisiting Woody's form definition))
Posted by 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))
Posted by 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))
Posted by 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))
Posted by 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
Posted by 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))
Posted by 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))
Posted by 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.