cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Date Mon, 19 Apr 2004 00:46:41 GMT
Guido Casper dijo:
>> I think that cocoon.getComponent(role) would be enough if writing those
>> components would be as painless as writing flowscript. No need for more
>> complex stuff.
> I don't think developers aren't eager to write reusable components. But
> currently it's just that hard to come up with components really making
> the user's life easier.

Yep. One of the things that refrained us to write components is the too
much overhead they have:

1-Implementations of the lifecycle: Configurable, composable, etc.
2-The (1) give you even more code to write based on the implementations
you choosed in (1).

And people just want to write a simple hello wold component. The question
is how much lines I need to write. And when we realize it is more than 20
lines. We are lost. It is really the better way to do things?

I think the key is in KISS. The Flow Engine is so popular because of his
own simplicity. And that is cool.

I realize that components are a diferents than FlowEngine scripts. But I
try to sell the concept of easy components writing is what the users need.
An alert is already out: People is starting to (ab)use of FlowEngine code
because they feel it is easier to write the full logic on FlowEngine
instead of writing a component. I think we need think about this fact. On
the mail list are clear samples of how they are even making workarounds to
make things works in Flow at any cost, even when using a component will be
easier (you have full access to many thins and in flow you have not the
same access). But the perception win in this case.

Components are existed before Flow, but Flow is more popular than writing
components, the question is why?

> The problem I have with cocoon.getComponent() is the user's side of the
> fence. getComponent() doesn't say anything about the granularity of a
> component as Avalon allows for (and encourages) components of any
> granularity. Avalon has been there before flow and is intended to make
> the Java developer's life easier not the flow user's.
> The services for flow users should be coarse grained and high level. And
> I believe that the user shouldn't have to deal with technical details
> like component lifecycle (and having to call releaseComponent()).
> Please note that I don't want to discuss the pro/vs. release(). I really
> don't care wether the developer has to call release (at least right now
> :-).
> I for sure don't want to increase overall complexity. But if I could
> trade reduced user complexity for increased developer complexity I would
> do.

a big +1.

>>>> The reason I'm thinking about this is that I wondered wether the
>>>> repository block justifies its existence now that we are short before
>>>> JSR170 comes along. And in my opinion it does. JSR170 is a Java API
>>>> while I want my _users_ building a CMS. Does it make sense and is it
>>>> achievable?
>> the JSR 170 is a complex beast. I would wrap it with a Repository avalon
>> component, make the interface really simple and pass this to the
>> scripting layer, hiding all the complexity inside.
> Exactly. I'm just thinking about a better way than an Avalon component
> (and thought it might be the right time to speak up now that we are
> designing a new container).
>> That's how I would do it.
>> And yes, I still believe in the pyramid of contracts, even more than in
>> the past, but the sitemap is not enough, we need something else, we
>> can't write script in XML.
> Yes, I realized that flowscript is the perfect solution to the missing
> piece of the pyramid of contracts for the webapp space.
> I just feel we should much more leverage it for this role and it is
> vital to give more emphasis to the user.

I think we share the same feeling :-D

I will add I will prefer to change the default FlowEngine language from
javascript to Groovy. I really believe it will give the user a more
productive language with the best Java integration. It will be really a
good tradeoff.

Best Regards,

Antonio Gallardo.

View raw message