> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > > What's the big deal about doing that in your configuration method? > > I don't do it this way. > This is how Cocoon does it AFAIK, take off your Cocoon hat ;-)
It's been off for a while now. I have questions for you, and let's take this back on the list :) > > Also the parameters object is derived from the configuration object > > Not here, that's a Cocoon implementation detail. Now you have me concerned. CONTRACT VIOLATION FLAGS ENGAGED 1) We need to have an enforceable and repeatable framework, or your component WILL NOT WORK in any other container than the one it was developed for. 2) The Parameters object is either a synonym for the Configuration object or we must EXPLICITLY define WHERE in the H-E-double hocky sticks it comes from. Unequivocably. The Parameters object must have a predictable content, and that cannot be the case if one container does one thing and another container disregards those contracts. Contracts are good--make them enforceable one way or another. > > that would otherwise be passed into the component. Really, it is > > pretty messy to mix those two. > > Still don't see why. > > One thing is *recommending* to use one or the other. > Another is *enforcing* it. > > There is no reason why having both is bad. Maintenance. If your component is configured in two different ways, the poor person coming in after you to clean up your mess (uh, err, I mean add new functionality) has to go through more than one method to see what gets set where. We want to reduce the work of the maintainer--making Avalon harder to resist. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
