date:20031217

husted  2003/12/17 12:48:30

  jakarta-struts/contrib/struts-jericho - New directory

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

cvs commit: jakarta-struts/contrib/struts-jericho README.txt project.properties project.xml

husted  2003/12/17 12:49:28

  Added:   contrib/struts-jericho README.txt project.properties
project.xml
  Log:
  Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
  
  Revision  ChangesPath
  1.1  jakarta-struts/contrib/struts-jericho/README.txt
  
  Index: README.txt
  ===
  Jericho is a whiteboard proposal describing one possible implementation of Struts 
2.x.
  
  Since Struts 2.x is slated as a revolution, the Apache practice is to assign a 
codename to a proposal until the Community comes to a consensus.
  
  This proposal is called Jericho since it tries to tear-down the walls within the 
Struts architecture. Jericho proposes to open-up Struts by
  
  * Declaring interfaces for all core components.
  
  * Providing working base implementations for all core components.
  
  * Encapsulating alll path references within Location objects (fka 
ActionForwards)and referring only to Locations from all other objects.
  
  * Providing additional extension points from core components so that the Inversion 
of Control pattern is fully realized.
  
  * Providing POJO signatures that encapsulate HTTP classes so that applications can 
be freed of HTTP semantics, if so desired.
  
  * Retain optional access to HTTP objects so that applications can be free to do 
whatever they need to do.
  
  -Backward Compatibility-
  
  Jericho is a revolution and backward compatability with prior versions of Struts is 
not the prime consideration. However, care is being taken to create a clear migration 
path, where practible, so that Jericho is available to the widest community possible.
  
  _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 
1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, 
such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
  
  A second alternative to explore is to provide an alternate configuration loader that 
would map the Struts 1.2 elements to Struts Jericho objects at initialization.
  
  _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
provided. These classes will provide the Struts 1.2.x behavior but also implement the 
Struts Jericho interfaces, so that the framework can use them interchangeably.
  
  These same techniques may be applied to provide adaptors for other frameworks, so as 
to make Struts Jericho available to the widest community possible.
  
  ###
  
  
  1.1  jakarta-struts/contrib/struts-jericho/project.properties
  
  Index: project.properties
  ===
  # ---
  # P R O J E C T  P R O P E R T I E S
  # ---
  
  compile.debug = on
  compile.optimize = off
  compile.deprecation = off
  
  maven.linkcheck.enable=true 
  
  # documentation properties
  maven.xdoc.date=left
  maven.xdoc.version=${pom.currentVersion}
  maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
  
  
  
  1.1  jakarta-struts/contrib/struts-jericho/project.xml
  
  Index: project.xml
  ===
  ?xml version=1.0 encoding=UTF-8?
  
  project
extend../project.xml/extend
nameJericho/name
idstruts-jericho/id
currentVersion0.1-dev/currentVersion
inceptionYear2003/inceptionYear
shortDescriptionStruts Jericho 2.x Whiteboard/shortDescription
description
Jericho is a whiteboard proposal describing one possible implementation of 
Struts 2.x.
Since Struts 2.x is slated as a revolution, the Apache practice is to assign 
a codename to a proposal
until the Community comes to a consensus.
This proposal is called Jericho since it tries to tear-down the walls within 
the Struts architecture.
/description
developers
  developer
nameTed Husted/name
idhusted/id
email[EMAIL PROTECTED]/email
organization/organization
  /developer
/developers
  
build
  unitTest
includes
  include**/*Test.java/include
/includes
  /unitTest
/build
  
  /project
  
  
  

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

cvs commit: jakarta-struts/contrib/struts-jericho/src - New directory

husted  2003/12/17 12:49:35

  jakarta-struts/contrib/struts-jericho/src - New directory

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

cvs commit: jakarta-struts/contrib/struts-jericho/src/conf - New directory

husted  2003/12/17 12:49:42

  jakarta-struts/contrib/struts-jericho/src/conf - New directory

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

cvs commit: jakarta-struts/contrib/struts-jericho/src/conf struts-jericho-config_2_0.dtd

husted  2003/12/17 12:50:35

  Added:   contrib/struts-jericho/src/conf
struts-jericho-config_2_0.dtd
  Log:
  Initial, working draft DTD for Struts-Jercho proposal. Still rough.
  
  Revision  ChangesPath
  1.1  
jakarta-struts/contrib/struts-jericho/src/conf/struts-jericho-config_2_0.dtd
  
  Index: struts-jericho-config_2_0.dtd
  ===
  !--
   DTD for the Struts Application Configuration File
  
   To support validation of your configuration file, include the following
   DOCTYPE element at the beginning (after the xml declaration):
  
   !DOCTYPE struts-config PUBLIC
 -//Apache Software Foundation//DTD Struts Configuration 1.2//EN
 http://jakarta.apache.org/struts/dtds/struts-jericho-config_2_0.dtd;
  
   $Id: struts-jericho-config_2_0.dtd,v 1.1 2003/12/17 20:50:35 husted Exp $
  --
  
  
  !-- == Defined Types = --
  
  
  !-- An Identifier is the name of a programming construct and must conform
   to the rules for identifiers in the Java language.
  --
  !ENTITY % Identifier CDATA
  
  
  !-- An AttributeName is the identifier of a page, request, session, or
   application scope attribute.
  --
  !ENTITY % AttributeName CDATA
  
  
  !-- A PropObject is the identifier of an object, such as a form,
   and also serves as the name of the corresponding scripting variable
   and the name of the attribute under which the object is accessed.
   Therefore, it must conform to the rules for an Identifier.
  --
  !ENTITY % PropObject CDATA
  
  
  !-- A Boolean is the string representation of a boolean (true or false)
   variable.
  --
  !ENTITY % Boolean (true|false)
  
  
  !-- A ClassName is the fully qualified name of a compiled class that is
   instantiated to provide the functionality of the enclosing element.
  --
  !ENTITY % ClassName CDATA
  
  
  !-- An Integer is a character string consisting solely of numeric digits,
   optionally preceeded by a minus sign, that can be converted to a
   32-bit integer.
  --
  !ENTITY % Integer CDATA
  
  
  !-- A Resource is a relative path, delimited by / characters, that
   defines the location of a resource relative to the location of the
   Struts configuration file itself.
  --
  !ENTITY % Resource #PCDATA
  
  
  !-- A PropName is the name of an object property, and must begin with
   a lower case letter and contain only characters that are legal in a
   identifier.
  --
  !ENTITY % PropName CDATA
  
  
  !-- A RequestPath is an application-relative URI path, beginning with a
   slash, that identifies a mapped resource (such as a server page or a
   servlet) within this web application.
  --
  !ENTITY % RequestPath CDATA
  
  
  !-- The name of a scope within which a object, such as a form handler, may be 
accessed.
  --
  !ENTITY % Scope (request|session|application)
  
  
  !-- == Top Level Elements  --
  
  
  !-- The struts-config element is the root of the configuration file
   hierarchy, and contains nested elements for all of the other
   configuration settings.
  --
  !ELEMENT struts-config (
   display-name?,
   description?,
   property*,
   catalog*,
   forms?,
   locations?,
   exceptions?,
   processors?,
   mappings?,
   bundles,
   plug-in*)
  
  !ATTLIST struts-config  id ID  #IMPLIED
  
  !-- The property element refers to the location of a properties file,
   relative to the Struts configuration file, that contains replacement
   variables to use when processing the elements. The properties defined
   can be referred to using the standard shell notation: ${property}.
  
   Properties can be used to avoid redundacy. For example, an often-used
   class name can be listed in the properties file:
  
   formHandler = app.struts.MyFormHandler
  
   and then referred to as the value for an attribute:
  
   handler = ${formHandler}
  
   The following attribute is defined:
  
   resourceThe path to the properties file, relative to the Struts
   Configuration file being processed.
  --
  !ELEMENT property
  !ATTLIST property   id  ID  #IMPLIED
  !ATTLIST property   resource%Resource;  #REQUIRED
  
  
  !-- The catalog element refers to the location of a Catalog file,
   relative to the Struts configuration file, that contains a registry
   of Command Chains that can be referred to in the command attributes
   of other elements.
  
   The following attribute is defined:
  
   resourceThe path to the Catalog file, relative to the Struts
   Configuration file being processed.
  --
  !ELEMENT property
  !ATTLIST property   id  ID

Struts 2.0 Discussion Forum

Is there one?  I have several ideas I'd like to toss into the discussion.

Don

On 17 Dec 2003 [EMAIL PROTECTED] wrote:

 husted  2003/12/17 12:49:28

   Added:   contrib/struts-jericho README.txt project.properties
 project.xml
   Log:
   Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.

   Revision  ChangesPath
   1.1  jakarta-struts/contrib/struts-jericho/README.txt

   Index: README.txt
   ===
   Jericho is a whiteboard proposal describing one possible implementation of Struts 
 2.x.

   Since Struts 2.x is slated as a revolution, the Apache practice is to assign a 
 codename to a proposal until the Community comes to a consensus.

   This proposal is called Jericho since it tries to tear-down the walls within the 
 Struts architecture. Jericho proposes to open-up Struts by

   * Declaring interfaces for all core components.

   * Providing working base implementations for all core components.

   * Encapsulating alll path references within Location objects (fka 
 ActionForwards)and referring only to Locations from all other objects.

   * Providing additional extension points from core components so that the 
 Inversion of Control pattern is fully realized.

   * Providing POJO signatures that encapsulate HTTP classes so that applications 
 can be freed of HTTP semantics, if so desired.

   * Retain optional access to HTTP objects so that applications can be free to do 
 whatever they need to do.

   -Backward Compatibility-

   Jericho is a revolution and backward compatability with prior versions of Struts 
 is not the prime consideration. However, care is being taken to create a clear 
 migration path, where practible, so that Jericho is available to the widest 
 community possible.

   _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the 
 Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a 
 tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.

   A second alternative to explore is to provide an alternate configuration loader 
 that would map the Struts 1.2 elements to Struts Jericho objects at initialization.

   _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
 provided. These classes will provide the Struts 1.2.x behavior but also implement 
 the Struts Jericho interfaces, so that the framework can use them interchangeably.

   These same techniques may be applied to provide adaptors for other frameworks, so 
 as to make Struts Jericho available to the widest community possible.

   ###


   1.1  jakarta-struts/contrib/struts-jericho/project.properties

   Index: project.properties
   ===
   # ---
   # P R O J E C T  P R O P E R T I E S
   # ---

   compile.debug = on
   compile.optimize = off
   compile.deprecation = off

   maven.linkcheck.enable=true

   # documentation properties
   maven.xdoc.date=left
   maven.xdoc.version=${pom.currentVersion}
   maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html



   1.1  jakarta-struts/contrib/struts-jericho/project.xml

   Index: project.xml
   ===
   ?xml version=1.0 encoding=UTF-8?

   project
 extend../project.xml/extend
 nameJericho/name
 idstruts-jericho/id
 currentVersion0.1-dev/currentVersion
 inceptionYear2003/inceptionYear
 shortDescriptionStruts Jericho 2.x Whiteboard/shortDescription
 description
 Jericho is a whiteboard proposal describing one possible implementation of 
 Struts 2.x.
 Since Struts 2.x is slated as a revolution, the Apache practice is to 
 assign a codename to a proposal
 until the Community comes to a consensus.
 This proposal is called Jericho since it tries to tear-down the walls 
 within the Struts architecture.
 /description
 developers
   developer
 nameTed Husted/name
 idhusted/id
 email[EMAIL PROTECTED]/email
 organization/organization
   /developer
 /developers

 build
   unitTest
 includes
   include**/*Test.java/include
 /includes
   /unitTest
 /build

   /project




 -
 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: Struts 2.0 Discussion Forum

2003-12-17 Thread James Mitchell

On Wed, 17 Dec 2003, Don Brown wrote:

 Is there one?  I have several ideas I'd like to toss into the discussion.

I'm +1 for keeping it here on the dev list. (if that's what you meant)




 Don

 On 17 Dec 2003 [EMAIL PROTECTED] wrote:

  husted  2003/12/17 12:49:28
 
Added:   contrib/struts-jericho README.txt project.properties
  project.xml
Log:
Create whiteboard directory for Struts-Jericho, a working proposal for Struts 
  2.x.
 
Revision  ChangesPath
1.1  jakarta-struts/contrib/struts-jericho/README.txt
 
Index: README.txt
===
Jericho is a whiteboard proposal describing one possible implementation of 
  Struts 2.x.
 
Since Struts 2.x is slated as a revolution, the Apache practice is to assign a 
  codename to a proposal until the Community comes to a consensus.
 
This proposal is called Jericho since it tries to tear-down the walls within 
  the Struts architecture. Jericho proposes to open-up Struts by
 
* Declaring interfaces for all core components.
 
* Providing working base implementations for all core components.
 
* Encapsulating alll path references within Location objects (fka 
  ActionForwards)and referring only to Locations from all other objects.
 
* Providing additional extension points from core components so that the 
  Inversion of Control pattern is fully realized.
 
* Providing POJO signatures that encapsulate HTTP classes so that applications 
  can be freed of HTTP semantics, if so desired.
 
* Retain optional access to HTTP objects so that applications can be free to do 
  whatever they need to do.
 
-Backward Compatibility-
 
Jericho is a revolution and backward compatability with prior versions of Struts 
  is not the prime consideration. However, care is being taken to create a clear 
  migration path, where practible, so that Jericho is available to the widest 
  community possible.
 
_DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the 
  Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow 
  a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
 
A second alternative to explore is to provide an alternate configuration loader 
  that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
 
_Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
  provided. These classes will provide the Struts 1.2.x behavior but also implement 
  the Struts Jericho interfaces, so that the framework can use them interchangeably.
 
These same techniques may be applied to provide adaptors for other frameworks, 
  so as to make Struts Jericho available to the widest community possible.
 
###
 
 
1.1  jakarta-struts/contrib/struts-jericho/project.properties
 
Index: project.properties
===
# ---
# P R O J E C T  P R O P E R T I E S
# ---
 
compile.debug = on
compile.optimize = off
compile.deprecation = off
 
maven.linkcheck.enable=true
 
# documentation properties
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
 
 
 
1.1  jakarta-struts/contrib/struts-jericho/project.xml
 
Index: project.xml
===
?xml version=1.0 encoding=UTF-8?
 
project
  extend../project.xml/extend
  nameJericho/name
  idstruts-jericho/id
  currentVersion0.1-dev/currentVersion
  inceptionYear2003/inceptionYear
  shortDescriptionStruts Jericho 2.x Whiteboard/shortDescription
  description
  Jericho is a whiteboard proposal describing one possible implementation of 
  Struts 2.x.
  Since Struts 2.x is slated as a revolution, the Apache practice is to 
  assign a codename to a proposal
  until the Community comes to a consensus.
  This proposal is called Jericho since it tries to tear-down the walls 
  within the Struts architecture.
  /description
  developers
developer
  nameTed Husted/name
  idhusted/id
  email[EMAIL PROTECTED]/email
  organization/organization
/developer
  /developers
 
  build
unitTest
  includes
include**/*Test.java/include
  /includes
/unitTest
  /build
 
/project
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Discussion Forum

Don Brown wrote:
 Is there one?  I have several ideas I'd like to toss into the
 discussion.

 Don
There's a Whiteboard page in the Wiki.

http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard

I'll be posting more about Jericho, but wanted to get what I had so far 
(a starter DTD) under CVS.

One other idea that I've been meaning to bring up in the wake of 
wildcard Mappings, is the idea of merging context attributes into 
ActionForward paths. For example, we could do something like

forward name=lookup merge=true path=/lookup.do?key={key} /

and have it replace {key} with request.getAttribute(key) (or session 
if not found).

-Ted.



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

Re: Context attributes (was: Struts 2.0 Discussion Forum)

2003-12-17 Thread Hubert Rabago

What about allowing Action objects to add the parameters themselves?  It adds a
great deal of flexibility, and doesn't limit the set of parameters that can be
used, nor does it require using the request or session attributes.

ActionForward forward = mapping.findForward(lookup);
forward.addParameter(param1,value1);
forward.addParameter(param2,2);
forward.addParameter(param3,3.0);
return forward;

Or maybe support for both (merge and addParameter).
This will also make bug 866 go away.

--- Ted Husted [EMAIL PROTECTED] wrote:
 Don Brown wrote:
   Is there one?  I have several ideas I'd like to toss into the
   discussion.
  
   Don
 
 There's a Whiteboard page in the Wiki.
 
 http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
 
 I'll be posting more about Jericho, but wanted to get what I had so far 
 (a starter DTD) under CVS.
 
 One other idea that I've been meaning to bring up in the wake of 
 wildcard Mappings, is the idea of merging context attributes into 
 ActionForward paths. For example, we could do something like
 
 forward name=lookup merge=true path=/lookup.do?key={key} /
 
 and have it replace {key} with request.getAttribute(key) (or session 
 if not found).
 
 -Ted.
 


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

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

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread Martin Cooper

On Wed, 17 Dec 2003, Don Brown wrote:

 Is there one?  I have several ideas I'd like to toss into the discussion.

Yep. This is it.

--
Martin Cooper



 Don

 On 17 Dec 2003 [EMAIL PROTECTED] wrote:

  husted  2003/12/17 12:49:28
 
Added:   contrib/struts-jericho README.txt project.properties
  project.xml
Log:
Create whiteboard directory for Struts-Jericho, a working proposal for Struts 
  2.x.
 
Revision  ChangesPath
1.1  jakarta-struts/contrib/struts-jericho/README.txt
 
Index: README.txt
===
Jericho is a whiteboard proposal describing one possible implementation of 
  Struts 2.x.
 
Since Struts 2.x is slated as a revolution, the Apache practice is to assign a 
  codename to a proposal until the Community comes to a consensus.
 
This proposal is called Jericho since it tries to tear-down the walls within 
  the Struts architecture. Jericho proposes to open-up Struts by
 
* Declaring interfaces for all core components.
 
* Providing working base implementations for all core components.
 
* Encapsulating alll path references within Location objects (fka 
  ActionForwards)and referring only to Locations from all other objects.
 
* Providing additional extension points from core components so that the 
  Inversion of Control pattern is fully realized.
 
* Providing POJO signatures that encapsulate HTTP classes so that applications 
  can be freed of HTTP semantics, if so desired.
 
* Retain optional access to HTTP objects so that applications can be free to do 
  whatever they need to do.
 
-Backward Compatibility-
 
Jericho is a revolution and backward compatability with prior versions of Struts 
  is not the prime consideration. However, care is being taken to create a clear 
  migration path, where practible, so that Jericho is available to the widest 
  community possible.
 
_DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the 
  Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow 
  a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
 
A second alternative to explore is to provide an alternate configuration loader 
  that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
 
_Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
  provided. These classes will provide the Struts 1.2.x behavior but also implement 
  the Struts Jericho interfaces, so that the framework can use them interchangeably.
 
These same techniques may be applied to provide adaptors for other frameworks, 
  so as to make Struts Jericho available to the widest community possible.
 
###
 
 
1.1  jakarta-struts/contrib/struts-jericho/project.properties
 
Index: project.properties
===
# ---
# P R O J E C T  P R O P E R T I E S
# ---
 
compile.debug = on
compile.optimize = off
compile.deprecation = off
 
maven.linkcheck.enable=true
 
# documentation properties
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
 
 
 
1.1  jakarta-struts/contrib/struts-jericho/project.xml
 
Index: project.xml
===
?xml version=1.0 encoding=UTF-8?
 
project
  extend../project.xml/extend
  nameJericho/name
  idstruts-jericho/id
  currentVersion0.1-dev/currentVersion
  inceptionYear2003/inceptionYear
  shortDescriptionStruts Jericho 2.x Whiteboard/shortDescription
  description
  Jericho is a whiteboard proposal describing one possible implementation of 
  Struts 2.x.
  Since Struts 2.x is slated as a revolution, the Apache practice is to 
  assign a codename to a proposal
  until the Community comes to a consensus.
  This proposal is called Jericho since it tries to tear-down the walls 
  within the Struts architecture.
  /description
  developers
developer
  nameTed Husted/name
  idhusted/id
  email[EMAIL PROTECTED]/email
  organization/organization
/developer
  /developers
 
  build
unitTest
  includes
include**/*Test.java/include
  /includes
/unitTest
  /build
 
/project
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Joe Germuska

- Make Inversion of Control central. By using an IoC framework to wire
Struts together, it makes it really easy to extend or improve Struts not
only for future development but for users as well. I'd recommend Spring's
IoC impl as it is small (100k), really easy to use, and easily
extendable. If we wanted to remain more agnostic, there are meta IoC
frameworks that let you plug in Pico/Spring/Avalon, etc.
Personally I suspect that a meta framework is more trouble than it's
worth, although I haven't really looked at any too closely. (Have
any pointers)

So then, with specific frameworks, I don't understand how Pico's
orientation towards constructors works in an environment where beans
need to be dynamically instantiated, but perhaps I just haven't
thought about it hard enough. Avalon seems too heavy, which leaves
us (or me at least) with Spring and HiveMind. I haven't developed
with either but so far the docs for Spring give me a warm fuzzy
feeling while the HiveMind docs kind of scare me.

- Use XML Schema over DTD's. Give struts config its own default namespace
to make it easier for users to mix in elements of other namespaces. An
example would be adding custom documentation attributes and elements. Of
course the usual arguments for XML Schema over DTD's apply as well.
XML Schema?! Naw, RelaxNG!!! After all, it is now an international
standard
(http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html)

- Replace paths with URL's, allowing for a default protocol. An action
path would look like action://foo or a tiles forward would be
tiles://tilesdef This would make it easy to plug in handlers to support
different presentation engines. If no protocol is specified, the path is
handled as usual.
I'm a little sketched out about assigning schemes of our own. I see
the motivation, and think the goal is good. Wonder if we could find
another mechanism.

- As Ted said, contine with the wildcard theme. Struts should do
everything possible to cut down configuration.
hear, hear! (, hear, hear, hear!!)

- Also, again totally agreeing with Ted, make everything interface based,
a few more hears here ;^)

--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
We want beef in dessert if we can get it there.
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Sgarlata Matt

- Original Message - 
From: Joe Germuska [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 5:04 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

 So then, with specific frameworks,  I don't understand how Pico's
 orientation towards constructors works in an environment where beans
 need to be dynamically instantiated, but perhaps I just haven't
 thought about it hard enough.  Avalon seems too heavy, which leaves
 us (or me at least) with Spring and HiveMind.  I haven't developed
 with either but so far the docs for Spring give me a warm fuzzy
 feeling while the HiveMind docs kind of scare me.

I agree with your assessment of frameworks 100%.  However, Spring is under
an LGPL license, so Struts can't use Spring unless either Struts switches to
LGPL or Spring switches to ASF, right?  It would be kind of silly for Struts
to stay under ASF in this case, since the Spring license would force the
undesirable LGPL clauses on any projects that were based on Struts.  Am I
right?

Matt

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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Edgar P Dollin

 And you're really going to have to break both of my arms and/or kick me
 out of Struts development if you want ActionForm *ever* changed to an
 interface again -- in *any* future Struts release.  I think it's an
 absolutely horrible idea, for reasons that have been documented way too
 many times to count.

 Craig McClanahan



 - Also, again totally agreeing with Ted, make everything interface 
 based,

 a few more hears here ;^)

 Joe Germuska

The interface discussion has come up previously and there was some emotion
tied to it.

Edgar


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

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread BaTien Duong

Are we on something revolutionary here? I am looking forward to this.

BaTien
DBGROUPS
Don Brown wrote:

Is there one? I have several ideas I'd like to toss into the discussion.

Don

On 17 Dec 2003 [EMAIL PROTECTED] wrote:

husted 2003/12/17 12:49:28

Added: contrib/struts-jericho README.txt project.properties
project.xml
Log:
Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
Revision ChangesPath
1.1 jakarta-struts/contrib/struts-jericho/README.txt
Index: README.txt
===
Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
Since Struts 2.x is slated as a revolution, the Apache practice is to assign a codename to a proposal until the Community comes to a consensus.

This proposal is called Jericho since it tries to tear-down the walls within the Struts architecture. Jericho proposes to open-up Struts by

* Declaring interfaces for all core components.

* Providing working base implementations for all core components.

* Encapsulating alll path references within Location objects (fka ActionForwards)and referring only to Locations from all other objects.

* Providing additional extension points from core components so that the Inversion of Control pattern is fully realized.

* Providing POJO signatures that encapsulate HTTP classes so that applications can be freed of HTTP semantics, if so desired.

* Retain optional access to HTTP objects so that applications can be free to do whatever they need to do.

-Backward Compatibility-

Jericho is a revolution and backward compatability with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practible, so that Jericho is available to the widest community possible.

_DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.

A second alternative to explore is to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization.

_Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to provided. These classes will provide the Struts 1.2.x behavior but also implement the Struts Jericho interfaces, so that the framework can use them interchangeably.

These same techniques may be applied to provide adaptors for other frameworks, so as to make Struts Jericho available to the widest community possible.

###

1.1 jakarta-struts/contrib/struts-jericho/project.properties

Index: project.properties
===
# ---
# P R O J E C T P R O P E R T I E S
# ---
compile.debug = on
compile.optimize = off
compile.deprecation = off
maven.linkcheck.enable=true

# documentation properties
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html

1.1 jakarta-struts/contrib/struts-jericho/project.xml

Index: project.xml
===
?xml version=1.0 encoding=UTF-8?
project
extend../project.xml/extend
nameJericho/name
idstruts-jericho/id
currentVersion0.1-dev/currentVersion
inceptionYear2003/inceptionYear
shortDescriptionStruts Jericho 2.x Whiteboard/shortDescription
description
Jericho is a whiteboard proposal describing one possible implementation of
Struts 2.x.
Since Struts 2.x is slated as a revolution, the Apache practice is to assign
a codename to a proposal
until the Community comes to a consensus.
This proposal is called Jericho since it tries to tear-down the walls within
the Struts architecture.
/description
developers
developer
nameTed Husted/name
idhusted/id
email[EMAIL PROTECTED]/email
organization/organization
/developer
/developers
build
unitTest
includes
include**/*Test.java/include
/includes
/unitTest
/build
/project

-
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: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

On Wed, 17 Dec 2003, Joe Germuska wrote:

Personally I suspect that a meta framework is more trouble than it's
worth, although I haven't really looked at any too closely. (Have
any pointers)

HiveMind, from what I've read, is more service-oriented. I've been using
Spring for a few months now and totally loving it. It completely stays
out of your way, leaving your code with little or no Spring dependencies.
Furthermore, it supports both javabean and constructor-style dependency
resolution.

XML Schema?! Naw, RelaxNG!!! After all, it is now an international
standard
(http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html)

Doesn't matter to me as long as I get namespace support :)

I'm a little sketched out about assigning schemes of our own. I see
the motivation, and think the goal is good. Wonder if we could find
another mechanism.

Well, I've seen it used particularly in Forrest to good effect. The key
is keeping the number of protocols to a small number, but allowing the
user to develop more if they feel the need.

Don

- As Ted said, contine with the wildcard theme. Struts should do
everything possible to cut down configuration.

hear, hear! (, hear, hear, hear!!)

- Also, again totally agreeing with Ted, make everything interface based,

a few more hears here ;^)

--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
We want beef in dessert if we can get it there.
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Martin Cooper

Just to add a few more off the top of my head:

* Make the Struts core independent of the Servlets spec and the Portlets
spec, so that it can be used for both, and more.

* Separate view-technology-specific code into separate components, so that
the core is view-technology agnostic. So, for example, all JSP specific
code, including all of the taglibs, would move to a JSP component.

* Rework Tiles into two facets, so that the core is independent of the
Servlets spec and JSP, and the JSP component is part of the view specific
component described above.

* Split out file upload handling into a separate pluggable component, with
its own configuration. I noticed that this is still in the initial Jericho
DTD, but I think it should not be. The file upload implementation is
pluggable, and so should be able to have its own config definition.

I know I have more in notes at home, but just wanted to throw these out.

A sort of meta-question: When is Struts no longer Struts? I mean, how much
change can we introduce in Struts 2.0 before it becomes so different that
it's really a different framework? Do we need to decide on what Struts is,
and is not, before we go too far down the path of Struts 2.0? Or do we let
whatever falls out just fall out and deal with it later?

--
Martin Cooper


On Wed, 17 Dec 2003, Don Brown wrote:

 Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
 release work. :)  I'll throw out some ideas here, then develop them later
 in the wiki:

 - Make Inversion of Control central.  By using an IoC framework to wire
 Struts together, it makes it really easy to extend or improve Struts not
 only for future development but for users as well.  I'd recommend Spring's
 IoC impl as it is small (100k), really easy to use, and easily
 extendable.  If we wanted to remain more agnostic, there are meta IoC
 frameworks that let you plug in Pico/Spring/Avalon, etc.

 - Use XML Schema over DTD's.  Give struts config its own default namespace
 to make it easier for users to mix in elements of other namespaces.  An
 example would be adding custom documentation attributes and elements.  Of
 course the usual arguments for XML Schema over DTD's apply as well.

 - Replace paths with URL's, allowing for a default protocol.  An action
 path would look like action://foo or a tiles forward would be
 tiles://tilesdef  This would make it easy to plug in handlers to support
 different presentation engines.  If no protocol is specified, the path is
 handled as usual.

 - As Ted said, contine with the wildcard theme.  Struts should do
 everything possible to cut down configuration.

 - Also, again totally agreeing with Ted, make everything interface based,
 have default implementations, and free apps of HTTP.  Ideally, I'd like to
 see extra effort going into making it easy if not effortless to take a
 Struts 2.0 app and use the code in a portlet or web service environment.
 At least in my area, clients are wanting human and machine interfaces,
 with the human interface generally being behind a portal.

 Anyways, those are my brainstorming thoughts.  If any look interesting,
 I'll write something up in the wiki.

 Don


 -
 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: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Nope, Spring is Apache-style, I just checked.  You had me worried there
for a minute :)

Don

On Wed, 17 Dec 2003, Sgarlata Matt wrote:

 - Original Message -
 From: Joe Germuska [EMAIL PROTECTED]
 To: Struts Developers List [EMAIL PROTECTED]
 Sent: Wednesday, December 17, 2003 5:04 PM
 Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

  So then, with specific frameworks,  I don't understand how Pico's
  orientation towards constructors works in an environment where beans
  need to be dynamically instantiated, but perhaps I just haven't
  thought about it hard enough.  Avalon seems too heavy, which leaves
  us (or me at least) with Spring and HiveMind.  I haven't developed
  with either but so far the docs for Spring give me a warm fuzzy
  feeling while the HiveMind docs kind of scare me.

 I agree with your assessment of frameworks 100%.  However, Spring is under
 an LGPL license, so Struts can't use Spring unless either Struts switches to
 LGPL or Spring switches to ASF, right?  It would be kind of silly for Struts
 to stay under ASF in this case, since the Spring license would force the
 undesirable LGPL clauses on any projects that were based on Struts.  Am I
 right?

 Matt

 -
 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: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Sgarlata Matt

Sorry about that!

You are right, the license is ASF.  It says so both on the SourceForge site
and in the license included in Milestone 3.  I don't know where I got the
idea that it was LGPL.

Matt
- Original Message - 
From: Don Brown [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 5:20 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

 Nope, Spring is Apache-style, I just checked.  You had me worried there
 for a minute :)

 Don

 On Wed, 17 Dec 2003, Sgarlata Matt wrote:

  - Original Message -
  From: Joe Germuska [EMAIL PROTECTED]
  To: Struts Developers List [EMAIL PROTECTED]
  Sent: Wednesday, December 17, 2003 5:04 PM
  Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

   So then, with specific frameworks,  I don't understand how Pico's
   orientation towards constructors works in an environment where beans
   need to be dynamically instantiated, but perhaps I just haven't
   thought about it hard enough.  Avalon seems too heavy, which leaves
   us (or me at least) with Spring and HiveMind.  I haven't developed
   with either but so far the docs for Spring give me a warm fuzzy
   feeling while the HiveMind docs kind of scare me.

  I agree with your assessment of frameworks 100%.  However, Spring is
under
  an LGPL license, so Struts can't use Spring unless either Struts
switches to
  LGPL or Spring switches to ASF, right?  It would be kind of silly for
Struts
  to stay under ASF in this case, since the Spring license would force the
  undesirable LGPL clauses on any projects that were based on Struts.  Am
I
  right?

  Matt

  -
  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]

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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Hmm...I'm not familiar with that discussion, but I don't see why general
form functionality couldn't be defined in an interface, but the ActionForm
left how it is.  Of course we also have a chance to do what Craig said
he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and
actions.  WebWork2/XWork seems to have done well with that approach.

Again, just throwing ideas out there :)

Don

On Wed, 17 Dec 2003, Edgar P Dollin wrote:

  And you're really going to have to break both of my arms and/or kick me
  out of Struts development if you want ActionForm *ever* changed to an
  interface again -- in *any* future Struts release.  I think it's an
  absolutely horrible idea, for reasons that have been documented way too
  many times to count.

  Craig McClanahan



  - Also, again totally agreeing with Ted, make everything interface
  based,

  a few more hears here ;^)

  Joe Germuska

 The interface discussion has come up previously and there was some emotion
 tied to it.

 Edgar


 -
 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: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

I think this might be a that was then, this is now issue. Once upon a 
time, people were trying to do nutty things like use Entity Beans for 
ActionForms. But people are older and wiser now, and more importantly, 
we have DynaActionForms and tools like XDoclet to mitigate the 
maintenance issues.

In fact, I'd like to merge the ValidatorForm with the DynaActionForm 
configuration, so we'd have a central place to define everything the 
framework wants to know about a form.

On the topic of form processing, I'd also like to add a populate method 
that the Request Processor could call, instead of doing it externally, 
so a form could populate itself.

-Ted.

Don Brown wrote:
Hmm...I'm not familiar with that discussion, but I don't see why general
form functionality couldn't be defined in an interface, but the ActionForm
left how it is.  Of course we also have a chance to do what Craig said
he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and
actions.  WebWork2/XWork seems to have done well with that approach.
Again, just throwing ideas out there :)

Don

On Wed, 17 Dec 2003, Edgar P Dollin wrote:


And you're really going to have to break both of my arms and/or kick me
out of Struts development if you want ActionForm *ever* changed to an
interface again -- in *any* future Struts release.  I think it's an
absolutely horrible idea, for reasons that have been documented way too
many times to count.

Craig McClanahan



- Also, again totally agreeing with Ted, make everything interface
based,

a few more hears here ;^)

Joe Germuska
The interface discussion has come up previously and there was some emotion
tied to it.
Edgar

-
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]



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Martin Cooper wrote:
* Split out file upload handling into a separate pluggable component, with
its own configuration. I noticed that this is still in the initial Jericho
DTD, but I think it should not be. The file upload implementation is
pluggable, and so should be able to have its own config definition.
Feel free to amend that if you like. I've so far managed to avoid file 
uploading in Struts applications, and so remain blissfully ignorant of 
the grittier details.

A sort of meta-question: When is Struts no longer Struts? I mean, how much
change can we introduce in Struts 2.0 before it becomes so different that
it's really a different framework? Do we need to decide on what Struts is,
and is not, before we go too far down the path of Struts 2.0? Or do we let
whatever falls out just fall out and deal with it later?
Legally, I'd say that Strut is whatever the Struts Community says it is. 
It's a brand that belongs to the ASF, which we manage on the 
Foundation's behalf.

Technically, I'd say that Struts (or any framework) is an aggregation of 
its components. In Struts 1.0, we had mainly Form, Forward, Mapping, 
Action, and Messaging components. In Struts 1.1, we added Exception, 
Validation, Composite (or Tile), and PlugIn components.

So long as Struts 2.x retains the same hallmark components in a 
recognizable form, I'd say it's still Struts. :)

Overall, it's my feeling that Struts does all the right things, it's 
just that we don't do them in all the right places. :) Being able to 
extend elements is one example. Encapsulating paths is another.

My own goal for Struts 2.x is to consistently apply all our best 
practices and eliminate inconsistent and legacy practices. We've got a 
good thing here; we just need to make it even better. :)

In terms of new functionality, the three biggest fish I'd like to fry 
are Workflow, SSL, and Unit Testing. Towards that end, I'd like to 
consider integrating LivingLogic's Workflow, ssl-ext, and Struts 
TestCase into the Struts 2.x development stream. We may also want to 
consider adding these as standard options to Struts 1.x, so as to blaze 
a trail.

Although it's not evident from the Jericho DTD, the intention is to use 
a Context object in the signatures, perhaps the Commons Chain Context, 
so as to encapsulate Servlet/Portlet dependencies.

-Ted.



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

Re: Context attributes (was: Struts 2.0 Discussion Forum)

2003-12-17 Thread gvanmatre


I like the idea of making the parameters/arguments passed between
actions declarative verses programmatic.  This makes it very easy to
define interfaces between pages.  The following code shows our
solution using the extendibility of struts metadata but it would be
slick if it was a feature of the baseline.

In the event that the forward is not a redirect, we just stage the data
in request scope for the target page in a Map collection.  This allows
data to be staged in the formbean that was not in the request
parameters. The target action just uses the populate method of beanutils
to move corresponding from the map cached in the request to the target
formbean.  A redirect is easy because the request processor does the
dirty work.  It would be fun if this kind processing could be moved up
in the framework.


Maybe both options of encoding arguments (declarative, programmatic)
could complement each other and both redirect and forward could have
similar behavior?


Gary


action

path=/viewResultsetI
type=com.rustts.action.RusttsDispatchAction
className=com.rustts.action.RusttsActionMapping

input=.dynaPage
name=ResultsetDynaForm
scope=session
parameter=cmd

set-property property=pageId
value=viewResultsetIPage /

forward name=quit path=/viewPage.do redirect=true
   className=com.rustts.action.RusttsForwardAction

 !-- values pulled from the from bean that interface
with
  the target page --

 set-property property=arg0 value=year /
 set-property property=arg1 value=month /
/forward

/action

// action execute method stages the form and request.  You might have //
parameters in the form bean not in the request.

if (mapping instanceof IRusttsActionMapping) {
   ((IRusttsActionMapping) mapping).setState(form, request);
}


package com.rustts.action;

import javax.servlet.http.HttpServletRequest;

import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;

/**
 * @author Gary VanMatre
 *
 * Extended the base action mapping to add custom properties
 * use the set-property element in the XML mapping to associate
 * a page with an action.
 */
public class RusttsActionMapping
extends ActionMapping
implements IRusttsActionMapping {

private String pageId = null;

// make sure that these values will not be persisted in a
// distributed deployment.  I believe that struts caches it's
// metadata in application scope which is not replicated (only
session)
private transient ActionForm form = null;
private transient HttpServletRequest request = null;

/**
 * Returns the pageId.
 * @return String
 */
public String getPageId() {
return pageId;
}

/**
 * Sets the pageId.
 * @param pageId The pageId to set
 */
public void setPageId(String pageId) {
this.pageId = pageId;
}

/**
 * This method's purpose is to stage date for the custom action
forward class codeRusttsForwardAction/code.
 * The reference should be effective only for the dialog
duration of a method call.
 * The method is invoked by @see
com.rustts.action.RusttsDispatchAction#execute(ActionMapping, ActonForm,
HttpServletRequest, HttpServletResponse).
 */
public void setState(ActionForm form, HttpServletRequest
request) {
this.form = form;
this.request = request;
}

/**
 * This method has been overridden to initiate the propagation
 * of arguments on an action forward.
 * If the mapping class realizes interface
 * codeIRusttsForwardAction/action, the specified properties
 * in the struts configuration file will be pulled from the form bean
and
 * staged for the next page.
 * The method of staging depends on if the action forward is a redirect.
*/
public ActionForward findForward(String name) {

ActionForward forward = super.findForward(name);
if ((forward != null)
 (forward instanceof IRusttsForwardAction)
 (request != null)
 (form != null)) {
forward =
   ((IRusttsForwardAction)
forward).stageForward(form, request);
}

return forward;

}

protected void finalize() {
pageId = null;
form = null;
request = null;
}

}



package com.rustts.action;

import java.net.URLEncoder;
import java.util.Iterator;
import java.util.Map;
import java.util.TreeMap;
import java.util.TreeSet;

import javax.servlet.http.HttpServletRequest;

import

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Vic Cekvenich

Martin Cooper wrote:

* Make the Struts core independent of the Servlets spec  SNIP
Above is my favorite wish!

I would like to be able to call an Action via XML-RPC for it to give me 
a FormBean and for me to give it a FormBean back. (or any other 
SOA). There was a few threads of SOAP Struts some time back.

And... maybe a FormBean is an XML DTD.
(Like .NET stuff, and iBatis 2.0 _sqlMap.getXMLResult())
This way a view can render it (such as core tags X: ) any way it wants. 
Ex: from javascript you call XML-RPC to get a XML (multirow bean)

And even a simple DAO interface, to be used optionaly be people, so 
they can go back and forth from iBatis to Hibreante or what ever.

And build Struts on top of HiveMind or similar. (IoC and Services... and 
XML).

If just the MVC interfaces are defined, then several implemenations can 
ship. One implemtation would be backwards compatible.
Once could be SOAPActionImpl.

Action's execute should take a Map as signature argument. This way we do 
not have Req/Resp tie in, but anything comes in.
Ex: execute(Map arg)  { .. }
A good 1st step is to have a TilesAction and Action have same signature 
for execute.

.V



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread [EMAIL PROTECTED]

  - Also, again totally agreeing with Ted, make everything interface 
  based,
 
  a few more hears here ;^)
 
  Joe Germuska
 
 The interface discussion has come up previously and there was some emotion
 tied to it.

I was around for Interface ActionForms in pre Struts 0.5 and it was really ugly, what 
some developers tried to do. This then triggered a number of
email's on the list to help them get it working. In almost all cases
they were trying to break the MVC Model, and pile all the logic into the
ActionForm implementation class they possibly could. 



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

Re: Portlets Framework

2003-12-17 Thread BaTien Duong

Howdy:

Here is a framework we are working on with very promissing results:
   1) User request is submitted to Struts request/response framework 
RequestProcessor (based on Struts-chain)
   2) RequestProcessor  passes information via ServletWebContext and 
looks into its Catalog of requested ServiceAction.
   3) The ServiceAction uses all facilities of current Struts such as 
ServiceForm, Validation, etc.
   4) The portal page has both static and dynamic fragments. The 
dynamic fragments are passed from ServletWebContext to PortletProcessor 
with contents stored in PortletWebContext. Note that ServletWebContext 
and PortletWebContext are just maps of name/value, same as cornerstone 
IContext.
   5) PortletProcessor calls requested portlet(s) passed via contents 
in PortletWebContext.
   6) Individual portlet  calls its processActions and render which are 
2 cornerstone services for component customization, component 
relationship, control flow customization, and component management. We 
are combining Cornerstone services and Hivemind services into our own 
services. This enable us to leverage on open-source low level 
developments and use it as a backdoor connection for different portlet 
applications which can be replaced with a more vendor neutral of JMS 
service. Security is a concern here, but if you wire various portlet 
applications together you are supposed to know what you are doing. The 
Struts pattern of service firewall such as ServiceForm can be used to 
avoid Trojan hourses.
   7) Results of portlet renders recorded in PortletWebContext are 
returned the ServiceAction, which overwrite its contents in 
ServletWebContext with the contents in PortletWebContext. The results in 
ServletWebContext is passed to Struts-chain ResponseProcessor.
   8) The ResponseProcessor passes ServletWebContext to the selected 
presentation engine, which can be any framework: JSP, JSF, Flex, XForm, 
WML, etc. The presentation engine renders the response using contents 
from ServletWebContext.

Hope this may stimulate into the best flexible framework that we can all 
benefit.

I thought this may be relevant to both Jetspeed and Struts, so I cross 
post in both. Sorry if it bothers you.

BaTien
DBGROUPS
Weaver, Scott wrote:

Hi Punit,

 

For example 
if we want to apply some simple filter on request, which is 
the best place (if any) do to this? How to install common 
portlet filters?
   



Remember, a JSR-168 compliant portal supports portlet applications as
indivdual web apps deployed to the respective servlet container, this a
requirement of the spec. Hence, you can use servlet filters within
individual portlet apps to attain the filter functionallity required by each
indivdual portlet application and the portlets contained within.  It was
crucial to the spec that it leverage as much functionallity from the servlet
standard a possible so as to make portlet and servlet develop easy/similar
as possible.
Hth,
** 
| Scott T Weaver |
| [EMAIL PROTECTED]| 
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
**

 

-Original Message-
From: Punit Pandey [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 17, 2003 8:03 AM
To: [EMAIL PROTECTED]; 
[EMAIL PROTECTED]; 
[EMAIL PROTECTED]; portlets
Subject: Portlets Framework

Hello,
We are in the process of developing one framework for 
portlets. The objective is to apply all possible patterns and 
also try to simplify the development process.

The biggest challenge for developing portlet-framework, seems 
to us, is unavailability of controller servlet. In most of 
the JSP/Servlet-frameworks (e.g struts) the request always 
goes through the controller servlet. But in case of a portal, 
we do not have any such control. Can anyone tell me how to do 
some sort of request-preprocessing for a portlet? For example 
if we want to apply some simple filter on request, which is 
the best place (if any) do to this? How to install common 
portlet filters?

Regards,

Punit Pandey

=
http://portlets.blogspot.com - Portlets blog 
http://groups.yahoo.com/group/portle ts/ - Portlets Discussion Group





-
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]
.

cvs commit: jakarta-struts/contrib project.xml

husted  2003/12/17 17:10:23

  Added:   contrib  project.xml
  Log:
  Base Maven project file for contrib artifacts.
  
  Revision  ChangesPath
  1.1  jakarta-struts/contrib/project.xml
  
  Index: project.xml
  ===
  ?xml version=1.0 encoding=UTF-8?
  
  project
pomVersion3/pomVersion
idstruts-contrib-master/id
nameStruts Contrib Master Maven POM/name
currentVersion1.0/currentVersion
  
organization
  nameApache Software Foundation/name
  urlhttp://www.apache.org/url
  inceptionYear2000/inceptionYear
logohttp://jakarta.apache.org/images/jakarta-logo.gif/logo
/organization
logohttp://jakarta.apache.org/struts/images/struts.gif/logo
inceptionYear2000/inceptionYear
packageorg.apache.struts/package
gumpRepositoryIdjakarta/gumpRepositoryId
  

urlhttp://jakarta.apache.org/struts/contrib/${pom.artifactId.substring(8)}/index.html/url
issueTrackingUrlhttp://nagoya.apache.org//issueTrackingUrl

siteAddressjakarta.apache.org/struts/siteAddress

siteDirectory/www/jakarta.apache.org/struts/contrib/${pom.artifactId.substring(8)}//siteDirectory

distributionDirectory/www/jakarta.apache.org/builds/jakarta-commons-sandbox/${pom.artifactId.substring(8)}//distributionDirectory

repository
  connectionscm:cvs:pserver:[EMAIL 
PROTECTED]:/home/cvspublic:jakarta-struts/contrib/${pom.artifactId.substring(8)}/connection
  
urlhttp://cvs.apache.org/viewcvs/jakarta-struts/contrib/${pom.artifactId.substring(8)}//url
/repository
  
  mailingLists
mailingList
  nameStruts User List/name
  subscribe
[EMAIL PROTECTED]
  /subscribe
  unsubscribe
[EMAIL PROTECTED]
  /unsubscribe
  archive
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=42
  /archive
/mailingList
mailingList
  nameStruts Developer List/name
  subscribe
[EMAIL PROTECTED]
  /subscribe
  unsubscribe
[EMAIL PROTECTED]
  /unsubscribe
  archive
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=41
  /archive
/mailingList
  /mailingLists
  
  dependencies
dependency
  idcommons-beanutils/id
  version1.6.1/version
  urlhttp://jakarta.apache.org/commons/beanutils.html/url
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
dependency
  idcommons-collections/id
  version2.1/version
  urlhttp://jakarta.apache.org/commons/collections.html/url
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
dependency
  idcommons-digester/id
  version1.5/version
  urlhttp://jakarta.apache.org/commons/digester.html/url
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
dependency
  idcommons-fileupload/id
  version1.0/version
  urlhttp://jakarta.apache.org/commons/fileupload.html/url
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
dependency
  idcommons-logging/id
  version1.0.3/version
  urlhttp://jakarta.apache.org/commons/logging.html/url
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
!--
dependency
  idcommons-validator/id
  versionSNAPSHOT/version
  urlhttp://jakarta.apache.org/commons/validator.html/url
/dependency
--
  
dependency
  idcommons-validator/id
  version1.1.1-dev/version
  urlhttp://jakarta.apache.org/commons/validator.html/url
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
dependency
  idoro/id
  version2.0.7/version
  urlhttp://jakarta.apache.org/oro//url
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
dependency
  idxml-apis/id
  version2.0.2/version
  urlhttp://xml.apache.org/commons//url
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
dependency
  groupIdantlr/groupId
  artifactIdantlr/artifactId
  version2.7.2/version
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
dependency
  idservletapi/id
  version2.2/version
/dependency
  
dependency
  idjakarta-struts/id
  version1.2-dev/version
  urlhttp://jakarta.apache.org/struts/index.html/url
  propertieswar.bundletrue/war.bundle/properties
/dependency
  
!-- for unit tests --
dependency
  idjunit/id
  version3.8.1/version
  urlhttp://www.junit.org/url
/dependency

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread [EMAIL PROTECTED]

I favor a evolutionary approach to getting to the
Next Generation of Struts. As apposed to scrapping
every piece of code we have. This would entail aggressively
deprecating functionality.

The advantages are we would most likely always have
a working framework, which would encourage user
participation, usage, testing. That means we could use it
in our paying jobs. Some of us may even be able to
justify working on Struts 2.0 on our paying Jobs time.
I am concerned where all the energy, time, code, 
documentation, and testing will come from with a clean start.
I strongly believe one of the reasons Struts is so popular
is that we were big on compatibility between releases,
and so staying up to date with the latest Struts release or
nightly was not very painful. 

The disadvantages are that it might seem like we
would have to do extra work in gradually refactoring
Struts into the next version.

Any code base that starts from scratch has to undergo
the painful process of setting up the initial classes,
tests etc... Again user participation, in usage, testing,
and contributions played a major, no, critical role in 
struts's development, and we'll need that same input again.
However, now days there are many other frameworks with which to
choose.

Bottom line is I believe like you do that we are smarter now and
know better ways to do things. Look up Erick Hatchers comments
he made a few months ago on Struts, and ways to improve it as
an example.

-Rob















 -Original Message-
 From: Ted Husted [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, December 17, 2003 09:22 PM
 To: 'Struts Developers List'
 Subject: Re: Struts 2.0 Discussion Forum
 
 Don Brown wrote:
   Is there one?  I have several ideas I'd like to toss into the
   discussion.
  
   Don
 
 There's a Whiteboard page in the Wiki.
 
 http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
 
 I'll be posting more about Jericho, but wanted to get what I had so far 
 (a starter DTD) under CVS.
 
 One other idea that I've been meaning to bring up in the wake of 
 wildcard Mappings, is the idea of merging context attributes into 
 ActionForward paths. For example, we could do something like
 
 forward name=lookup merge=true path=/lookup.do?key={key} /
 
 and have it replace {key} with request.getAttribute(key) (or session 
 if not found).
 
 -Ted.
 
 
 
 
 -
 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: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread David Graham


--- Vic Cekvenich [EMAIL PROTECTED] wrote:
 
 And even a simple DAO interface, to be used optionaly be people, so 
 they can go back and forth from iBatis to Hibreante or what ever.

I started the Mapper project in the commons for this exact reason.  It
doesn't belong in Struts.

http://jakarta.apache.org/commons/sandbox/mapper/

David

 
 And build Struts on top of HiveMind or similar. (IoC and Services... and
 
 XML).
 
 If just the MVC interfaces are defined, then several implemenations can 
 ship. One implemtation would be backwards compatible.
 Once could be SOAPActionImpl.
 
 Action's execute should take a Map as signature argument. This way we do
 
 not have Req/Resp tie in, but anything comes in.
 Ex: execute(Map arg)  { .. }
 A good 1st step is to have a TilesAction and Action have same signature 
 for execute.
 
 
 .V
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

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

Re: Struts 2.0 Discussion Forum

[EMAIL PROTECTED] wrote:
I favor a evolutionary approach to getting to the
Next Generation of Struts. As apposed to scrapping
every piece of code we have. This would entail aggressively
deprecating functionality.
I believe the plan was to do both. Work can continue on Struts 1.x.x to 
evolve it into an even more useful framework. Meanwhile, work on a new 
codebase for Struts 2.x.x can also proceed.

Of course, when people say new codebase, I don't think we mean a 
cleanroom implementation. There would be lots of reuse of code that 
already works well.

The relationship between the branches is liable to be synergistic. In 
evolutionary mode, it's sometimes hard to see the forest for the trees, 
and in revolutionary mode is sometimes hard to see the trees for the 
forest :)

In the end, whether Struts 1.x.x evolves into Struts 2.x.x, or whether 
Struts 2.x.x emerges from a revolution, will be up to Darwin. The 
volunteers will elect to spend their time on this or that, and whichever 
approach proves more attractive will win.

In the meantime, it's important to avoid saying whether a given codebase 
will be 2.x.x or not. When the time comes, the community can decide, but 
we'd need a working 2.x.x candidate in front of us first. :)

http://incubator.apache.org/learn/rules-for-revolutionaries.html

-Ted.



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

cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

husted  2003/12/17 18:59:33

  Modified:src/share/org/apache/struts/action ActionServlet.java
  Log:
  Javadoc tweaks only. No functional changes.
  
  Revision  ChangesPath
  1.171 +115 -103  
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
  
  Index: ActionServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
  retrieving revision 1.170
  retrieving revision 1.171
  diff -u -r1.170 -r1.171
  --- ActionServlet.java27 Nov 2003 05:38:53 -  1.170
  +++ ActionServlet.java18 Dec 2003 02:59:33 -  1.171
  @@ -142,7 +142,7 @@
* component of an MVC architecture./li
* liInstead of producing the next page of the user interface directly,
* action classes will generally use the
  - * codeRequestDispatcher.forward()/code facility of the servlet API
  + * codeRequestDispatcher.forward/code facility of the servlet API
* to pass control to an appropriate JSP page to produce the next page
* of the user interface./li
* /ul
  @@ -162,10 +162,11 @@
* liOptionally populate the properties of an codeActionForm/code bean
* associated with this mapping./li
* liCall the codeexecute/code method of this action class, passing
  - * on a reference to the mapping that was used (thereby providing access
  - * to the underlying ActionServlet and ServletContext, as well as any
  - * specialized properties of the mapping itself), and the request and
  - * response that were passed to the controller by the servlet container.
  + * on a reference to the mapping that was used, the relevant form-bean
  + * (if any), and the request and the response that were passed to the
  + * controller by the servlet container (thereby providing access to any
  + * specialized properties of the mapping itself as well as to the
  + * ServletContext).
* /li
* /ul
*
  @@ -173,9 +174,7 @@
* on the following servlet initialization parameters, which you will specify
* in the web application deployment descriptor (code/WEB-INF/web.xml/code)
* for your application.  Subclasses that specialize this servlet are free to
  - * define additional initialization parameters. Several of these were
  - * deprecated between the 1.0 and 1.1 releases. The deprecated parameters
  - * are listed after the nominal parameters./p
  + * define additional initialization parameters. /p
* ul
* listrongconfig/strong - Comma-separated list of context-relative
* path(s) to the XML resource(s) containing the configuration information
  @@ -204,29 +203,6 @@
* listrongvalidating/strong - Should we use a validating XML parser to
* process the configuration file (strongly recommended)? [true]/li
* /ul
  - * pThe following parameters may still be used with the Struts 1.1 release but
  - * are bdeprecated/b.
  - * ul
  - * listrongformBean/strong - The Java class name of the ActionFormBean
  - * implementation to use [org.apache.struts.action.ActionFormBean].
  - * emDEPRECATED - Configure this using the className attribute
  - * of each lt;form-beangt; element./em/li
  - * listrongforward/strong - The Java class name of the ActionForward
  - * implementation to use [org.apache.struts.action.ActionForward].
  - * Two convenient classes you may wish to use are:
  - * ul
  - * liemorg.apache.struts.action.ForwardingActionForward/em -
  - * Subclass of codeorg.apache.struts.action.ActionForward/code
  - * that defaults the coderedirect/code property to
  - * codefalse/code (same as the ActionForward default value).
  - * liemorg.apache.struts.action.RedirectingActionForward/em -
  - * Subclass of codeorg.apache.struts.action.ActionForward/code
  - * that defaults the coderedirect/code property to
  - * codetrue/code.
  - * /ul
  - * emDEPRECATED - Configure this using the className attribute of
  - * each lt;forwardgt; element./em/li
  - * /ul
*
* @author Craig R. McClanahan
* @author Ted Husted
  @@ -241,67 +217,72 @@
   
   
   /**
  - * Comma-separated list of context-relative path(s) to our configuration
  - * resource(s) for the default module.
  + * pComma-separated list of context-relative path(s) to our configuration
  + * resource(s) for the default module./p
*/
   protected String config = /WEB-INF/struts-config.xml;
   
   
   /**
  - * The Digester used to produce ModuleConfig objects from a
  - * Struts configuration file.
  + * pThe Digester used to produce ModuleConfig objects from a
  + * Struts configuration file./p
  + *
* @since Struts 1.1
*/
   protected Digester configDigester = null;
   
   
   /**
  - * The flag to request backwards-compatible

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

husted  2003/12/17 19:34:58

  Modified:src/share/org/apache/struts/util RequestUtils.java
  Log:
  Remove unused private field.
  
  Revision  ChangesPath
  1.137 +4 -11 
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
  
  Index: RequestUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
  retrieving revision 1.136
  retrieving revision 1.137
  diff -u -r1.136 -r1.137
  --- RequestUtils.java 28 Aug 2003 05:50:32 -  1.136
  +++ RequestUtils.java 18 Dec 2003 03:34:58 -  1.137
  @@ -117,13 +117,6 @@
*/
   protected static Log log = LogFactory.getLog(RequestUtils.class);
   
  -/**
  - * The message resources for this package.
  - */
  -private static MessageResources messages =
  -
MessageResources.getMessageResources(org.apache.struts.util.LocalStrings);
  -
  -
   // - Public Methods
   
   /**
  
  
  

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

cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

husted  2003/12/17 19:38:42

  Modified:src/share/org/apache/struts/action ActionServlet.java
  Log:
  Javadoc tweaks only. No functional changes.
  
  Revision  ChangesPath
  1.172 +68 -65
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
  
  Index: ActionServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
  retrieving revision 1.171
  retrieving revision 1.172
  diff -u -r1.171 -r1.172
  --- ActionServlet.java18 Dec 2003 02:59:33 -  1.171
  +++ ActionServlet.java18 Dec 2003 03:38:42 -  1.172
  @@ -115,7 +115,7 @@
   import org.xml.sax.SAXException;
   
   /**
  - * pstrongActionServlet/strong represents the controller in the
  + * pstrongActionServlet/strong provides the controller in the
* Model-View-Controller (MVC) design pattern for web applications that is
* commonly known as Model 2.  This nomenclature originated with a
* description in the JavaServerPages Specification, version 0.92, and has
  @@ -123,33 +123,36 @@
*
* pGenerally, a Model 2 application is architected as follows:/p
* ul
  - * liThe user interface will generally be created with JSP pages, which
  - * will not themselves contain any business logic.  These pages represent
  + * liThe user interface will generally be created with server pages, which
  + * will not themselves contain any business logic. These pages represent
* the view component of an MVC architecture./li
* liForms and hyperlinks in the user interface that require business logic
  - * to be executed will be submitted to a request URI that is mapped to the
  - * controller servlet./li
  - * liThere will be bone/b instance of this servlet class,
  + * to be executed will be submitted to a request URI that is mapped to this
  + * servlet./li
  + * liThere can be bone/b instance of this servlet class,
* which receives and processes all requests that change the state of
  - * a user's interaction with the application.  This component represents
  - * the controller component of an MVC architecture./li
  - * liThe controller servlet will select and invoke an action class to perform
  - * the requested business logic./li
  - * liThe action classes will manipulate the state of the application's
  + * a user's interaction with the application.  The servlet delegates the
  + * handling of a request to a @link(RequestProcessor) object. This component
  + * represents the controller component of an MVC architecture./li
  + * liThe codeRequestProcessor/code selects and invokes an @link(Action) class 
to perform
  + * the requested business logic, or delegates the response to another 
resource./li
  + * liThe codeAction/code classes can manipulate the state of the application's
* interaction with the user, typically by creating or modifying JavaBeans
* that are stored as request or session attributes (depending on how long
  - * they need to be available).  Such JavaBeans represent the model
  + * they need to be available). Such JavaBeans represent the model
* component of an MVC architecture./li
* liInstead of producing the next page of the user interface directly,
  - * action classes will generally use the
  - * codeRequestDispatcher.forward/code facility of the servlet API
  - * to pass control to an appropriate JSP page to produce the next page
  - * of the user interface./li
  + * codeAction/code classes generally return an @link(ActionForward) to 
indicate
  + * which resource should handle the response. If the codeAction/code
  + * does not return null, the codeRequestProcessor/code forwards or
  + * redirects to the specified resource (by utilizing
  + * codeRequestDispatcher.forward/code or codeResponse.sendRedirect/code)
  + * so as to produce the next page of the user interface./li
* /ul
*
  - * pThe standard version of codeActionServlet/code implements the
  - *following logic for each incoming HTTP request.  You can override
  - *some or all of this functionality by subclassing this servlet and
  + * pThe standard version of codeRequestsProcessor/code implements the
  + *following logic for each incoming HTTP request. You can override
  + *some or all of this functionality by subclassing this object and
*implementing your own version of the processing./p
* ul
* liIdentify, from the incoming request URI, the substring that will be
  @@ -157,11 +160,11 @@
* liUse this substring to map to the Java class name of the corresponding
* action class (an implementation of the codeAction/code interface).
* /li
  - * liIf this is the first request for a particular action class, instantiate
  - * an instance of that class and cache it for future use./li

cvs commit: jakarta-struts/src/share/org/apache/struts/action RequestProcessor.java