date:20010916

Re: Forwarding Actions onto other Actions

2001-09-16 Thread Ted Husted


There is actually just such a check, though this would be a very good
suggestion if there weren't ;-)

See processActionForm in ActionServlet.

Please let us know if you see anything else. 

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


Bob Rullo wrote:
 
 This is my first posting to the dev board so bare with me.
 
 From what I've seen in looking in the ActionServlet code it appears that
 everytime a action is called the form instance for that action is placed
 into the mapping.getScope( ).  Shouldn't there be a check before to see if
 the ActionForm is already in the scope?  Reason being that one action could
 make some modifications to a form instance and then forward it to another
 action that will make more changes to the form instance.  Basically my
 problem is that if two actions having the same form instance are called in
 the same request the form instance stored in the request will always be
 overridden by the last action.
 
 I propose that we should do a check before each action to determine if the
 form already exists in the desired scope.  If so, use the scoped instance,
 if not, build the form instance off of the request parameters as it is now.
 
 If this was by design, could someone shed some light to why?
 
 Thank you for your help,
 -Bob

Re: Forwarding Actions onto other Actions

2001-09-16 Thread Bob Rullo


Ted,

I did see that check in the processActionForm method, but if you notice, in
the processPopulate which is called right after the processActionForm call
you'll see that the bean, no matter where it came from, gets reset and then
populated with the request parameters via the RequestUtil.populate method.

Am I missing something here?  Sure seems like it'll reset the form bean no
matter what which to me, isn't desirable.

-Bob

- Original Message -
From: Ted Husted archive@jab.org
To: [EMAIL PROTECTED]
Sent: Sunday, September 16, 2001 6:04 AM
Subject: Re: Forwarding Actions onto other Actions


 There is actually just such a check, though this would be a very good
 suggestion if there weren't ;-)

 See processActionForm in ActionServlet.

 Please let us know if you see anything else.

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


 Bob Rullo wrote:
 
  This is my first posting to the dev board so bare with me.
 
  From what I've seen in looking in the ActionServlet code it appears
that
  everytime a action is called the form instance for that action is placed
  into the mapping.getScope( ).  Shouldn't there be a check before to see
if
  the ActionForm is already in the scope?  Reason being that one action
could
  make some modifications to a form instance and then forward it to
another
  action that will make more changes to the form instance.  Basically my
  problem is that if two actions having the same form instance are called
in
  the same request the form instance stored in the request will always be
  overridden by the last action.
 
  I propose that we should do a check before each action to determine if
the
  form already exists in the desired scope.  If so, use the scoped
instance,
  if not, build the form instance off of the request parameters as it is
now.
 
  If this was by design, could someone shed some light to why?
 
  Thank you for your help,
  -Bob

Re: Forwarding Actions onto other Actions

2001-09-16 Thread Ted Husted


Unfortunately, calling reset is necessary. A primary reason is that that
if a checkbox is unchecked then it will be ommitted from the request.
This can give inconsistent results when a ActionForm is being returned
for editing. The reset method gives the developer the opportunity to set
the checkbox to a known state (to make up for the vagrancies of  HTML). 

The abstract implementation of reset is empty. If a developer is going
to reuse beans between requests, it is the developer's responsiblity to
see that reset performs correctly.

All the population also takes places through mutators that the developer
defines. If there are circumstances where a ActionForm should not
populate itself through the request, the developer can design the
mutators accordingly.

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


Bob Rullo wrote:
 
 Ted,
 
 I did see that check in the processActionForm method, but if you notice, in
 the processPopulate which is called right after the processActionForm call
 you'll see that the bean, no matter where it came from, gets reset and then
 populated with the request parameters via the RequestUtil.populate method.
 
 Am I missing something here?  Sure seems like it'll reset the form bean no
 matter what which to me, isn't desirable.
 
 -Bob
 
 - Original Message -
 From: Ted Husted archive@jab.org
 To: [EMAIL PROTECTED]
 Sent: Sunday, September 16, 2001 6:04 AM
 Subject: Re: Forwarding Actions onto other Actions
 
  There is actually just such a check, though this would be a very good
  suggestion if there weren't ;-)
 
  See processActionForm in ActionServlet.
 
  Please let us know if you see anything else.
 
  -- Ted Husted, Husted dot Com, Fairport NY USA.
  -- Custom Software ~ Technical Services.
  -- Tel +1 716 737-3463
  -- http://www.husted.com/about/struts/
 
 
  Bob Rullo wrote:
  
   This is my first posting to the dev board so bare with me.
  
   From what I've seen in looking in the ActionServlet code it appears
 that
   everytime a action is called the form instance for that action is placed
   into the mapping.getScope( ).  Shouldn't there be a check before to see
 if
   the ActionForm is already in the scope?  Reason being that one action
 could
   make some modifications to a form instance and then forward it to
 another
   action that will make more changes to the form instance.  Basically my
   problem is that if two actions having the same form instance are called
 in
   the same request the form instance stored in the request will always be
   overridden by the last action.
  
   I propose that we should do a check before each action to determine if
 the
   form already exists in the desired scope.  If so, use the scoped
 instance,
   if not, build the form instance off of the request parameters as it is
 now.
  
   If this was by design, could someone shed some light to why?
  
   Thank you for your help,
   -Bob

RE: Forwarding Actions onto other Actions

2001-09-16 Thread Nathan Coast


Hi, 

I think Bob's point is that if an action form has been populated once during
a request, it would be useful if the reset wasn't called again.  i.e. if the
request was forwarded to other actions which use an action form of the same
name, it'd be useful if form properties could be set during the first action
and not reset before arriving at the second action.  I've coded around this
by setting request attributes in the first action and reading them in the
second (ugly).

I don't think anyone disagrees that it's essential the action forms are
reset between requests.

Cheers
Nathan

-Original Message-
From: Ted Husted [mailto:archive@jab.org]
Sent: Sunday, September 16, 2001 1:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Forwarding Actions onto other Actions


Unfortunately, calling reset is necessary. A primary reason is that that
if a checkbox is unchecked then it will be ommitted from the request.
This can give inconsistent results when a ActionForm is being returned
for editing. The reset method gives the developer the opportunity to set
the checkbox to a known state (to make up for the vagrancies of  HTML). 

The abstract implementation of reset is empty. If a developer is going
to reuse beans between requests, it is the developer's responsiblity to
see that reset performs correctly.

All the population also takes places through mutators that the developer
defines. If there are circumstances where a ActionForm should not
populate itself through the request, the developer can design the
mutators accordingly.

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


Bob Rullo wrote:
 
 Ted,
 
 I did see that check in the processActionForm method, but if you notice,
in
 the processPopulate which is called right after the processActionForm call
 you'll see that the bean, no matter where it came from, gets reset and
then
 populated with the request parameters via the RequestUtil.populate method.
 
 Am I missing something here?  Sure seems like it'll reset the form bean no
 matter what which to me, isn't desirable.
 
 -Bob
 
 - Original Message -
 From: Ted Husted archive@jab.org
 To: [EMAIL PROTECTED]
 Sent: Sunday, September 16, 2001 6:04 AM
 Subject: Re: Forwarding Actions onto other Actions
 
  There is actually just such a check, though this would be a very good
  suggestion if there weren't ;-)
 
  See processActionForm in ActionServlet.
 
  Please let us know if you see anything else.
 
  -- Ted Husted, Husted dot Com, Fairport NY USA.
  -- Custom Software ~ Technical Services.
  -- Tel +1 716 737-3463
  -- http://www.husted.com/about/struts/
 
 
  Bob Rullo wrote:
  
   This is my first posting to the dev board so bare with me.
  
   From what I've seen in looking in the ActionServlet code it appears
 that
   everytime a action is called the form instance for that action is
placed
   into the mapping.getScope( ).  Shouldn't there be a check before to
see
 if
   the ActionForm is already in the scope?  Reason being that one action
 could
   make some modifications to a form instance and then forward it to
 another
   action that will make more changes to the form instance.  Basically my
   problem is that if two actions having the same form instance are
called
 in
   the same request the form instance stored in the request will always
be
   overridden by the last action.
  
   I propose that we should do a check before each action to determine if
 the
   form already exists in the desired scope.  If so, use the scoped
 instance,
   if not, build the form instance off of the request parameters as it is
 now.
  
   If this was by design, could someone shed some light to why?
  
   Thank you for your help,
   -Bob


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper at LevelSeas for the presence of computer viruses.

www.mimesweeper.com
**

Bug report for Struts [2001/09/16]

2001-09-16 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  EHN=Ehnancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
|  866|New|Enh|2001-03-06|Clean Way to Add Parameters to Redirecting Forward|
|  905|New|Enh|2001-03-08|Need new mode for html:options for single Collecti|
|  931|New|Enh|2001-03-11|Struts needs to cleanly support running multiple c|
| 1467|New|Enh|2001-04-23|Enhancement requested for HIDDEN tag/ alternaive t|
| 1481|New|Enh|2001-04-24|Enhanced resolution of collection property in html|
| 1586|Opn|Nor|2001-05-01|The html:form tag generates incorrect focus java|
| 1683|New|Enh|2001-05-09|Change Struts tags to be more granular in their de|
| 1797|New|Enh|2001-05-17|Add a way to write out nbsp; if data is null |
| 1817|New|Enh|2001-05-18|Nested property lookup should understand Maps |
| 1826|New|Enh|2001-05-20|Dynamic Properties (instead of using the Reflectio|
| 1871|New|Enh|2001-05-23|tag that displays iterate tag index value |
| 1895|New|Enh|2001-05-24|Provide a way to specify xerces and xalan in build|
| 1896|New|Enh|2001-05-24|Store copies of the TLD files in CVS  |
| 2017|Ass|Maj|2001-06-05|Text entered in forms using multi-part/formdata ca|
| 2020|New|Enh|2001-06-06|GenericDataSource needs customisable properties   |
| 2046|Opn|Enh|2001-06-07|a struts tag within another struts tag|
| 2068|Opn|Nor|2001-06-08|The ActionMapping is not always stored in the Http|
| 2096|New|Enh|2001-06-09|Change html:options/ to use a collection like l|
| 2108|Ass|Enh|2001-06-11|Form Initialisation   |
| 2116|New|Enh|2001-06-11|OptionsTag and SelectTag (small refactor) proposed|
| 2164|New|Enh|2001-06-13|add per item header and footer to ErrorsTag   |
| 2214|New|Maj|2001-06-18|ActionServlet uses double-check idiom which is bro|
| 2226|New|Min|2001-06-18|NullPointerException in ActionMapping.findForward(|
| 2265|New|Enh|2001-06-21|additional constructor for ActionError|
| 2315|New|Blk|2001-06-25|Cannot find ActionMappings|
| 2503|New|Nor|2001-07-08|File Upload of File with Lines  4k Inserts \n Cha|
| 2513|New|Nor|2001-07-09|Options tag does not work as documented   |
| 2601|Unc|Enh|2001-07-12|Request http filter for MessageResources  |
| 2679|New|Nor|2001-07-18|iterate tag problem   |
| 2683|New|Nor|2001-07-18|File Upload doesn't work with Opera   |
| 2757|New|Nor|2001-07-23|file upload problem: MultipartIterator: invalid mu|
| 3148|Unc|Maj|2001-08-16|multiple attribute in custom tags |
| 3161|New|Min|2001-08-19|org.apache.strutstaglib.html.OptionsTag.getIterato|
| 3190|New|Nor|2001-08-20|FORM tag doesn't handle all cases of servlet mappi|
| 3193|New|Cri|2001-08-20|html:option causing JVM crash   |
| 3202|New|Maj|2001-08-21|OptionsTag.doEndTag - calls method to populate se|
| 3212|New|Blk|2001-08-21|Somehow encrypting the data-source password   |
| 3239|New|Nor|2001-08-22|tag properties not exposed to iterator index  |
| 3251|New|Nor|2001-08-23|Struts  on AIX   (Websphere 3.5.3)|
| 3281|New|Nor|2001-08-27|rewrite uses responseUtils.filter |
| 3283|New|Enh|2001-08-27|Adding Multiple Match Logic Equal/notEqual Tags   |
| 3288|New|Nor|2001-08-27|Image tag is missing an property  |
| 3289|New|Enh|2001-08-27|Need style attribute in the html:option and html|
| 3337|New|Nor|2001-08-29|Application scope objects being cached by tags.   |
| 3353|New|Enh|2001-08-29|Need More Flexibility Setting/Getting ActionForm P|
| 3465|New|Nor|2001-09-06|FormFile.destroy() doesn't work for temporary file|
| 3482|Ass|Nor|2001-09-06|broken link   |
| 3485|New|Enh|2001-09-07|How to Chain action   |
| 3539|New|Nor|2001-09-10|UTF-16 format character decode error when html-for|
+-+---+---+--+--+
| Total   49 bugs   |

cvs commit: jakarta-struts/legacy - New directory

2001-09-16 Thread husted


husted  01/09/16 09:57:06

  jakarta-struts/legacy - New directory

cvs commit: jakarta-struts/doc project.xml installation.xml

2001-09-16 Thread husted


husted  01/09/16 09:59:09

  Modified:doc  project.xml installation.xml
  Log:
  Refactor menu; add Tomcat 4 installation notes.
  
  Revision  ChangesPath
  1.9   +22 -15jakarta-struts/doc/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/project.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- project.xml   2001/08/11 03:49:19 1.8
  +++ project.xml   2001/09/16 16:59:09 1.9
  @@ -5,34 +5,38 @@
   
   titleStruts Framework/title
   
  -menu name=Documentation
  +menu name=About Struts
   item name=Homehref=index.html/
  -item name=Installationhref=installation.html/
  -item name=User Guide (1.0)href=userGuide/index.html/
  -item name=Javadoc href=api/index.html/
  -item name=Release Notes (nightly) href=release-notes.html/
  -item name=Release Notes (1.0) href=release-notes-1.0.html/
  +item name=User Guide  href=userGuide/index.html/
   item name=Resources   href=userGuide/resources.html/
   item name=Who We Are  href=userGuide/volunteers.html/
  -item name=TODO List (1.1) href=todo-1.1.html/
  +!-- item name=FAQ href=userGuide/faq/index.html/ -- 
  +item name=Mailing Lists   
href=http://jakarta.apache.org/site/mail.html/
  +item name=Bug Database
href=http://jakarta.apache.org/site/bugs.html/
  +/menu
  +
  +menu name=Getting Started
  +item name=Installationhref=installation.html/
  +item name=Release Notes   href=release-notes-1.0.html/
  +item name=Javadoc href=api-1.0/index.html/
   /menu
   
   menu name=Java Developer Guides
   item name=Digester
  -  
href=api/org/apache/struts/digester/package-summary.html#package_description/
  +  
href=api-1.0/org/apache/struts/digester/package-summary.html#package_description/
   item name=Utilities
  -  
href=api/org/apache/struts/util/package-summary.html#package_description/
  +  
href=api-1.0/org/apache/struts/util/package-summary.html#package_description/
   /menu
   
   menu name=Tag Library Guides
   item name=Bean Tags
  -  
href=api/org/apache/struts/taglib/bean/package-summary.html#package_description/
  +  
href=api-1.0/org/apache/struts/taglib/bean/package-summary.html#package_description/
   item name=HTML Tags
  -  
href=api/org/apache/struts/taglib/html/package-summary.html#package_description/
  +  
href=api-1.0/org/apache/struts/taglib/html/package-summary.html#package_description/
   item name=Logic Tags
  -  
href=api/org/apache/struts/taglib/logic/package-summary.html#package_description/
  +  
href=api-1.0/org/apache/struts/taglib/logic/package-summary.html#package_description/
   item name=Template Tags
  -  
href=api/org/apache/struts/taglib/template/package-summary.html#package_description/
  +  
href=api-1.0/org/apache/struts/taglib/template/package-summary.html#package_description/
   /menu
   
   menu name=Tag Library Reference
  @@ -42,8 +46,11 @@
   item name=Template Tags  href=struts-template.html/
   /menu
   
  -menu name=Proposals (1.1)
  -item name=Workflow Systemhref=proposal-workflow.html/
  +menu name=Current Development
  +item name=Release Notes (nightly) href=release-notes.html/
  +item name=Javadoc (nightly)   href=api/index.html/
  +item name=Workflow Proposal   href=proposal-workflow.html/
  +item name=TODO List   href=todo-1.1.html/
   /menu
   
   /project
  
  
  
  1.10  +3 -2  jakarta-struts/doc/installation.xml
  
  Index: installation.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/installation.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- installation.xml  2001/07/21 06:19:14 1.9
  +++ installation.xml  2001/09/16 16:59:09 1.10
  @@ -311,10 +311,11 @@
   required./a/li
 liResin 1.2+ standalone - No additional steps required./li
 liSilverStream 3.7.1 and later - a href=installation-sas.htmlAdditional 
steps required./a/li
  -  liTomcat 3.1 and prior - Not recommended. Use Tomcat 3.2.1 or later./li
  -  liTomcat 3.2.1+ standalone - No additional steps required./li
  +  liTomcat 4 - a href=installation-tc40.htmlAdditional steps may be 
required./a/li
 liTomcat 3.2.1 with Apache - a href=installation-tc.htmlAdditional steps 
   required./a/li
  +  liTomcat 3.2.1+ standalone -

cvs commit: jakarta-struts/doc/userGuide volunteers.xml resources.xml

2001-09-16 Thread husted


husted  01/09/16 10:05:09

  Modified:doc/userGuide volunteers.xml resources.xml
  Log:
  Add David and Oleg to Committer list. Update Resources page.
  
  Revision  ChangesPath
  1.3   +2 -0  jakarta-struts/doc/userGuide/volunteers.xml
  
  Index: volunteers.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/volunteers.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- volunteers.xml2001/06/15 01:48:38 1.2
  +++ volunteers.xml2001/09/16 17:05:09 1.3
  @@ -68,6 +68,8 @@
   libVincent Massol/b/li  (vmassol at apache.org)
   libCedric Dumoulin/b/li (cedric.dumoulin at lifl.fr)
   libMartin Cooper/b/li   (martinc at apache.org)
  +libDavid Winterfeldt/b/li   (dwinterfeldt at apache.org)
  +libOleg Alexeev/b/li(oalexeev at apache.org)
   /ul
   /section
   
  
  
  
  1.5   +118 -105  jakarta-struts/doc/userGuide/resources.xml
  
  Index: resources.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/resources.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- resources.xml 2001/07/05 01:35:22 1.4
  +++ resources.xml 2001/09/16 17:05:09 1.5
  @@ -9,140 +9,153 @@
   chapter name=Struts Resources href=resources 
   
   section name=Contributor Tabligs href=taglibs 
  -
  -pa href=http://husted.com/about/struts/indexed-tags.htm;bIndexed 
Tags/b/a by Dave Hays - Produce indexed names 
  -such as lt;input type=text name=parameter[0].value value=Mac. Link, Submit, 
and 
  -Select tags are included too./p
  -
  -pa href=http://husted.com/about/struts/logic-niallp.htm;bStruts IF/THEN/ELSE 
and 
  -SWITCH tags/b/a by Niall Pemberton./p
  -
  -pa href=http://husted.com/about/struts/rowtag.zip;bRowTag/b/a (ZIP file 
for 
  -download) - Source for a Struts-compatible tag to generate alternating row colors 
in a 
  -table by Niall Pemberton. [iNOTE: Requires a Struts build dated after 
2001-04-28/i]
  -/p
  -
  +pa 
href=http://husted.com/about/struts/struts-was.zip;bStruts-WAS.jar/b/a by 
Christopher Assenza - Modified Struts 1.0 JAR for Websphere 3.5 or 4. Zipped for 
download. (For additional tips regarding Websphere 3.5 see a 
href=http://jakarta.apache.org/struts/installation-was352-x.html;http://jakarta.apache.org/struts/installation-was352-x.html/a.)/p
  +pa href=http://struts.application-servers.com/;bStruts Layout/b/a by 
Improve - An extension library to  improve interfaces creation with Struts./p
  +pa href=http://husted.com/about/struts/indexed-tags.htm;bIndexed 
Tags/b/a [Also available in the nightly build] by Dave Hays - Produce indexed 
names such as lt;input type=text name=parameter[0].value value=Mac. Link, 
Submit, and Select tags are included too./p
  +pa href=http://husted.com/about/struts/logic-niallp.htm;bStruts IF/THEN/ELSE 
and SWITCH tags/b/a by Niall Pemberton./p
  +pa 
href=http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01251.html;bTextArea
 Wrapping/b/a by Matthias Bauer. Patch to HTML:TextArea tag to provide wrapping of 
long lines./p
  +pa href=http://husted.com/about/struts/rowtag.zip;bRowTag/b/a (ZIP file 
for download) - Source for a Struts-compatible tag to generate alternating row colors 
in a table by Niall Pemberton. [iNOTE: Requires a Struts build dated after 
2001-04-28/i]/p
   /section
   
   section name=Contributor Extensions href=extensions 
  -
  -pa href=http://www.rpsenterprises.com/struts/index.html;bStruts 
Transformer/b/a 
  -by Ron Smith - Transformations are responsible for taking an object in one form and 
  -transforming it into another. A forward transformation takes an object from its 
primary form 
  -to a secondary form (e.g. Date object to String). A reverse transformation takes an 
object 
  -from a secondary form to its primary form (e.g. String to Date)./p
  -
  -pa href=http://www.rpsenterprises.com/struts/index.html;bStruts 
Extender/b/a 
  -by Ron Smith - Add extensions to the struts framework via entries in the Struts 
configuration 
  -file./p
  -
  -pa href=http://husted.com/about/struts/mapper.zip;bMapper/b/a framework 
by Capco 
  -- The Mapper framework can be used for automating the process of 
  -validating/converting/transferring data fields. font size=2(See README to get
  -started.)/font/p
  -
  -pa href=http://husted.com/about/struts/StrutsCodeMaker.htm;bStruts 
CodeMaker/b/a 
  -by Ravindran Ramaiah - Generate Action and Form class by reading the JSP files/p
  -
  -pa href=http://www.sura.ru/~gonza/bean-factory/;bBean factory by Oleg V 
Alexeev/b/a - 
  -Adds the ability to easily link data bean creation to any Struts Action. All 
information 
  -about databeans and actions mappings stored in the standard Struts configuraton 
file. /p
  -
  -pa href=http://husted.com/about/struts/struts-menu.zip;bStruts Menu/b/a 
  -(ZIP file for download)

Re: Updating Site for Struts 1.1

2001-09-16 Thread Ted Husted


[EMAIL PROTECTED] wrote:
 Do you mean check in the generated versions of the 1.0 docs, so that they
 can be included in the struts-documentation.war and therefore land up on the
 web site? If so, +1.

Done. For lack of a better idea, I setup a legacy folder with a
api=1.0 subfolder, and amended build-webapps.xml to copy it over to the
target/documentation folder.

Haven't tried to make any of this live yet though.


 Currently, there are only two items in the menu that are not 1.1 related
 (User Guide and 1.0 Release Notes). Are you proposing separating only the
 documentation part of the menu into two sections, one for 1.0 and one for
 1.1, or the whole menu?

What I'm proposing is that we segregrate the Current Development
items, and maintain the 1.0 items as the defaults. I've checked-in a new
project.xml that runs like this:

About Struts
+ Home
+ User Guide
+ Resources
+ Who We Are
+ Mailing List
+ Bug Database

Getting Started
+ Installation
+ Release Notes
+ Javadoc

Java Developer Guides
+ Digester
+ Utilities

Tab Library Guides
+ Bean Tags
+ HTML Tags
+ Logic Tags
+ Template Tags

Tag Library Reference
+ Bean Tags
+ Logic Tags
+ Template Tags

Current Development
+ Release Notes (nightly)
+ Javadoc (nightly)
+ Workflow Proposal
+ TODO List


 If the goal is to have a more complete set of pages for both 1.0 and 1.1 on
 the web site, then perhaps we should think about having the 1.1 (or latest,
 which is currently 1.1) pages at the site entry point, and have a link to
 the latest-stable-release sub-site, which would look very similar but
 contain only 1.0 data.

I'd suggest the reverse. There's still a lot to be done with 1.1, and we
shouldd promote 1.0 as the default entry point. If 1.1 is the
entry-point, it sends the message that people should start using that
version, when I don't believe they should. I personally don't feel that
we've even defined what will be in 1.1. We've collected a number of
suggestions, but that doesn't feel like a feature set to me. 


 I'm not clear on what you mean by conform, since I can see two
 alternatives. Option 1 would be to clone your site into Struts Resources, so
 that they both contain the same material. Option 2 would be to take your
 page, turn it into the Struts Resources page, and reset your page to
 simply refer to the Struts page. Subsequent additions might then be made to
 your page, which would later be merged into the Struts page.
 
 Of these, I would prefer option 2, because (a) resource information would
 not be duplicated, and (b) it would be easier for people to identify what is
 unique to your site (and therefore new).

It's difficult for me to keep the Struts pages updated on a
rapid-development basis, so I went with option 1 for now. 


  + Create standalone Digester and Bean-Utils Developers guide with
  Struts-specific information, and then link to the Commons for general
  information.
 
 Not sure about this. Can you elaborate on the kind of Struts-specific
 information you have in mind? Also, the individual Commons projects do not
 seem to publish any documentation on the web site, so there are no developer
 guides available as there were prior to those components moving from Struts
 to Commons. I would definitely be +1 on having documentation available on
 the Commons site.

For the time being, I would like to at least bring back our original
developer's guide, now that we have the 1.0 API back on board. The
Commons is still in a shake-down period, and I want to be sure that our
developers at least have the 1.0 documentation handy. Of course, I would
plan on amdend this with a statement about it being deprecated and
moved. Ditto for the Bean-Utils.


-- Ted Husted.

Re: Updating Site for Struts 1.1

2001-09-16 Thread Ted Husted


I have to knock-off for a few hours, but here's what's still on my list
for tonight:

- Add kickstart FAQ to UserGuide, with link to jGuru FAQ
- Update nightly Release Notes from CVS reports (as needed)
- Update items on TODO list; revise language for release of 1.0.
- Add link to FAQ to TODO regarding release of version x.xx
- Review bugzilla for documentation issues
- Review documentation generally for other clarifications
- Adjust formatting on workflow proposal

-T.

Re: Updating Site for Struts 1.1

2001-09-16 Thread martin . cooper

- Original Message -
From: Ted Husted archive@jab.org
To: [EMAIL PROTECTED]
Sent: Sunday, September 16, 2001 11:05 AM
Subject: Re: Updating Site for Struts 1.1

 [EMAIL PROTECTED] wrote:
  Do you mean check in the generated versions of the 1.0 docs, so that
they
  can be included in the struts-documentation.war and therefore land up on
the
  web site? If so, +1.

 Done. For lack of a better idea, I setup a legacy folder with a
 api=1.0 subfolder, and amended build-webapps.xml to copy it over to the
 target/documentation folder.

 Haven't tried to make any of this live yet though.

  Currently, there are only two items in the menu that are not 1.1 related
  (User Guide and 1.0 Release Notes). Are you proposing separating only
the
  documentation part of the menu into two sections, one for 1.0 and one
for
  1.1, or the whole menu?

 What I'm proposing is that we segregrate the Current Development
 items, and maintain the 1.0 items as the defaults. I've checked-in a new
 project.xml that runs like this:

 About Struts
 + Home
 + User Guide
 + Resources
 + Who We Are
 + Mailing List
 + Bug Database

 Getting Started
 + Installation
 + Release Notes
 + Javadoc

 Java Developer Guides
 + Digester
 + Utilities

 Tab Library Guides
 + Bean Tags
 + HTML Tags
 + Logic Tags
 + Template Tags

 Tag Library Reference
 + Bean Tags
 + Logic Tags
 + Template Tags

 Current Development
 + Release Notes (nightly)
 + Javadoc (nightly)
 + Workflow Proposal
 + TODO List

+1, with the addition of the taglib reference for HTML tags.

  If the goal is to have a more complete set of pages for both 1.0 and 1.1
on
  the web site, then perhaps we should think about having the 1.1 (or
latest,
  which is currently 1.1) pages at the site entry point, and have a link
to
  the latest-stable-release sub-site, which would look very similar but
  contain only 1.0 data.

 I'd suggest the reverse. There's still a lot to be done with 1.1, and we
 shouldd promote 1.0 as the default entry point. If 1.1 is the
 entry-point, it sends the message that people should start using that
 version, when I don't believe they should. I personally don't feel that
 we've even defined what will be in 1.1. We've collected a number of
 suggestions, but that doesn't feel like a feature set to me.

+1. A very good point.

  I'm not clear on what you mean by conform, since I can see two
  alternatives. Option 1 would be to clone your site into Struts
Resources, so
  that they both contain the same material. Option 2 would be to take your
  page, turn it into the Struts Resources page, and reset your page to
  simply refer to the Struts page. Subsequent additions might then be made
to
  your page, which would later be merged into the Struts page.

  Of these, I would prefer option 2, because (a) resource information
would
  not be duplicated, and (b) it would be easier for people to identify
what is
  unique to your site (and therefore new).

 It's difficult for me to keep the Struts pages updated on a
 rapid-development basis, so I went with option 1 for now.

I guess I wasn't very clear on what I meant by (2). I actually meant do (1)
first, and then reset your site to point to the Struts site, but not contain
the same material. Your rapid updates would continue to occur on your site,
with periodic transfers to the Struts site. Your site would then be a
pointer to the Struts site plus the latest additions.

But it's really your decision as to what you keep on your own site :-). It's
such a great resource, I'm sure whatever you decide, the site will be of
great benefit to everyone.

   + Create standalone Digester and Bean-Utils Developers guide with
   Struts-specific information, and then link to the Commons for general
   information.

  Not sure about this. Can you elaborate on the kind of Struts-specific
  information you have in mind? Also, the individual Commons projects do
not
  seem to publish any documentation on the web site, so there are no
developer
  guides available as there were prior to those components moving from
Struts
  to Commons. I would definitely be +1 on having documentation available
on
  the Commons site.

 For the time being, I would like to at least bring back our original
 developer's guide, now that we have the 1.0 API back on board. The
 Commons is still in a shake-down period, and I want to be sure that our
 developers at least have the 1.0 documentation handy. Of course, I would
 plan on amdend this with a statement about it being deprecated and
 moved. Ditto for the Bean-Utils.

+1

 -- Ted Husted.

Thanks for doing all this!

--
Martin Cooper

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

2001-09-16 Thread martinc


martinc 01/09/16 21:52:58

  Modified:src/share/org/apache/struts/taglib/html FormTag.java
  Log:
  Call reset() when a form been is instantiated by the html:form tag.
  PR: 2108
  Submitted by: Corneil du Plessis (bug report), Erik Hatcher (patch)
  
  Revision  ChangesPath
  1.14  +14 -8 
jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java
  
  Index: FormTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- FormTag.java  2001/05/04 22:21:05 1.13
  +++ FormTag.java  2001/09/17 04:52:58 1.14
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java,v 1.13 
2001/05/04 22:21:05 craigmcc Exp $
  - * $Revision: 1.13 $
  - * $Date: 2001/05/04 22:21:05 $
  + * $Header: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FormTag.java,v 1.14 
2001/09/17 04:52:58 martinc Exp $
  + * $Revision: 1.14 $
  + * $Date: 2001/09/17 04:52:58 $
*
* 
*
  @@ -88,7 +88,7 @@
* properties correspond to the various fields of the form.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.13 $ $Date: 2001/05/04 22:21:05 $
  + * @version $Revision: 1.14 $ $Date: 2001/09/17 04:52:58 $
*/
   
   public class FormTag extends TagSupport {
  @@ -562,8 +562,16 @@
try {
Class clazz = Class.forName(type);
bean = clazz.newInstance();
  -if (bean instanceof ActionForm)
  -((ActionForm) bean).setServlet(servlet);
  +if (bean instanceof ActionForm) {
  +ActionForm form = (ActionForm)bean;
  +ActionMappings mappings = (ActionMappings)
  +pageContext.getAttribute(Action.MAPPINGS_KEY,
  + PageContext.APPLICATION_SCOPE);
  +
  +form.setServlet(servlet);
  +form.reset(mappings.findMapping(getActionMappingName()),
  +   pageContext.getRequest());
  +}
} catch (Exception e) {
throw new JspException
(messages.getMessage(formTag.create, type,
  @@ -806,6 +814,4 @@
   type = formBean.getType();
   
   }
  -
  -
   }

Tiles broken

2001-09-16 Thread Jeff Turner


Hi,

The Tiles from Struts CVS seems to be broken. I can compile it, but when
I run the jar under Tomcat 4.0 rc2, it breaks with the error:

javax.servlet.jsp.JspException: Error -  Tag Insert : Can't get component definition 
'doc.mainLayout'. Check if this name exist in component definitions.
at 
org.apache.struts.taglib.tiles.InsertTag.processDefinitionName(InsertTag.java)
at org.apache.struts.taglib.tiles.InsertTag.createTagHandler(InsertTag.java)
at org.apache.struts.taglib.tiles.InsertTag.doStartTag(InsertTag.java)
at org.apache.jsp.index$jsp._jspService(index$jsp.java:69)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)


The tiles war from the binary distribution works though.

Here's the build log from an out-of-CVS compile:

http://newgate.socialchange.net.au/~jeff/apache/jakarta/jakarta-struts/tiles-buildlog.txt

Is anyone else playing with this stuff?

thanks,

--Jeff

Re: Forwarding Actions onto other Actions

Re: Forwarding Actions onto other Actions

Re: Forwarding Actions onto other Actions

RE: Forwarding Actions onto other Actions

Bug report for Struts [2001/09/16]

cvs commit: jakarta-struts/legacy - New directory

cvs commit: jakarta-struts/doc project.xml installation.xml

cvs commit: jakarta-struts/doc/userGuide volunteers.xml resources.xml

Re: Updating Site for Struts 1.1

Re: Updating Site for Struts 1.1

Re: Updating Site for Struts 1.1

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

Tiles broken

13 matches

Site Navigation

Mail list logo

Footer information