RE: Indexed properties and BeanUtils.populate exception.
Your bean looks correct... It is probably something to do with the JSP tags.
I'm not an expert of the Struts tags (I'm more on the Java side), but
perhaps the tag does not handle the property as indexed. There is an
attribute indexed on the html:select tag, but the documentation says it's
used only within an iterate tag. Maybe you should try to use an iterate tag.
I found this post that may be relevant to you, check it out:
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg12084.html.
Also I've seen a post that talks about the support for indexed properties on
the select tag being available in the nightly build only, check this:
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg15026.html.
Hope that will help solve your problem.
Fr.
-Original Message-
From: Fredrik Östling [mailto:[EMAIL PROTECTED]]
Sent: 18 January 2002 09:09
To: [EMAIL PROTECTED]
Subject: Indexed properties and BeanUtils.populate exception.
I have multiple select tag in my JSP as follows:
html:select multiple=true size=5
property=testStrings
html:options collection=appellationTypes
property=name labelProperty=name/
/html:select
In my form bean I have these getters and setters:
public void setTestStrings( String[] in )
{
System.out.println(setTestStrings( String[] in ));
testStrings = in;
}
public void setTestStrings( int index, String in )
{
System.out.println(setTestStrings( int index,
String in ));
testStrings[index] = in;
}
public String[] getTestStrings()
{
System.out.println(getTestStrings());
return testStrings;
}
public String getTestStrings( int index )
{
System.out.println(getTestStrings( int index ));
return testStrings[index];
}
The problem is that if I select one or more fields in
the multiple select box and post it I get this
annoying Exception:
javax.servlet.ServletException: BeanUtils.populate
Struts should handle indexed properties, shouldnt it?
What am I doing wrong?
I dont know how to debug this either.
/ Fredrik
_
Hitta snörapporter...
från 500 olika skidorter i Europa
på http://se.snow.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, please notify the sender of this email
immediately. You should not copy, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: setMappedProperty
The Struts PropertyUtils is now deprecated: all further developement is done within the commons beanutils project. Future Struts release after 1.0.x will use the new commons library. If you really want this feature with Struts 1.0.x, see this posting: http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg03153.html Fr. -Original Message- From: Diego Amicabile [mailto:[EMAIL PROTECTED]] Sent: 03 December 2001 17:20 To: [EMAIL PROTECTED] Subject: setMappedProperty Hi people, I wonder why the PropertyUtils class in struts does not include the method setMappedProperty. like in org.apache.commons.beanutils Why wasn't this feature implemented? Would it be difficult? Greetings and thank you for your great work. Diego Nokia 5510 insolito ma geniale. Vai a http://it.promotions.yahoo.com/nokia/ scoprilo e vincilo. Il concorso termina il 16 dicembre 2001. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: proposal for map properties in form beans (call for comments)
Why can't you use the Commons BeanUtils MappedProperty feature?
Supposing you have these methods on your bean:
public void setProperty(String key, Object value)
public Object getProperty(String key)
then you can use this notation in the Struts nightly build:
bean:write name=formBean property=property(key)/
Fr.
-Original Message-
From: Stefan Wachter [mailto:[EMAIL PROTECTED]]
Sent: 26 November 2001 12:25
To: [EMAIL PROTECTED]
Subject: proposal for map properties in form beans (call for comments)
Dear all,
I have a lot of form bean classes that store their values in maps. Currenty
I must implement lots of similar getter and setter methods in each form bean
class in order to allow struts to access these values. E.g.
public String getName() {
return (String)myValues.get(name);
}
public void setName(String aString) {
myValues.put(name, aString);
}
My proposal is to enable struts to directly access values in maps. For
example a bean can have a map valued-property values (i.e. the method
public
Map getValues();). Now I want to access a value in this map exactly as if
it
was a normal property. For example in JSP:
bean:write name=formBean property=value.name/
The big advantage of this feature would be that I can drive the application
with meta-data. Adding a new property does not need the form beans to be
touched. Even the JSP could be prepared to generate additional fields.
Unfortunately when I scanned the struts sources I found that this kind of
extension is problematic because currently properties are accessed by the
java.beans.ProperyDescriptor instances. I think that the access would have
to be
changed to use reflection directly.
Has someone coments or suggestions on this topic?
Ciao,
Stefan
PS: This mechanism of accessing mapped values is built into the web-objects
framework.
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, please notify the sender of this email
immediately. You should not copy, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Commons BeanUtils with Struts 1.0 (was RE: PropertyUtils.getIndexedProperty() with Obect key as parameter)
Dimitri, I'm not sure what would be the best way to use the common BeanUtils with Struts 1.0. I suppose your suggestion will work, but you'll have to change many java file in order to change the imports. If your project is not going into production until later, it may be easier to take the struts nightly build which already uses the commons stuff. By the time you need to get into production, struts 1.1 may be out. I have no idea when this will be though. The real issue here is that 1.1 has a large scope, meaning that unfortunately new and simpler features implemented in the commons beanutils will not be available until much later. It would be nice to have an intermediate release that just integrates with the commons stuff (beanutils + digester). Can anybody else here make suggestions - Ted, Craig ? Fr. -Original Message- From: Dimitri Valdin [mailto:[EMAIL PROTECTED]] Sent: 01 October 2001 19:21 To: [EMAIL PROTECTED] Subject: Antwort: RE: PropertyUtils.getIndexedProperty() with Obect key as paramete r Thanks Francois, I have expected smth like that. Can you give me a hint. What would be the best way to use this feature within struts 1.0 Should I just modify struts imports and rebuild the library ? What about release 1.1 ? Dmitri Valdin -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: PropertyUtils.getIndexedProperty() with Obect key as parameter
This feature is now available in the Jakarta commons project, where BeanUtils/PropertyUtils have been upgrated to support MappedProperties, which is exactly what you describe. Have a look at the BeanUtils 1.1 component on http://jakarta.apache.org/commons/components.html. Fr. PS: BeanUtils/PropertyUtils/Digester have moved to the commons project, and are no longer part of Struts. -Original Message- From: Dimitri Valdin [mailto:[EMAIL PROTECTED]] Sent: 01 October 2001 17:00 To: [EMAIL PROTECTED] Subject: PropertyUtils.getIndexedProperty() with Obect key as parameter Hello, at the moment I am working for the Deutsche Bank in Germany. I have managed to persuade people to use Struts for their purposes, and we are happy about that. Thank you for the nice product. I would like to propose a small extension. It would be nice to have access not only to indexed properties with integer as index, but to get access to some property through some key, for example to access HashMap or Hashtables. bean:write name=someBean property=someProperty.value[key]/ Bean should have an access method getSomeProperty() which returns HashMap or smth similar. or bean:write name=someBean property=someProperty[key]/ Bean should have an access method Object getSomeProperty(Object key) similar to Object getSomeProperty(int index) which is already supported by Struts Here is a sample implementation. Let me know what do you think about it, or you have a better idea perhaps. Regards, Dmitri Valdin (See attached file: PropertyUtils.java)(See attached file: A.java)(See attached file: patchfile.txt) -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: Web-app_2_2.dtd
The ActionServlet does this resolution already, it looks for this DTD
locally:
ActionServlet {
...
/**
* The set of public identifiers, and corresponding resource names, for
* the versions of the configuration file DTDs that we know about.
There
* strongMUST/strong be an even number of Strings in this list!
*/
...
protected String registrations[] = {
-//Apache Software Foundation//DTD Struts Configuration 1.0//EN,
/org/apache/struts/resources/struts-config_1_0.dtd,
-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN,
/org/apache/struts/resources/web-app_2_2.dtd,
-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN,
/org/apache/struts/resources/web-app_2_3.dtd
};
...
protected Digester initDigester(int detail) {
...
// Register our local copy of the DTDs that we can find
for (int i = 0; i registrations.length; i += 2) {
URL url = this.getClass().getResource(registrations[i+1]);
if (url != null)
digester.register(registrations[i], url.toString());
}
...
}
Not sure why it does not work in your case. Check previous postings and
Struts resources about deploying Struts on WebLogic. Check also the parser
being used, maybe trying another one...
Fr.
-Original Message-
From: Sureka, Sushil [mailto:[EMAIL PROTECTED]]
Sent: 04 September 2001 15:29
To: '[EMAIL PROTECTED]'
Subject: Web-app_2_2.dtd
I posted it on struts-user mailing list but could not get a reply. Thats the
reason I am posting it on dev mailing list.
Hello All,
We are using struts for our application. One of the problem we have
encountered is with the finding of Web-app_2.2.dtd . Seems like the name of
the dtd is hard coded in the ActionServlet java class. During deployment of
the application (using weblogic) the server waits for like 2 minutes or so
before it determines it can not find the dtd since we are running behind the
firewall. We are not sure how can we change this behaviour it so that it
always look for it locally (instead of going on internet) and save us all
the wasted time
Sushil
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***
RE: Difficulties with Commons-Digester 1.0
There is also the possibility to use the Digester's caller ClassLoader. The
little helper class I attach with this email is quite helpful in getting the
caller's ClassLoader. With this approach, I would think there is no need to
specify additional options for a class loader, assuming of course the caller
of the Digester is able to instantiate all the needed classes.
I'd be interested anyway about any comments on this approach (using the
attached class). It has worked for me in many environment (Tomcat, WebLogic,
standalone apps, ...) without problems. But I never looked into the security
aspects and the overall validity of the approach. All I can say is that the
JDK uses similar methods for loading resources: it looks at the execution
stack in order to get a reference to the caller's ClassLoader. The only
difference is that the JDK does this using native call, and the attached
class derives from the SecurityManager in order to do this without native
code.
Fr.
-Original Message-
From: Scott Sanders [mailto:[EMAIL PROTECTED]]
Sent: 17 July 2001 22:00
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Difficulties with Commons-Digester 1.0
I am aware of this issue, and in talking with Craig, the solution is to add
a boolean useContextClassLoader to digester to turn this on and off. I will
be updating the Commons Digester to handle this hopefully in the next week
or two. If you want to send a patch, feel free ;-)
Scott Sanders
- Original Message -
From: Immanuel, Gidado-Yisa [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 11:21 AM
Subject: Difficulties with Commons-Digester 1.0
I'm cross posting this on Struts-dev and Commmons.
I attempted to incorporate the commons-digester_1.0 into my struts-
based application. A quick note on how I'm using it: In one of
my actions, I 'digest' an xml file. The digester.jar,
collections.jar, and beanutils.jar are all placed in 'WEB-INF/lib'
for the web-app in question.
The difficulty that I ran into is that the Digester could not find
the classes that needed to be instantiated. I found a solution by
comparing the struts and commons versions of ObjectCreateRule. The
struts-ObjectCreateRule locates a class using the current-class'
ClassLoader, while the commons-ObjectCreateRule first tries to use
the context-ClassLoader that is set in the currentThread.
struts.digester.ObjectCreateRule (line 151):
// Instantiate the new object and push it on the context stack
Class clazz = Class.forName(realClassName);
commons.digester.ObjectCreateRule (line 156):
// Check to see if the context class loader is set,
// and if so, use it, as it may be set in server-side
// environments and Class.forName() may cause issues
ClassLoader ctxLoader =
Thread.currentThread().getContextClassLoader();
if (ctxLoader == null) {
clazz = Class.forName(realClassName);
} else {
clazz = ctxLoader.loadClass(realClassName);
}
In the commons.digester.ObjectCreateRule, I made the following
changes, to enforce using the class' ClassLoader:
ClassLoader ctxLoader =
Thread.currentThread().getContextClassLoader();
- if (ctxLoader == null) {
+ if (true) {
+ System.out.println(OBJECTCREATERULE IS USING
Class.forName()...);
clazz = Class.forName(realClassName);
} else {
clazz = ctxLoader.loadClass(realClassName);
}
And this worked for me. I understand (more or less) the intent behind
the code in commons-ObjectCreateRule, but I'm not enough of an expert
in ClassLoaders to suggest a good solution. Craig, can you help out
on this one? Perhaps, there's something I need to do that does not
involve changing the commons-digester1.0 at all?
Thanks,
Gidado
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***
ClassContextHelper.java
RE: digester
Look at the mapper configuration file loading process in the mapper framework that is available on Ted Husted site ( http://www.husted.com/about/struts/resources.htm#extensions http://www.husted.com/about/struts/resources.htm#extensions ). See Mappers.initDigester(). I've had to create a few custom rules as well. Not sure if you can call this a better example. I still think it's overly complicated but it does the job. Fr -Original Message- From: Rakesh [mailto:[EMAIL PROTECTED]] Sent: 13 July 2001 07:21 To: [EMAIL PROTECTED] Subject: digester Is there a better example availiable anywhere of the struts digester than the struts-config file ? Any good working examples ? Rakesh The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: ActionMapping Workflows
David, I agree with you: tokens should be used. See my previous postings as well where I give reasons on why: http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01330.html. All these discussions about alternate scopes, workflow, custom context, transaction token, command token, etc. are for me one and the same. It all resolves in a context being identified by a token. But I have not given further thoughts to this idea yet. Fr. -Original Message- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: 11 July 2001 00:33 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: ActionMapping Workflows Maybe the token that can be generated in an action be used or make a workflow token. David --- Robbin L. Gratz [EMAIL PROTECTED] wrote: With the return stack concept, I'm assuming this will be a session scope variable. What happens when the user clicks the back button rather than going through the process the app provides? Now the session is out of synch with the actual position in the process that the user is in. It seems to me that there has to be some sort of request/page scope data item in the form of a hidden variable or link parameter that indicates what position in the process the user is in. I had thought about the stack concept before but couldn't get past this problem. Has anyone else come up with a solution? -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 4:16 PM To: [EMAIL PROTECTED] Subject: Re: ActionMapping Workflows I'm liking the ActionRequest idea. I've tried similar things, but needed the parameter map idea. Do you have any code yet? I agree that leveraging ActionForwards sounds like the way to go. As to the requirements Matthias started, I would change 3 to 3. The ability to call (or nest) another workflow and return to the current step when the called workflow is complete. So as to not imply a particular implementation. Martin Cooper wrote: I have a similar concern. In addition, there may be runtime parameter values that need to be passed along, particularly when actions are chained (something I do a lot of). I am working on something related, in conjunction with what Matthias referred to as a return stack. The goal is to be able to handle go back to where you came from requests, where the specification of the actual destination could require multiple dynamic parameters. The idea is that there is something called an ActionRequest, which is essentially a combination of an ActionForward and a parameter Map, with some smarts added in. A stack of these objects is kept in the session. When one is popped off the stack, the smarts will find the appropriate form bean type, populate one from the parameter map, forward the request as appropriate, and have Struts invoke the target action with this new form bean instead of the one it would normally get. I haven't fully figured this out yet, and there are some pieces of the puzzle I'm still working through. It's pretty clearly targetted at using forwards to chain actions, but it should be able to be extended to work with redirects, forwards to JSPs, etc. Thoughts, anyone? -- Martin Cooper At 08:35 AM 7/10/01, Robbin L. Gratz wrote: Another point that I believe is getting ignored on the workflow stuff is how is data getting transferred between the different steps. In the system I just worked on, we had a number of two or more step workflows that were used within other larger workflows. The output from these sub workflows needed to be captured along the way to accomplish the parent workflow. My thought was to have a controlling action whose associated data/form object stores the data retrieved from the various steps of a workflow, whether these steps were individual actions or another workflow process. Any thoughts from anyone or has someone solved this issue more elegantly? -Original Message- From: Jonathan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 8:35 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: ActionMapping Workflows Can I ask how you all are thinking about bouncing around between steps in the workflow? Is it a stack that each step gets popped off? Arent workflow steps cyclical sometimes? Developers talk alot about graphing workflows but I have not read about the implementation. - Original Message - From: Matthias Bauer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 10, 2001 9:12 AM Subject: Re: ActionMapping Workflows Ok, that's fine with me and it makes pretty much sense. However, this will not be enough to implement workflow completely. It is just a little step toward workflow control as a whole, just the same as the simple workflow extension I already proposed
Mapper framework
Just a few remarks on the mapper framework that Ted has published on his site (http://www.husted.com/about/struts/resources.htm#extensions). It is still work in progress, so consider it as an early release. It is still lacking a few things, especially proper doc and javadoc! This release includes the mapper and one bonus item: a TMX resource bundle. Integration of the mapper into Struts is quite easy. To give you an idea, I attached our base class for ActionForms. For now, this distribution will give you a more concrete idea of what the mapper is. If you're also interested in integrating the TMX resource bundle into Struts, we also have a MessageResources and MessageResourcesFactory for that. I've just now created a TO DO list for the mapper, also in XML like the Struts one, and I attached it as well. EShellActionForm.java todo.xml Enjoy, François Rey mailto:[EMAIL PROTECTED] The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *** EShellActionForm.java todo.xml
RE: Struts 1.1 TODO List -- Event and Listener Model
Your idea would certainly work. To avoid the overhead of introspection, you'll probably want to do some caching of the introspection results (e.g. the validate methods). A concern I have is whether subclassing from your base validation class is a desired feature: unless you do some code generation, you'll have to do it yourself and write the methods. Where does the configuration come in? Also, I think the naming convention would be more accurate and flexible if it was based on the form name rather than the class name. This is with such a naming convention that we have integrated our mapper framework with struts: each ActionForm looks for a mapper named mapping.getNamed() + Mapper and execute it if found. Finally, I'm not sure what you mean by keeping validation and conversion separate and why you would do so. My earlier postings were argumenting why we should not dissociate them. In the case of our mapper framework, it supports both, while still keeping them somewhat separate. The mapping steps (validate/convert/transfer) can be executed all at once or selectively. In the case of Form validation, validate and convert are done together for each mapping (form values). In other contexts you could perfectly validate all mappings (values) first, then convert them all in a separate step (so you can do other things in between), and finally transfer. Fr. -Original Message- From: Cook, Levi [mailto:[EMAIL PROTECTED]] Sent: 26 June 2001 17:43 To: '[EMAIL PROTECTED]' Subject: RE: Struts 1.1 TODO List -- Event and Listener Model And now, for something completely different.. I officially withdraw my support for the JavaBeans validation/conversion track :) I'd like to thank everyone for their input on this idea tho., if nothing else I've learned quite a bit. Besides, I might have another abstraction in mind now :) Its actually not *my* idea becuase it occured to me as I was writing unit tests with JUnit. For those of you familiar with JUnit, I'm basically thinking of something like this: com.myco.struts.ui.MyForm ActionForm com.myco.struts.ui.MyFormValidation Validation Where MyFormValidation is analogous to the JUnit TestCase. Essentially, I'd like the ActionServlet to locate this class by a simple naming convention; eg. form.getClass().getName() + Validation. If found, it would load, instantiate, setup(Serializable form) and run the objects command method (eg. run()). The command method, in turn would introspect itself and execute all the validate mothods. Each validate method would then be able to record their respective errors into a member ActionErrors object. The ActionServlet then retrieves any ActionErrors through the getErrors method. Vatidation + setup(form Serializable) : void + run : void + getErrors : ActionErrors Anyway, I'll post more on this later, just wanted to get the idea out there for feedback (or criticism). As a side note, I'm a proponent for keeping Validation and Conversion separate, simply becuase I view each as significant potentially discrete issues. Regards, Levi Cook The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: Extending the scope of the struts validation
I definitely would like to share the code but I don't have a web server somewhere where I can put it. And the zip file will be over 200Kb so I don't think sending it to the list is recommended, is it? A couple options: - Yahoo My Briefcase (and you get a couple banners) - SourceForge Any preference or other suggestions? Fr. -Original Message- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: 23 June 2001 21:18 To: [EMAIL PROTECTED] Subject: Re: Extending the scope of the struts validation I'm intersted in seeing the code too. If my validation framework does more, maybe we can make them work in tandem. I've actually been working on making the validation framework work independant of Struts. A friend of mine wants to be able to configure a different set of rules just to run on an EJB layer. The work is going well. I need to test it a little bit, but I'm hoping to post the update by the end of the weekend. David --- Ted Husted [EMAIL PROTECTED] wrote: Personally, I'm probably +1 on all of this, though it's hard to be sure until the code is on the table ;-) A very good approach, regardless of whether you want to offer it to Struts or to the Commons, is to setup a portal page someplace, as David, Oleg, and Cedric have done. You could always post what you have now, and update the rest as soon as you are able. (Release early, release often ;-) It's very good news that you were able to persuade your company to make this public. I believe a validation framework is something the Java community can really use right now. I also like the stance that this is something that we can use in Struts AND ELSEWHERE, since a focal point of a framework like Struts should be to allow as much code as possible to be shared with other environments. Frangois Rey wrote: If the interest is there, I can submit the code (although I'd prefer waiting another week to finish some doc). But I don't think it should be within the Struts project. I also don't think the strutsx would be an ideal place either because as I said it does not depend on Struts, only a bit now because the PropertyUtils and Digester are still part of Struts. I'm more thinking of the Jarakta commons since it is more generic in nature and is has been built on top of things that will be transferred into the Jakarta commons. The other reason why it is better placed in the commons is because it is actually a generic validate/convert/transfer framework which can also have an interesting value for other types of applications, not only for web developement. For example it could be used in a file handler in order to validate each record and produce a message object so be sent to a backend. With the ability to generate code out of the configuration file, performance would be improved ! by avoiding reflection and could be used for server applications with higher performance requirements. Again lots of things an open source community can do... __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: Logic tags and string properties
Actually I like emptyString very much ! I use the same keyword in my validation properties (in the mapper-config.xml :) Just a couple tips which may or may not be relevant: 1. I had to distinguish empty strings from blank strings in order to provide finer control over validation and conversion. 2. Having a default value for some properties may lead to some troubles if there are a choice of multiple attributes with overlaping semantics. For example, suppose an attribute 'emptyString' defaults to true, but that you also have another attribute 'null'. Depending on how you code your logic, setting 'null' to true may lead to both 'emptyString' and 'null' to be true at the same. Again, depending on how it's coded (e.g. the order in which you test the attributes, whether you set one to false when setting the other to true, ...) you may have unexpected behavior. Fr. -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: 25 June 2001 14:06 To: [EMAIL PROTECTED] Subject: Re: Logic tags and string properties why dont you just change it to isEmpty or emptyString which everyone knows already? =) - Original Message - From: Martin Cooper [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 25, 2001 1:19 AM Subject: Re: Logic tags and string properties Picking up on an old thread here (because I'd like to go ahead and fix the problem :-) ). If we add an 'empty' attribute to logic:present and logic:notPresent, what should the allowed values be? One option which occurs to me is that empty='true' would mean that the condition is true if the property is an empty string, while empty='false' would mean that the condition is false if the property is an empty string. To preserve the existing semantics of these tags when the attribute is not specified, 'empty' would default to 'true' for logic:present and 'false' for logic:notPresent. Is this what you had in mind? -- Martin Cooper - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 23, 2001 9:29 AM Subject: Re: Logic tags and string properties On Wed, 23 May 2001, Martin Cooper wrote: It seems that it is not possible to use the logic tags to test is this property either null or an empty string?. Using logic:present, I can determine that some value is present, but as far as I can tell, there is no way to test for an empty string. Specifying value= for tags such as notEqual seems to result in a complaint that a required attribute has not been specified. (Is this correct, or is this a bug in Resin, the container I'm using?) This is ultimately due to a restriction on the way that jsp:setProperty name=beanname property=*/ works, which I copied in the BeanUtils and PropertyUtils classes. As the properties are being copied, if the input value is a zero length string, it is *not* copied. Changing this behavior now would be very likely to break existing code, so I think we need to deal with it. But, your question is more general in scope because the input beans could come from the application as well. So, I had a couple of ideas for solving this, and I'd like to hear what people think. 1) Modify the present and notPresent tags such that the empty string is equivalent to null for the purposes of this test, if in fact the specified property is a String. This might break things, though - I'm not sure. 2) Define two new logic tags - perhaps empty and notEmpty - which define emptiness as a property being either null or the empty string. Unlike present and notPresent, these tags would only work with the name and property attributes (i.e. not cookie, parameter, etc), since the others don't really make sense distinct from present and notPresent. The second option appeals to me more, because it seems somewhat cleaner than muddying the definition of presence to include type-specific values. A third option would be to add an empty attribute to the logic:present and logic:notPresent tags, which tells them how to treat empty strings. The default, of course, would be the current behavior. Comments, anyone? -- Martin Cooper Craig The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: Extending the scope of the struts validation
I'll send it tomorrow then. I'm tied up on other things today, so I'll prepare this tonight. Thanks, Fr. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: 25 June 2001 14:37 To: [EMAIL PROTECTED] Subject: Re: Extending the scope of the struts validation You can send it to me, Francois. I'll post it on my Struts page right away, and add it to the Contributor's area in the Struts CVS later this week. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ Rey Francois wrote: I definitely would like to share the code but I don't have a web server somewhere where I can put it. And the zip file will be over 200Kb so I don't think sending it to the list is recommended, is it? A couple options: - Yahoo My Briefcase (and you get a couple banners) - SourceForge Any preference or other suggestions? Fr. The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: server-side, java-based validation rules for struts..
I'm not so much of an XML expert, but isn't the CCDATA character section
offering a nice solution in order to preserve the real look of a reg. exp.
in an XML file?
Fr.
-Original Message-
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: 25 June 2001 18:11
To: [EMAIL PROTECTED]
Subject: RE: server-side, java-based validation rules for struts..
Regular expressions should be:
^quot;\(?(\d{3})\)?[-| ]?(\d{3})[-| ]?(\d{4})$quot;
Properties file version
^\\\(?(\\d{3})\\)?[-| ]?(\\d{3})[-| ]?(\\d{4})\$
David
--- David Winterfeldt [EMAIL PROTECTED] wrote:
When you are doing regular expressions you can
basically just cut and paste them from an example
and
escape out the few XML sensitive characters, but you
have to escape out the escape characters in a java
properties file which I think makes something that
is
already hard to read even more unreadable. This is
just a simple regular expression.
XML Version (phone number with double quotes around
it)
quot;^\(?(\d{3})\)?[-| ]?(\d{3})[-|
]?(\d{4})$quot;
Properties file version
\^\\(?(\\d{3})\\)?[-| ]?(\\d{3})[-| ]?(\\d{4})$\
In a regular expression a '(' means something and
regular expressions also use '\' to escape out
characters except they don't match java's escape
characters. So '\\(' is escaping out a '\' which is
then escaping a '('.
I did a project keeping all of my regular
expressions
in a properties file and I find keeping them in xml
much more convenient. Of course if you were using a
Java IDE then you wouldn't have to worry about
escaping out the java escape characters yourself,
but
not everyone uses a full blown IDE.
When I mentioned less technical people I meant
art/design people that use something like
Dreamweaver.
Dreamweaver already has basic support for JSP and
one
day it will probably support or have a plugin for
editing XML files. I don't think less technical
people are going to find a java IDE easier to use
than
an HTML editor if you use properties files. There
are
lots of generic XML editing packages so you don't
have
to hand roll your own xml editor. And there's
always
vi or notepad.
David
http://home.earthlink.net/~dwinterfeldt
--- Nick Afshartous [EMAIL PROTECTED]
wrote:
Cook, Levi writes:
IMHO, expressing rules using first class Java
objects *can* be just as
flexible as defining rules in an XML file.
The analog to changing a value in an XML file
is
using a property editor to
change values stored in a JavaBean (thus
avoiding
recompiling). The upside
of this approach is simpler integration with
visual editors (simply
implement a property editor for your
form-bean).
Ultimately, I feel this is
where your less technical people can begin to
contribute more effectivly.
The other route requires hand-rolling a visual
editor for your XML scheme
and/or having your users learn quite a bit
about
the intricacies of your
schema.
Thanks Levi for pointing out that a property
editor
could be used.
Could one also add new rules and attributes
dynamically with a
property editor ?
Maybe the trickiest part for the users would be to
learn the
syntax for rule expressions. In particular how to
refer
to object attributes within a rule.
--
Nick
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***
RE: Opening up a thread on ALTERNATE SCOPES
This is also an area I like to discuss but I do not have any implementation nor the requirement yet to implement alternate scopes. I've made an earlier posting on this topic giving my thoughts, which I repeat below. --- start of extract --- (...) This has suggested me the notion of contexts, some being standards (request, session, etc.), others being custom defined (like your notion of workflow). Each context type would carry different behavior in terms of: - how many context of this type can be started during a session - how many context of this type can run concurrently in a session - whether going through the starting point of a context will create a new instance of a context, reuse an existing one, etc. - critical section handling (useful for form submission and transaction processing) - etc. We haven't given any further thoughts than this, and certainly not in terms of implementation. But the need has been identified and put in a list of things to look into someday. I'd be curious to know whether anybody else agrees with this idea of joining together into the same concept of custom contexts, things like : workflow, sensitive forms, and transaction integrity. --- end of extract --- Like you suggest, those scopes should most likely be stored in the session or application contexts. One thing that I think should be considered is to combine the notion of transaction integrity (usually implemented with a token) with the notion of alternate scope (also usually represented with a token). Fr. -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: 21 June 2001 04:06 To: [EMAIL PROTECTED] Subject: Opening up a thread on ALTERNATE SCOPES Hello all. We were talking about workflow a few weeks ago and the conversation dissipated. I am trying to open it up again because I have found a need for more scopes, and a need to implement these new scopes in the next few months. I am interested specifically in how it can be implemented in Struts. Let me begin with the new scopes. 1) Workflow scope within an application Store values from the first step until the final step and then get rid of the values You could probably use an adaptor, hide implementation from the developer, and store this scope inside the session scope Example - within an application store a value Do Activity 1, then do Activity 2, then do Activity 3, then throw out the value 2) Workflow between applications (mentioned by Dan Connelly earlier) Store values from the first step until the final step and then get rid of the values You could probably use an adaptor, hide implementation from the developer, and store this scope inside the application scope Example - store a value and do Activity 1 in Application 1, then do Activity 2 in Application 2, then do Activity 3 in Application 3, then throw out the value 3) Sub-Application scope Store values that pertain to a sub-directory within an application You could probably use an adaptor, hide implementation from the developer, and store this scope inside the session or application scope though I'm not sure which would be more appropriate. Example - Your applcation is a magazine which has 4 different sections, and you want to store values only pertaining to each section. When you leave the section the value is not visible, and may or may not disappear (depending on what you want to do). The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: Work flow RFC
Another possibility is to develop extensions for the TogetherJ CASE tool. It is entirely written in Java, therefore can run on most platform, and from my understanding it is possible to define new diagram types and patterns. This may not directly relate to workflow, but we have in our team created the concept of a request servicing diagram which is a class diagram representing the objects involved in servicing a request. Particularly on this diagram we display the request object and the action it is mapped to. Although we have not done it yet, it is quite possible to develop a pattern that generates the corresponding action mapping entry in the struts-config.xml, and vice-versa. François Rey Financial WebSuite Capco http://www.capco.com/ -Original Message- From: Craig Tataryn [mailto:[EMAIL PROTECTED]] Sent: 05 June 2001 20:06 To: Jonathan Cc: [EMAIL PROTECTED] Subject: Re: Work flow RFC Is this a workflow editor or just a configuration editor (which would be nice for struts)? craig. Jonathan wrote: Again, Ive got to say look at the Barracuda project. They have one of these gui configurers. Check it out at http://barracuda.enhydra.org/Barracuda/GetBConfig.event - Original Message - From: Craig Tataryn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 05, 2001 12:28 PM Subject: Work flow RFC Hi, I would like your comments for the workflow item on our TODO list. Currently this is how I've envisioned the workflow project: 1) A nice GUI type Applet or Application that has visual constructs which can be connected in a Visio type manner to create an Activity diagram or some other type of flow diagram. 2) This diagram will be persisted in an XML file which holds meta data for the elements in diagram (position, type of construct (controller, flat html page, cgi script, flow arrow, etc..)). 3) The diagram can be exported to a struts config file via XSLT (i.e. workflow.xml - workflow2struts.xsl - struts-config.xml) 4) A diagram can also be imported from a struts-config.xml file via XSLT (i.e. struts-config.xml - struts2workflow.xsl - workflow.xml). Of course some sort of pretty layout code would have to be used to un-jumble the mess of constructs that are sucked out of the struts-config.xml file (i.e. take a guess at proper positioning information). The GUI should employ some sort of extensibility mechanism like BSF (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell (http://www.beanshell.org/) to allow users to plug-in their own functionality (i.e. validation code) without jeopardizing the core code (what I call the Emeril Lagasse technique -- BAM!). I realize this is a very high level look at the TODO but I think as we get more comments we will get more granular and can start dishing out segments. Let me know what you think. tataryn:craig/ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: Adding a new workflow scope type
We have also explored such idea, although this was just a discussion in our team. We however have also concluded that the notion of workflow, or contexts in our terms, is strongly related to the notion of command token already discussed in this user list in Dec. 2000, and therefore both should be looked into at the same time. Indeed, a workflow very often relates to form submissions, sometimes several forms across multiple pages. In those cases, a better management of the data associated to the workflow is needed, so that the session context can be cleaned up correctly. And wherever forms are submitted, transaction integrity is also required. And in both cases, tokens are required to handle them. This has suggested me the notion of contexts, some being standards (request, session, etc.), others being custom defined (like your notion of workflow). Each context type would carry different behavior in terms of: - how many context of this type can be started during a session - how many context of this type can run concurrently in a session - whether going through the starting point of a context will create a new instance of a context, reuse an existing one, etc. - critical section handling (useful for form submission and transaction processing) - etc. We haven't given any further thoughts than this, and certainly not in terms of implementation. But the need has been identified and put in a list of things to look into someday. I'd be curious to know whether anybody else agrees with this idea of joining together into the same concept of custom contexts, things like : workflow, sensitive forms, and transaction integrity. François Rey Financial WebSuite Capco http://www.capco.com/ -Original Message- From: TKV Tyler VanGorder [mailto:[EMAIL PROTECTED]] Sent: 11 May 2001 02:07 To: [EMAIL PROTECTED] Subject: Adding a new workflow scope type I have seen this asked a couple of times on the strut users mailing list. The problem this new workflow scope is meant to address is as follows: When a browser client establishes a session with the servlet engine, there is nothing stopping the user from opening up more than one browser window during that session. This means that any data stored in the session scope will be shared by both windows. A user can proceed through an instance of the same workflow in each of their browser windows and there is no way of distinguishing which data belongs to each instance. The request scope doesn't solve this problem if a workflow spans more than one browser request. Thus a new scope type: workflow A workflow is started by a particular action mapping and a token is generated to identify the workflow context. That ID is set on an attribute of the request. The workflow context is passed along by encoding the additional workflow context ID into any URL that is embedded in the JSPs. So, encoding a standard URL now goes through two layers - First we grab the workflow context ID from the request attributes. - We encode the workflow context ID into our URL. - Finally, we encode the new URL with the servlet's session ID. You then modify the ActionServlet, so that when it gets a request, it can parse out the workflow ID out of the encoded URL and place it back into the request object. Objects that are in workflow scope are stored in the user's session using the workflow context ID as the key. The value of that entry is another hashmap that allows arbitrary key/object mappings. Finally, you identify a particular action as ending a workflow. The action servlet parses our the workflow ID from the URL, does NOT put that into the request object and removes all the data for that workflow from the user's session. Any comments on this? Thanks Tyler Van Gorder [EMAIL PROTECTED] Landacorp. The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
RE: JSP Components
I am reposting this item below because I haven't got any feedback since I posted it on 8 March. Just briefly, this is about the ability to perform an Action specific to a JSP component being reused. Right now it is not possible to make an action being automatically performed when including a JSP component. I'm sure some people would be able to comment (Craig and Cedric notably), because I think the topic of reusing JSP components is (IMHO) an interesting and essential one. Thanks in advance. Franois Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ -Original Message- From: Rey Francois [mailto:[EMAIL PROTECTED]] Sent: 08 March 2001 14:40 To: '[EMAIL PROTECTED]' Subject: JSP Components In the context of building reusable JSP components, I have been confronted with the following limitation that both the Struts templating and the Components from Cedric Dumoulin currently have. In a word, this limitation is actually due to the fact that none of them provide a way to perform an action specific to the included JSP. For example, an application home page may be composed of a body that actually corresponds to another page in the web application. In this case, the body is already modeled with a mapping and an action that performs the necessary logic to retrieve the dynamic content. When servicing the home page, one would logically like to reuse that action in order to avoid the duplication of its logic in the action servicing the home page. One way to do this would be to directly call the action to reuse within the perform() of the action servicing the home page. However this is not very flexible because it requires manual intervention. My short research in past postings actually seems to indicate that this problem has been mentioned before under various forms. A proposal for a portal framework was discussed before, and such framework would require such feature. In one instance the Jetspeed framework was considered for integration with Struts. In another case one talked about allowing the ActionServlet to do both forwards and includes. My questions then are: - has anybody else been confronted to this limitation, and if so, did you avoid the problem (for example by using frames) or did you find a solution? - would such a feature be considered for inclusion in either Struts or the Components framework from Cedric Dumoulin? - anybody having further thoughts on this issue? Thanks for your feedback on this topic. Franois Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of The Capital Markets Company. http://www.capco.com *** The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of The Capital Markets Company. http://www.capco.com ***
RE: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.)
We're talking about extending the ActionForm with a base class containing the two collections (errors and object values). This base class will itself have to be derived into concrete ActionForms with the relevant properties and their corresponding set/get methods. Fr. -Original Message- From: Spencer Smith [mailto:[EMAIL PROTECTED]] Sent: 01 March 2001 15:42 To: [EMAIL PROTECTED] Subject: Re: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.) Are you talking about modifying the actual struts classes or extending them in myFormBeans Pages? The problem I have run into is that at first, I wanted to make some minor mods to the Struts classes and add a couple of new entries into the struts-html.tld files, but I was told be the lead guy that that was not a viable option, because each time we upgraded struts we would have to change the code all over again, and deploying it all over it a real pain. I was actually looking into using Perl5 regular expressions to use Auto-Validation with my FormBeans pages. I think this is a very viable solution as long as you don't have to mod the struts ActionForm page. Maybe the way to go is to create a generic new generic Validator class that will do something like the following: validateEmail validateRange validateText etc, etc. What do you think? - Original Message - From: "Rey Francois" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 28, 2001 11:20 PM Subject: RE: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.) Our intention is to use ActionForms as converters to object values. Typically the information entered in a form is going to be used as parameters to a backend request or will go into some object or bean that will be sent to the backend. One should not send to the backend the ActionForm object itself because this would make the backend interface dependent on the front-end. So somehow the information has to be extracted form the ActionForm. With JDBC, ActionForm values will be used to set parameters of a Statement or PreparedStatement. With an EJB backend a Value Object may have to be populated. In other cases it can be a Request object that is part of the public interface to the backend, or in the case of a JCA interface, a Record object. In our approach the ActionForm setter methods use the Format classes to validate and create correct object values and catch any exception resulting from an invalid input, storing corresponding error messages in a collection that can be used in the validate(). Objects resulting from valid parsed inputs are stored internally in a hashtable, and can be retrieved within Action.perform() by calling a generic getValue method on the ActionForm. We have not implemented this yet, but this is how we intend to implement ActionForms. Comments on this approach are welcomed. Franois Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ -Original Message- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: 28 February 2001 18:21 To: [EMAIL PROTECTED] Subject: RE: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.) I think it is good to tie together the valdation and conversion of the strings to objects and objects to properly formatted strings. I'm curious to know if how you have and/or plan to tie this in with your beans (ActionForm). Will they just have setters and getters for strings and you will use your format class as you need it outside of the beans or do you have the functionality built into your bean (custom PropertyDescriptors and/or something like String getDateAsText(), Date getDateValue()). David --- Rey Francois [EMAIL PROTECTED] wrote: See also the posting I made a few days ago regarding validation. I've pasted it below. The main idea is to use the java.text.Format class to do the validation and transformation between Strings and objects (both ways). The XML customization you're talking about should achieve this double goal: validation and transformation. Franois Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ - begin paste In our case, we have chosen to use the java.text.Format as a superclass of all our validation and formatting classes. I would suggest Struts to consider this approach. Our decision derives from the following requirements: 1 Validation of Strings data according to a specified format The basic requirement is to validate that a string complies to a specified format. For example, for a string representing a date, the requirement is to make sure it is of the form: dd/mm/. 2 Parsing Strings to Objects and vice-versa Beyond the simple aspect of validating the format of an input string, it is also often required to transform the validated string into a usable form for further processing. In Java this means creating
RE: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.)
Our intention is to use ActionForms as converters to object values. Typically the information entered in a form is going to be used as parameters to a backend request or will go into some object or bean that will be sent to the backend. One should not send to the backend the ActionForm object itself because this would make the backend interface dependent on the front-end. So somehow the information has to be extracted form the ActionForm. With JDBC, ActionForm values will be used to set parameters of a Statement or PreparedStatement. With an EJB backend a Value Object may have to be populated. In other cases it can be a Request object that is part of the public interface to the backend, or in the case of a JCA interface, a Record object. In our approach the ActionForm setter methods use the Format classes to validate and create correct object values and catch any exception resulting from an invalid input, storing corresponding error messages in a collection that can be used in the validate(). Objects resulting from valid parsed inputs are stored internally in a hashtable, and can be retrieved within Action.perform() by calling a generic getValue method on the ActionForm. We have not implemented this yet, but this is how we intend to implement ActionForms. Comments on this approach are welcomed. Franois Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ -Original Message- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: 28 February 2001 18:21 To: [EMAIL PROTECTED] Subject: RE: Validating bean properties (WAS: Re: Stupd question aboutStru ts and EJB.) I think it is good to tie together the valdation and conversion of the strings to objects and objects to properly formatted strings. I'm curious to know if how you have and/or plan to tie this in with your beans (ActionForm). Will they just have setters and getters for strings and you will use your format class as you need it outside of the beans or do you have the functionality built into your bean (custom PropertyDescriptors and/or something like String getDateAsText(), Date getDateValue()). David --- Rey Francois [EMAIL PROTECTED] wrote: See also the posting I made a few days ago regarding validation. I've pasted it below. The main idea is to use the java.text.Format class to do the validation and transformation between Strings and objects (both ways). The XML customization you're talking about should achieve this double goal: validation and transformation. Franois Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ - begin paste In our case, we have chosen to use the java.text.Format as a superclass of all our validation and formatting classes. I would suggest Struts to consider this approach. Our decision derives from the following requirements: 1 Validation of Strings data according to a specified format The basic requirement is to validate that a string complies to a specified format. For example, for a string representing a date, the requirement is to make sure it is of the form: dd/mm/. 2 Parsing Strings to Objects and vice-versa Beyond the simple aspect of validating the format of an input string, it is also often required to transform the validated string into a usable form for further processing. In Java this means creating an object instance from the string. With the date example, this could mean creating a java.util.Date object. On the other hand, it is also required to perform the reverse operation. In the case of an instance of a java.util.Date, it should be possible to get a string representation of it according to a specified format. 3 String buffer parsing and formatting It should be easy to parse only a certain part of a larger string when the latter contains the formatting of several elements. Conversely, it should be easy to append the string representation of an object to an existing string. This can be useful for example in the context of marshalling object instances into an XML representation. 4 Independence of the usage context The classes involved should be coupled to any context of usage. This is to allow maximum reuse of the logic in various contexts. For example the framework should not depend on the HTTP request of the Servlet API. This should enable the creation of a library of formatter that can be used in various projects. This library can contain basic formatters, but also more business oriented ones such as account number formatting, etc. 5 Internationalization In some cases it is necessary to have the parsing and validation processing aware of locale-specific factors. The date example is again a very good illustration of this requirement, whereby in the United States dates are of the form mm/dd/, while in Europe dates are of the form dd/mm/. In the context of a graphical user
RE: Validating bean properties (WAS: Re: Stupd question aboutStruts and EJB.)
See also the posting I made a few days ago regarding validation. I've pasted it below. The main idea is to use the java.text.Format class to do the validation and transformation between Strings and objects (both ways). The XML customization you're talking about should achieve this double goal: validation and transformation. Franois Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ - begin paste In our case, we have chosen to use the java.text.Format as a superclass of all our validation and formatting classes. I would suggest Struts to consider this approach. Our decision derives from the following requirements: 1 Validation of Strings data according to a specified format The basic requirement is to validate that a string complies to a specified format. For example, for a string representing a date, the requirement is to make sure it is of the form: dd/mm/. 2 Parsing Strings to Objects and vice-versa Beyond the simple aspect of validating the format of an input string, it is also often required to transform the validated string into a usable form for further processing. In Java this means creating an object instance from the string. With the date example, this could mean creating a java.util.Date object. On the other hand, it is also required to perform the reverse operation. In the case of an instance of a java.util.Date, it should be possible to get a string representation of it according to a specified format. 3 String buffer parsing and formatting It should be easy to parse only a certain part of a larger string when the latter contains the formatting of several elements. Conversely, it should be easy to append the string representation of an object to an existing string. This can be useful for example in the context of marshalling object instances into an XML representation. 4 Independence of the usage context The classes involved should be coupled to any context of usage. This is to allow maximum reuse of the logic in various contexts. For example the framework should not depend on the HTTP request of the Servlet API. This should enable the creation of a library of formatter that can be used in various projects. This library can contain basic formatters, but also more business oriented ones such as account number formatting, etc. 5 Internationalization In some cases it is necessary to have the parsing and validation processing aware of locale-specific factors. The date example is again a very good illustration of this requirement, whereby in the United States dates are of the form mm/dd/, while in Europe dates are of the form dd/mm/. In the context of a graphical user interface, this is an important requirement. The java.text.Format class satisfies all the above requirements. It is a standard Java object, so using it should be consistent with future Java developments. Finally, J2SE already proposes some formatters for numeric values, date, and messages. In our context, these format classes will be used for: - HTTP request parameter validation - Handling of request and return buffer to and from legacy systems - Displaying of the data elements in an HTML front-end Eventually, beyond the use of Format classes, we intend to create a sort of format class instance pool, whereby pre-initialized format classes are stored for repetitive usage. This avoids the creation and initialization of an object each time a validation/formatting has to be performed. The Struts digester would be a great tool for initializing this pool. Comments welcomed! --- end paste --- -Original Message- From: Nick Pellow [mailto:[EMAIL PROTECTED]] Sent: 28 February 2001 08:07 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Validating bean properties (WAS: Re: Stupd question aboutStruts and EJB.) Martin, [EMAIL PROTECTED] wrote: Actually, the plan is to build exactly this type of validation into Struts 1.1. In particular, I am hoping to incorporate it into the automated bean creation tool, one way or another. Yup, I minutes after my lost post, I received the post for Volunteer for Validation Framework. Wish I had read that first! The validation stuff sure could be interesting. The idea is to define your bean(s) in an XML file, and have the tool generate the actual bean code for you. When you define a bean, you can specify its type, along with some other validation rules (yet to be determined). The tool will create a validate() method, and that method will populate ActionErrors as appropriate. My original thought was to generate code based on the validation rules. However, David Winterfeldt has written an interesting validator that runs off an XML spec directly. This may be a better approach, in that you can modify the rules later without recreating the bean, among other things. I was considering an approach where coders wrote
