struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dionisius Purba" <Dionisius.Pu...@mitrais.com>
Subject RE: big validation.xml
Date Fri, 02 Jul 2004 04:00:46 GMT
Thanks a lot for sharing that, James.
I'll try it.

Another thing, I was curious, why there's no such
"positiveInteger" and "positiveDouble" in Standard Built In Validations,
because I think it's pretty much needed.

So how do you people usually implement that positiveInteger/positiveDOuble?
In previous project, I ended up with coding my custom validator class.
Are there any better ways?
Thanks in advance for any suggestions/ideas.

~dion

-----Original Message-----
From: James Mitchell [mailto:jmitchell@apache.org]
Sent: Thursday, July 01, 2004 5:37 PM
To: Struts Users Mailing List
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." <foux.dev@foux.net>
To: "Struts Users Mailing List" <user@struts.apache.org>
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))
>
>
> Christopher.Marsh-Bourdon@ftid.com 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" <Dionisius.Purba@mitrais.com>
> >01/07/2004 08:07
> >Please respond to "Struts Users Mailing List"
> >
> >
> >        To:     "Struts Users Mailing List" <user@struts.apache.org>
> >        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: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
> >
> >
> >-----------------------------------------
> >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: 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


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message