Ok, let me try and restate what I think I read.
We define the lifecycles as delegates for example:
delegate void Service( IServiceManager manager );
We also define some lifecycle attribute, for example:
[AvalonLifecycle("Serviceable")]
which a component would define on the method that matches the
corresponding delegate definition, for example:
[AvalonLifecycle("Serviceable")]
public void MyServiceMethod( IServiceManager manager) {}
Then at runtime, when a component is deployed, the container would
reflect over the component looking for the set of attributes and setting
up the delegates then.
Did I get that right? I think that might just work. My only concern with
it is the container would have to check every method in the component to
see what lifecycles it uses instead of just checking the class
definition for interfaces.
Ok make it two concerns, also, given this approach, if the component
maker defined the MyServiceMethod incorrectly (didn't match the
delegate) the mistake wouldn't be caught at compile time because the
delegate wouldn't actually be created until it is deployed. This could
just increase the test/debug cycle a bit. This makes it a bit awkward.
Chris
-----Original Message-----
From: Berin Loritsch [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 12:32 PM
To: Avalon Developers List
Subject: Re: ROLE & Lifecycles in C#
Leo Sutic wrote:
>
>>-----Original Message-----
>>From: Geer, Christopher S [mailto:[EMAIL PROTECTED]
>>Sent: den 29 juli 2003 18:14
>>To: [EMAIL PROTECTED]
>>Subject: ROLE & Lifecycles in C#
>>
>>
>>I've been working with Yauheny on the Framework/Fortress port
>>to C# and had a couple of questions that I was hoping to
>>Avalon community could help answer.
>>
>>1) In light of the recent discussion and clarification of the
>>ROLE field
>
>
> One solution is to simply skip it. In Phoenix, for example,
> when you want a MyComponent, you have to:
>
> a) declare a dependency on MyComponent.
>
> b) declare under what name you will look it up.
>
> For example:
>
> Depends on: MyComponent
> Name: my-component
>
> Then:
>
> MyComponent comp = (MyComponent) manager.lookup ("my-component");
I believe the attribute allows for this. For example:
[AvalonDependency(MyComponent, "my-component")]
[AvalonService]
public void servicio( ServiceManager manager ) throws ServiceException
{
MyComponent comp = (MyComponent) manager.lookup("my-component");
}
We need to think on this a little more. In fact for the .NET framework,
we might be able to cheat and simply put something like this:
[AvalonDependency(ComponentoDePaz)]
public void paz(ComponentoDePaz dePaz)
{
m_dePaz = dePaz;
}
The only issue is lifecycle is made a little more difficult, but it is
a bit friendlier to the user.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
