On Fri, Jul 25, 2003 at 11:09:46AM -0400, Berin Loritsch wrote:
> Perhaps if I have a better understanding of the real problem you are trying
> to solve, I might be able to better grasp what you are getting at. For
> instance, I can think of some things that would make sense for a container
> to pass into a component on lookup but I have trouble in my mind coming up
> with a reason to pass user variables to the component.
Ok. Currently I have a component requires a URI location to work, it has
4 or so methods in it's interface, each of them need the remote URI location
for the methods to work. At the moment I specify the URI location
as a parameter to each method, something like:
interface Component {
void doOp1(URI uri);
void doOp2(URI uri);
void doOp3(URI uri);
void dpOp4(URI uri);
}
Ideally I'd like to be able to specify the URI once, and then be able to call
the methods, outside of Avalon you'd do something like:
Component c = new Component("http://host/location/";);
c.doOp1();
...
c.doOp2();
as a constructor parameter.
Inside of Avalon, as far as I can tell, to do this I need to add a setter
method to set the URI:
interface Component {
setURI(URI uri);
void doOp1();
void doOp2();
void doOp3();
void dpOp4();
}
But I don't really like this too much, because setURI() needs to be called
to make the component valid. I need to check in each operation that the URI
has been set if a user of this component forgets to set it, etc, etc.
What I'd like to be able to do, is specify the URI when the component
is looked up, so that I can be sure that the component is valid when the
user gets a reference to it.
Perhaps parameterizing the lookup is the wrong approach - but hopefully that
gives you a better understanding of what I'm trying to do.
> Keep in mind that components might be shared across instances, so what it
> looks like you are proposing won't work for them. Also, I would like to
> know the scope of the parameter. Does it apply as long as the client
> maintains
> its reference to the component, so that after the component is released the
> parameter is null and void?
Honestly I hadn't thought about the scope of the parameter, with my container
I would be setting the parameter to be the internal URI reference which
would mean it would exist until the component is decomissioned.
But, since it's an RT, we can change the solution to be however we like! :)
> Solving real problems is what will keep Avalon Framework lean and mean. I
> think we should resist changes to Avalon Framework unless there is a well
> defined reason to do so, and all the committers agree. So we need to
> compare
> a real life example showing why it is cumbersome to do it now, and how much
> easier it will be in the future if we adopt the proposal.
Sure, I agree we should keep the interfaces lean and mean. If this solution
is not the best, perhaps there's a better solution to the problem that we
might discover ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
