Newbe Questions about Components

[Kerry Todyruik <ke...@todyruik.com>]

Hi.

I am fairly new to using Avalon.  I think the framework is great and I
am trying to integrate the framework into a web application that I am
building.

I am still trying to wrap my brain around the idea of components and
which classes I have written should become components and what should
not.  I have read through "Developing with Avalon" thoroughly.

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?  On the same thought, do any classes that need to access the
logging facility also need to be components?

I am using the Command pattern and have already created a number of
commands that perform simple to complex database operations.  One
example might be something like an ApproveCompany(int companyid) that
changes the status field of a company record in the database.

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.

Another thought I had is to build some kind of command invoking
component.  This might be useful as I have a number of command classes
to do various maintenance activities on the database.  I would
appreciate any thoughts on this or suggestions from those who may have
implemented something like this already.

Thanks in advance,
Kerry Todyruik

-- 
Kerry Todyruik <ke...@todyruik.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Newbe Questions about Components

[Peter Donald <pe...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Newbe Questions about Components

[Paul Hammant <Pa...@yahoo.com>]

Kerry,

>I am fairly new to using Avalon.  I think the framework is great and I
>am trying to integrate the framework into a web application that I am
>building.
>
You know then that Framework and Excalibur are the subprojects of Avalon 
that you are going to use.  Pheonix itself os not really best used in a 
webapp.  I guess you knew that,

>I am still trying to wrap my brain around the idea of components and
>which classes I have written should become components and what should
>not.  I have read through "Developing with Avalon" thoroughly.
>
>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?  On the same thought, do any classes that need to access the
>logging facility also need to be components?
>
No, not all classes need to be components.

>I am using the Command pattern and have already created a number of
>commands that perform simple to complex database operations.  One
>example might be something like an ApproveCompany(int companyid) that
>changes the status field of a company record in the database.
>
We have a "command stream" in use for AvalonDB. :

    
http://cvs.apache.org/viewcvs/jakarta-avalon-cornerstone/apps/db/src/java/org/apache/avalon/db/transport/

The commands are not components, they are simple beans.  But they they 
are only serializable messanges.  The handlers that process them are 
components (primarily for loggable capability).

>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.  
>
Don't worry dude, leave your commands are is and seperate processing 
logic to other classes (handlers).

>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.
>
>Another thought I had is to build some kind of command invoking
>component.  This might be useful as I have a number of command classes
>to do various maintenance activities on the database.  I would
>appreciate any thoughts on this or suggestions from those who may have
>implemented something like this already.
>
Again in the DB project we have a ....

     Reply processRequest(Request request) throws XXXException;

....that is the central hub for handling of requests...

Any clearer?

Regards,

- Paul H


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>