cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Federico Barbieri <scoo...@betaversion.org>
Subject Re: [RT] Cocoon and web applications
Date Tue, 27 Feb 2001 05:07:05 GMT
Jon Stevens wrote:
> 
> Ok, I apologize in advance if this sounds harsh in any way. It isn't meant
> to sound harsh. So, take everything I say with a grain of salt.
> 
> thanks,
> 
> -jon
> 
> on 2/26/01 12:34 PM, "Berin Loritsch" <bloritsch@apache.org> wrote:
> 
> > Turbine is a specific framework.  There
> > is nothing that says that Turbine can't be built on Avalon, nor is there
> > anything that says that pieces of Turbine could be included in Avalon.
> 
> Yes there is. The fact that it would end up breaking a lot of people's code
> and the fact that the configuration is entirely different between Turbine
> and Avalon. Those are two MAJOR issues that no one here likes to even think
> about. People just like to say that it can be done...but in reality, it
> can't unless you want to also upset a lot of people.
> 

Avalon patterns are designed to be decoupled that is you implement what
you want and you can forget the rest. This is not evident from the
implementation but it's true. Catalina is running on top of avalon right
now and keeps using its configuration system. No problema.

I've spent most of my time to make sure block implementors are provided
with nice (IMHO) tools and patterns but are still free to do things
their own way if they wish. 

So the problem is not in terms of "it's painful to rearchitect
configuration" becouse you don't have too... the issue is what you gain.
Today I would say nothing... tomorrow... well it may be a dream but I
think it can gain a lot. Why? 
Take an example... Let's say both cocoon and turbine are blocks...
avalon doesn't make any difference, blocks are all alike. Then you may
have turbine using cocoon as output (renderer) AND cocoon using turbine
at the same time. Each of the two may have different advandages and
disavantages but both are possible and easy to implement in such
enviroment.

In other words moving to a common ground helps those who may wish to
have more integration. 

I'm not asking you to move turbine to be a block right now... it doesn't
make sense at least today. I whould be more than happy to hear turbine's
devs take a look at jakarta-avalon/proposal that is the core of avalon
specs and state your opinion. 
You keep saying "take a look at turbine" so for me to say "you look at
avalon" looks like stupid... here's the difference. Jakarta avalon is
made up ONLY by interfaces and design patterns. There's nothing (almost)
belonging to the kernel implementation. The entire cvs is used by
cocoon, james, phoenix and cornerstone, each single calss. The cvs split
has this (among others) purpose... construct a round table where cocoon,
james, phoenix are all EQUAL users. The feeling that avalon devs drive
the evoluton and all the others have to follow their daily caprices MUST
be over. 
My best reward whould be to see cocoon action pattern formalized and
placed here. 

Any developer that thinks he can gain from this common ground is
welcomed, I personally think it make sense for turbine too, if you don't
think so... well we can still be friends. :-) 

> Add to the fact that up until just recently (thanks to Sam's efforts),
> Avalon has been a terrible moving target. 

I like to think I have my contribution in this... :-)

> Solve those problems and I would be more than happy to have Turbine use
> Avalon where it makes sense (I have been saying that for years now).
> However, the fact of the matter is that I don't see it happening unless
> someone steps up to make it happen. Of course I wouldn't -1 it, but I sure
> am not going to do it. What I have works just fine now and Avalon isn't my
> itch. I don't need blocks, I don't need stuff componentized into a bazillion
> pieces. I just need a web app framework.
> 

You're right... there is the need for volunteers first. Thou it could
help try to make things easier for anyone with good intention... 

> > This has promise, although I would have to give some time to research
> > the Turbine MVC patterns.  There is alot that could be learned here.
> 
> Nice to hear you say that given that the Action framework you just talked
> about in Cocoon 2 is essentially something that was invented at least 4
> years ago (even before Turbine existed) by my friend Leon Atkinson and was
> done first in PHP! I find it humorous that this same Action framework is
> also in Struts as well. More re-invention of the wheel because no one
> bothers to look at Turbine first or people claim that Turbine isn't J2EE so
> they don't want to use it. Duh. How lame.
> 

This is been said so many times... this happend becouse it's way easier
and faster to reinvent the weel than dig into turbine. No matter that
turbine is well designed and documented. 
I know this is true right now but I don't like it. The best solution I
can think about is to spend some more effort to get turbine and cocoon
closer where it's possible so that developers from both sides will find
easier to dig in the other project. 

> Seeing projects like Cocoon trying to do a bazillion different things and
> only being able to do an ok (not excellent, but not horribly bad) job of
> each of those things (for example, Cocoon is great at output into a bunch of
> different formats, but sucks for webapps). You can't build one tool that
> solves every problem. For example, that is why there is "cp" and "mv" on
> Unix...they each do one thing really well.

I don't want to build a tool that can do everything, I'd like to see
tools that can be easily integrated. My VCR and my TV do very different
things but the both use the same plug. 

Fede

Mime
View raw message