[SPRING icm STRUTS] DelegatingActionProxy

[Cuball]

We gebruiken reeds een geruime tijd Struts als MVC framework binnen onze applicaties, nu hebben we besloten om ook gebruik te maken van het Spring framework, dit icm met Struts (dus niet het MFC framework die bij Spring geleverd wordt).

nu gaan we zo te werk binnen onze struts-config.xml:

code:

<action path="/person/initEdit" 
                name="personForm" 
                parameter="initEdit"
                type="be.xxx.celmeeting.web.action.PersonAction">
            <forward name="success" path=".selectEditPerson"></forward>
            <forward name="failed" path=".addPerson"></forward>
        </action>
        
<action path="/person/save" 
                name="personForm" 
                parameter="save"
                validate="true"
                type="be.xxx.celmeeting.web.action.PersonAction"
                input=".addPerson">
            <forward name="success" path=".addPerson"></forward>
        </action>
.....

De klasse PersonAction is afgeleid van de Struts DispatchAction. In deze klasse staan dus verschillende acties gegroepeerd die allemaal logisch bij elkaar horen. Hier alle acties die met een person te maken hebben. Deze beginnen allemaal met /person/ Indien we geen gebruik zouden maken van een DispatchAction zitten we per project snel over de 100 actie klasses. Nu zoals er te lezen staat in de documentatie van Spring moet je nu voor elke actie beschrijven welke business logica bean geinjecteerd moeten worden. Dit ziet er zo ongeveer uit in de applicationContext.xml:

code:

        <bean name="/person/initEdit" 
                class="be.xxx.celmeeting.web.action.PersonAction">
        <property name="personBO">
                <ref bean="personBO"/>
            </property>
        </bean>
        
        <bean name="/person/save" 
                class="be.xxx.celmeeting.web.action.PersonAction">
        <property name="personBO">
                <ref bean="personBO"/>
            </property>
        </bean>

In dit voorbeeld is nu slechts 1 bean nodig, maar zoals je kan verwachten is dit bij ander acties niet het geval. Wat ik nu heel vervelend vond is dat je dit voor ELKE mogelijke actie moet schrijven, en zoals eerder gezegd hebben we over de 100 acties, dus in de applicationContext wordt dus heel veel herhaald. Wat in feite niet nodig is omdat het meestal dezelfde bean is die wordt geinjecteerd voor eenzelfde DispatchAction.

Wat ik nu in gedachten had is het volgende, graag wat opmerkingen:

code:

        <action path="/person/initEdit" 
                name="personForm" 
                parameter="initEdit"
                type="be.xxx.celmeeting.web.proxy.PersonDelegatingProxy">
            <forward name="success" path=".selectEditPerson"></forward>
            <forward name="failed" path=".addPerson"></forward>
        </action>
        
        <action path="/person/save" 
                name="personForm" 
                parameter="save"
                validate="true"
                type="be.xxx.celmeeting.web.proxy.PersonDelegatingProxy"
                input=".addPerson">
            <forward name="success" path=".addPerson"></forward>
        </action>

hier maak ik gebruik van een DelegatingActionProxy, en deze doet het volgende:

code:

public class PersonDelegatingProxy extends DelegatingActionProxy {

    protected String determineActionBeanName(ActionMapping mapping) {
    
        String prefix = mapping.getModuleConfig().getPrefix();
        String path = mapping.getPath();
        String beanName = prefix;
        StringTokenizer stok = new StringTokenizer(path,"/");

        return "/" + (String) stok.nextElement();
    }
}

niet echt nette code maar het doet het volgende: ik haal voor elke actie bv: /person/initEdit en /person/save het laatste deel ervan en geef dan voor beide acties hetzelfde " /person " terug.

In de applicationContext.xml heb ik dan maar 1 bean te definiëren:

code:

    <bean name="/person" 
                class="be.xxx.celmeeting.web.action.PersonAction">
        <property name="personBO">
                <ref bean="personBO"/>
            </property>
            
        </bean>

en zo vermijd ik een heel stuk herhaalde code. Wat vinden jullie van deze manier van werken? Volledig tegen de bedoeling van de DelegatingActionProxy ? of net daar waar het voor gemaakt is?

[Alarmnummer]

Cuball schreef op dinsdag 10 mei 2005 @ 08:38:
In dit voorbeeld is nu slechts 1 bean nodig, maar zoals je kan verwachten is dit bij ander acties niet het geval. Wat ik nu heel vervelend vond is dat je dit voor ELKE mogelijke actie moet schrijven, en zoals eerder gezegd hebben we over de 100 acties, dus in de applicationContext wordt dus heel veel herhaald. Wat in feite niet nodig is omdat het meestal dezelfde bean is die wordt geinjecteerd voor eenzelfde DispatchAction.

Check de Abstract beans om herhalende beanconfiguratie te voorkomen.

[edit]
Oplossing 2: Autowiring. Ik heb het zelf nog nooit gebruikt omdat ik het een onduidelijkheid veroorzakende feature vind. Ze raden het zelf ook af

[ Voor 22% gewijzigd door Alarmnummer op 10-05-2005 09:38 ]

[Cuball]

akkoord, dit zorgt voor een stuk minder herhalende code.
Maar ik blijf toch met het probleem dat er voor elke actie een 1 op 1 mapping bestaat met de nodige beans die geinjecteerd moeten worden.

[Alarmnummer]

Cuball schreef op dinsdag 10 mei 2005 @ 09:38:
akkoord, dit zorgt voor een stuk minder herhalende code.
Maar ik blijf toch met het probleem dat er voor elke actie een 1 op 1 mapping bestaat met de nodige beans die geinjecteerd moeten worden.

Ok.. maar door te werken met een abstract bean hoef je het niet overal meer op te geven. Je geeft het op bij de abstract bean en bij het extenden ervan erf je daar alle settings van over. Dus wat is het probleem? De configuratie is nu minder herhalend.

[Cuball]

Stel ik heb volgende klasse

code:

PersonAction extends DispatchAction {

    private PersonBO personBO = null;
    
    public ActionForward init(ActionMapping mapping,
        ActionForm form,
        HttpServletRequest request,
        HttpServletResponse response)
        throws Exception {

                               // doiets (eventueel met personBO : personBO.getEmptyPersonOfWhatever()) 
                                       
                              return forward
               }
               public ActionForward save(ActionMapping mapping,
        ActionForm form,
        HttpServletRequest request,
        HttpServletResponse response)
        throws Exception {

                               // doiets (eventueel met personBO: personBO.savePerson(person))               
                              return forward
               }
}

hier zijn slechts 2 acties opgegeven maar meestal zijn er een stuk of 10 en heb ik ook een 10-tal DispatchAction klasses.
Bovenstaande acties zijn nu gemapt op /person/init en /person/save. Volgens spring dus 2 verschillende beans dus 2 definities. Maar zoals je kan zien gaat het hier maar om 1 klasse. Daarom maak ik gebruik van de die DelegatingActionProxy om bovenstaande om te vormen naar 1. En zo hoef ik in Spring slechts 1 bean te definieren /person die personBO injecteerd in men DispatchAction.