Re: Proposed enhancement to bean:message
Yes, that is exactly what I intended. -- Martin Cooper - Original Message - From: Oleg V Alexeev [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 18, 2001 11:11 PM Subject: Re: Proposed enhancement to bean:message Hello Martin, +1 I think it must work at standard struts way - bean:message name=myBean/ bean:message name=myBean property=myKeyProperty/ and existing one - bean:message key=myForm/ Tuesday, June 19, 2001, 9:49:56 AM, you wrote: MC I posted this a few weeks ago as a patch, when it should more properly have MC been a proposal. Here, then, is the proposal: MC A problem with the current bean:message tag is that the only way to MC specify the message resource key dynamically is by using a JSP expression. MC This leads to the use of the following pattern: MC bean:define id=myKey name=myForm property=myKeyProperty MC type=java.lang.String/ MC bean:message key=%= myKey %/ MC An alternative is to have the Action look up the key and set the resulting MC string value in the property for use on the JSP page via bean:write. This MC doesn't feel right, because the responsibility for looking up the MC appropriately localized text is then divided between the Action and the JSP MC page. MC By enhancing the bean:message tag to allow it to obtain the message MC resource key from a bean property, we can simplify the above example to: MC bean:message name=myForm property=myKeyProperty/ MC Here, the 'name' and 'property' attributes are used to obtain the message MC resource key from a bean. That key is then used as if it had been specified MC using the 'key' attribute. MC I believe this proposal would enhance the i18n functionality of Struts by MC allowing dynamic specification of messages, while delegating the resolution MC of the actual message text to the view. MC Comments? MC -- MC Martin Cooper -- Best regards, Olegmailto:[EMAIL PROTECTED]
Re: Proposed enhancement to bean:message
Hi Martin, +1 I think it is a really good idea and I was about to ask for a feature like this. keep going ;-) simon Martin Cooper schrieb: I posted this a few weeks ago as a patch, when it should more properly have been a proposal. Here, then, is the proposal: A problem with the current bean:message tag is that the only way to specify the message resource key dynamically is by using a JSP expression. This leads to the use of the following pattern: bean:define id=myKey name=myForm property=myKeyProperty type=java.lang.String/ bean:message key=%= myKey %/ An alternative is to have the Action look up the key and set the resulting string value in the property for use on the JSP page via bean:write. This doesn't feel right, because the responsibility for looking up the appropriately localized text is then divided between the Action and the JSP page. By enhancing the bean:message tag to allow it to obtain the message resource key from a bean property, we can simplify the above example to: bean:message name=myForm property=myKeyProperty/ Here, the 'name' and 'property' attributes are used to obtain the message resource key from a bean. That key is then used as if it had been specified using the 'key' attribute. I believe this proposal would enhance the i18n functionality of Struts by allowing dynamic specification of messages, while delegating the resolution of the actual message text to the view. Comments? -- Martin Cooper
Re: Client/Server Side Validation for Struts 1.1
This is what I'm saying. Lets not use your social security number as an
example because it is only for the USA. Lets use money. In the USA we use
1,000.55 for one-thousand-fifty-five dolars. In Brasil they use 1.000,55.
We would allow a user who lives in Brasil who also chose to view content in
Portuguese to enter the number the way THEY understand. WE, on the other
hand will have built a filter to change what they entered into the format
which we work with (1,000.55 ) to validate it. This means ONE validation
created for money, but a filter had to be created for users located in
Brasil. The filter just changed their format to the format we need to
process. When we decide to give this capability to another location/language
we jjust create a filter and use the same validator. Of course the filter
would have to work going TO the application from the presentation and from
the application back to the presentation.
If not, you have to do validations for a zillion different permutations of
possibilities
What do you think?
- Original Message -
From: David Winterfeldt [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Jonathan Asbell [EMAIL PROTECTED]
Sent: Monday, June 18, 2001 11:01 PM
Subject: Re: Client/Server Side Validation for Struts 1.1
What do you mean by converted into the format of the
system? Do you mean the object and not the String
representation in the ActionForm? Or are you refering
to the part where I talk about associating a locale to
a phone number?
Expand on what you were saying if this doesn't cover
it, but the initial validations would be to get
required fields filled in and in the correct format to
be converted to objects. For example, there would be
no reason to check that a social security number is in
your system until it is a well formed social security
number. Then you can convert your ActionForm to a
JavaBean with correct java types (java.util.Date,
etc.) and with the typed JavaBean you can then pass
that to a validation bean, an EJB, or any other server
side resource. And if you have a multi-tier
distributed system you would ideally want to get the
information filled in properly before you send it to
an EJB.
Or if you mean that there are a lot of permutations
for phone numbers or dates, there are. If we model
things to take a pattern (MM/dd/ or (###)
###-), then one type of class can perform the
validation/conversion based on the pattern. A date
can get converted to a date for checking if it falls
in a range, is within the last seven days, etc., but a
phone number is phone number and can't really be
converted into a standard format like a date.
David
--- Jonathan Asbell [EMAIL PROTECTED] wrote:
Hi Dave. I really think (and tell me what you
think) that all special
formatting shoudl eventually be converted into the
format of the system it
is running on, THEN validated. Otherwise you have
to design a gazillion
permutations to validate. We could instead make
various converters for each
situation as needed, and one central validation
package.
- Original Message -
From: David Winterfeldt [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 18, 2001 2:26 PM
Subject: RE: Client/Server Side Validation for
Struts 1.1
I've still been continuing work on the Struts
Validator
(http://home.earthlink.net/~dwinterfeldt/)
in it's present form, but I've been thinking about
the
discussion under this thread and the best way to
integrate these ideas with what I've done so far.
It
seems like it is best to keep everything as
separate
components and just make sure they work together.
The
Mapper is separate. There should be a general
validation/transformation package that you can
pass in
a String and it can create on object for you and
throw
an Exception if it can't (based on
java.text.Format as
you suggested). This package could then be used
for
the Mapper, validation, and formatting. So you
should
be able to define that a date should be
MM/dd/
and this would be used for formatting of the date
object as it is converted to a String in the
ActionForm and also would be used for validation
and
after validation for the transformation back to a
date
object. But as it was discussed, the way the
standard
message resources work (from a region down to a
language) doesn't make sense for a phone number
that
should be associated with region and has nothing
to do
with the language. I was thinking that if
resources
like phone numbers were loaded based on a location
and
you could reference them from the validation.xml
that
might work.
fieldproperty=phone
depends=mask
var name=mask value=${trans:US_phone}/
arg0
key=registrationForm.phone.displayname/
/field
The 'trans' prefix would represent that the value
should be retreived from the
RE: Client/Server Side Validation for Struts 1.1
Hi Jonathan, Interesting question, and one we're still wrestling with in Barracuda too. I see one possible problem with filtering then validating. Using your example below, what happens if the Brasilian values looks like this: 1.00@0,55 The problem now becomes how do we filter something that is invalid? Do we silently suppress the invalid @ character because we don't know what it is? Or do we just leave it alone? Or what about something like this: 1.00,05,5 Which comma is the real one? The essence of filtering is that you are changing things that the user entered to get them into a format that the software can understand (ie Floats). In many cases, we can safely guess user intent, but in others it becomes much more difficult. For instance, lets say I'm accepting a whole dollar bid on an item (ie. no decimal points). What if the user enters 10.00? If my filter tries to guess intent and silently skips the decimal since its not a valid character for this value, it could conceivably convert my ten dollar bid into a thousand dollar bid (by dropping the decimal). Since the result of the filtering is a valid number, processing continues and the bid is placed (and in many cases the user might not even realize what just happened). Granted this is a contrived example, but I think it illustrates one of the pitfalls of filtering. To be safe, any time you filter/adjust a value, you really want to give the user a chance to verify that the adjustment you made is correct. Often, however, that type of hey is this what you meant? isn't real conducive to the app workflow. Just some food for thought... Christian Christian Cryder [[EMAIL PROTECTED]] Barracuda - MVC Component Framework for Webapps http://barracuda.enhydra.org What a great time to be a Geek -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 6:20 AM To: [EMAIL PROTECTED] Subject: Re: Client/Server Side Validation for Struts 1.1 This is what I'm saying. Lets not use your social security number as an example because it is only for the USA. Lets use money. In the USA we use 1,000.55 for one-thousand-fifty-five dolars. In Brasil they use 1.000,55. We would allow a user who lives in Brasil who also chose to view content in Portuguese to enter the number the way THEY understand. WE, on the other hand will have built a filter to change what they entered into the format which we work with (1,000.55 ) to validate it. This means ONE validation created for money, but a filter had to be created for users located in Brasil. The filter just changed their format to the format we need to process. When we decide to give this capability to another location/language we jjust create a filter and use the same validator. Of course the filter would have to work going TO the application from the presentation and from the application back to the presentation. If not, you have to do validations for a zillion different permutations of possibilities What do you think? - Original Message - From: David Winterfeldt [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Jonathan Asbell [EMAIL PROTECTED] Sent: Monday, June 18, 2001 11:01 PM Subject: Re: Client/Server Side Validation for Struts 1.1 What do you mean by converted into the format of the system? Do you mean the object and not the String representation in the ActionForm? Or are you refering to the part where I talk about associating a locale to a phone number? Expand on what you were saying if this doesn't cover it, but the initial validations would be to get required fields filled in and in the correct format to be converted to objects. For example, there would be no reason to check that a social security number is in your system until it is a well formed social security number. Then you can convert your ActionForm to a JavaBean with correct java types (java.util.Date, etc.) and with the typed JavaBean you can then pass that to a validation bean, an EJB, or any other server side resource. And if you have a multi-tier distributed system you would ideally want to get the information filled in properly before you send it to an EJB. Or if you mean that there are a lot of permutations for phone numbers or dates, there are. If we model things to take a pattern (MM/dd/ or (###) ###-), then one type of class can perform the validation/conversion based on the pattern. A date can get converted to a date for checking if it falls in a range, is within the last seven days, etc., but a phone number is phone number and can't really be converted into a standard format like a date. David --- Jonathan Asbell [EMAIL PROTECTED] wrote: Hi Dave. I really think (and tell me what you think) that all special formatting shoudl eventually be
Workflow: Struts inside of Struts
For the sake of our discussion on Struts Workflow,belowis mostof an internal company proposal from me to a co-worker concerning a simple Workflow demo. This proposal is drawn, in part, from recent ideas posted to this list. What may be different in what I am suggesting is that Workflow really means the "composition" of existing applications. That is, an application that wraps up some number of existing apps. The "View" might be a Todo listin one window in a frameset spawning links to display inthe "main" window of the frameset.. Struts inside of Struts. Dan Connelly Keeping [our] Workflow extremely simple at this point, it seemsto me that our next step is to show that we can interpose a"pre-condition" between two separate, pre-exisiting applications. Also,that we can wrap the two applications in pre- and post- actions. We have two interesting applications from Apache running on our Tomcatserver: "Mail Accounts" (aka "example") and "File Upload" (aka"upload). The default setup for these two applications is to run themin two separate Web Contexts within the server. Currently, there is nointeraction between these two applications. They are just separatedemonstrations of "Struts," the MVC framework (Release 1.0) from Apache. I propose that we will now develop a Workflow Context (WFContext) torequire that a user wanting to run "File Upload" must first "login"through the "Mail Accounts" applications and that there must be listeda "notification account" among that user's email accounts. This is theWorkflow pre-condition to be demonstrated. Once this pre-condition is satisfied, then the user may proceed to use"File Upload" to transfer data. For each file transferred, an emailnotification of the upload completion status will be sent to thedesignated account. This is the Workflow post-action to bedemonstrated. (There will also be pre-actions, but they will behidden.) The aim here is to subsume two existing applications into a new "Uploadwith Mail Workflow" application which will control these apps out of itsown Web Context. (The Web Context is a server concept, while the WFContext is part of theWorkflow logic framework, unknown to Web server. In a previous email Idescribed a WFContext as an application specific data structure --principally a hashtable -- that gradually instantiates unknown data in acontrolled manner.) Our goal is to utilize the logic of the existing applications withoutmodification to their Java code or to any existing database. It willbe permitted, however, to modify the code of the Struts framework and tomodify the "struts-config.xml" for both of the affected application.Despite these changes and despite the new Workflow logic (application),the two applications should continue to run with unchangedfunctionality. It is assumed that Tomcat's security settings would prevent the directuse of the two applications once the Workflow became a requirement.Privileged "LDAP" accounts would continue to have direct access to thetwo separate applications.
Anyone evaluate TCF yet?
Anyone take a look at Thin Client Framework by IBM's alphaworks? Supposed to help produce MVC apps in java rapidly. http://alphaworks.ibm.com/tech/tcf tataryn:craig/
server-side, java-based validation rules for struts..
I believe its well established that Struts would benefit from a good
validation framework (duh, right?). While there are a number of
really good ideas floating around, some seem to be introducing
unnecessary complexity (IMHO, of course)
Getting to the point, I think constrained properties from the
JavaBeans spec. provides a built in, flexible foundation for
struts invoked validation.
(http://java.sun.com/products/javabeans/docs/spec.html)
key advantages:
* support is provided by the standard java.beans package
* it doesn't require learning anything proprietary (even though
other solutions are very cool :)
* its conceptually simple; ie. before accepting a new value,
the bean/ActionForm's setter method(s) ensures its accepted by
all registered listeners before commiting the value
(java.bean.VetoableChangeListenter).
* and finally, its wide open for extension (key since we can't
predict all validation scenario's, right?)
I also believe that integration with Struts could be pretty straight
forward. In a nutshell, we could make 2 modifications ActionServlet:
1. Make it responsible for registering change-listeners
2. Make it handle PropertyVetoException(s) thrown by setter methods
(primarily by turning them into ActionErrors)
Prior to making a formal proposal for this, I thought it might be
useful to consider the attached code fragments:
Then again, maybe I'm way off and should be ignored- If I am,
let me know..
Regards,
Levi Cook
struts-config
!-- etc.. --
form-bean name=myForm type=MyForm
change-listener
property=email
type=RequiredEmailAddressValidator
/
/form-bean
!-- etc.. --
/struts-config
import java.beans.*
public class RequiredEmailAddressValidator implements VetoableChangeListener {
public void vetoableChange(PropertyChangeEvent evt)
throws PropertyVetoException
{
String email= null;
boolean emptyOk= false;
try {
email= (String) evt.getNewValue();
}
finally {
if(StringValidator.checkEmail(email, emptyOk) == false)
throw new PropertyVetoException(some.msg.key, evt);
}
}
}
import org.apache.struts.action.ActionForm;
import java.beans.*;
public class MyForm extends ActionForm {
private static final String EMAIL_PROP_NAME= email;
private String email;
public String getEmailAddress() {
return email;
}
public void setEmail(String newEmail)
throws PropertyVetoException
{
vcs.fireVetoableChange(EMAIL_PROP_NAME, email, newEmail);
email= newEmail;
}
private VetoableChangeSupport vcs=
new VetoableChangeSupport(this);
public void addEmailVetoableChangeListener(VetoableChangeListener lsnr) {
vcs.addVetoableChangeListener(EMAIL_PROP_NAME, lsnr);
}
public void removeEmailVetoableChangeListener(VetoableChangeListener lsnr) {
vcs.removeVetoableChangeListener(EMAIL_PROP_NAME, lsnr);
}
}
import java.beans.*;
public class OptionalEmailAddressValidator implements VetoableChangeListener {
public void vetoableChange(PropertyChangeEvent evt)
throws PropertyVetoException
{
String email= null;
boolean emptyOk= true;
try {
email= (String) evt.getNewValue();
}
finally {
if(StringValidator.checkEmail(email, emptyOk) == false)
throw new PropertyVetoException(some.msg.key, evt);
}
}
}
import org.apache.regexp.*;
public final class StringValidator {
/**
* Check that String email is a valid email address.
* emptyOK=true indicates that an empty String is valid
* for this test.
*/
public static boolean checkEmail(String email, boolean emptyOK) {
if ((emptyOK == true) (KRStringValidator.isEmpty(email)))
return true;
else if (StringValidator.isValidEmail(email))
return true;
else
return false;
}
/**
* Checks to see if a String is a valid email address.
*/
public static boolean isValidEmail(String email) {
if(email == null) return false;
try {
RE reEmail = new RE(^.+\\@.+\\..+$);
if (reEmail.match(email) )
return true;
else
return false;
}
catch(RESyntaxException e) {
System.out.println(e);
return false;
}
}
/**
* Checks to see if a String is null or all spaces.
*/
public static boolean isEmpty(String s) {
return ((s == null) || (s.trim().length() == 0));
}
}
BaseHandlerTag implementation question
I have a question concerning the way the org.apache.struts.taglib.html.BaseHandlerTag class is implemented. In particular, I'm wondering why the methods prepareFocusEvents, prepareTextEvents, etc. are private instead of protected. I ran into this today because I wanted to build a custom text tag. I was hoping to be able to make a simple extension to struts by subclassing TextTag and overriding the prepareTextEvents method to do some custom behavior. Unfortunately, since prepareTextEvents is private, I can't do that. I'm wondering if anyone can offer a good reason for making these methods private? Thanks.
Re: Client/Server Side Validation for Struts 1.1
I don't think you should filter out unexpected characters. Java NumberFormat can let you handle how someone from a locale would enter a number and then convert it to a float or double. USA we use 1,000.55 dollars. #,###.## Brasil they use 1.000,55 #.###,## I think you should make the use put in a good value (of course it is always up to the developer). If some leaned on the keyboard and put in 3.44, I would not want to assume that it is 3.44. And when you get into currency you may have a minimum of $10 US dollars or 20,000 Lira so I'm not sure how it helps to get them into the same format except to save it, do a currency conversion, or validate on rules for each currency. It is a complicated issue. I always thought it was best to save the amount, the currency, and the date so you can calculate currency conversions if you need to, but preserve the original user data for future reference/calculations. David --- Jonathan [EMAIL PROTECTED] wrote: Hello Christian. My answer would be that in 1.00@0,55 we would leave it as is and filter it. If after the filter (when it is in the format WE need) we could not validate it, than its not valid. The power must rely in the filter because WE, ABSOLUTELY, NEED TO VALIDATE IN OUR FORMAT. Therfore the filter must know about @ characters etc. - Original Message - From: Christian Cryder [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Jonathan Asbell [EMAIL PROTECTED] Sent: Tuesday, June 19, 2001 11:12 AM Subject: RE: Client/Server Side Validation for Struts 1.1 Hi Jonathan, Interesting question, and one we're still wrestling with in Barracuda too. I see one possible problem with filtering then validating. Using your example below, what happens if the Brasilian values looks like this: 1.00@0,55 The problem now becomes how do we filter something that is invalid? Do we silently suppress the invalid @ character because we don't know what it is? Or do we just leave it alone? Or what about something like this: 1.00,05,5 Which comma is the real one? The essence of filtering is that you are changing things that the user entered to get them into a format that the software can understand (ie Floats). In many cases, we can safely guess user intent, but in others it becomes much more difficult. For instance, lets say I'm accepting a whole dollar bid on an item (ie. no decimal points). What if the user enters 10.00? If my filter tries to guess intent and silently skips the decimal since its not a valid character for this value, it could conceivably convert my ten dollar bid into a thousand dollar bid (by dropping the decimal). Since the result of the filtering is a valid number, processing continues and the bid is placed (and in many cases the user might not even realize what just happened). Granted this is a contrived example, but I think it illustrates one of the pitfalls of filtering. To be safe, any time you filter/adjust a value, you really want to give the user a chance to verify that the adjustment you made is correct. Often, however, that type of hey is this what you meant? isn't real conducive to the app workflow. Just some food for thought... Christian Christian Cryder [[EMAIL PROTECTED]] Barracuda - MVC Component Framework for Webapps http://barracuda.enhydra.org What a great time to be a Geek -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 6:20 AM To: [EMAIL PROTECTED] Subject: Re: Client/Server Side Validation for Struts 1.1 This is what I'm saying. Lets not use your social security number as an example because it is only for the USA. Lets use money. In the USA we use 1,000.55 for one-thousand-fifty-five dolars. In Brasil they use 1.000,55. We would allow a user who lives in Brasil who also chose to view content in Portuguese to enter the number the way THEY understand. WE, on the other hand will have built a filter to change what they entered into the format which we work with (1,000.55 ) to validate it. This means ONE validation created for money, but a filter had to be created for users located in Brasil. The filter just changed their format to the format we need to process. When we decide to give this capability to another location/language we jjust create a filter and use the same validator. Of course the filter would have to work going TO the application from the presentation and from the application back to the presentation. If not, you have to do validations for a zillion different permutations of possibilities What do you think? - Original Message - From: David Winterfeldt [EMAIL PROTECTED] To: [EMAIL
RE: Struts 1.0 Released - Looking forward to 1.1!!!!!!!
Martin, Ideally I would like Struts html tags (text, checkbox, hidden etc.) to automatically generate the name with the subscript if its embedded in an IterateTag so that iterated beans are automatically updated by Struts. For example: logic:iterate id=list name=formExample property=beanArray trtdhtml:text name=list property=desc//td /logic:iterate generates: input type=text name=beanArray[0].desc value=../ input type=text name=beanArray[1].desc value=../ input type=text name=beanArray[2].desc value=../ etc. etc. I realise you can do this with the indexId scripting variable, but this is simpler. I raised it before (prior to indexId and getIndex method) in the following messages: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05231.html http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg00975.html What do you think? Niall -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: 19 June 2001 05:28 To: [EMAIL PROTECTED] Subject: Re: Struts 1.0 Released - Looking forward to 1.1!!! Niall, Regarding auto-generating a subscript, what do you have in mind? The indexId attribute was added to the iterate tag recently (just before Struts 1.0) so that a scripting variable can be created containing the value of the current index. However, from the description in the TODO list, I'm not sure if that's the same thing or not. Thanks! -- Martin Cooper - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 18, 2001 6:46 PM Subject: Struts 1.0 Released - Looking forward to 1.1!!! Congratulations and thank you for Struts 1.0 - a great product. Now I know you guys deserve a well earned rest now Struts 1.0 is released, but what sort of timescale do you envisage work starting on 1.1? I am particularly interested for starters in: 1) ActionForms with dynamic properties. 2) If/Else and Switch/Case tags (I submitted tags which do this to the dev list a while ago). 3) Improved Iteration Support - auto-generating a subscript. These areas are currently unassigned on the ToDo list and presumably need a committer to take control. If someone is assigned I am more than willing to contribute to these (and other) areas. Niall -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 16 June 2001 01:23 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] Struts 1.0 (Final) Released As promised at JavaOne, the Struts project team is proud to announce the availability of Version 1.0 (final release) of the Struts Framework. The binary distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/ and the source distribution is available at: http://jakarta.apache.org/builds/jakarta-struts/release/v1.0/src/ Craig McClanahan
