Can someone unsubscribe me

[Prabha Desai]

Title: Can someone unsubscribe me





The automated version is not working. I have been trying for the past few months.

beware: beta remnants

[Dan Connelly]

I tried to replace the beta on my Tomcat 
with the 1.0, but that peskybeta just kept hanging around. I must be 
so stupid.



jakarta-struts-1.0-src/src/example/org/apache/struts/webapp/example/ApplicationResources.properties:index.title=MailReader 
Demonstration Application (Struts 1.0-b1)

Extending the scope of the struts validation

[Frangois Rey]

You may remember some of my earlier postings about a mapper framework that we use as a 
validation framework. I now have the support in my company to make it open source. 
However, I first would prefer to:

1- Invite the community to realize that a validation framework, definitely required in 
Struts, is only part of a larger requirement.
2- Propose the extension of the scope of the TO DO item for validation so that is does 
a bit more than just validation but also convert the value and transfer them to where 
they should end up.

I know I've already approached this topic in my previous postings, but I there hasn't 
been much follow up on this. However I still believe those that have developed web 
applications with Struts have been confronted to the same problems we have been trying 
to solve. So instead of submitting a big zip file that may or may not get interest, I 
first would like to share the reasons that led us to developing the mapper framework.

In our company, after evaluating a few options, we have chosen Struts as the base 
framework for developing web applications. We have developed our own simple extensions 
to Struts in order to provide added support for things like i18n and transaction 
integrity. Form validation was also a top item in our list of needed extensions, but 
looking at the Struts 1.1 TO DO list we decided to wait and see what the community 
would come up with. For one of our customer project, we have looked at the validation 
framework from David Winterfeldt in order to implement form validation. We were very 
attracted to that framework because it offered configuration-based validation and also 
client-side validation. However beyond the simple need to validate form properties, we 
also needed to do type conversion (text-object) on each field and populate another 
bean (a command bean) with the converted values. Having a framework that only 
addressed the validation part meant that we would still need to do a lot of custom 
coding in order to convert values and populate our command beans. And in addition to 
this, we also needed to do type conversion and populate presentation  beans when 
receiving result messages from the backend, which means even more custom coding.

I think by now you should understand and hopefully agree with me that validation is 
actually only the first part of larger need: once values have been validated, you need 
to do something with them. Whatever is needed to do, it should not be the 
responsibility of the ActionForm. The latter should remain a View object that is only 
a placeholder for user input. Business logic should be separated into another set of 
objects. Actions seem to be a good place for implementing this business logic. However 
doing so ties the logic to the web application framework in a way that makes the reuse 
of this logic outside of a web application difficult. So a good application architect 
would usually factor this business logic into another set of objects that is not 
dependent from the web application. Often these objects are actually just sending 
requests to a backend where the real business logic resides. But whatever these 
objects are (the real Model, a PreparedStatement, or a proxy to a Model layer 
implemented on another server), the point is that these are objects which need to be 
initialized and populated with the user input.

Coming back to our project: we have an EJB backend accessed with a messaging 
framework: you send command messages (objects), and you get result messages (objects). 
And of course we wanted to avoid lots of custom code in our actions because it's 
tedious, not so fun to write, and increases the maintenance burden (more lines of 
code). So we took the decision to develop the mapper framework. What we now have is 
used almost all over the place in the application we're developing, for the things I 
mentioned above: validation, type conversion, and bean population, and for both 
directions: forms - command messages and result messages - presentation beans. The 
code in our Actions.perform() has decreased dramatically to just a few things. When we 
get to the Action, the ActionForm.validate() has successfully validated the user input 
with its mapper. In the Action.perform(), all we do is to ask the same mapper to 
create the command message and populate it with the converted values, send this object 
to the backend, ask another mapper to process the result message, and then forward to 
the JSP.

Now that I have explained why validation is just part of a larger story, one might say 
that a validation-only framework is a good start anyway. The problem with that 
approach is that actually validation and conversion can be one and the same thing: if 
you are able to convert a value into something else, this is at least partly 
validating the value. Using the SimpleDateFormat class to create a Date object from a 
String value will fail if the string is not in the proper format and does not contain 

cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example ApplicationResources.properties

[craigmcc]

craigmcc01/06/23 10:50:38

  Modified:src/example/org/apache/struts/webapp/example Tag:
STRUTS_1_0_BRANCH ApplicationResources.properties
  Log:
  Grr, Forgot to update the version number in the example app.
  
  Submitted by: Dan Connelly [EMAIL PROTECTED]
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +1 -1  
jakarta-struts/src/example/org/apache/struts/webapp/example/ApplicationResources.properties
  
  Index: ApplicationResources.properties
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/ApplicationResources.properties,v
  retrieving revision 1.1
  retrieving revision 1.1.2.1
  diff -u -r1.1 -r1.1.2.1
  --- ApplicationResources.properties   2001/04/11 02:09:59 1.1
  +++ ApplicationResources.properties   2001/06/23 17:50:38 1.1.2.1
  @@ -31,7 +31,7 @@
   index.heading=MailReader Demonstration Application Options
   index.logon=Log on to the MailReader Demonstration Application
   index.registration=Register with the MailReader Demonstration Application
  -index.title=MailReader Demonstration Application (Struts 1.0-b1)
  +index.title=MailReader Demonstration Application (Struts 1.0)
   index.tour=A Walking Tour of the Example Application
   linkSubscription.io=I/O Error: {0}
   linkSubscription.noSubscription=No subscription under attribute {0}
  
  
  

Re: Extending the scope of the struts validation

[David Winterfeldt]

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/

RE: Struts 1.0 Released - Looking forward to 1.1!!!!!!!

[Niall Pemberton]

Ted,

I submitted a patch a month ago, following a go-ahead from Craig to a
bugzilla I raised and it got zero response. Now maybe it wasn't any good and
probably I should have put more explanation, but a response saying something
would have been great.

That was the reason I put the comment about a committer being assigned - I'd
rather know there was someone with power interested rather than waste
effort again.

I also submitted code for if/else and switch/case tags - if you've got the
time, I would appreciate your opinion on those as well.

1) PATCH: [Bug 1683] - Change Struts tags to be more granular in their
design:

This patch affected the following tags and involved re-factoring code out of
the doStartTag() method so that Struts tags could be more easily sub-classed
and individual bits of functionality overriden - a good example of where
this could be used is, generating names which include the index value when
embedded in an IterateTag.

BaseFieldTag.java, BaseFieldTag.java, ButtonTag.java, CancelTag.java,
CheckboxTag.java, ImageTag.java, ImgTag.java, MultiboxTag.java,
RadioTag.java, ResetTag.java, SelectTag.java, SubmitTag.java,
TextareaTag.java


http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg01450.html

I believe quite a few of these tags have been changed since I submitted this
so unless CVS is clever I gues its now can't be applied and was a waste of
time.


2) IF / ELSE and SWITCH/CASE Tags:

These tags are basically just new wrappers for existing Struts
functionality - the key classes extend the existing Struts CompareTagBase. I
have a new version since I submitted them which includes the ability to
specify condtions on the case tag - rather than just having to be equal -
if its of interest I can send it.


http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01372.html


Niall


 -Original Message-
 From: Ted Husted [mailto:[EMAIL PROTECTED]]
 Sent: 21 June 2001 11:13
 To: [EMAIL PROTECTED]
 Subject: Re: Struts 1.0 Released - Looking forward to 1.1!!!


 Just a note:

 Committers make the final decision about whether something is added to
 the official distribution, but we do not control the contribution or
 development process. Everyone is invited and encouraged to discuss how
 they would implement features here on the dev list, and then go off and
 implement them -- usually for use in your own project. When you bring
 the code back to list, then we can make the decision about whether it's
 a good fit with the Struts core.

 But, hey, don't wait on us guys -- do what *you* need to do, and then
 show us the code when you're ready.

 -- Ted Husted, Husted dot Com, Fairport NY USA.
 -- Custom Software ~ Technical Services.
 -- Tel 716 737-3463.
 -- http://www.husted.com/about/struts/

 Niall Pemberton wrote:
  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.

Re: Struts 1.0 Released - Looking forward to 1.1!!!!!!!

[Michael Mok]

Hi Niall

I have been using your extentions (being able to access and update indexed
properties via the iterate tag) in my Web Timesheet system. Yes it would be
really good if your changes are committed into the 1.1 release. Your code
change is certainly not a waste of time for me.

Otherwise if you made any updates to apply on top of the 1.0 STRUTS, can you
let me know so I can incorporate into my development environment.

Thanks in advance.

Regards


Michael Mok
www.webappcabaret.com/normad

- Original Message -
From: Niall Pemberton [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, June 24, 2001 5:08 AM
Subject: RE: Struts 1.0 Released - Looking forward to 1.1!!!


 Ted,

 I submitted a patch a month ago, following a go-ahead from Craig to a
 bugzilla I raised and it got zero response. Now maybe it wasn't any good
and
 probably I should have put more explanation, but a response saying
something
 would have been great.

 That was the reason I put the comment about a committer being assigned -
I'd
 rather know there was someone with power interested rather than waste
 effort again.

 I also submitted code for if/else and switch/case tags - if you've got the
 time, I would appreciate your opinion on those as well.

 1) PATCH: [Bug 1683] - Change Struts tags to be more granular in their
 design:

 This patch affected the following tags and involved re-factoring code out
of
 the doStartTag() method so that Struts tags could be more easily
sub-classed
 and individual bits of functionality overriden - a good example of where
 this could be used is, generating names which include the index value when
 embedded in an IterateTag.

 BaseFieldTag.java, BaseFieldTag.java, ButtonTag.java, CancelTag.java,
 CheckboxTag.java, ImageTag.java, ImgTag.java, MultiboxTag.java,
 RadioTag.java, ResetTag.java, SelectTag.java, SubmitTag.java,
 TextareaTag.java


 http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg01450.html

 I believe quite a few of these tags have been changed since I submitted
this
 so unless CVS is clever I gues its now can't be applied and was a waste of
 time.


 2) IF / ELSE and SWITCH/CASE Tags:

 These tags are basically just new wrappers for existing Struts
 functionality - the key classes extend the existing Struts CompareTagBase.
I
 have a new version since I submitted them which includes the ability to
 specify condtions on the case tag - rather than just having to be
equal -
 if its of interest I can send it.


 http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01372.html


 Niall


  -Original Message-
  From: Ted Husted [mailto:[EMAIL PROTECTED]]
  Sent: 21 June 2001 11:13
  To: [EMAIL PROTECTED]
  Subject: Re: Struts 1.0 Released - Looking forward to 1.1!!!
 
 
  Just a note:
 
  Committers make the final decision about whether something is added to
  the official distribution, but we do not control the contribution or
  development process. Everyone is invited and encouraged to discuss how
  they would implement features here on the dev list, and then go off and
  implement them -- usually for use in your own project. When you bring
  the code back to list, then we can make the decision about whether it's
  a good fit with the Struts core.
 
  But, hey, don't wait on us guys -- do what *you* need to do, and then
  show us the code when you're ready.
 
  -- Ted Husted, Husted dot Com, Fairport NY USA.
  -- Custom Software ~ Technical Services.
  -- Tel 716 737-3463.
  -- http://www.husted.com/about/struts/
 
  Niall Pemberton wrote:
   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.
 

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html ErrorsTag.java

[rleland]

rleland 01/06/23 20:22:55

  Modified:src/share/org/apache/struts/taglib/html ErrorsTag.java
  Log:
  Buzilla 2198 This is a limited patch that doesn't add arguments to the errors
   tag, which is needed to fully cleanup error reporting.
  Currently given:
  
 html:errors property=p1/
 html:errors property=p2/
 html:errors property=p3/
  
  If there is an error for property p1,
  an errors.header will be printed for p2 and p3 also
  regardless if there is an error
  or not for that property !
  
  The patch below restricts the printing of the header
  to only those properties which have errors, and the global
  html:errors/ tag.
  
  Revision  ChangesPath
  1.9   +14 -10
jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java
  
  Index: ErrorsTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- ErrorsTag.java2001/04/18 23:32:34 1.8
  +++ ErrorsTag.java2001/06/24 03:22:55 1.9
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v 1.8 
2001/04/18 23:32:34 craigmcc Exp $
  - * $Revision: 1.8 $
  - * $Date: 2001/04/18 23:32:34 $
  + * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v 1.9 
2001/06/24 03:22:55 rleland Exp $
  + * $Revision: 1.9 $
  + * $Date: 2001/06/24 03:22:55 $
*
* 
*
  @@ -98,7 +98,7 @@
* /ul
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.8 $ $Date: 2001/04/18 23:32:34 $
  + * @version $Revision: 1.9 $ $Date: 2001/06/24 03:22:55 $
*/
   
   public class ErrorsTag extends TagSupport {
  @@ -230,22 +230,25 @@
   RequestUtils.present(pageContext, bundle, locale, errors.header);
   boolean footerPresent =
   RequestUtils.present(pageContext, bundle, locale, errors.footer);
  -
  +
   // Render the error messages appropriately
StringBuffer results = new StringBuffer();
   String message = null;
   if (headerPresent)
   message = RequestUtils.message(pageContext, bundle,
  locale, errors.header);
  - if (message != null) {
  - results.append(message);
  - results.append(\r\n);
  - }
   Iterator reports = null;
   if (property == null)
   reports = errors.get();
   else
   reports = errors.get(property);
  +   // Render header iff this is a global tag or there is an error for this 
property
  +   boolean propertyMsgPresent = reports.hasNext();
  +   if ((message != null)(property == null) || propertyMsgPresent) {
  +   results.append(message);
  +   results.append(\r\n);
  +   }
  +
   while (reports.hasNext()) {
   ActionError report = (ActionError) reports.next();
   message = RequestUtils.message(pageContext, bundle,
  @@ -260,7 +263,8 @@
   if (footerPresent)
   message = RequestUtils.message(pageContext, bundle,
  locale, errors.footer);
  - if (message != null) {
  +
  +if ((message != null)(property == null) || propertyMsgPresent) {
results.append(message);
results.append(\r\n);
}
  
  
  

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html ErrorsTag.java

[rleland]

rleland 01/06/23 20:33:10

  Modified:src/share/org/apache/struts/taglib/html ErrorsTag.java
  Log:
  Pretty up formatting.
  
  Revision  ChangesPath
  1.10  +10 -10
jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java
  
  Index: ErrorsTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- ErrorsTag.java2001/06/24 03:22:55 1.9
  +++ ErrorsTag.java2001/06/24 03:33:10 1.10
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v 1.9 
2001/06/24 03:22:55 rleland Exp $
  - * $Revision: 1.9 $
  - * $Date: 2001/06/24 03:22:55 $
  + * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v 1.10 
2001/06/24 03:33:10 rleland Exp $
  + * $Revision: 1.10 $
  + * $Date: 2001/06/24 03:33:10 $
*
* 
*
  @@ -98,7 +98,7 @@
* /ul
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.9 $ $Date: 2001/06/24 03:22:55 $
  + * @version $Revision: 1.10 $ $Date: 2001/06/24 03:33:10 $
*/
   
   public class ErrorsTag extends TagSupport {
  @@ -232,7 +232,7 @@
   RequestUtils.present(pageContext, bundle, locale, errors.footer);
   
   // Render the error messages appropriately
  - StringBuffer results = new StringBuffer();
  + StringBuffer results = new StringBuffer();
   String message = null;
   if (headerPresent)
   message = RequestUtils.message(pageContext, bundle,
  @@ -254,17 +254,17 @@
   message = RequestUtils.message(pageContext, bundle,
  locale, report.getKey(),
  report.getValues());
  - if (message != null) {
  - results.append(message);
  - results.append(\r\n);
  + if (message != null) {
  + results.append(message);
  + results.append(\r\n);
  + }
}
  - }
   message = null;
   if (footerPresent)
   message = RequestUtils.message(pageContext, bundle,
  locale, errors.footer);
   
  -if ((message != null)(property == null) || propertyMsgPresent) {
  +if ((message != null)(property == null) || propertyMsgPresent) {
results.append(message);
results.append(\r\n);
}
  
  
  

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html ErrorsTag.java

[rleland]

rleland 01/06/23 20:36:10

  Modified:src/share/org/apache/struts/taglib/html Tag:
STRUTS_1_0_BRANCH ErrorsTag.java
  Log:
  Buzilla 2198 This is a limited patch that doesn't add arguments to the errors
   tag, which is needed to fully cleanup error reporting.
  Currently given:
  
 html:errors property=p1/
 html:errors property=p2/
 html:errors property=p3/
  
  If there is an error for property p1,
  an errors.header will be printed for p2 and p3 also
  regardless if there is an error
  or not for that property !
  
  The patch below restricts the printing of the header
  to only those properties which have errors, and the global
  html:errors/ tag.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.8.2.1   +17 -13
jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java
  
  Index: ErrorsTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v
  retrieving revision 1.8
  retrieving revision 1.8.2.1
  diff -u -r1.8 -r1.8.2.1
  --- ErrorsTag.java2001/04/18 23:32:34 1.8
  +++ ErrorsTag.java2001/06/24 03:36:10 1.8.2.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v 1.8 
2001/04/18 23:32:34 craigmcc Exp $
  - * $Revision: 1.8 $
  - * $Date: 2001/04/18 23:32:34 $
  + * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java,v 
1.8.2.1 2001/06/24 03:36:10 rleland Exp $
  + * $Revision: 1.8.2.1 $
  + * $Date: 2001/06/24 03:36:10 $
*
* 
*
  @@ -98,7 +98,7 @@
* /ul
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.8 $ $Date: 2001/04/18 23:32:34 $
  + * @version $Revision: 1.8.2.1 $ $Date: 2001/06/24 03:36:10 $
*/
   
   public class ErrorsTag extends TagSupport {
  @@ -237,30 +237,34 @@
   if (headerPresent)
   message = RequestUtils.message(pageContext, bundle,
  locale, errors.header);
  - if (message != null) {
  - results.append(message);
  - results.append(\r\n);
  - }
   Iterator reports = null;
   if (property == null)
   reports = errors.get();
   else
   reports = errors.get(property);
  +   // Render header iff this is a global tag or there is an error for this 
property
  +   boolean propertyMsgPresent = reports.hasNext();
  +   if ((message != null)(property == null) || propertyMsgPresent) {
  +   results.append(message);
  +   results.append(\r\n);
  +   }
  +
   while (reports.hasNext()) {
   ActionError report = (ActionError) reports.next();
   message = RequestUtils.message(pageContext, bundle,
  locale, report.getKey(),
  report.getValues());
  - if (message != null) {
  - results.append(message);
  - results.append(\r\n);
  + if (message != null) {
  + results.append(message);
  + results.append(\r\n);
  + }
}
  - }
   message = null;
   if (footerPresent)
   message = RequestUtils.message(pageContext, bundle,
  locale, errors.footer);
  - if (message != null) {
  +
  +if ((message != null)(property == null) || propertyMsgPresent) {
results.append(message);
results.append(\r\n);
}
  
  
  

cvs commit: jakarta-struts/doc release-notes-1.1-ms1.xml

[rleland]

rleland 01/06/23 21:08:43

  Added:   doc  release-notes-1.1-ms1.xml
  Log:
  Add Version 1.1 Milestone one docs to capture changes since
  version 1.0 was released.
  
  Revision  ChangesPath
  1.1  jakarta-struts/doc/release-notes-1.1-ms1.xml
  
  Index: release-notes-1.1-ms1.xml
  ===
  ?xml version=1.0?
  document url=./release-notes-1.1-ms1.xml
  
properties
  authorCraig R. McClanahan/author
  titleStruts Release Notes (Version 1.1 Milestone 1)/title
/properties
  
body
  
section name=Introduction href=Introduction
  
  pThis document contains the release notes for
  strongVersion 1.1 Milestone 1/strong of the Struts Framework,
  and covers changes that have taken place since
  a href=release-notes-1.0.htmlVersion 1.0/a
  was released.  The following sections cover
  a href=#NewNew Features/a and a href=#ChangesChanges/a
  to Struts./p
  
/section
  
  
section name=What's Included? href=Included
  
  pThe binary distribution of this release includes the following
  files relevant to Struts 1.1:/p
  ul
  licodeINSTALL/code - Brief installation instructions.  See
  the codeStruts Documentation Application/code, or online at
  a 
href=http://jakarta.apache.org/struts/;http://jakarta.apache.org/struts//a
  for more information./li
  licodeLICENSE/code - The Apache Software Foundation license that
  defines the terms under which you can use Struts (and other software
  licensed by Apache)./li
  licodeREADME/code - A brief introduction to Struts./li
  licodelib//code - Directory containing files you will need in
  your own applications.  The individual files of interest are:/li
  ul
  licodestruts.jar/code - JAR file that contains the compiled
  Java classes for version 1.0 of Struts.  You must
  place this file in the code/WEB-INF/lib/code directory of
  your web application./li
  licodestruts-x.tld/code - The tag library descriptor files
  for the Struts 1.1 tag libraries (bean, html, logic, and
  template).  You must place these files in the code/WEB-INF/code
  directory of your web application, and reference them with
  appropriate codelt;taglibgt;/code directives in your
  web.xml file./li
  licodejdbc2_0-stdext.jar/code - The JDBC 2.0 Optional Package
  API classes (package codejavax.sql/code).  You will need to
  include this file in the code/WEB-INF/lib/code directory
  of your application, if it is not already made visible to web
  applications by your servlet container./li
  licodestruts-config_1_1.dtd/code - The document type descriptor
  (DTD) for the Struts configuration file (which is typically named
  code/WEB-INF/struts-config.xml/code.  Your configuration file
  will be validated against an internal copy of this DTD -- this
  copy is available for reference purposes only./li
  licodeweb-app_2_2.dtd/code - The document type descriptor (DTD)
  for web.xml files conforming to the Servlet 2.2 specification.
  This copy is for reference purposes only./li
  licodeweb-app_2_3.dtd/code - The document type descriptor (DTD)
  for web.xml files conforming to the Servlet 2.3 specification.
  This copy is for reference purposes only./li
  /ul
  licodewebapps//code - Web Application Archive (WAR) files for the
  web applications that are included with Struts./li
  /ul
  
  pThe struts 0.5 milestone API release is no longer supported.
 and has been removed as of Struts 1.1:/p
  ul
  /ul
  
/section
  
  
section name=What's New? href=New
  
  
  pThe following new features have been added to the basic controller
  framework (package codeorg.apache.struts.action/code):/p
  ul
  /ul
  
  pThe following new features have been added to the utility classes
  (package codeorg.apache.struts.util/code):/p
  ul
  /ul
  
  pThe following new features have been added to the
  emstruts-html/em custom tag library (package
  codeorg.apache.struts.taglib.html/code):/p
  ul
  /ul
  
  pThe following new features have been added to the
  emstruts-logic/em custom tag library (package
  codeorg.apache.struts.taglib.logic/code):/p
  ul
  /ul
  
  pThe following new features have been added to the
  emstruts-template/em custom tag library (package
  codeorg.apache.struts.taglib.template/code):/p
  ul
  /ul
  
  pThe following new features have been added to the Struts Documentation
  application (and corresponding contents on the Struts web 

Re: server-side, java-based validation rules for struts..

[Martin Cooper]

 Slightly more exact mechanics for registering the listeners are:
 1. Instantiate the form-bean
 2. Instantiate zero to many listeners
 3. Register each listener [...]

This sounds like it could be an expensive process to be going through on
each request. I think you'd want to arrange for the listeners to be
cacheable (by Struts) so that step 2 can be performed either at startup time
or on first hit for a given listener.

--
Martin Cooper


- Original Message -
From: Cook, Levi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 21, 2001 8:20 AM
Subject: RE: server-side, java-based validation rules for struts..


 Yes, the end result is ActionForms with Listeners registered prior to the
 ActionServlet populating our form with the users request values.

 Slightly more exact mechanics for registering the listeners are:
 1. Instantiate the form-bean
 2. Instantiate zero to many listeners
 3. Register each listener using one of following bean method naming
 conventions:
addPropertyNameVetoableChangeListener(VetoableChangeListener
listener)
addVetoableChangeListener(String propertyName, VetoableChangeListener
 listener)
addVetoableChangeListener(VetoableChangeListener listener)

 A key abstraction here, is that neither object ever has an explicit
 reference to the other. Said another way this provides loose coupling
 between our action forms and their listeners. This supports the struts as
a
 framework concept by allowing the following:

 1. The number (zero to many) of listeners may be unknown at compile-time,
 and can vary throughout run-time.

 2. Listener and form objects neet to be loosely coupled becuase we have no
 way of predicting all the Listeners (eg. Validations) users could be
 interested in.


 Abstraction sure seems difficult to explain sometimes, thanks again for
 helping me refine my explanation.

 Levi


  -Original Message-
  From: Jonathan [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, June 21, 2001 9:10 AM
  To: [EMAIL PROTECTED]
  Subject: Re: server-side, java-based validation rules for struts..
 
 
  So you are saying that when an ActionForm is instantiated its
  associated listener(s) get shoved in (read registered) via
  a set method on the ActionForm, and the Listener actually does
  the registering of itself in its constructor or something.
 
  So what you have is a bunch of ActionsForms with their
  listeners already registered.  Did I get it?
 
 
  - Original Message -
  From: Levi Cook [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Thursday, June 21, 2001 11:44 AM
  Subject: Re: server-side, java-based validation rules for struts..
 
 
   I guess that's the critical part, eh-- sorry for the hand-waving :)
  
   At this point, I see the Struts controller coordinating
  these rules,
  based
   on the contents of struts-config.xml:
   1. Instantiation of our form-bean as needed (no real
  change here).
   2. Instantiation of optional change-listeners*
  associated with our
  form.
   (peek at the xml fragment below)
   3. Now, it can register the change-listener (aka
   VetoableChangeListener), with our new form-bean.
   note: addPropertyNameVetoableChangeListener
removePropertyNameVetoableChangeListener
   adhere to a naming pattern established by the
  JavaBeans spec.
   for more on this, see the last section on this page:
  
  
 

http://java.sun.com/docs/books/tutorial/javabeans/properties/constrained.htm
 l
  
   Assuming that this is all happened smoothly, which I think
  is pretty safe,
   that leaves the following main question:
   -- What happens when Struts begins to populate our action form?
  
   A. Nothing, our users suddendly started getting everything
  right, so our
   Validators never complain about their input anymore.
   B. Our, the more probable route... our Validators start throwing
   PropertyVetoExceptions because our user's aren't any better
  at answering
   these questions than we are :)
  
   This point introduces the next responsibily I planned on handing the
   struts-controller: handling PropertyVetoExceptions. In
  short, I'd like it
  to
   basically turn these exceptions into ActionErrors for us.
  
   Hope this sounds a little clearer, thanks for the
  feedback-- I think it
   greatly influences the ideas quality.
  
   Regards,
   Levi Cook
  
 struts-config
   !-- etc.. --
   form-bean name=myCCForm type=MyCCForm
 change-listener
 property=creditCard
 type=CreditCardValidator
 /
   /form-bean
   !-- etc.. --
 /struts-config
  
   - Original Message -
   From: Jonathan Asbell [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]
   Sent: Thursday, June 21, 2001 4:42 AM
   Subject: Re: server-side, java-based validation rules for struts..
  
  
Levi, you lost me somewhere in your explanation from
  .now have to
account for interacting with Struts-- That's where I see

cvs commit: jakarta-struts/doc index.xml

[rleland]

rleland 01/06/23 21:55:08

  Modified:doc  index.xml
  Log:
Correct typo in index.xml  Bugzilla 2205
   submitted by  [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.7   +2 -3  jakarta-struts/doc/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/index.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- index.xml 2001/06/15 23:35:40 1.6
  +++ index.xml 2001/06/24 04:55:08 1.7
  @@ -58,10 +58,10 @@
 changes, since the Struts 1.0-beta-3 release./p
   
 hr width=75%/
  -  
  +
 pYou can acquire interim binary and source distributions of Struts from the
 following locations:/p
  -  
  +
 ul
 liDownload the source directly via
 a href=http://jakarta.apache.org/getinvolved/cvsindex.html;
  @@ -111,7 +111,6 @@
 ul
 listrongSTRUTS-USER Mailing List/strong - Subscribe to this list
 to communicate with other developers that are using
  -  mailing list to communicate with other developers that are using
 Struts for their own applications, including questions about the
 installation of Struts, and the usage of particular Struts features.
 [a href=mailto:[EMAIL PROTECTED];Subscribe/a]