You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Richard Tomlinson <Ri...@t-mobile.co.uk> on 2003/10/01 12:17:56 UTC
Raising feature requests and fix suggestions - What's the accepted way.
Hi,
I've got a number of issues that I'd like to raise regarding feature requests with suggested fixes. Can someone inform me of the best way to go about this? I'd like to know what the process is to suggesting, raising and fixing features and problems so that they can be destined for the next release.
I'd like to initially tackle the following issues:
o html:errors tag - Add the ability to specify the maximum number of errors to display rather than displaying all available errors.
o html:link - Improve the way it handles multi-module support. My previous message regading module support was unanswered.
o Adding ActionMessages/ActionErrors from a specified resource bundle - I saw a patch for this that unfortunately didnt address the issue correctly (Bug 7892)
o The addition of a ReloadableActionServlet to be used for development purposes. I take note of the comments seen before regarding reloading and sync'ing requests so it would be useful for ONLY development purposes. The gain in productivity is substantial when its possible to reload without restarting the container and a reloadable ActionServlet should be included in the distribution. From a simple implementation it appears that there are clean-up problems needing to be addressed with the tiles factory and request processors being left in invalid states but still present in the ServletContext. I'm also interested in support of real-time changes to modules without re-loading config to facilitate the use of CMS products in a large production environment.
Comments please.
Regards
Richard Tomlinson
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Looking for thoughts on html:errors with indexed properties
Posted by Vic Cekvenich <ce...@basebeans.com>.
I belive I had "reported" in bugzzila multi row validation problme 2
years ago, as well as posts.
Here is the code I have been shiping for a long time with bP (writen by
Jose/Ben):
package com.fX.base;
/*
* MultiRowValidator.java
* by Ben Tomasini - original by Jose Quiteriono ?
* 12/10/2002
*
*/
import java.io.Serializable;
import java.util.Collection;
import java.util.Iterator;
import javax.servlet.http.HttpServletRequest;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.commons.validator.Field;
import org.apache.commons.validator.ValidatorAction;
import org.apache.struts.action.ActionErrors;
/**
* This class contains multi-row validations for a collection
* *** validation.xml
ex: use
<form name="ClosingChecklistForm">
<field property="sortOrder" depends="multiRowRequired,multiRowInteger">
<arg0 key="ClosingChecklistForm.sortOrder.displayname"/>
<var>
<var-name>rowName</var-name>
<var-value>row</var-value>
</var>
</field>
<field property="daysBeforeBenchmark" depends="multiRowInteger">
<arg0 key="ClosingChecklistForm.daysBeforeBenchmark.displayname"/>
<var>
<var-name>rowName</var-name>
<var-value>row</var-value>
</var>
</field>
<field property="description" depends="multiRowRequired">
<arg0 key="ClosingChecklistForm.description.displayname"/>
<var>
<var-name>rowName</var-name>
<var-value>row</var-value>
</var>
</field>
</form>
*
*/
public class MultiRowValidator extends
org.apache.struts.validator.FieldChecks
implements Serializable {
//TODO: rename row to index
/**
* Commons Logging instance.
*/
private static Log LOG = LogFactory.getLog(MultiRowValidator.class);
/**
* <p>Checks if the field isn't null and length of the field is
greater than zero not
* including whitespace.</p>
*
* @param bean The bean - must implement Collection
* @param va The <code>ValidatorAction</code> that is
currently being performed.
* @param field The <code>Field</code> object associated
with the current field
* being validated.
* @param errors The <code>ActionErrors</code> object to add
errors to if any
* validation errors occur.
* @param request Current request object.
*/
public static boolean validateMultiRowRequired(Object bean,
ValidatorAction va,
Field field,
ActionErrors errors,
HttpServletRequest
request) {
boolean valid = true;
// Need to iterate over a collection
Collection coll = (Collection) bean;
for (Iterator i = coll.iterator(); i.hasNext();) {
Object entry = (Object) i.next();
if (!validateRequired(entry, va, field, errors, request))
valid = false;
}
return valid;
}
/**
* <p>Checks if the field matches the regular expression in the
field's mask attribute.</p>
*
* @param bean The bean - must implement collection
* @param va The <code>ValidatorAction</code> that is
currently being performed.
* @param field The <code>Field</code> object associated
with the current field
* being validated.
* @param errors The <code>ActionErrors</code> object to add
errors to if any
* validation errors occur.
* @param request Current request object.
*/
public static boolean validateMultiRowMask(Object bean,
ValidatorAction va,
Field field,
ActionErrors errors,
HttpServletRequest
request) {
boolean valid = true;
// Need to iterate over a collection
Collection coll = (Collection) bean;
for (Iterator i = coll.iterator(); i.hasNext();) {
Object entry = (Object) i.next();
if (!validateMask(entry, va, field, errors, request))
valid = false;
}
return valid;
}
/**
* <p>Checks if the field can safely be converted to an int
primitive.</p>
*
* @param bean The bean - must implement collection
* @param va The <code>ValidatorAction</code> that is
currently being performed.
* @param field The <code>Field</code> object associated
with the current field
* being validated.
* @param errors The <code>ActionErrors</code> object to add
errors to if any
* validation errors occur.
* @param request Current request object.
*/
public static boolean validateMultiRowInteger(Object bean,
ValidatorAction va,
Field field,
ActionErrors errors,
HttpServletRequest
request) {
boolean valid = true;
// Need to iterate over a collection
Collection coll = (Collection) bean;
for (Iterator i = coll.iterator(); i.hasNext();) {
Object entry = (Object) i.next();
if (validateInteger(entry, va, field, errors, request) != null)
valid = false;
}
return valid;
}
/**
* <p>Checks if the field can safely be converted to a float
primitive.</p>
*
* @param bean The bean - must implement collection
* @param va The <code>ValidatorAction</code> that is
currently being performed.
* @param field The <code>Field</code> object associated
with the current field
* being validated.
* @param errors The <code>ActionErrors</code> object to add
errors to if any
* validation errors occur.
* @param request Current request object.
*/
public static boolean validateMultiRowFloat(Object bean,
ValidatorAction va,
Field field,
ActionErrors errors,
HttpServletRequest
request) {
boolean valid = true;
// Need to iterate over a collection
Collection coll = (Collection) bean;
for (Iterator i = coll.iterator(); i.hasNext();) {
Object entry = (Object) i.next();
if (validateFloat(entry, va, field, errors, request) != null)
valid = false;
}
return valid;
}
/**
* <p>Checks if a fields value is within a range (min & max
specified
* in the vars attribute).</p>
*
* @param bean The bean - must implement collection
* @param va The <code>ValidatorAction</code> that is
currently being performed.
* @param field The <code>Field</code> object associated
with the current field
* being validated.
* @param errors The <code>ActionErrors</code> object to add
errors to if any
* validation errors occur.
* @param request Current request object.
*/
public static boolean validateMultiRowRange(Object bean,
ValidatorAction va,
Field field,
ActionErrors errors,
HttpServletRequest
request) {
boolean valid = true;
// Need to iterate over a collection
Collection coll = (Collection) bean;
for (Iterator i = coll.iterator(); i.hasNext();) {
Object entry = (Object) i.next();
if (!validateIntRange(entry, va, field, errors, request))
valid = false;
}
return valid;
}
/**
* <p>Return <code>true</code> if the specified object is a String or
* a <code>null</code> value.</p>
*
* @param o Object to be tested
*/
protected static boolean isString(Object o) {
if (o == null) {
return (true);
}
return (String.class.isInstance(o));
}
}
Also needded is attached valdation XMl that should be used in addition
to other valdiation xmls. Let me know if you nned more suggestions, etc.
for how we have gotten arround it.
hth,
.V
James Turner wrote:
> Hi gang,
> Currently, the html:errors tag doesn't work well with
> indexed properties, because it looks for an exact match on
> the property name. So if you have an error in
> petFish[3].species, you need to have:
> <html:errors property="petFish[3].species">
>
> I'd like to propose (and will implement if people think it's
> a good idea) two new things.
>
> First off, doing <html:errors name="petFish"
> property="species" indexed="true"> should match errors for
> the current iteration values.
>
> Secondly, doing <html:errors name="petFish"
> property="species"> should match all errors for any
> iteration.
>
> James
Looking for thoughts on html:errors with indexed properties
Posted by James Turner <tu...@blackbear.com>.
Hi gang,
Currently, the html:errors tag doesn't work well with
indexed properties, because it looks for an exact match on
the property name. So if you have an error in
petFish[3].species, you need to have:
<html:errors property="petFish[3].species">
I'd like to propose (and will implement if people think it's
a good idea) two new things.
First off, doing <html:errors name="petFish"
property="species" indexed="true"> should match errors for
the current iteration values.
Secondly, doing <html:errors name="petFish"
property="species"> should match all errors for any
iteration.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Raising feature requests and fix suggestions - What's the accepted
way.
Posted by Ted Husted <hu...@apache.org>.
To discuss whether a feature might be a good idea, you can post here.
Though, it can take several days before everyone weighs in. We're all
volunteers with real jobs. Many of us can only work on Struts on the
weekends.
To raise and fix issues, you can post tickets to Bugzilla. This is where
patches should go, so they don't get lost. If you have an alternate
patch, you can append that to the same ticket.
If you strongly believe in an issue, you might have to lobby for it.
This is often the case in open source. On another project, I had to make
several followups over a two-week period before getting a three line
patch committed. It's just the way things work on volunteer projects.
Bugzilla, the DEV list, and CVS are the only media that the committers
use to develop Struts. Both Bugzilla and CVS are programmed to post
changes to the DEV list, so everything that happens is reflected here.
See also
http://jakarta.apache.org/struts/using.html
http://jakarta.apache.org/site/getinvolved.html
http://jakarta.apache.org/struts/faqs/helping.html
-Ted.
Richard Tomlinson wrote:
> Hi,
>
> I've got a number of issues that I'd like to raise regarding feature requests with suggested fixes. Can someone inform me of the best way to go about this? I'd like to know what the process is to suggesting, raising and fixing features and problems so that they can be destined for the next release.
>
> I'd like to initially tackle the following issues:
>
> o html:errors tag - Add the ability to specify the maximum number of errors to display rather than displaying all available errors.
>
> o html:link - Improve the way it handles multi-module support. My previous message regading module support was unanswered.
>
> o Adding ActionMessages/ActionErrors from a specified resource bundle - I saw a patch for this that unfortunately didnt address the issue correctly (Bug 7892)
>
> o The addition of a ReloadableActionServlet to be used for development purposes. I take note of the comments seen before regarding reloading and sync'ing requests so it would be useful for ONLY development purposes. The gain in productivity is substantial when its possible to reload without restarting the container and a reloadable ActionServlet should be included in the distribution. From a simple implementation it appears that there are clean-up problems needing to be addressed with the tiles factory and request processors being left in invalid states but still present in the ServletContext. I'm also interested in support of real-time changes to modules without re-loading config to facilitate the use of CMS products in a large production environment.
>
> Comments please.
>
> Regards
> Richard Tomlinson
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Raising feature requests and fix suggestions - What's the accepted
way.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Richard Tomlinson wrote:
>Hi,
>
>I've got a number of issues that I'd like to raise regarding feature requests with suggested fixes. Can someone inform me of the best way to go about this? I'd like to know what the process is to suggesting, raising and fixing features and problems so that they can be destined for the next release.
>
>I'd like to initially tackle the following issues:
>
>o html:errors tag - Add the ability to specify the maximum number of errors to display rather than displaying all available errors.
>
>o html:link - Improve the way it handles multi-module support. My previous message regading module support was unanswered.
>
>o Adding ActionMessages/ActionErrors from a specified resource bundle - I saw a patch for this that unfortunately didnt address the issue correctly (Bug 7892)
>
>o The addition of a ReloadableActionServlet to be used for development purposes. I take note of the comments seen before regarding reloading and sync'ing requests so it would be useful for ONLY development purposes. The gain in productivity is substantial when its possible to reload without restarting the container and a reloadable ActionServlet should be included in the distribution. From a simple implementation it appears that there are clean-up problems needing to be addressed with the tiles factory and request processors being left in invalid states but still present in the ServletContext. I'm also interested in support of real-time changes to modules without re-loading config to facilitate the use of CMS products in a large production environment.
>
>
As others have mentioned, Bugzilla is the best way to raise enhancement
requests (and post corresponding patches), while the STRUTS-DEV list is
the best place to discuss ideas.
With regard to reload, you're going to find yourself disappointed when
you can change config files but not classes; so it seems like a lot of
effort for little gain (but it's not my effort, so not as big a deal
:-). I have found that using the right container makes all the
difference in the world; my typical turnaround time for an "ant reload"
command issued against Tomcat is a couple of seconds -- and that means
reloading the entire app, so it *does* pick up new and updated Java classes.
>Comments please.
>
>Regards
>Richard Tomlinson
>
>
Craig
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org