cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Mon, 19 Apr 2004 21:10:22 GMT
Leon Widdershoven <> writes:

> 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.
> >>
> >> I think you could slowly move towards enforcing a FOM only 
> access to 
> >> Cocoon; maybe start with two levels of access: a default 
> FOM only and 
> >> a "RAD flag" (developer_mode='true') that be configured to say to 
> >> Cocoon that a developer wants to allow script X to have access 
> >> outside of the FOM model ?
> >>
> No, please no. It is hard enough to find  components/scripts that do 
> what you
> want them to do - without reinventing the wheel. It really is 
> not a good 
> idea
> to artificially limit access to ready-made logic and thus 
> forcing users 
> to either
> hack the cocoon sources, or to reinvent the wheel.
> What you can say is that particular scripts should be 
> considered private 
> or protected
> to indicate that their contract may change at any time without notice 
> and that it
> is thus very unwise to build a system based on that. (Yes, like Java).
> A protected script also makes sense if it manages a resource 
> which must 
> be called
> only when particular demands have been met, or which may have side 
> effects on the
> fllowscript environment.
> But both such cases would be to protect the user, and not to 
> force users to a certain development model favoured by the 
> developer. The developer may well be right in his opinions, 
> but users come from different backgrounds and would not 
> understand they be limited because their way is not neat.
> I am sorry if this sounds to harsh, but it really *is* hard enough to 
> find functions which
> do what you want them to do. If you then find out those functions are 
> 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?

> If I read to much in the statement above I am sorry. But I 
> strongly feel 
> that flow
> is a more powerfull  technology than xsp for many 
> applications, and that it should be kept simple for users. 
> And simple is not a limited set of 
> functions, but
> a feature rich environment which allows you to do what you 
> want without 
> 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...

View raw message