Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: 
 <1E0CC447E59C974CA5C7160D2A2854EC097DF2@SJMEMXMB04.stjude.sjcrh.local>
From: "Hunsberger, Peter" <Peter.Hunsberger@STJUDE.ORG>
To: <dev@cocoon.apache.org>
Date: Mon, 19 Apr 2004 16:10:22 -0500
Subject: RE: [RT] Use of flowscript or the pyramid of contracts  (was Re: [RT]
 Checked exceptions considered harmful)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-SEF-FD9E3BCC-24E9-4B6F-96E-FFC4B78-SJCRH: 1
content-class: urn:content-classes:message
Thread-Topic: [RT] Use of flowscript or the pyramid of contracts  (was Re:
 [RT] Checked exceptions considered harmful)
Thread-Index: AcQmUXcOJqRRMeyzSWi/gwmzuJ5imgAAGANA
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Leon Widdershoven <qaz@dds.nl> writes:

>=20
> Guido Casper wrote:
>=20
> > Yes that might be one reason. Another one IMO is that it's=20
> much easier=20
> > to (conceptually) come up with a reusable sitemap component=20
> (being a=20
> > specialized thing) than it is to come up with a reusable flow=20
> > component.
> >
> > Guido
> >
> I think that is the true question.
> I am writing an application which gets an excel spreadsheet with=20
> information;
> this information must be read into data structures, and compared with=20
> existing
> databaserecords, and then  merged.  I use flow to get the=20
> user data.  I have tried to write the total application=20
> entirely in Javascript (with of=20
> course HSSF
> Java classes). It works, but is not really maintable.
> So I wrote a reusable flow component called a Java Package.=20
> The main class gets the uploaded spreadsheet and all flags,=20
> and returns errors or OK. It can be called from any=20
> flowscript program, the classes can be configured, it can be=20
> called by Java classes. How much more reusable can you get?
>=20
> And at the same time I think this is not what flowscript=20
> developers call reusable. What is the characteristic of a=20
> reusable flowscript component, defined in a way a user can=20
> understand? For cocoon components that's easy. Implement a=20
> particular interface and it is a particular kind of=20
> component. But flowscript is just much more free on the one=20
> side, and in other ways a bit more restricted.
>=20
>=20
> >>
> >> I think you could slowly move towards enforcing a FOM only=20
> access to=20
> >> Cocoon; maybe start with two levels of access: a default=20
> FOM only and=20
> >> a "RAD flag" (developer_mode=3D'true') that be configured to say to 
> >> Cocoon that a developer wants to allow script X to have access=20
> >> outside of the FOM model ?
> >>
> No, please no. It is hard enough to find  components/scripts that do=20
> what you
> want them to do - without reinventing the wheel. It really is=20
> not a good=20
> idea
> to artificially limit access to ready-made logic and thus=20
> forcing users=20
> to either
> hack the cocoon sources, or to reinvent the wheel.
>=20
> What you can say is that particular scripts should be=20
> considered private=20
> or protected
> to indicate that their contract may change at any time without notice=20
> and that it
> is thus very unwise to build a system based on that. (Yes, like Java).
>=20
> A protected script also makes sense if it manages a resource=20
> which must=20
> be called
> only when particular demands have been met, or which may have side=20
> effects on the
> fllowscript environment.
>=20
> But both such cases would be to protect the user, and not to=20
> force users to a certain development model favoured by the=20
> developer. The developer may well be right in his opinions,=20
> but users come from different backgrounds and would not=20
> understand they be limited because their way is not neat.
>=20
> I am sorry if this sounds to harsh, but it really *is* hard enough to=20
> find functions which
> do what you want them to do. If you then find out those functions are=20
> blocked for
> some unfathomable (ideologic) reason, you would not be glad.

Well, given the fact that I wrote the bit you're responding to and not
Guido I don't think he'll find it harsh ;-)

I don't see much difference between marking something "private" vs. "not
for normal access by end users"? In fact I think the "RAD flag" would be
a little more liberal than private vs. public since if you needed you
could always flag a script as using non-FOM objects, but if the object
is private you're going to need the source of the Java object to make
the change?

>=20
> If I read to much in the statement above I am sorry. But I=20
> strongly feel=20
> that flow
> is a more powerfull  technology than xsp for many=20
> applications, and that it should be kept simple for users.=20
> And simple is not a limited set of=20
> functions, but
> a feature rich environment which allows you to do what you=20
> want without=20
> to much
> Java (a bit like xsp is now),

Personally, I tend to agree.  However, if others feel the need to
restrict the contract more than currently I think there should be some
kind of escape hatch for developers...