avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Newbe Questions about Components
Date Fri, 30 Nov 2001 22:47:43 GMT
Hi,

On Sat, 1 Dec 2001 07:52, Kerry Todyruik wrote:
> The first Component I moved over was a DataSource component.  Pretty
> straightforward.  But now, in order to access my DataSource component,
> do all classes that perform a database operation need to be a composable
> component? 

If by component you mean they must implement Component then no. You can still 
do something like

myObject.setDataSource( myDataSource );

> On the same thought, do any classes that need to access the
> logging facility also need to be components?

not really.

> If I now have to make my Command classes into components, then I can't
> use the constructor anymore to define parameters.  Should I then use set
> methods to set the paramters before calling execute()?  If I do this, I
> feel I am losing some of the conciseness and clearity of the command
> objects I was using.  I'll also have to check that the parameters have
> been properly set or not.  I am also worried that making command object
> like these into components might be a misuse of the component framework
> and would like to check this.

It's hard to say without looking at the code but I suspect that it would be 
best not make them components. However if they do need some substantial 
amount of resources from the system you could still do something as simple as

Action action = new MyAction(123);
setupLogger( action );
if( aciton instanceof Composable )
{
  ((Composable)action).compose( componentManager );
}

action.execute();

That way if the actions required extra resources for whatever reason (ie some 
may use DataSource, some may use JNDI, some may use a Mail Session etc) they 
would all be able to get whatever they wanted out of the component manager.

So it really depends on how many actions does your application have? If there 
is lots and they each have different needs (ie some need DataSource, some 
need JNDI etc) then you could optionally make the Actions composable. 
Something like

interface Action {}
class AbstractAction implements Action {}
class AbstractComposableAction extends AbstractAction implements Composable {}

-- 
Cheers,

Pete

-----------------------------------------------------------
    If your life passes before your eyes when you die, 
 does that include the part where your life passes before 
                        your eyes?
-----------------------------------------------------------

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message