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.
-- Stefano.
