Hi,

I´ve just discovered Struts and I am finding it great. We've developed a
framework of our own in my company and now I'm trying to map how to migrate
things to Struts.

One of the things we have that works great (in terms of productivity) is a
class that simply calls a serie of "services" objects (Data Access Objects)
passing a Bean to be filled and some filters (in a HashMap). This is very
usefull in the classic "master-detail" problem (nearly 70% of our pages -
intranet applications).

In the "master" case , we usually have only one service call loading a
list.
In the "detail" case, we can have a lot of services loading lists (for
combo boxes) and a service loading the "detail" bean.
Even in the "master" page we can have a serie of service calls to load
"Combo Filters".

In our framework the configuration is done programatically (which is bad),
calling configuration methods of a "Command" class (like an Action class).
This is done in the servlet (the calls).

My question is about what is the best design strategy to implement this
using Struts. My first thought was to extend tha Action class to implement
the serie of service calls. The problem is how to retrieve the
configuration of services, beans and filters (I would like to do that in a
declarative manner).

I thought about extending the ActionMapping class to add these
configurations and use the set-property tag to set them, but it would be
quite confuse (the configuration is a bit more complicated then a list of
name-value pairs). I think I would need a XML hierarchy of my own.

Any suggestions appreciated ... :)

Thanks in advance.

********Confidencialidade do Correio do Eletrônico***************
Informações confidenciais podem estar contidas nesta mensagem. Se você não
se encontra na lista de destinatários ou não é o remetente da mesma, você
não deve copiar ou enviar esta mensagem para ninguém. Neste caso, você deve
destruir e notificar o remetente da mesma. A empresa considera opiniões,
conclusões e outras informações que não se relacionam com o negócio oficial
da corporação de responsabilidade do usuário do serviço.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to