Re: Where is Struts 2 going?

2003-09-21 Thread Craig R. McClanahan 
On Sun, 21 Sep 2003, Peter A. Pilgrim wrote:

> Date: Sun, 21 Sep 2003 11:22:12 +0100
> From: Peter A. Pilgrim <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Where is Struts 2 going?
>
> Ted Husted wrote:
> > I working on something similar right now too, but using the FormProc
> > package. I believe that we should represent entire input form in XML,
> > including things like the default control type and field labels, and so
> >  forth, along with prompts, error messages, validations, and type
> > conversions. Ideally, we should be able to write a default form just by
> > reference to an XML element.
> >
> > What I like about FormProc is that is not focussed on JavaBeans, but on
> > the process of validating a list of parameters against a form definition
> > and then transferring the validated properties to some target object.
> > The object can also be a Map, which makes for a very nifty hand-off to
> > something like a Context. =:)
> >
> > In fact, expanding on the DynaForm idea, it might also be possible to
> > create a type-safe Context backed by a XML-configured form object. We
> > could then use the same XML document on both layers. On the presentation
> > layer, it can generate and/or validate the data-entry form. On the
> > business layer, it can define the properties expected by a Context.
> >
> > Of course, this is much like what we've been talking about doing for the
> > Validator, but right now the emphasis there seems to be on the JavaBean
> > and moving away from the form, where I believe we should be emphasizing
> > the form and moving away from (pure) JavaBeans.
> >
> Ted
>
> You lost me over the architecture.
> What I dont understand is that the current browsers are communicating
> HTML on HTTP. So how in the first do you get XML in the front end?
> Are proposing that there are new types of browsers that communicate
> exclusively XML over HTTP?
>

Just as a for-instance, any XForms based client will do exactly this.  But
from a Struts perspective, our goal should be to be agnostic to such
choices in terms of the basic controller framework.

> If so then it makes for interesting future, where the HTTP request
> representing a HMTL Form for example, a POST method, is a XML document
> and the output is XML.
>
>
>

Craig


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where is Struts 2 going?

2003-09-21 Thread Craig R. McClanahan 
On Sun, 21 Sep 2003, Peter A. Pilgrim wrote:

> Date: Sun, 21 Sep 2003 11:15:38 +0100
> From: Peter A. Pilgrim <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Where is Struts 2 going?
>
> Craig R. McClanahan wrote:
> > On Tue, 16 Sep 2003, Mete Kural wrote:
> >
> --///--
>
> > The best way to get involved would be to check out CVS sources for both
> > jakarta-struts and jakarta-commons-sandbox, become familiar with the code
> > referenced above, and start making suggestions and improvements.  A really
> > good starting point would be portlet-specific implementations of all the
> > commands that currently have only servlet-specific implementations.
> >
> I found the nightly cvs builds, but would rather grab updates via CVS.
> What is the CVS checkout module called for commons chain?

It's in jakarta-commons-sandbox.

Craig


> In the past I can do
>
> % cvs -d:pserver:[EMAIL PROTECTED]:/home/cvspublic checkout jakarta-struts
>
> but the following fails
>
> % cvs -d:pserver:[EMAIL PROTECTED]:/home/cvspublic checkout commons-chain
> cvs server: cannot find module `commons-chain' - ignored
> cvs [checkout aborted]: cannot expand modules
>
> TIA
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/contrib/struts-chain/src/java/org/apache/struts/chain/legacy CatalogConfiguratorPlugIn.java

2003-09-21 Thread husted 
husted  2003/09/21 21:00:22

  Modified:contrib/struts-chain/src/java/org/apache/struts/chain/legacy
CatalogConfiguratorPlugIn.java
  Log:
  JavaDoc fix.
  
  Revision  ChangesPath
  1.4   +4 -4  
jakarta-struts/contrib/struts-chain/src/java/org/apache/struts/chain/legacy/CatalogConfiguratorPlugIn.java
  
  Index: CatalogConfiguratorPlugIn.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-chain/src/java/org/apache/struts/chain/legacy/CatalogConfiguratorPlugIn.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- CatalogConfiguratorPlugIn.java31 Aug 2003 21:53:00 -  1.3
  +++ CatalogConfiguratorPlugIn.java22 Sep 2003 04:00:21 -  1.4
  @@ -81,7 +81,7 @@
   
   /**
* CatalogConfiguratorPlugIn looks up the current
  - * Catalog stored under the Constants.CATALOG_KEY
  + * Catalog stored under the Constants.CATALOG_ATTR
* context attribute (creating an empty one if necessary), and adds new
* chain definitions from one of the following two sources (only one of these
* properties should be configured for a particular instance of this
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where is Struts 2 going?

2003-09-21 Thread Ted Husted 
Sorry to confuse you, Peter. Apparently, I'm not being clear.

FormProc is a SourceForge project . 
It's a mature library that is used by the JPublish Framework and 
distributed under the Apache License. It is designed to capture a list 
of parameters, validate those parameters, and if valid, transfer the 
parameter to a target object. The target can be an arbitrary JavaBean or 
a Map. The list can be any List or extracted from a HttpServletRequest.

XML is only used as a deployment descriptor. I'm not talking about using 
a XML DOM in the workflow, only to use XML to define a more complete 
Form object than we see today in FormProc or the Validator.

I'm using FormProc in my current project now, along with Commons Chain 
and Maverick, and everything is lining up quite nicely. Soon, I'll port 
the work into a Struts context where it will be easier to see what I'm 
talking about.

Right now, I'm using FormProc to validate the input parameters and 
convert them directly into a target object (a Commons Chain context). If 
the validation fails, my Velocity markup is displaying the original 
input from a list maintained by FormProc. If the validation succeeds, 
the target object is passed down to the business layer, validated, 
converted, and ready to use.

In many ways, this approach is similar to where JavaServer Faces is 
going. The components have their own String cache, so you don't have to 
define one. Likewise, FormProc has its own input cache.

The missing piece right now is that I need to make the Converters 
bi-directional. When a target object comes back from the business layer, 
I'd like to hand it to the form object to convert back to a list of 
Strings. So if I have "12/31/2003" being converted to a Date, I can get 
a Date converted back to "12/31/2003", without writing any additional code.

The only place XML comes in is in defining the form object (a POJO). 
Right now, FormProc has the same sort of internal object that Validator 
would use, with the addition of a Converter property. I believe it would 
be useful to extend that object to include all the other properties we 
like to use in forms, like a label, a usage hint, an initial value, a 
default control type, and, in the case of a HTML control, the script 
triggers and so forth.

The goal being that we could hand the form object to a JSP tag, 
Velocimacro, or whatever, and have it render the markup for a default 
input form. Of course, in many case, a custom form might be needed 
instead, but it would at least be nice to have the option =:0) And, of 
course, you could define as few or as many of these properties as needed.

This is the same general direction JavaServer Faces is going with the 
DataGrid, but I'd like to generalize it for use with any type of input 
form.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22700] - Add check for nonexistent form field in focus javascript

2003-09-21 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22700

Add check for nonexistent form field in focus javascript

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
Summary|Setting focus to a form |Add check for nonexistent
   |field that doesn't exist|form field in focus
   |causes javascript error on  |javascript
   |loading the page|

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 17368] - multiple does not populate form bean under jdk1.3

2003-09-21 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17368

 multiple does not populate form bean under jdk1.3

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16272] - Validator doesn't support resource bundles

2003-09-21 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16272

Validator doesn't support resource bundles

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-09-22 01:53 ---
Fixed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/web/example/WEB-INF validation.xml

2003-09-21 Thread dgraham 
dgraham 2003/09/21 18:50:01

  Modified:web/example/WEB-INF validation.xml
  Log:
  Removed unsupported bundle attribute for PR# 16272.
  
  Revision  ChangesPath
  1.9   +2 -3  jakarta-struts/web/example/WEB-INF/validation.xml
  
  Index: validation.xml
  ===
  RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/validation.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- validation.xml25 May 2003 22:51:20 -  1.8
  +++ validation.xml22 Sep 2003 01:50:01 -  1.9
  @@ -36,8 +36,7 @@
   
   
   
  +depends="required, minlength,maxlength">
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22971] - Bugs in MessageTag and MessageResources

2003-09-21 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22971

Bugs in MessageTag and MessageResources

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-09-22 01:50 ---
The issue with  taking Object parameters is discussed in bug #11852.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23005] - html:messages tag does not gracefully handle missing message resource keys.

2003-09-21 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23005

html:messages tag does not gracefully handle missing message resource keys.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-09-22 01:42 ---
Fixed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2003-09-21 Thread dgraham 
dgraham 2003/09/21 18:39:19

  Modified:src/share/org/apache/struts/taglib/html MessagesTag.java
  Log:
  doAfterBody() treats missing message keys the same as
  doStartTag().  If the message is null, it's removed from the
  PageContext, else it's set as usual.  This finishes the fix
  for PR# 23005.
  
  Revision  ChangesPath
  1.24  +12 -8 
jakarta-struts/src/share/org/apache/struts/taglib/html/MessagesTag.java
  
  Index: MessagesTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/MessagesTag.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- MessagesTag.java  9 Sep 2003 03:55:35 -   1.23
  +++ MessagesTag.java  22 Sep 2003 01:39:19 -  1.24
  @@ -252,10 +252,10 @@
   report.getKey(),
   report.getValues());
   
  -if (msg != null) {
  -pageContext.setAttribute(id, msg);
  -} else {
  +if (msg == null) {
   pageContext.removeAttribute(id);
  +} else {
  +pageContext.setAttribute(id, msg);
   }
   
   if (header != null && header.length() > 0) {
  @@ -298,7 +298,11 @@
   report.getKey(),
   report.getValues());
   
  -   pageContext.setAttribute(id, msg);
  +   if (msg == null) {
  +   pageContext.removeAttribute(id);
  +   } else {
  +   pageContext.setAttribute(id, msg);
  +   }
   
  return (EVAL_BODY_TAG);
   } else {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23020] - simple page action mappings within modules to jsp's not working

2003-09-21 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23020

simple page action mappings within modules to jsp's not working





--- Additional Comments From [EMAIL PROTECTED]  2003-09-22 01:29 ---
Does this happen using the standard RequestProcessor instead of Tiles?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22467] - Sorting enhancements for LabelValueBean

2003-09-21 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22467

Sorting enhancements for LabelValueBean

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-09-22 01:21 ---
Fixed.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/src/share/org/apache/struts/util LabelValueBean.java

2003-09-21 Thread dgraham 
dgraham 2003/09/21 18:18:03

  Modified:src/share/org/apache/struts/util LabelValueBean.java
  Log:
  Implement Comparable interface for PR# 22467.
  
  Revision  ChangesPath
  1.7   +36 -6 
jakarta-struts/src/share/org/apache/struts/util/LabelValueBean.java
  
  Index: LabelValueBean.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/LabelValueBean.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- LabelValueBean.java   4 Jul 2003 18:26:19 -   1.6
  +++ LabelValueBean.java   22 Sep 2003 01:18:03 -  1.7
  @@ -62,19 +62,37 @@
   package org.apache.struts.util;
   
   import java.io.Serializable;
  +import java.util.Comparator;
   
   /**
* A simple JavaBean to represent label-value pairs. This is most commonly used
* when constructing user interface elements which have a label to be displayed
* to the user, and a corresponding value to be returned to the server. One
* example is the  tag.
  - *
  + * 
  + * 
  + * Note: this class has a natural ordering that is inconsistent with equals.
  + * 
  + * 
* @author Craig R. McClanahan
* @author Martin F N Cooper
* @author David Graham
  + * @author Paul Sundling
* @version $Revision$ $Date$
*/
  -public class LabelValueBean implements Serializable {
  +public class LabelValueBean implements Comparable, Serializable {
  +
  +/**
  + * Comparator that can be used for a case insensitive sort of 
  + * LabelValueBean objects.
  + */
  +public static final Comparator CASE_INSENSITIVE_ORDER = new Comparator() {
  + public int compare(Object o1, Object o2) {
  + String label1 = ((LabelValueBean) o1).getLabel();
  + String label2 = ((LabelValueBean) o2).getLabel();
  + return label1.compareToIgnoreCase(label2);
  + }
  +};
   
   
   // --- Constructors
  @@ -132,6 +150,18 @@
   
   // - Public Methods
   
  + /**
  +  * Compare LabelValueBeans based on the label, because that's the human 
  + * viewable part of the object.
  +  * @see Comparable
  +  */
  + public int compareTo(Object o) {
  + // Implicitly tests for the correct type, throwing 
  +// ClassCastException as required by interface
  + String otherLabel = ((LabelValueBean) o).getLabel();
  +
  + return this.getLabel().compareTo(otherLabel);
  + }
   
   /**
* Return a string representation of this object.
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22912] - ActionMessages.getSortedProperties() needed

2003-09-21 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22912

ActionMessages.getSortedProperties() needed





--- Additional Comments From [EMAIL PROTECTED]  2003-09-22 01:06 ---
I don't think adding this method to ActionMessages is appropriate.  Users of
ActionMessages (ie. ) should probably do the sorting instead.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22228] - Action.saveErrors() should save empty ActionErrors objects

2003-09-21 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8

Action.saveErrors() should save empty ActionErrors objects

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-09-21 23:15 ---
I agree with Steve and consider the current behavior a nice feature.  You can
create an ActionErrors object, conditionally add ActionError objects to it, and
call saveErrors() at the end of the validation (or right before you forward to
the error page).  The saveErrors() code handles the case of an empty
ActionErrors object for you which makes the validation code easier to write.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where is Struts 2 going?

2003-09-21 Thread Peter A. Pilgrim 
Ted Husted wrote:
The browsers universally accept HTML documents as output over HTTP, but 
they do not input HTML or XML, but a simple list of parameters. We've 
been experimenting with transforming that list into JavaBeans, and I'm 
not sure that the experiment has succeeded. It made writing tags more 
convenient but maintaining the JavaBeans has been costly. Especially 
when, for a lot of teams, the formbeans correspond 1:1 with their model 
beans, except for a few native parameters.

The list being the CGI parameters ( terminology from my PERL/ CGI days /
 pre-servlet ) on the servlet request.
I assume that the JavaBeans are capturing subset of the servlet request
parameter of which they can be an arbitary size. Consider a loginform
bean with only username and password, I would argue that you only
want to capture these two CGI parameter. You can define a dyna bean
for this two. So I disagree that the model design is wrong.
Following the Struts perspective, the Command Validator is designed to 
validate a JavaBean. But, when the input is coming in from HTTP, I don't 
really want a  JavaBean. I want to validate the parameters and, if they 
pass, then I might want to put them on a JavaBean or a Map, or whatever 
my business layer expects. If validation fails, I don't really want to 
display the object I'm validating (following the Validator perspective), 
I want to redisplay the original input.

What I really want to do is take a list of parameters, validate the 
parameters, and if they pass, set them to an arbitrary target object. I 
also don't want to catch every matching parameter, I just want the ones 
I need for this workflow (or "form"). And, if validation fails, I want 
to redisplay the original input.
So what you want to is not instantiate or populate a form bean, but
transfer the CGI parameters into an XML document object. You want
to validate that XML document and then pass that doc to the business
tier layer. You are assuming in your business delegate or whereever
you have an XML document to EJB or JDO or whatever ValueObject
transformation. In other words the XML doc is used to instantiate
a business value object and populate it.
I can see that this is flawed, because if you are calling several
business tier methods with your XML doc then every call to the
business tier involves a transformation. Is this correct? If it is not
then you must cache this transformation somewhere?
Secondly you need to alter the taglibs for struts. The standard tags
understand a form bean and property. Are you suggesting that the
tags are changed or modified to support XPath syntax.
	

Which is what FormProc does. =:0)

Where is this FormProc? What is the URL?

I had to patch the original input list so that it could be exposed. Next 
I want to make the stock converters bi-directional. So, if it's supposed 
to take a String like "12/31/2003" and turn it into a Date, I can also 
hand it a Date and get back a String like "12/31/2003". This way I can 
pass my Model object to the form and get a list of String parameters to 
expose to the server page.
Are you going against advice in your book here? I am sure that you
recommend not exposing the model object in your form bean, because
some one could fake a primary key or data. For example if you
store a value object directly in a action form you then it might
expose "employeeId" and "salaryId" unless to make provision
to protect these properties.
Also some field in the form bean should be always be Strings and
we should perform the conversion between String and Date in the
form bean. But if we dont have a form bean, but a list of CGI
parameters how do we do this? Is this what your FormProc does?
Sounds to me like a fancy hash map of sorts.
When I mentioned XML, I mean define a object deployment descriptor in 
XML, same as the struts-config.xml, web.xml, and validator.xml. But, 
neither Validator or FormProc goes far enough. I want a form object that 
describes everything about the form, so that I could actually hand that 
object to a tag or Velocimacro or something and have it render a default 
HTML input form for me, just as we hand it the output from that form so 
that it can tender a default validation.

Sounds to me like inject intermediate language that is
look and feel neutral, between the Struts Action and the view
(JSP or Velcity or otherwise)
----

--
Peter Pilgrim
   __ _ _ _
  / //__  // ___// ___/   +  Serverside Java
 / /___/ // /__ / /__ +  Struts
/ // ___// ___// ___/ +  Expresso Committer
 __/ // /__ / /__ / /__   +  Independent Contractor
/___///////   +  Intrinsic Motivation
On Line Resume
   ||
   \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Bug report for Struts [2003/09/21]

2003-09-21 Thread bugzilla 
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  866|New|Enh|2001-03-06|Clean Way to Add Parameters to Redirecting Forward|
| 3202|Opn|Enh|2001-08-21|OptionsTag.doEndTag -> calls method to populate se|
| 5395|Opn|Enh|2001-12-12|ActionContext class   |
| 5566|New|Enh|2001-12-21|html:link bug |
| 5739|Opn|Enh|2002-01-08|Struts fails silently in too many places  |
| 5937|New|Enh|2002-01-21|html:form trims all extensions|
| 6686|New|Enh|2002-02-26|make "action" attribute of html:form tag optional |
| 6847|Opn|Enh|2002-03-04|Multiple file upload not possible due to MultiPart|
| 7062|Opn|Enh|2002-03-12|nested:iterate and logic:iterate -- add odd/even a|
| 7892|Opn|Enh|2002-04-09|Using Multiple Resource Bundles for an Application|
| 7902|Opn|Enh|2002-04-10|The exception handling declaration in the DTD does|
| 9088|Opn|Enh|2002-05-15|FormTag.getActionMappingURL() assumes 1 servlet ma|
| 9616|New|Enh|2002-06-05|Some more Struts docs |
| 9748|New|Enh|2002-06-10|attribute labelKeyProperty for Options tag|
| 9949|Opn|Enh|2002-06-18|Suggest, a 'multiple' attribute for the  ta|
|13521|New|Enh|2002-10-11|CombinedDispatchAction|
|13544|Opn|Enh|2002-10-11|[exception] support contextRelative paths |
|13565|Opn|Enh|2002-10-12|To "errors", add prefix, suffix, header, footer at|
|13638|Opn|Enh|2002-10-15|add Config Factory|
|13809|Opn|Enh|2002-10-21|Struts configuration is not validated after use   |
|14068|Opn|Enh|2002-10-29|Why can't I use forwards with exception elements i|
|14071|Opn|Enh|2002-10-29|Need clear info on which Struts attributes produce|
|14183|Opn|Enh|2002-11-01|html:img does not support forward attribute   |
|14471|Opn|Nor|2002-11-12|validator-rules.xml JavaScript fails when field no|
|14749|Opn|Enh|2002-11-21|Action "input" not starting with '/' and not a val|
|15805|Opn|Enh|2003-01-05|Enhance ModuleException to allow getting chained E|
|15912|Opn|Enh|2003-01-09|Client-side validation fails if not all form-field|
|15921|Opn|Enh|2003-01-09|Allow relative actions in struts-config.xml   |
|16074|New|Enh|2003-01-14|html:form uses 'action' not 'input' to select mapp|
|16272|Opn|Nor|2003-01-20|Validator doesn't support resource bundles|
|16401|New|Enh|2003-01-24|ActionValidatorUtil   |
|16603|Opn|Enh|2003-01-30| forwardPattern should support differe|
|16634|New|Enh|2003-01-31|reuiredif ignores missing property|
|16708|New|Enh|2003-02-03|I18N on ActionForwards|
|16783|Opn|Nor|2003-02-04|stop and start ( restart) application |
|16792|Ass|Enh|2003-02-05|Migrate to commons-resources for message resources|
|16804|New|Enh|2003-02-05|html:text tag has no filter attribute |
|16810|Opn|Nor|2003-02-05|Javascript Date validation for datePattern not sup|
|16814|New|Enh|2003-02-05|Add a generalized utililty class to expose informa|
|16946|Opn|Nor|2003-02-10|SwitchAction not setting context properly for tile|
|16971|New|Enh|2003-02-11|"multiple" attribute on select tag should not rend|
|17368|Opn|Nor|2003-02-25| multiple does not populate form bean|
|17449|New|Enh|2003-02-26|Allow relative URL in action attribute of  custom tag to write forms' proper|
|18022|New|Enh|2003-03-14|HttpSessionBindingListener.valueUnbound() called o|
|18032|Opn|Enh|2003-03-16| tag appending session doesn't work with|
|18107|New|Enh|2003-03-18|contextRelative enhancement to  tag  |
|18111|New|Enh|2003-03-18|contextRelative enhancement to  t|
|18221|New|Enh|2003-03-21|Move custom taglibs into their own jar/distributio|
|18237|Opn|Nor|2003-03-21|Tiles excessive memory usage  |
|18289|New|Enh|2003-03-24|Dynamic Message Resources |
|18293|New|Enh|2003-03-24|Loading language files does not use Resource Bundl|
|18370|New|Enh|2003-03-26|generate MANIFEST.MF with a

Re: Where is Struts 2 going?

2003-09-21 Thread Ted Husted 
The browsers universally accept HTML documents as output over HTTP, but 
they do not input HTML or XML, but a simple list of parameters. We've 
been experimenting with transforming that list into JavaBeans, and I'm 
not sure that the experiment has succeeded. It made writing tags more 
convenient but maintaining the JavaBeans has been costly. Especially 
when, for a lot of teams, the formbeans correspond 1:1 with their model 
beans, except for a few native parameters.

Following the Struts perspective, the Command Validator is designed to 
validate a JavaBean. But, when the input is coming in from HTTP, I don't 
really want a  JavaBean. I want to validate the parameters and, if they 
pass, then I might want to put them on a JavaBean or a Map, or whatever 
my business layer expects. If validation fails, I don't really want to 
display the object I'm validating (following the Validator perspective), 
I want to redisplay the original input.

What I really want to do is take a list of parameters, validate the 
parameters, and if they pass, set them to an arbitrary target object. I 
also don't want to catch every matching parameter, I just want the ones 
I need for this workflow (or "form"). And, if validation fails, I want 
to redisplay the original input.

Which is what FormProc does. =:0)

I had to patch the original input list so that it could be exposed. Next 
I want to make the stock converters bi-directional. So, if it's supposed 
to take a String like "12/31/2003" and turn it into a Date, I can also 
hand it a Date and get back a String like "12/31/2003". This way I can 
pass my Model object to the form and get a list of String parameters to 
expose to the server page.

When I mentioned XML, I mean define a object deployment descriptor in 
XML, same as the struts-config.xml, web.xml, and validator.xml. But, 
neither Validator or FormProc goes far enough. I want a form object that 
describes everything about the form, so that I could actually hand that 
object to a tag or Velocimacro or something and have it render a default 
HTML input form for me, just as we hand it the output from that form so 
that it can tender a default validation.

-Ted.

Peter A. Pilgrim wrote:
Ted Husted wrote:

I working on something similar right now too, but using the FormProc 
package. I believe that we should represent entire input form in XML, 
including things like the default control type and field labels, and 
so  forth, along with prompts, error messages, validations, and type 
conversions. Ideally, we should be able to write a default form just 
by reference to an XML element.

What I like about FormProc is that is not focussed on JavaBeans, but 
on the process of validating a list of parameters against a form 
definition and then transferring the validated properties to some 
target object. The object can also be a Map, which makes for a very 
nifty hand-off to something like a Context. =:)

In fact, expanding on the DynaForm idea, it might also be possible to 
create a type-safe Context backed by a XML-configured form object. We 
could then use the same XML document on both layers. On the 
presentation layer, it can generate and/or validate the data-entry 
form. On the business layer, it can define the properties expected by 
a Context.

Of course, this is much like what we've been talking about doing for 
the Validator, but right now the emphasis there seems to be on the 
JavaBean and moving away from the form, where I believe we should be 
emphasizing the form and moving away from (pure) JavaBeans.

Ted

You lost me over the architecture.
What I dont understand is that the current browsers are communicating
HTML on HTTP. So how in the first do you get XML in the front end?
Are proposing that there are new types of browsers that communicate
exclusively XML over HTTP?
If so then it makes for interesting future, where the HTTP request 
representing
a HMTL Form for example, a POST method, is a XML document and the output
is XML.


--
Ted Husted,
  Junit in Action  - ,
  Struts in Action - ,
  JSP Site Design  - .
"Get Ready, We're Moving Out!!" - 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Where is Struts 2 going?

2003-09-21 Thread Andrew Hill 

If so then it makes for interesting future, where the HTTP request
representing
a HMTL Form for example, a POST method, is a XML document and the output
is XML.


This is the approach XForms takes.

-Original Message-
From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED]
Sent: Sunday, 21 September 2003 18:22
To: Struts Developers List
Subject: Re: Where is Struts 2 going?


Ted Husted wrote:
> I working on something similar right now too, but using the FormProc
> package. I believe that we should represent entire input form in XML,
> including things like the default control type and field labels, and so
>  forth, along with prompts, error messages, validations, and type
> conversions. Ideally, we should be able to write a default form just by
> reference to an XML element.
>
> What I like about FormProc is that is not focussed on JavaBeans, but on
> the process of validating a list of parameters against a form definition
> and then transferring the validated properties to some target object.
> The object can also be a Map, which makes for a very nifty hand-off to
> something like a Context. =:)
>
> In fact, expanding on the DynaForm idea, it might also be possible to
> create a type-safe Context backed by a XML-configured form object. We
> could then use the same XML document on both layers. On the presentation
> layer, it can generate and/or validate the data-entry form. On the
> business layer, it can define the properties expected by a Context.
>
> Of course, this is much like what we've been talking about doing for the
> Validator, but right now the emphasis there seems to be on the JavaBean
> and moving away from the form, where I believe we should be emphasizing
> the form and moving away from (pure) JavaBeans.
>
Ted

You lost me over the architecture.
What I dont understand is that the current browsers are communicating
HTML on HTTP. So how in the first do you get XML in the front end?
Are proposing that there are new types of browsers that communicate
exclusively XML over HTTP?

If so then it makes for interesting future, where the HTTP request
representing
a HMTL Form for example, a POST method, is a XML document and the output
is XML.


--
Peter Pilgrim
__ _ _ _
   / //__  // ___// ___/   +  Serverside Java
  / /___/ // /__ / /__ +  Struts
 / // ___// ___// ___/ +  Expresso Committer
  __/ // /__ / /__ / /__   +  Independent Contractor
 /___///////   +  Intrinsic Motivation
On Line Resume
||
\\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where is Struts 2 going?

2003-09-21 Thread Peter A. Pilgrim 
Ted Husted wrote:
I working on something similar right now too, but using the FormProc 
package. I believe that we should represent entire input form in XML, 
including things like the default control type and field labels, and so 
 forth, along with prompts, error messages, validations, and type 
conversions. Ideally, we should be able to write a default form just by 
reference to an XML element.

What I like about FormProc is that is not focussed on JavaBeans, but on 
the process of validating a list of parameters against a form definition 
and then transferring the validated properties to some target object. 
The object can also be a Map, which makes for a very nifty hand-off to 
something like a Context. =:)

In fact, expanding on the DynaForm idea, it might also be possible to 
create a type-safe Context backed by a XML-configured form object. We 
could then use the same XML document on both layers. On the presentation 
layer, it can generate and/or validate the data-entry form. On the 
business layer, it can define the properties expected by a Context.

Of course, this is much like what we've been talking about doing for the 
Validator, but right now the emphasis there seems to be on the JavaBean 
and moving away from the form, where I believe we should be emphasizing 
the form and moving away from (pure) JavaBeans.

Ted

You lost me over the architecture.
What I dont understand is that the current browsers are communicating
HTML on HTTP. So how in the first do you get XML in the front end?
Are proposing that there are new types of browsers that communicate
exclusively XML over HTTP?
If so then it makes for interesting future, where the HTTP request representing
a HMTL Form for example, a POST method, is a XML document and the output
is XML.
--
Peter Pilgrim
   __ _ _ _
  / //__  // ___// ___/   +  Serverside Java
 / /___/ // /__ / /__ +  Struts
/ // ___// ___// ___/ +  Expresso Committer
 __/ // /__ / /__ / /__   +  Independent Contractor
/___///////   +  Intrinsic Motivation
On Line Resume
   ||
   \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Where is Struts 2 going?

2003-09-21 Thread Peter A. Pilgrim 
Craig R. McClanahan wrote:
On Tue, 16 Sep 2003, Mete Kural wrote:

--///--

The best way to get involved would be to check out CVS sources for both
jakarta-struts and jakarta-commons-sandbox, become familiar with the code
referenced above, and start making suggestions and improvements.  A really
good starting point would be portlet-specific implementations of all the
commands that currently have only servlet-specific implementations.
I found the nightly cvs builds, but would rather grab updates via CVS.
What is the CVS checkout module called for commons chain?
In the past I can do
% cvs -d:pserver:[EMAIL PROTECTED]:/home/cvspublic checkout jakarta-struts

but the following fails

% cvs -d:pserver:[EMAIL PROTECTED]:/home/cvspublic checkout commons-chain
cvs server: cannot find module `commons-chain' - ignored
cvs [checkout aborted]: cannot expand modules
TIA

--
Peter Pilgrim
   __ _ _ _
  / //__  // ___// ___/   +  Serverside Java
 / /___/ // /__ / /__ +  Struts
/ // ___// ___// ___/ +  Expresso Committer
 __/ // /__ / /__ / /__   +  Independent Contractor
/___///////   +  Intrinsic Motivation
On Line Resume
   ||
   \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]