cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Date Wed, 26 Jan 2005 14:20:19 GMT
BURGHARD Éric wrote:
> 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.

You know, Éric, the difference between open development and closed 
development is that the final argument about what gets or doesn't get 
done is the magic "show me the damn code".

Oh, don't get me wrong, I committed many of the same sins: the adaptive 
cache and real blocks are both major designs that I never stepped up to 
the plate to implement.

As for you, the itch was not enough for such a big scratch. I'm also 
happy about it... our blocks are becoming more and more separated, the 
community is incrementally moving toward the need for more integration 
and their complex dependency chains is not making the itch strong enough 
for people to think about scratching.

It will all come together, eventually, and by doing it incrementally, 
the entropy generated will be low.

Daniel, on the other hand, puts his fingers where his mouth is: code 
gets done, items pushes, architectures cleaned.

My role is to make sure that he doesn't go off the tangent and changes 
just for the sake of elegance... which is against entropy management, if 
  ain't broke don't fix it, yadda yadda.... you know, the usual stuff.. 
and fast turns into bikeshedding.

I agree with you that having the ability to pass a nested data structure 
(dom or nested collections) from the sitemap to the template system 
would be useful and not more harmful than what we already have in place.

But I don't need it personally so I won't work on it.

Daniel doesn't need it and doesn't even like it, so it won't come from 
him, but I think he wouldn't vote -1 in case you submitted a patch.

So, in short, "show me the damn code" :-)

No, seriously, it all keeps balance to the thing: at the end the mixture 
of lazyness and itching is an extremely powerful combination to keep 
people honest, architectures as simple as possible, and new idea 
floating around.


View raw message