Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: BURGHARD =?ISO-8859-15?Q?=C9ric?= <eric.burghard@systheo.com>
Subject: Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Date: Wed, 26 Jan 2005 11:12:20 +0100
Lines: 75
Message-ID: <ct7qcm$aus$1@sea.gmane.org>
References: <cstjmv$6iq$1@sea.gmane.org> <41F279A6.7020704@nada.kth.se>
 <csu7ct$kpi$1@sea.gmane.org> <41F37683.9090203@nada.kth.se>
 <ct0hge$udh$1@sea.gmane.org> <41F3EDFE.70505@nada.kth.se>
 <F2D7D294-6DC7-11D9-9957-000393B3DE96@hard-bop.com>
 <ct37l2$n8n$1@sea.gmane.org> <41F52D15.2060809@apache.org>
 <ct45s8$p2m$1@sea.gmane.org> <41F5EF03.6000404@apache.org>
 <ct5bfv$e36$1@sea.gmane.org> <41F64675.6090009@nada.kth.se>
 <41F6A189.1020903@apache.org> <41F6DCD3.3020907@nada.kth.se>
 <41F6EE2F.8060302@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8Bit
User-Agent: KNode/0.8.2
Sender: news <news@sea.gmane.org>

Stefano Mazzocchi wrote:

> 
> My girlfriend tells me that sometimes it seems like I argue for the sake
> of arguing.., that I would take the other side no matter what... and
> that in a single conversation I might argue about why something is black
> and then argue about the same thing is white once I change the other
> person's opinion.
> 
> I know I do that... and the reason why I do that is that I force people
> to convince themselves before convincing me. There is no such thing as
> being right or wrong.... especially if we don't understand what we
> really want in the first place.
>

Thanks to you and daniel, i changed my mind during theses threads. I never
thought about the real goal of jx : to be a simple template language, SoC
and IoC compliant. So, i was the first to request a servicemanager
access :-), It's certainly due to my misunderstanding of the whole process,
but i think that jx role didn't appear clearly in the current
implementation (ie effectively far from preserving the former properties).

After beeing convinced by your explanations, i happily jumped on the other
side (vote -1 for my own request). No problem about that.

> I think that as long as cocoon grows incrementally and organically,
> there is no problem in any approach and that usage will tell us if
> something was a good idea or a bad one.
> 
> So, to cut it short: it really doesn't matter what you are saying but
> *how much you are willing to suffer to get it across* :-)
> 
> More than anything, I act as a filter. A pain in your butt. I play death
> in a design chess game... where the community is what wins.
> 
> So, it doesn't really matter what you do or propose, but how and how
> open is your mind when you do that. The sofware result will be shaped by
> reality and usage anyway, and it will never be perfect because
> perfection is never in living things (and open developped software is a
> living organism) if not in their own existance.
> 

I really approve this kind of approach.

Cocoon is really convenient for doing complex things but it should be
convenient for simple things too (stateless templating as you said) to be
able to attract less involved developpers (It take us near one year of
intensive web application developpement around cocoon to be able to discuss
with you).

Dom in sitemap parameters is the kind of little addition (user point of
view) that could simplify some simple use cases with jx as well as with
flow. It gives a kind of access to the servicemanager via input modules
(one of the first thing you learn with cocoon) without knowing a thing on
avalon component lifecycle or existing java classes. You don't have to
implement any input module access in jx, it didn't compromise any existing
things either.

If you want to enforce some properties on jx (restrict the kind of objects,
deprecate $session, ...) you could do it after this little addition anyway.
(i'm sure these restrictions could help to give a better vision to new
users of what the sitemap, flow and jx are supposed to be and to do).

I don't feel strong enough for implementing such thing :-(, but i feel that
with the help of the the ObjectHelper and by implemeting a new method that
return object instead of object.tostring() in inputmodule (naive view) it
should be easy to pass object from sitemapcontroler to jxtg.

Don't hesitate (everybody) to point me to the right direction, i will be
happy to contribute if i estimate that my project will not suffering from
my involvement here.

Regards.

�ric.