James
Thank you for that, just what we needed.
Thanks
Christopher Marsh-Bourdon
"James Mitchell" <[EMAIL PROTECTED]>
01/07/2004 10:37
Please respond to "Struts Users Mailing List"
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject: Re: big validation.xml
I would not recommend using Modules unless you have a specific need for
them. And from what you both describe, you don't need Modules.
You are better off splitting up the validation.xml and struts-config.xml
into smaller, more managable peices. By activity or use case.
(from web.xml)
...
...
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>
/WEB-INF/classes/elms/resource/struts-config.xml,
/WEB-INF/classes/elms/resource/struts-config-common.xml,
/WEB-INF/classes/elms/resource/struts-config-manageproducts.xml,
/WEB-INF/classes/elms/resource/struts-config-payment.xml,
/WEB-INF/classes/elms/resource/struts-config-makeloan.xml,
/WEB-INF/classes/elms/resource/struts-config-disbursement.xml,
/WEB-INF/classes/elms/resource/struts-config-workcollections.xml,
/WEB-INF/classes/elms/resource/struts-config-branchTab.xml,
/WEB-INF/classes/elms/resource/struts-config-corporateTab.xml
</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
...
...
(from struts-config.xml)
...
...
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property
property="pathnames"
value="
/WEB-INF/classes/elms/resource/validator-rules.xml,
/WEB-INF/classes/elms/resource/validation.xml,
/WEB-INF/classes/elms/resource/validation-makeloan.xml,
/WEB-INF/classes/elms/resource/validation-takepayment.xml,
/WEB-INF/classes/elms/resource/validation-workcollections.xml,
/WEB-INF/classes/elms/resource/validation-corporateTab.xml"
/>
</plug-in>
...
...
Using this simple technique we have virtually eliminated contention of
files.
Be careful with this though, if you define duplicate action-mapping (by
path) or form-beans (by name), the last one loaded silently wins.
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Foux Dev." <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, July 01, 2004 4:22 AM
Subject: Re: big validation.xml
> Hi,
>
> I would suggest you take a close look to Struts Modules. Isolating
> specific parts of your application into modules has the following
> advantages:
>
> - reduces size of validation.xml and struts-config.xml files, as each
> module as its own set of files; althrough validation and resources can
> be shared between modules.
>
> - better separation of team work: each team handles its own set of XML,
> resources, HTML/JSP/.. files, and therefore reduces dramatically
> CVS/SVN/.. conflicts! Working in a team on a huge monolithic
> configuration file is a nightmare!
>
> - better overview of your global application and a lot more
maintainable.
>
> Of course, splitting your application into modules will also need some
> "standard rules" between them, but that's not of Struts' responsability,
> rather a development management issue. And there are not specific rules
> for splitting applications into modules: it's more based on logic and
> common sense than anything else.
>
> Cheers,
> Fulco
>
>
> some useful links:
> - http://jakarta.apache.org/struts/userGuide/configuration.html
> - he "Struts Survival Guide" on www.objectsource.com has a lot of tips
> and tricks that will save you hours of surfing forums/mailinglist
> looking for answers (nooo, I've nothing to do with that book ;o))
>
>
> [EMAIL PROTECTED] wrote:
>
> >I'm in the same boat, up until now we've developed small Struts
> >applications (about 20 different sets of input/view forms). Now we are
> >going to migrate an application which we wrote in our own framework to
> >Struts. This contains about 300 separate input/view forms (a lot will
be
> >reduced down due to re-usability of Struts over our own framework). As
> >Dion asks, what is the best practice for projects of this size?
> >
> >Cheers
> >
> >Christopher Marsh-Bourdon
> >
> >
> >
> >
> >
> >"Dionisius Purba" <[EMAIL PROTECTED]>
> >01/07/2004 08:07
> >Please respond to "Struts Users Mailing List"
> >
> >
> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > cc:
> > Subject: big validation.xml
> >
> >
> >Hi all,
> >
> >Struts-validator, or I guess it has become common-validator (?) is very
> >cool,
> >a lot of thanks for making life easier.
> >Because there are lots of entities in application that I'm developing,
> >more than 80,
> >the validation.xml file will be so big, roughly more than two thousands
> >line.
> >
> >For such a big validation.xml, will there be effect in performance
> >in the JSP that utilize the validation.xml?
> >Are there any tips/best practices for such situation?
> >
> >Thanks a lot in advance for any comments/suggestions.
> >
> >
> >~dion
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> >
> >
> >-----------------------------------------
> >The information in this e-mail is confidential. It is intended solely
for
the addressee. If you are not the intended recipient please notify the
sender immediately and delete this message. Any review, dissemination,
distribution, copying or other use of this communication or the
information
in it is strictly prohibited.
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-----------------------------------------
The information in this e-mail is confidential. It is intended solely for the
addressee. If you are not the intended recipient please notify the sender immediately
and delete this message. Any review, dissemination, distribution, copying or other use
of this communication or the information in it is strictly prohibited.
