Leon Widdershoven <[EMAIL PROTECTED]> 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...
