You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Guido Casper <gc...@s-und-n.de> on 2004/04/19 08:59:20 UTC

Re: [RT] Use of flowscript or the pyramid of contracts

Antonio Gallardo wrote:
> 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:

Antonio, I think you may be right. But what I'm after is that I don't 
care that much how difficult it is to _write_ that components than I do 
for how difficult it is to _use_ that components. If the developer 
thinks it is worth it she happily goes the extra mile. Think how 
difficult it is for a newbie to write a sitemap component and how easy 
it is to use it.

> 
> 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?

Hm, I'm thinking out loud: Is there a way to come up with reusable 
components in Javascript (even if just providing higher level wrappers 
around Avalon components)? So that developers and users both may benefit 
and still keeping concerns separated.

Maybe I just want to much of architectural guidance?

Guido

-- 
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
                     Tel.: +49-5251-1581-87
Klingenderstr. 5    mailto:gcasper@s-und-n.de
D-33100 Paderborn   http://www.s-und-n.de
-------------------------------------------------

Re: [RT] Use of flowscript or the pyramid of contracts

Posted by Leszek Gawron <ou...@wlkp.org>.
On Mon, Apr 19, 2004 at 08:59:20AM +0200, Guido Casper wrote:
> Antonio Gallardo wrote:
> >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:
> 
> Antonio, I think you may be right. But what I'm after is that I don't 
> care that much how difficult it is to _write_ that components than I do 
> for how difficult it is to _use_ that components. If the developer 
> thinks it is worth it she happily goes the extra mile. Think how 
> difficult it is for a newbie to write a sitemap component and how easy 
> it is to use it.
The problem in writing components is the lack of documentation. After you are
a little bit familiar with cocoon internals (and without docs that comes after
quite a long time) writing a simple component is a piece of cake when you use
such tools as eclipse that generates all methods you have to implement
automatically.


Another thing is that people using cocoon in some part do not know Java at all
or at the level that stops them from doing any serious development. When I
started to use cocoon my Java knowledge was minimal. For two weeks I tried to
at least understand what the samples do and how this magic works. Cocoon users
are thrown on a very deep water at once. Almost every aspect of a web
publishing or application is implemented here in a innovative way. (sitemap,
transformers, flowscript, form frameworks).
	lg
-- 
            __
         | /  \ |        Leszek Gawron            //  \\
        \_\\  //_/       ouzo@wlkp.org           _\\()//_
         .'/()\'.     Phone: +48(501)720812     / //  \\ \
          \\  //  recursive: adj; see recursive  | \__/ |