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:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-------------------------------------------------

Reply via email to