You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Mike Baroukh <mb...@cardiweb.com> on 2006/11/02 17:47:50 UTC
[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
Re: [struts2] ConfigurationBuilder
Posted by Martin Gainty <mg...@hotmail.com>.
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 a
JDeveloper created package such as model.packagename ?
M-
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
contents
----- Original Message -----
From: "Mike Baroukh" <mb...@cardiweb.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
Re: [struts2] ConfigurationBuilder
Posted by Don Brown <do...@gmail.com>.
I'd love to see something like this for Struts 2. Take a look at the
XmlConfigurationProvider and see how you could improve it to add this
functionality. Please let us know how it goes.
Don
On 11/2/06, Mike Baroukh <mb...@cardiweb.com> wrote:
>
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org