struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Gainty" <>
Subject Re: [struts2] ConfigurationBuilder
Date Thu, 02 Nov 2006 18:32:49 GMT
the real test is to see if you can import the configBuilder classes/interfaces with respect
to their functional grouping
Given any web application can you import your configBuilder generayed entity beans to a say
JDeveloper created package such as model.packagename ?

This e-mail communication and any attachments may contain confidential and privileged information
for the use of the 
designated recipients named above. If you are not the intended recipient, you are hereby notified
that you have received
this communication in error and that any review, disclosure, dissemination, distribution or
copying of it or its 
----- Original Message ----- 
From: "Mike Baroukh" <>
To: "Struts Users Mailing List" <>
Sent: Thursday, November 02, 2006 11:47 AM
Subject: [struts2] ConfigurationBuilder

> Hi.
> I don't know if this post is on the right place.
> I wanted to speak about a method I use to build my struts2 (but I was 
> doing the same with struts1 ...) configuration file.
> This to :
> - share my experience
> - eventually have any comment that tell me why I'm totally wrong.
> - eventually, have any return from struts2 developpers who think this 
> way to do could be incorporated in struts2 ...
> I build web application in a developper team.
> Once, I said to me that struts1/2 configuration file is not enough 
> modular and boring to do (especially with tiles !).
> I also thought that there was not enough check or constraints :
> - no check for class or view existence.
> - no way to say that this 'pool' of actions MUST herite from this class 
> or implements that interface
> So I made my struts configbuilder.
> Here is an example of what it does :
> <struts>
>    <package name="packagename" >
>        <action name="affichePrestation" class="MyActionAction">
>            <result name="success">view.jsp</result>
>        </action>
>    </package>
> </struts>
> wich reside in package "mymodule" is automatically included in the 
> package "packagename" loaded before (so benefit of interceptors, 
> extends, ...) and action is converted to
>  <action name="affichePrestation" class="mymodule.MyActionAction">
>       <result name="success">/WEB-INF/classes/mymodule/view.jsp</result>
>  </action>
> As you can see :
> - packages with the same name are "aggregated"
> - class names are automatically expanded
> - view names are automatically expanded too.
> Also, I if use tiles, jsp name is automatically replaced with a 
> generated tiles name that is automatically created and incorporated in 
> the main tiles config file.
> For views, you can see that I used to put jsps in the same package of 
> actions. this way
> - it's much, much  simplier.
> - jsps are accessible via /WEB-INF/classes/<packagename>/
> - action + config + jsp = a sort of component : I can, for example, 
> refactor and change package name. My component will continue to work 
> correctly without having to change anything.
> I suppose that there must be a lot of people who will think that this 
> way to do is "bad", but what I can say is that applications are much 
> more easy to write and much more easy to maintain. I do that from about 
> 2 years now and I had no problem on any application server I use (resin, 
> tomcat, weblogic, websphere, jboss ...).
> In fact, it's  simple, but helps a lot when writing web applications.
> Mike


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
View raw message