cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Casper <gcas...@s-und-n.de>
Subject Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Tue, 20 Apr 2004 18:42:07 GMT
Leon Widdershoven wrote:
> Guido Casper wrote:
> 
>> Yes that might be one reason. Another one IMO is that it's much easier
>> to (conceptually) come up with a reusable sitemap component (being a
>> specialized thing) than it is to come up with a reusable flow component.
>>
>> Guido
>>
> I think that is the true question.
> I am writing an application which gets an excel spreadsheet with 
> information;
> this information must be read into data structures, and compared with 
> existing
> databaserecords, and then  merged.  I use flow to get the user data.  I 
> have
> tried to write the total application entirely in Javascript (with of 
> course HSSF
> Java classes). It works, but is not really maintable.
> So I wrote a reusable flow component called a Java Package. The main
> class gets the uploaded spreadsheet and all flags, and returns errors or 
> OK.
> It can be called from any flowscript program, the classes can be 
> configured,
> it can be called by Java classes. How much more reusable can you get?
> 
> And at the same time I think this is not what flowscript developers call
> reusable. What is the characteristic of a reusable flowscript component,
> defined in a way a user can understand?
> For cocoon components that's easy. Implement a particular interface and
> it is a particular kind of component. But flowscript is just much more free
> on the one side, and in other ways a bit more restricted.

But it is possible :-), like somewhat being proved by CForms (and other 
components as well but CForms is the only one with a dedicated 
flowscript API).

I'm quite excited about the recent discussions about the "best" database 
interaction layer. It may result in several approaches in parallel 
(which is perfect as there are quite various requirements being targeted 
by db apps/tools) but I feel one (or several) of those might evolve into 
something like a "prototype of a reusable flow component" (or be the 
base of another layer providing the "prototype of a reusable flow 
component" :-).

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

Mime
View raw message