cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <...@dds.nl>
Subject Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Tue, 20 Apr 2004 19:19:38 GMT
Guido Casper wrote:

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

Me too. I do hope that more than one way of doing things will be 
created. There is nothing like darwinism to determine what is really 
usefull.
Besides, the Object/Relational mapping can also be done in (at least) 
two ways. I even saw a listing of about 9 Java O/R frameworks! Some
free, some not. I think Hibernate and OJB are the most probable "early 
adopters", though OJB withJDO has a bit of a disadvantage since the
required libraries cannot -apparently - be bundled with cocoon but must 
be downloaded by sun, which is a bit of a set-back concerning the
samples block.

I however do look forward to an O/R framework with javascript, besides a 
simple SQL engine, of course. I have started playing with
O/R myself as I found it both easier to understand (a single framework 
is an advantage), and found better understandable documentation
on it. It helped that my reverse-db of OJB tool did not work out of the 
box (as a typical user who earns his meager(:) bread with development
I do like non-core (for me) functionality to work out of the box).

Leon


Mime
View raw message