On Friday 19 March 2004 02:30, Berin Loritsch wrote:
Granted, the same type of thing can be done using attributes instead of naming conventions. The attributes would prove more flexible as well because they can include more information than the general "Type" that is acceptable. That would minimize the occurance of IllegalArgumentExceptions, etc. because the tool would then be able to provide a control that does not allow the user to input bad information.
Is this the first time two of us can agree? Wouldn't that be something to celebrate? Or are you just being sarcastic?
We agree on this. It isn't the first time. The thing is in many respects we agree on many things, just not on the methodology most times.
However, in order to tool that, the current Avalon Meta package is woefully unequipped. Then again, I am sure there are a number of other ways to accomplish the same goal. But, as you say, it comes down to the tools that enable the user to do what they need.
Do I think Avalon Meta in the current shape is a final solution? Have I not made it obvious that my angle is from the component towards the container, not the other way like everyone else?
I would imagine the answers to be the following:
1) No. 2) Yes.
To which I add, that component to container is only one area. There is also component to tool, as the example at the top of the list proves.
There are many aspects in which a tool can assist developers that have nothing to do with the container. That is why I feel that restricting the meta info to only that recognized by the container is a mistake. I do feel that there should be a set of meta-info that the container recognizes and that should be pretty much set in as much stone as Avalon Framework. However I also feel that there is value in allowing other attributes to be used for components that work with tools or provide instrumentation hints.
When you constrain your set of gathered attributes to only the ones recognized by the container, you lose out on a large group of enhancements that can provide real value add. I am not saying the container should recognize all these extra attributes or even worry about them. The contract between the component and the container is just that. It should remain at that. There can be contracts between a component and a tool. Contracts between a component and an add on to the container. Does that mean that we are now restricted to that container, or just that we need the add on to work in other containers?
The point I am trying to get to is that the contracts should be limited to exactly what they are. Just how much information does a component have to provide to the container to be useful? IMO, it is limited to the services provided, and the dependencies needed. Everything else is extra. Does it mean that it is not useful? No. It can be used for component validation and verification. It can be used for a number of things. So, if I have a component with the minimal amount of information supplied, I shouldn't have to worry about it being rejected because I didn't supply validation tags.
Do you see what I am getting at?
Why do I ask so many questions?
Because we never learn if we don't.
Niclas?
:)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
