Leon Widdershoven wrote:
Guido Casper wrote:
Yes that might be one reason. Another one IMO is that it's much easierI think that is the true question.
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 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
