[Struts Wiki] Update of "StrutsUpgradeNotes12to13" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 The comment on the change is: Reorganize the configuration section. -- == 4. Configuration == + === 4.1 CoR Request Processor === + The ''default'' Request Processor for Struts 1.3 is the new Chain (CoR) based ''ComposableRequestProcessor''. - === 4.1 CoR Request Processor === By default, the ComposableRequestProcessor will use a configuration file included in the struts-core JAR, and you won't need to do anything. + === 4.2 Original Request Processors === + + If you want to continue using either of the existing Request Processors (i.e. RequestProcessor or TilesRequestProcessor) then you need to specify this in the controller element of the ''struts-config.xml'' + + {{{ + + }}} + + {{{ + + }}} + + === 4.3 Tiles === + - However, if you want to use Tiles, you must instruct Struts to use a configuration file included in the struts-tiles JAR instead. To do this: + If you want to use Tiles, you must instruct Struts to use a configuration file included in the struts-tiles JAR instead. To do this: * Add a '''chainConfig''' ''init-param'' in the web.xml pointing to the location of the ''chain-config.xml'' @@ -71, +86 @@ }}} + In addition to configuring the ComposableRequestProcessor to use the provided Tiles chain config file, you should also update the '''DOCTYPE''' definition in your ''tiles-defs.xml'' file: - You can do much more to configure the ComposableRequestProcessor, but those details are outside the scope of this document. - - === 4.2 Original Request Processors === - - If you want to continue using either of the existing Request Processors (i.e. RequestProcessor or TilesRequestProcessor) then you need to specify this in the controller element of the ''struts-config.xml'' {{{ - +http://struts.apache.org/dtds/tiles-config_1_3.dtd";> }}} + + You can do much more to configure the ComposableRequestProcessor, but those details are outside the scope of this document. == 5 Deprecations which have been removed == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease134" by TedHusted
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by TedHusted: http://wiki.apache.org/struts/StrutsActionRelease134 The comment on the change is: Flesh-out major features section -- http://struts.apache.org/download.cgi - [Highlight new features?] + Major changes since Struts Action 1.2 include + + * Composable Request Processor + * Arbitrary configuration properties + * Opt-In Cancel Handling + * Enhanced Global Exception Handlers + * Extends attribute + * "isCommitted" Exception Handling + * Postback Actions + * Wildcard ActionConfig properties + + Composable Request Processor: For Action 1.3, we turned the request processor methods into Commands that are part of a flexible Chain of Commands. + + Arbitrary configuration properties: Most every Struts configuration element now accepts a map of key/value pairs. Arbitrary configuration properties let us externalize more of our configurations, encouraging reuse. + + Opt-In Cancel Handling: In Struts Action 1.3, the Cancel token is only honored if the new property "cancellable" is set for the Action Mapping. If the Cancel token is present, but cancellable is not set, then an InvalidCancelException is thrown. The InvalidCancelExeption may be caught by a Declarative Exception Handler, like any other Exception. + + Enhanced Global Exception Handlers: We now support use of global exception handlers in cases when no ActionConfig has yet been identified, as in with "preprocessing" commands in a custom request processing chain. + + Extends attribute: In the Struts configuration file, we can now use the extends attribute to adopt default settings from another element, as we already can in the Tiles configuration files. + + "isCommitted" Exception Handling: When using Tiles, sometimes the response is already committed when an exception occurs. Now, the ExceptionHandler tests response.isCommitted , and, if true, includes the configured view path, rather than forwarding to it. + + Postback Forms: The action attribute of the Form taglib is now optional. If omitted, the original URI of the original request is used. + + Wildcard ActionConfig properties: Wildcards can now be used in the properties of an ActionConfig. + + The 1.3.x series of Struts Action Framework has a minumum requirement of the following specification versions: + + * Java Servlet 2.3 and JavaServer Pages (JSP) 1.2 + * Java 2 Standard Platform Edition (J2SE) 1.4 The release notes are available online at: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease134" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 The comment on the change is: Proposed release announcement, please contribute! -- || C4. || Post an announcement to lists and website || _ || + == Proposed Release Announcement == + + Subject: [ANNOUNCE] Struts Action Framework v1.3.4 [Alpha|Beta|] + + The Apache Struts team is pleased to announce the release of Struts Action Framework 1.3.4 [Alpha|Beta|for General Availability]. + + Struts Action is available in both a full distribution, and a library distribution containing only the framework and dependencies. + + http://struts.apache.org/download.cgi + + [Highlight new features?] + + The release notes are available online at: + + http://struts.apache.org/struts-action/userGuide/release-notes.html + + Notes on upgrading from prior versions can be found on the community-maintained wiki: + + http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMaintenanceMaven" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Note that the instructions apply to snapshots and distributions as well as svn. -- Maven 2 does not use .properties files. Per-developer and per-system configuration is done in '''~/.m2/settings.xml'''. (Where '~' represents the user's home directory.) For more information, refer to the [http://maven.apache.org/maven-settings/settings.html settings model] and the Suggested Settings section below. + == Acquiring the Source Code == + - == Checkout Source from Subversion == + === Checkout Source from Subversion === The Struts Subversion repository is organized into sub-projects. You can check out Struts Action 1 alone using this URL: {{{ @@ -20, +22 @@ {{{ svn co https://svn.apache.org/repos/asf/struts/current current }}} + + === Snapshot or Distribution === + + The following instructions should work equally well from the 'src' directory of a Struts Action snapshot or distribution. If they don't, let us know! == Building with Maven == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "UserPreferences" by GeorgeDinwiddie
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by GeorgeDinwiddie: http://wiki.apache.org/struts/UserPreferences -- - 第ä¸æ¬¡ä½¿ç¨ + ##language:en + [[UserPreferences]] + If you are coming to this page for the first time, you'll see the form into which you can enter your username and some other settings (password is stored, in plaintext, but currently not used). It is best to choose a WikiName (like Firstname``Lastname) as username to get your changes and signatures link back to your Wiki``Homepage. Entering your email will enable you to get notifications on page changes. + + If you click on '''Create Profile''', a user profile will be created for you. With the response, a HTTP cookie will be sent that contains your user ID, which enables the system to recognize you. + + /!\ ''This "ID", shown in the response page, can be used to send the same cookie to other machines you might use. So jot it down! Or cut and paste the URL shown above, after you created your profile.'' + + '''Logout''' clears the cookie. As described above, '''Login''' enables you to gain access to your user profile if you somehow lost the cookie or are on another machine. '''Save''' just updates your profile. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease134" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 -- || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit "-SNAPSHOT" || (./) || || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || (./) || - || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || + || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || - || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || + || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || - || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.4 || || + || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.4 || (./) || || A5. || Update all pom.xml files to "1.3.5-SNAPSHOT" || (./) || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || -- || - || A7. || Post release-quality vote on dev@ list |||| + || A7. || Post release-quality vote on dev@ list || (./) || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "UserPreferences" by wujiegao
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by wujiegao: http://wiki.apache.org/struts/UserPreferences -- + 第ä¸æ¬¡ä½¿ç¨ - ##language:en - [[UserPreferences]] - If you are coming to this page for the first time, you'll see the form into which you can enter your username and some other settings (password is stored, in plaintext, but currently not used). It is best to choose a WikiName (like Firstname``Lastname) as username to get your changes and signatures link back to your Wiki``Homepage. Entering your email will enable you to get notifications on page changes. - - If you click on '''Create Profile''', a user profile will be created for you. With the response, a HTTP cookie will be sent that contains your user ID, which enables the system to recognize you. - - /!\ ''This "ID", shown in the response page, can be used to send the same cookie to other machines you might use. So jot it down! Or cut and paste the URL shown above, after you created your profile.'' - - '''Logout''' clears the cookie. As described above, '''Login''' enables you to gain access to your user profile if you somehow lost the cookie or are on another machine. '''Save''' just updates your profile. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease134" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 -- || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit "-SNAPSHOT" || (./) || - || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || || + || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || (./) || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.4 || || - || A5. || Update all pom.xml files to "1.3.5-SNAPSHOT" || || + || A5. || Update all pom.xml files to "1.3.5-SNAPSHOT" || (./) || - || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || + || A6. || Announce the Test Build on dev@ and user@ lists (optional) || -- || || A7. || Post release-quality vote on dev@ list |||| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease134" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 -- || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' || || Antlr || 2.7.2 || Released || Struts Validator || + || Bean Scripting Framework || 2.3.0 || Released || Scripting || || Commons !BeanUtils || 1.7.0 || Released || core (!ActionServlet, configuration, !DynaActionForm) || || Commons Chain || 1.0 || Released || core (!RequestProcessor) || || Commons Digester || 1.6 || Released || core (!ActionServlet, configuration) || @@ -77, +78 @@ || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || (./) || || 2. || Run Cactus Tests (see below) || n/a || - || 3. || Play test examples application (TC 5.0.x) || || + || 3. || Play test examples application (TC 5.0.x) || (./) || '''Note:''' Cactus tests are not working and have been moved to the sandbox. @@ -87, +88 @@ See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || - || A0. || Update all pom.xml files to omit "-SNAPSHOT" || || + || A0. || Update all pom.xml files to omit "-SNAPSHOT" || (./) || || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease134" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 -- == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || - || 1. || Announce plan to dev@ list || || + || 1. || Announce plan to dev@ list || (./) || - || 2. || Review/Resolve Outstanding Bugs || || + || 2. || Review/Resolve Outstanding Bugs || (./) || - || 3. || Update Release Notes || || + || 3. || Update Release Notes || (./) || - || 4. || Check Dependencies || || + || 4. || Check Dependencies || (./) || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the "beta/release-candidate/final" process. @@ -75, +75 @@ === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || - || 1. || Run Unit Test targets || || + || 1. || Run Unit Test targets || (./) || - || 2. || Run Cactus Tests (see below) || || + || 2. || Run Cactus Tests (see below) || n/a || || 3. || Play test examples application (TC 5.0.x) || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "SAF1RoughSpots" by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/SAF1RoughSpots -- 1. '''Built-in support for RAP (Redirect After Post) pattern''' [FrankZ] I'm not sure how best to accomplish this, but this should be a very easy thing for a developer to do, the framework should do any required heavy lifting. Again, not so much a rough spot as it is something I think a lot of people would appreciate. * [MichaelJ] Redirect-After-Post is fully implemented in [http://struts.sourceforge.net/strutsdialogs/index_v1.html Struts Dialogs 1.x]. After Struts 1.2.9 got better dispatch action, I stopped advertising Struts Dialogs project, but it is still valuable in terms of samples. Check it out. EventActionDispatcher and !EventDispatchAction can implement Redirect-After-Post as well, Paul and I spent quite some time discussing how !EventDispatchAction can be used for both input and render phases. + * [MichaelJ] To simplify redirect-after-post pattern, Struts must implement Flash scope, that is, the scope that survives after redirect, but is automatically cleaned up after redirected request finishes. Currently similar pattern is applied to the messages queued to session scope. 1. '''Pre and post-processing abilities''' [FrankZ] A developer should be able to specify a class and method to call before and after an Action executes, on a per-mapping basis. This should be independant of modifying a chain. Should just amount to adding the appropriate config file changes and two commands to the default chain. This is for handling things like common setup of view-type Actions, etc. * [MichaelJ] +0. I prefer having 1:1 correspondence between mapping and action class. With autopopulation out of the way, I can call whatever I want right in the beginning and at the end of execute() method. Same thing, but simpler, I think. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsUpgradeNotes12to13" by NiallPemberton
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by NiallPemberton: http://wiki.apache.org/struts/StrutsUpgradeNotes12to13 The comment on the change is: Change notes to reference Validator 1.3.0 -- [http://jakarta.apache.org/commons/fileupload/ Commons FileUpload] version 1.1 (previously was version 1.0). As well as needing to upgrade the !FileUpload jar you will now also need the [http://jakarta.apache.org/commons/io/ Commons IO] Version 1.1 jar. - === 3.3 Commons Validator 1.2.0 === + === 3.3 Commons Validator 1.3.0 === Struts 1.3 now depends on - [http://jakarta.apache.org/commons/validator/ Commons Validator] version 1.2.0 (previous was version 1.1.4) - remember to upgrade the Validator jar. + [http://jakarta.apache.org/commons/validator/ Commons Validator] version 1.3.0 (previous was version 1.1.4) - remember to upgrade the Validator jar. - * Validator 1.2 will recognize config files from prior versions. Optionally, you may + * Validator 1.3.0 will recognize config files from prior versions. Optionally, you may - * Change the doctype declaration at the top of validation.xml to refer to the dtd for version 1.2 + * Change the doctype declaration at the top of validation.xml to refer to the dtd for version 1.3.0 {{{ http://jakarta.apache.org/commons/dtds/validator_1_2_0.dtd";> + "http://jakarta.apache.org/commons/dtds/validator_1_3_0.dtd";> }}} * If you change the doctype you will have to change the deprecated ''arg0-arg3'' elements to ''arg'' elements. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease134" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease134 New page: = Struts Action 1.3.4 Release = == Info == 1. Struts [http://struts.apache.org/releases.html#Releases Release Guidelines] 2. [http://wiki.apache.org/incubator/SigningReleases Signing Releases] 3. Apache [http://apache.org/dev/mirrors.html Mirroring Guidelines] == Release Manager == The release manager is '''Wendy Smoak''' == How to Help == Everyone in the Struts community, users, developers, and committers, is encouraged to test a release, report any issues, and post to dev@ any comments on the overall quality of the release. To help everyone get started with Struts Action 1.3.4 (when it is available), here are the simplest installation instructions that can possibly work: * Download the Struts 1.3.4 distribution from http://svn.apache.org/dist/struts/action/v1.3.4/ (when it is available.) (Until then, try a [http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/ snapshot].) * Extract the distribution to a likely location (/opt/struts-action-1.3.4) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME * Install Apache Tomcat * http://wiki.apache.org/struts/StrutsMaintenanceMaven * Change to the new folder (e.g., /opt/struts-action-1.3.4/src) * $ mvn * Wait about five minutes for Maven to download and build everything ** If you see any error messages, please do a quick search of the mail archives and/or post them on the Dev list, and if they appear to be newly introduced issues, a Jira tickets will need to be created so we can track and resolve the issue as quickly as possible. Oh, and THANK YOU for your help. == Outstanding Issues == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10121&fixfor=21720 == Resolved Issues == http://issues.apache.org/struts/secure/ReleaseNote.jspa?version=21720&styleName=Text&projectId=10121&Create=Create == TO DO == == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || || 1. || Announce plan to dev@ list || || || 2. || Review/Resolve Outstanding Bugs || || || 3. || Update Release Notes || || || 4. || Check Dependencies || || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the "beta/release-candidate/final" process. Likewise, the [http://httpd.apache.org/dev/release.html HTTPD Release Guidelines] is a helpful "overall process" backgrounder, but HTTPD does not use a test-build stage. External Dependency versions for this release: || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' || || Antlr || 2.7.2 || Released || Struts Validator || || Commons !BeanUtils || 1.7.0 || Released || core (!ActionServlet, configuration, !DynaActionForm) || || Commons Chain || 1.0 || Released || core (!RequestProcessor) || || Commons Digester || 1.6 || Released || core (!ActionServlet, configuration) || || Commons !FileUpload || 1.1 || Released || Struts Upload || || Commons IO || 1.1 || Released || Required by Commons !FileUpload || || Commons Logging || 1.0.4 || Released || core (logging all over) || || Commons Validator || 1.3.0 || Released || Struts Validator || || Jakarta Oro || 2.0.8 || Released || Commons Validator || '''Note:''' This release of Struts Action depends on Struts Build 1.0.0 for the Checkstyle config file. == Testing Checklist == === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || || || 2. || Run Cactus Tests (see below) || || || 3. || Play test examples application (TC 5.0.x) || || '''Note:''' Cactus tests are not working and have been moved to the sandbox. == Test Build Checklist (A) == See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit "-SNAPSHOT" || || || A1. || Tag release in svn: STRUTS_ACTION_1_3_4 || || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.4 || || || A5. || Update all pom.xml files to "1.3.5-SNAPSHOT" || || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || || A7. || Post release-quality vote on dev@ list |||| == Vote (A) == || PMC Member || Quality || Voting thread is _ If release vote fails, including for a lack of quorum, remove from dist folder. == Point Release Checklist (B) == || '''#''' || '''Description''' || '''Completed''' || || B
[Struts Wiki] Update of "StrutsReleasePlans" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsReleasePlans -- * StrutsExtrasRelease131 - ''Struts Extras Version 1.3.1'' (cancelled) * StrutsActionRelease132 - ''Struts Action Version 1.3.2'' * StrutsActionRelease133 - ''Struts Action Version 1.3.3'' + * StrutsActionRelease134 - ''Struts Action Version 1.3.4'' == 1.2.x == * StrutsRelease122 - ''Struts Version 1.2.2'' * StrutsRelease123 - ''Struts Version 1.2.3'' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease133" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- * Wait about five minutes for Maven to download and build everything ** If you see any error messages, please do a quick search of the mail archives and/or post them on the Dev list, and if they appear to be newly introduced issues, a Jira tickets will need to be created so we can track and resolve the issue as quickly as possible. Oh, and THANK YOU for your help. - == Outstanding Bugs == + == Outstanding Issues == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10121&fixfor=21710 + + == Resolved Issues == + + http://issues.apache.org/struts/secure/ReleaseNote.jspa?version=21710&styleName=Text&projectId=10121&Create=Create == TO DO == @@ -90, +94 @@ || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || (./) || || A5. || Update all pom.xml files to "1.3.4-SNAPSHOT" || (./) || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || -- || - || A7. || Post release-quality vote on dev@ list || || + || A7. || Post release-quality vote on dev@ list || (./) || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease133" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- || A0. || Update all pom.xml files to omit "-SNAPSHOT" || (./) || || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || (./) || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || - || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || + || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || - || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || || + || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || (./) || - || A5. || Update all pom.xml files to "1.3.4-SNAPSHOT" || || + || A5. || Update all pom.xml files to "1.3.4-SNAPSHOT" || (./) || - || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || + || A6. || Announce the Test Build on dev@ and user@ lists (optional) || -- || - || A7. || Post release-quality vote on dev@ and user@ lists || || + || A7. || Post release-quality vote on dev@ list || || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMavenRelease" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMavenRelease The comment on the change is: Combine deploy, site, and site:deploy -- {{{ ~/svn/struts/STRUTS_ACTION_1_3_X $ rm -rf $M2_REPO/org/apache/struts/action - $ mvn deploy -P pre-assembly,perform-itest + $ mvn deploy site site:deploy -P pre-assembly,perform-itest {about 20 minutes later...} - $ mvn site site:deploy $ cd assembly $ mvn assembly:assembly $ scp target/assembly/out/* people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMavenRelease" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMavenRelease -- 1. Create and upload signatures for all .jar and .pom files in maven-snapshot-repository, and the .zip assembly file. {{{ - ~/svn/struts/current/action + ~/svn/struts/STRUTS_ACTION_1_3_X $ rm -rf $M2_REPO/org/apache/struts/action $ mvn deploy -P pre-assembly,perform-itest {about 20 minutes later...} - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease133" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || (./) || || 2. || Run Cactus Tests (see below) || n/a || - || 3. || Play test examples application (TC 5.0.x) || || + || 3. || Play test examples application (TC 5.0.x) || (./) || '''Note:''' Cactus tests are not working and have been moved to the sandbox. @@ -84, +84 @@ || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit "-SNAPSHOT" || (./) || - || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || || + || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || (./) || - || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || + || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || || || A5. || Update all pom.xml files to "1.3.4-SNAPSHOT" || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease133" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || - || 1. || Run Unit Test targets || || + || 1. || Run Unit Test targets || (./) || - || 2. || Run Cactus Tests (see below) || || + || 2. || Run Cactus Tests (see below) || n/a || || 3. || Play test examples application (TC 5.0.x) || || + '''Note:''' Cactus tests are not working and have been moved to the sandbox. - === Cactus Tests === - - || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Status''' || - || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || || - || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || || - || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || || - || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || || - == Test Build Checklist (A) == See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || - || A0. || Update all pom.xml files to omit "-SNAPSHOT" || || + || A0. || Update all pom.xml files to omit "-SNAPSHOT" || (./) || || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease133" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease133 -- == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || - || 1. || Announce plan to dev@ list || || + || 1. || Announce plan to dev@ list || (discussed) || - || 2. || Review/Resolve Outstanding Bugs || || + || 2. || Review/Resolve Outstanding Bugs || (./) || - || 3. || Update Release Notes || || + || 3. || Update Release Notes || (./) || - || 4. || Check Dependencies || || + || 4. || Check Dependencies || (./) || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the "beta/release-candidate/final" process. @@ -63, +63 @@ || Commons Logging || 1.0.4 || Released || core (logging all over) || || Commons Validator || 1.3.0 || Released || Struts Validator || || Jakarta Oro || 2.0.8 || Released || Commons Validator || + + '''Note:''' This release of Struts Action depends on Struts Build 1.0.0 for the Checkstyle config file. == Testing Checklist == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsAction1Planning" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsAction1Planning -- To lay the groundwork for future changes, three "experimental" classes and interfaces are being added to the framework so that early adopters can experiment with using Struts Chain to develop applications. We do consider these members experimental, and they are subject to change, based on our experience using them with our own applications. - '''ActionCommand''' - A Chain Command-like interface with one method: + '''!ActionCommand''' - A Chain Command-like interface with one method: - + {{{ void execute(ActionContext context) + }}} Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API. - '''ActionContext''' - A Chain Context that implements the logical Action class API. + '''!ActionContext''' - A Chain Context that implements the logical Action class API. Existing code could be converted by changing references to context.* and so forth. The context could be constructed by the Request Processor, as an optional Command in the Chain, so that it could be exposed this through thread-local, opening the door for POJO actions that don't implement a particular interface. - '''ViewContext (pending)''' - A Chain Context that implements the logical "Velocity Tools" API. + '''!ViewContext (pending)''' - A Chain Context that implements the logical "Velocity Tools" API. - In a later release, when the new members stabilize, we could move the taglib dependencies from the servlet contexts to the ViewContext. View technologies could then look exclusively to the ViewContext rather than poke around in the various servlet contexts. (Of course, support for the original architecture would remain for some time, to give third party libraries the chance to migrate.) + In a later release, when the new members stabilize, we could move the taglib dependencies from the servlet contexts to the !ViewContext. View technologies could then look exclusively to the !ViewContext rather than poke around in the various servlet contexts. (Of course, support for the original architecture would remain for some time, to give third party libraries the chance to migrate.) - After having a chance to work with ActionContext and ViewContext ourselves, we could introduce more support for these members in a later release. But for 1.3.x, they could be marked "experimental". + After having a chance to work with !ActionContext and !ViewContext ourselves, we could introduce more support for these members in a later release. But for 1.3.x, they could be marked "experimental". - The Commons Chain WebContext we now pass around Struts Chain could be called the "StrutsContext" to differentiate it from the ActionContext and ViewContext. + The Commons Chain !WebContext we now pass around Struts Chain could be called the "!StrutsContext" to differentiate it from the !ActionContext and !ViewContext. (Are we now starting to call everything "Context" instead of "Action"? Not really. We use the "Context" suffix when a member extends Chain Context. This convention is unlike the current "Action" soup, since "Context" is a suffix that identifies a member's "family" history.) - Another experimental member is the catalog element, which could be used to to support using a Chain of ActionCommands in lieu of an Action. + Another experimental member is the catalog element, which could be used to to support using a Chain of !ActionCommands in lieu of an Action. - == Struts Action Framework 1.4.x considerations == + == Struts Action Framework 1.4.x considerations == One we get past 1.3.x, there are some other things that we might consider. - Consider combining DTDs. Right now, using "standard" extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the DynaForm configuration. + Consider combining DTDs. Right now, using "standard" extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the !DynaForm configuration. - Consider refactoring for Spring. We identified the need for adding a IOC container to Struts some time ago, but stalled on the point of whi
[Struts Wiki] Update of "StrutsAction1Planning" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsAction1Planning New page: = Struts Action Framework 1 Planning = This page collects ideas and discussion on what could be included in future releases of Struts Action 1. This page is a whiteboard, meaning no one has committed to anything and therefore its purpose is to share information and brainstorm. == 1.3.x and beyond == The 1.3.x series utilizes Struts Chain as the default request processor and adds an "extends" attribute to all the configuration elements (a la Tiles). We would also like to add a Ant-style properties file to make variable substitutions within the XML elements. The substitution feature is supported by Spring and iBATIS, among others. Substitutions are a useful way to configure applications and reduce redundancy. == Experimental Members == To lay the groundwork for future changes, three "experimental" classes and interfaces are being added to the framework so that early adopters can experiment with using Struts Chain to develop applications. We do consider these members experimental, and they are subject to change, based on our experience using them with our own applications. '''ActionCommand''' - A Chain Command-like interface with one method: void execute(ActionContext context) Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API. '''ActionContext''' - A Chain Context that implements the logical Action class API. Existing code could be converted by changing references to context.* and so forth. The context could be constructed by the Request Processor, as an optional Command in the Chain, so that it could be exposed this through thread-local, opening the door for POJO actions that don't implement a particular interface. '''ViewContext (pending)''' - A Chain Context that implements the logical "Velocity Tools" API. In a later release, when the new members stabilize, we could move the taglib dependencies from the servlet contexts to the ViewContext. View technologies could then look exclusively to the ViewContext rather than poke around in the various servlet contexts. (Of course, support for the original architecture would remain for some time, to give third party libraries the chance to migrate.) After having a chance to work with ActionContext and ViewContext ourselves, we could introduce more support for these members in a later release. But for 1.3.x, they could be marked "experimental". The Commons Chain WebContext we now pass around Struts Chain could be called the "StrutsContext" to differentiate it from the ActionContext and ViewContext. (Are we now starting to call everything "Context" instead of "Action"? Not really. We use the "Context" suffix when a member extends Chain Context. This convention is unlike the current "Action" soup, since "Context" is a suffix that identifies a member's "family" history.) Another experimental member is the catalog element, which could be used to to support using a Chain of ActionCommands in lieu of an Action. == Struts Action Framework 1.4.x considerations == One we get past 1.3.x, there are some other things that we might consider. Consider combining DTDs. Right now, using "standard" extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the DynaForm configuration. Consider refactoring for Spring. We identified the need for adding a IOC container to Struts some time ago, but stalled on the point of which to use. Since then, Spring has gained a lot of momentum. Spring is used by the MyFaces and Beehive teams, and its on the radar for Shale. There is already a Struts-Spring component in the Spring distribution and other common ground. == Struts Action Framework 1.5.x considerations == Based on our own work with the "experimental" members introduced in 1.3.x, we might consider some other changes. '''Consider a "smart" action type'''. The idea is that a command in Struts chain could look at the type indicated by the ActionMapping so both Action classes and ActionCommand implementations are supported. People could then mix-and-match Actions with ActionCommands (or even chains of ActionCommands). We might even try placing an ActionCommand interface on ActionForm, so people could skip having a seperate Action or ActionCommand class. The ActionForm could do it all. '''Consider a "populate" method on ActionForm'''. From an OOP standpoint, it might be cleaner if an ActionForm populated itself rather than rely on a
[Struts Wiki] Update of "FrontPage" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/FrontPage -- * [:Shale:StrutsShale] -- A proposal for a next generation Struts architecture * StrutsTi -- A proposal and discussion pages for a next generation Struts architecture focusing on simplicity * ["StrutsMoreAboutJSF"] -- JSF vs. Struts (Is this still relevant?) + * StrutsAction1Planning -- Ideas for new versions of Struts Action Framework 1. * StrutsAction2 -- Discussion on plans/tasks for Struts Action 2.0 * StrutsWhiteboard -- Project proposals and discussion * ["SAF1RoughSpots"] -- Discussions of what can be done to continue the evolution of Struts Action1 Framework - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMaintenanceMaven" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: add settings.xml schema -- ~/.m2/settings.xml {{{ - + http://maven.apache.org/POM/4.0.0"; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd";> ... ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "WhyChain" by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/WhyChain The comment on the change is: Added some pictures (will need to refactor the chain docs) -- the implementation of the new ComposableRequestProcessor class in Struts 1.3. + == Struts 1.0 == + In Struts 1.0, requests were processed using a lump of code in ActionServlet. To keep it organized, the code was subdivided in a series of methods. Unsurprisingly, each method in the series had a coherent task and was named after its task. + == Struts 1.1.x - 1.2.x == + In Struts 1.1, we pulled out that lump of code and turned it into a first class object called the RequestProcessor. The original methods remained mainly the same, but now they were methods in a coherent object, rather than a set of related methods in a larger object. + + inline:struts12rp.gif Since it was a first-class object, we could subclass this new request processor, and plug in a new one, without touching the Servlet. (Users do not like to subclass ActionServlet.) We were also able to use a different request processor for each module, if need be. The problem is that it was still an all-or-nothing object. Extensions like Tile and Workflow both needed to subclass the RequestProcessor in different ways for their own reasons. + + == Struts 1.3.x == For Struts 1.3, we turned the 1.1 request processor methods into Commands. Rather than subclassing a monolithic object, we could now just replace Commands. We could also insert or remove Commands, if needed, to extend or streamline the request processing gauntlet. @@ -28, +36 @@ * A flexible processing layer for business applications * An extensible request processor for Struts - The refactoring of the request processor is a proof-of-concept for CoR. The request processing gauntlet is the "business logic" of the Struts framework. It's also a hoary example of some very nasty business logic. IMHO, if we can do the Struts request processor in CoR, we can do anything in CoR :) + The refactoring of the request processor is a proof-of-concept for CoR. The request processing gauntlet is the "business logic" of the Struts framework. It's also a hoary example of some very nasty business logic. IMHO, if we can do the Struts request processor in CoR, we can do anything in CoR + + inline:struts13rp.gif Yes, Struts Chain is a challenging application for CoR, and the implementation is not as slick as we might like. But, challenge is a good thing. And, I'm sure as more of us gain experience using CoR in other contexts, we'll devise more elegant solutions. The great thing about CoR is that it's easy to refactor. I'm using CoR in my own applications, and it's working quite well. I hope to start reapplying some of that experience to Struts Chain, and I'm sure others will too. + + inline:struts13rp2.gif + Here is a link to Ted's message in the archives: http://marc.theaimsgroup.com/?l=struts-dev&m=111097810923548&w=2 + Other links: + + http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html + + http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains2.html + + http://www.infonoia.com/en/content.jsp?d=inf.05.06&pr=1 + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "ShaleClay" by RyanKanno
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by RyanKanno: http://wiki.apache.org/struts/ShaleClay -- - Describe ShaleClay here. - DebuggingShaleClay + * DebuggingShaleClay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of "DebuggingShaleClay" by RyanKanno
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by RyanKanno: http://wiki.apache.org/struts/DebuggingShaleClay -- + Various tips on helping debug the various issues that a developer would find using ShaleClay. - == Incorrect public id == + [[TableOfContents()]] + === Incorrect public id === + - === Problem === + Problem When running a web application in offline mode (ie, no Internet), ShaleClay attempts to download the appropriate dtd to validate the various ShaleClay configuration files. However, with no Internet connection, the web server should report the following error: {{{java.net.UnknownHostException: struts.apache.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)}}} - === Solution === + Solution The reason is that there is an incorrect public id in one (or more) of your ShaleClay configuration files. @@ -18, +21 @@ {{{"-//Apache Software Foundation//DTD Shale Clay View Configuration 1.0//EN"}}} - === See === + See [http://www.mail-archive.com/user%40struts.apache.org/msg45712.html Struts Mailing List Message] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "DebuggingShaleClay" by RyanKanno
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by RyanKanno: http://wiki.apache.org/struts/DebuggingShaleClay New page: == Incorrect public id == === Problem === When running a web application in offline mode (ie, no Internet), ShaleClay attempts to download the appropriate dtd to validate the various ShaleClay configuration files. However, with no Internet connection, the web server should report the following error: {{{java.net.UnknownHostException: struts.apache.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)}}} === Solution === The reason is that there is an incorrect public id in one (or more) of your ShaleClay configuration files. The correct public id should be: {{{"-//Apache Software Foundation//DTD Shale Clay View Configuration 1.0//EN"}}} === See === [http://www.mail-archive.com/user%40struts.apache.org/msg45712.html Struts Mailing List Message] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "ShaleClay" by RyanKanno
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by RyanKanno: http://wiki.apache.org/struts/ShaleClay The comment on the change is: Adding Debugging Tips -- Describe ShaleClay here. + DebuggingShaleClay + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "ShaleClay" by RyanKanno
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by RyanKanno: http://wiki.apache.org/struts/ShaleClay New page: Describe ShaleClay here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "Shale/UserDocs" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/Shale/UserDocs The comment on the change is: Added a link for Clay -- == User Documentation == * [:Shale/GettingStarted:Getting Started with Shale] * [:ShaleCoreLibrary:Shale Core Library] + * [:ShaleClay:Shale Clay] * [:ShaleTestFramework:Shale Test Framework] * [:ShaleRemoting:Shale Remoting] * [:ShaleValidation:Shale Validation] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "Shale" by AndrewKuzmin
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by AndrewKuzmin: http://wiki.apache.org/struts/Shale -- * [:/UserDocs:User Documentation] - Shale user docs on the wiki. * [:/Resources:External Resources] - Articles, tutorials, books etc. on Shale. * [:/JsfResources:JavaServer Faces] - JSF Resources. + * [http://www.java201.com/resources/tags/shale Shale Related Resources] - Articles, Books, Presentations, Tutorials. === Project Maintenance and Resources === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease132" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsActionRelease132 The comment on the change is: Link to the Action 1 project summary instead, and note that login is required. -- == Where To Report Bugs == - Use JIRA to report issues: + Use JIRA to report issues: http://issues.apache.org/struts/browse/STR - http://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=show&createNew=true + You will have to [http://issues.apache.org/struts/secure/Dashboard.jspa?os_destination=%2Fbrowse%2FSTR Login] before you can create a new issue. Do not use Apache Bugzilla (it does not accept Struts bugs anyway). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease132" by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/StrutsActionRelease132 The comment on the change is: Explicitly pointed to JIRA repository -- == Outstanding Bugs == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10121&fixfor=21699 + + == Where To Report Bugs == + + Use JIRA to report issues: + + http://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=show&createNew=true + + Do not use Apache Bugzilla (it does not accept Struts bugs anyway). == TO DO == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMavenRelease" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMavenRelease -- = Struts Maven 2 Release Process = - == 1. Releasing Struts Action == + == 1. Releasing Struts Action 1 == 1. Create the new directory on cvs.apache.org, for example cvs.apache.org/dist/struts/action/v1.3.x (no, don't actually use 'x') 1. Ensure that your settings.xml contains a for apache-maven-test-builds (see the Suggested Settings section on StrutsMaintenanceMaven) 1. Clear out your local Maven repo - 1. Build all jar and war artifacts, including -sources and -javadoc, + 1. Build, test and deploy all jar and war artifacts, including -sources and -javadoc. - 11. verifiy war files - 111. cd to {your struts checkout}/action/integration/apps-it - 111. run $mvn -P perform-itest - 11. deploy them to maven-snapshot-repository. 1. Build and deploy the website 1. Create the assembly and upload it to cvs.apache.org/dist - 1. Make sure that everything under maven-snapshot-repository/org/apache/struts is group writeable + 1. Make sure that everything under maven-snapshot-repository/org/apache/struts/ and www/struts.apache.org/struts-action is group writeable - 1. Create and upload signatures for all .jar and .pom files in maven-snapshot-repository, and the .zip, and .tar.gz files. + 1. Create and upload signatures for all .jar and .pom files in maven-snapshot-repository, and the .zip assembly file. {{{ + ~/svn/struts/current/action - rm -rf $M2_REPO/org/apache/struts/action + $ rm -rf $M2_REPO/org/apache/struts/action - mvn deploy -P pre-assembly + $ mvn deploy -P pre-assembly,perform-itest {about 20 minutes later...} - mvn site site:deploy + $ mvn site site:deploy - {may have to deploy the site for each module individually} - cd assembly + $ cd assembly - mvn assembly:assembly + $ mvn assembly:assembly - scp target/assembly/out/* people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.x + $ scp target/assembly/out/* people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.x }}} == 2. Releasing the struts-parent pom == - 1. Update the version number in pom/pom.xml (remove -SNAPSHOT) and commit changes + 1. Update the version number in maven/pom/pom.xml (remove -SNAPSHOT) and commit changes 1. Post release vote on dev@ 1. 'mvn deploy' to deploy to dist/maven-repository 1. Upload a signature for the deployed pom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMaintenanceWebsite" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceWebsite -- - After the subproject reorganization: + === Edit === + * Edit the src/site/site.xml and src/site/xdoc/*.xml files. + * Execute 'mvn site' from the top level of the project, for example: 'struts/current/action' - * Edit the xdocs/*.xml files. - * Run 'maven multiproject:site' from the 'site' subproject (NOT from 'build') + === Preview === + * To preview the site locally: 'mvn site:run' (?? Might not work yet, or might require a snapshot of maven-site-plugin) + * Or point your browser at target/site/index.html (but be aware that relative links to modules won't work) + + === Deploy === + + * To deploy: mvn site:deploy (See the Suggested Settings section on StrutsMaintenanceMaven to avoid repeated password prompts) + + Or + - * From the command line, change to the site/target/docs directory + * From the command line, change to the site/target/site directory * scp the website files to people.apache.org. * Using PuTTY, the command is: pscp -r *.* [EMAIL PROTECTED]:/www/struts.apache.org * Using Cygwin, the command is: scp -r * [EMAIL PROTECTED]:/www/struts.apache.org - * After an hour, the copy on people will propogate to the main website. (So test your local copy first!) * You can update the site for a single sub-project by using the correct destination path. For example: {{{ - /svn/struts/current/tiles + /svn/struts/current/action/tiles $ maven clean site ... - $ scp -r target/docs/* [EMAIL PROTECTED]:/www/struts.apache.org/struts-tiles + $ scp -r target/site/* [EMAIL PROTECTED]:/www/struts.apache.org/struts-tiles }}} + After you deploy the site, check the permissions! + === Permissions === - (See also: 'maven site:deploy' on http://maven.apache.org/maven-1.x/reference/plugins/site/) - - Note: * Everyone should ssh to people.apache.org and set your umask to 002 ($ umask 002). This will mark the files so that other people in the Struts group can update them. * If the permissions are not set correctly, you can fix it with: $ chmod -R g+w . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMaintenanceMaven" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven -- == Integration Testing == - The Maven 2 [http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html build lifecycle] includes a phase for integration testing. Currently, a module may contain only unit tests ''or'' integration tests, but not both. See the [http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies testing strategies] page for discussion and proposals. + The Maven 2 [http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html build lifecycle] includes a phase for integration testing. See the [http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies testing strategies] page for discussion and proposals. Integration tests for Struts Action are located under the '''integration''' module. Integration tests will only be run if the ''perform-itest'' profile is enabled. - - === Cactus Tests === - - The Cactus tests for Struts Taglib are located in the action/integration/taglib-it module. To run the tests, you must provide a value for the 'cargo.tomcat5x.home' System property, for example: - {{{ -~/svn/struts/current/action/integration/taglib-it -$ mvn -P perform-itest -Dcargo.tomcat5x.home=c:/java/apache-tomcat-5.5.16 - }}} - - (This will run the default '''install''' goal which includes the '''integration-test''' phase.) - - See the Suggested Settings section below for information on configuring the 'cargo.tomcat5x.home' System property in your settings.xml file, so that you don't have to specify it on the command line. - - There is no Cactus plugin for Maven 2, so - * The Struts Taglib testing webapp is manually configured for Cactus with extra information in web.xml, and a jspRedirector.jsp file in the root directory. - * Executions of the Surefire, Compiler, War, and Cargo plugins are bound to various lifecycle phases - - '''NOTE:''' If the tests fail, Cargo will not be able to stop the container. === Apps === @@ -92, +74 @@ }}} Then visit http://localhost:8080/webappname in your browser. This requires that the cargo.tomcat5x.home system property is set, usually either on the command line (-Dcargo.tomcat5x.home=...) or in ~/.m2/settings.xml. See the Suggested Settings section, below. + === Cactus Tests === + + The Cactus tests for Struts Taglib are not working and have been moved to the sandbox/apps-test/taglib-it module. == Suggested Settings == @@ -154, +139 @@ To avoid repeated password prompts, configure the apache-maven-snapshots in ~/.m2/settings.xml. + == Releases == + + * StrutsMavenRelease + == References == * [http://www.mergere.com/m2book_download.jsp Better Builds With Maven] - free book from Mergere (requires registration) * [http://www.developer.com/open/article.php/10930_3552026_2 This article] provides a good introduction to Maven 2 and lists some other useful goals. - * StrutsMavenRelease == TODO == * Consolidate some of the example apps to reduce the size of the distribution (?Suggested by Don?) * Create a custom deployment plugin to handle promoting our test builds from cvs.apache.org/maven-snapshot-repository to www.apache.org/dist/maven-repository. * http://www.nabble.com/Re%3A-m2-Releases-and-test-builds-p3824610.html - * Figure out how to run the Cactus tests in 'integration/el-it' against the strutsel-exercise-taglib webapp which is in the 'apps' module. + * Figure out how to run the Cactus tests in 'sandbox/apps-test/el-it' against the strutsel-exercise-taglib webapp which is in the 'apps' module. * http://www.nabble.com/Cargo-and-Maven-2-and-Cactus-t1420342.html * Fix the Cactus tests for Struts Taglib * Revisit the war plugin configuration for including the source code in the example webapps under WEB-INF/src. This is currently being done with an execution of the antrun plugin in apps/pom.xml. Martin mentions that a element is present in the war plugin source, but it does not appear to be available in the latest released version. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "SAF1RoughSpots" by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/SAF1RoughSpots -- == Code Issues == - 1. '''I/O conversion''' [MichaelJ] The suckiest part of SAF1 is I/O conversion. !FormDef seem to solve most conversion/validation issues, so bring !FormDef into Struts core and consider using dynaforms with nested business objects as a best practice. + 1. '''I/O conversion''' [MichaelJ] The suckiest part of SAF1 is I/O conversion. [https://formdef.dev.java.net/ FormDef] seem to solve most conversion/validation issues, so bring !FormDef into Struts core and consider using dynaforms with nested business objects as a best practice. - 1. '''SAF1 lifecycle''' [MichaelJ] The lifecycle of SAF1 is quite simple, for a user's perspective it includes just reset/populate/validate functions. Consider to call all lifecycle functions explicitly from an action class, no more automatic population. + 1. '''SAF1 lifecycle''' [MichaelJ] The lifecycle of SAF1 is quite simple; from a user's perspective it includes just reset/populate/validate functions. Consider the option to call all lifecycle functions explicitly from an action class, no more automatic population. * [FrankZ] I personally would not want to see the auto-population and validation and such go away. I think them being declarative is a powerful notion. I DO however agree that a developer should be able to turn them off declaratively and do it all manually. - * [MichaelJ] Considering to call lifecycle functions explicitly does not mean removing autopopulation from the next release :) 1. '''Automatic validation''' [MichaelJ] Deprecate automatic validation, newbies always stumble upon the fact that their action class is not called when validation fails. Instead, promote explicit validation. * [FrankZ] Definite -1 from me. Again, I'm +1 to being able to turn it on and off, but I very much believe it should be there. Perhaps there is some room for better logging in the cases you mention? - * [MichaelJ] Deprecating autovalidation does not mean removing that feature from the next release :) I hope you reconsider your "-1" or do you want me to remove "deprecate" word entirely? I think that without autovalidation things will be clearer: action class will always be called, and different error conditions with different targets can be supported. 1. '''Input attribute''' [MichaelJ] Deprecate "input" attribute of "action" tag in struts-config.xml. At least, rename it to "error" or something. A frequent misconception is to think that the lifecycle starts with displaying an "input" page, which is obviously not true. * [FrankZ] +0. I don't disagree with you at all, and I think there are probably other things that could similarly be changed. However, I think it is very important that anything done with SAF1 be evolutionary and take backwards-compatibility into consideration in a big way. I think if you want revolution you go for SAF2 (a minor revolution in that it's theoretically still compatible) or Shale. - * [MichaelJ] Hey Frank, now ''you'' are writing me off the boat? ;) What if I want some revolution staying within SAF1 codebase? 1. '''Form attribute''' [MichaelJ] Add "form" attribute with the same meaning as "name" attribute; deprecate "name". * [FrankZ] +0. Same comment as the above point. - * [MichaelJ] Again, "add" means add. It does not mean removing "name" in the next release. 1. '''Differentiate forward from redirect in mappings''' [MichaelJ] "forward" tag implements both forward and redirect, this is confusing. Implement two separate tags like "render" for forward and "transfer" for redirect. "forward" tag still can be kept for compatibility purposes. * [FrankZ] Hmm, I'm not sure how I feel about that. Maybe simply adding a type attribute, ala Webwork, would do the trick? "forward" or "redirect" as values? @@ -46, +42 @@ }}} - This mapping use new format for action mapping. "component" is essentially "action" with different defaults and some new elements. This is 1:1 correspondence between mapping and action class. Same action class handles input phase as well as render phase (I saw your remark about Redirect-After-Post, here it is, implemented). + This mapping uses the action mapping format introduced in Struts Dialogs project. A "component" is essentially an "action" with different defaults and some new elements. This is 1:1 correspondence between mapping and action class. Same action class handles input phase as well as render phase (I saw your remark about Redirect-After-Post, here it is, implemented). 1. '''!DispatchActions''' [MichaelJ] Having that many dispatching actions in the
[Struts Wiki] Update of "WildcardsForActionMappings" by afattahi
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by afattahi: http://wiki.apache.org/struts/WildcardsForActionMappings -- } abstract Search() abstract initSearch() - abstract Edd() + abstract Edit() - abstract initEdd() + abstract initEdit() } }}} - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "WildcardsForActionMappings" by afattahi
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by afattahi: http://wiki.apache.org/struts/WildcardsForActionMappings New page: == WildcardsForActionMappings == One of the new features in Struts 1.2. is the support of wildcards for action mapping. A sample could be found at http://struts.apache.org/struts-action/userGuide/building_controller.html#action_mapping_example This feature can be used in advance to generalize the actions even more. Consider below as a very usual example: Imagine a system which has an accounting form that enables user to inserts, updates and search for its accounts. This system also has a product form which does the same for product. A good deign is to do encapsulate all related forms actions (search, edit, form initialization etc...) in one FormAction. If we put all action in one java action, then will we found which action must take place for each request to the form? Is this request for editing account or searching it? Well, we can use the old fashion(!) DispatchLookUpAction and deal with dispatch parameter. Another alternative is using action wild cards consider below sample: === Example === {{{ type="com.mycompany.{1}FormAction" name="{1}{2}FormBean" parameter="dispatch" validate="false" scope="request" > Too bad struts does not support wild card for forward names!!! }}} The above pattern accepts /Account/EditForm.do, /Account/SearchForm.do, /Product/SearchForm.do etc... So no need for sending dispatch parameter, the url itself contains the requested action (Edit,Search). In your action, you can get this second parameter by parsing the request URI. (Maybe strust has a utility for it!) Below code does this by calling the getMethod, {{{ String getActionPath(HttpServletRequest req) { String path; path = req.getRequestURI(); path = path.substring(path.lastIndexOf('/') + 1); return path; } String getMethod() throws WebException { String method = getActionPath(Req); //Assume that the path is /Account/SearchForm.do etc... method = method.replaceAll("Form.do", ""); log.debug("Method '" + method + "' found from action path."); if (!method.equals(EDIT_FORM_METHOD) && !method.equals(SEARCH_FORM_METHOD)) { throw new WebException("Invaild internal Method", WebException.INVALID_INPUT); } return method; } }}} So: user calls /Account/EditForm.do Struts calls AccountFormAction class. And in this action you can get the actual method. Struts also forwards to proper jsp, which for this sample it will be /main/form/AccountEditForm.jsp Imagine the lot that you can do when mixing above feature with a nice parent class, which does all same tasks for actions by itself, and only calls use casespecific methods. As you might have notice all forms have the same flow and same task should be done for all of them, form should be displayed, after user submitted back the form, form must be validated first for user input ( not null fields etc) then for business validation. If user did not entered valid data, form is initialized and send back to user So you can create a parent for all form actions, like below: {{{ public abstract class BaseFormAction { execute() { //YOU CAN DO LOT HERE //get the method(); //Validate user inputs. If there is an error forward to show.METHOD.from //This METHOD will be Edit or Search //if method is search // call Search(); // if method is add // call Add() } abstract Search() abstract initSearch() abstract Edd() abstract initEdd() } }}} All abstracts will be implemented in actual classes ( AccountFormAction ). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "FrontPage" by afattahi
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by afattahi: http://wiki.apache.org/struts/FrontPage -- * StrutsSolutions -- A page to find solutions to common "ways of doing things"-type questions * ["StrutsIDEGuides"] -- Guides to help IDE users work on and with Struts * StrutsLogging -- How to enable logging so that you can see more messages from Struts + * WildcardsForActionMappings -- How to use advance wildcards === Project Maintenance and Resources === * StrutsReleasePlans -- Release plans for each Struts release - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- addPerson.jsp }}}The ValidationInterceptor should still cause an input result to occur but if we make it through to invoking the action and there is no execute method we return the value of the configured assumed result. + 1. When an action returns `LOGIN`, save the request in the session (even POSTs) and enable the user to re-execute it after login. + == What JDK Version? == * [jcarreira] We've been using JDK 1.5 on Tomcat 5+ for over a year... Everything we write and wire together is using generics and annotations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by RainerHermanns
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by RainerHermanns: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] I'd encourage people to give the ww: tags a spin... they're really much more powerful than the JSTL or previous struts tags and you don't need so many tags to do things. On being closer to HTML attributes, do you have some examples? * [mrdon] +1 for aligning attributes with HTML attributes * [tm_jee] -1. If I'm not mistaken I think WW's tag are doing stuff in a broader perspective, typically in a theme perspective and I hope we could still keep it that way, if possible. A textfield for example, merely says its a textfield, how it behaves is entirely up to the particular theme. Normally, one would extends from a parent theme, and overide those components' template that they want alteration accordingly or introduce other templates that could co-exists with their counterparts to skin the component. + * [rainerh] Big -1... The ww tags are no dynamic replacement for simple HTML tags, but a complete set of UI components. With these themeable components small and large webapps can be easily build. All (important) HTML attributes are supported, not for the simple tags, but for the complete component. 1. Actions should return concrete objects, not symbolic results. Symbolic results might have been optimal when you had one event/method per action and the outcomes were always whole-page views, but they get in the way now. When you want to return anything that requires more than the symbol, you have to do some less than intuitive things to make the Action and the Result cooperate. I'd prefer to see a concrete Result get returned from Action methods, which would allows developers to do more powerful things more easily. There are a bunch of ways to make it backward compatible too. You could return 'new SymbolicResult("success")' and have the SymbolicResult do the lookup stuff (You could even redefine the String constants to be SymbolicResults). You could alternatively use a static class to do Results.find(SUCCESS). Or you could even allow method to continue to return String or Result, and if String wrap it in a SymbolicResult. * [frankz] +1. This is one area where I personally think Struts had it right and we've seen frameworks getting it "wrong" subsequently. !ActionForward I believe is the right concept, even if the realization might not be optimal. I think the difference between return "ok"; and return new ActionResult("ok"); is pretty minimal, but the later opens up a lot of possibilities being a true object that can have behaviors and properties and such. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- }}} * [jcarreira] That depends on whether you're using the form tag or not, but agreed... the XHTML theme should be cleaned up and made the default. - * [tm_jee] XHTMl them is currently the default, if not mistaken. + * [tm_jee] XHTML theme is currently the default, if not mistaken. 1. File upload should support progress notification. Have a look at webwork-multipart on java.net, it's based on the pell parser but has a progress API. * [jcarreira] We've implemented this at work with WebWork fileupload + DWR + a class that looks at the file as it's uploading to see how big it is on disk @@ -282, +282 @@ * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. + * [tm_jee] I agree with Phil, I still like configuring through configuration without recompilation. 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. @@ -338, +339 @@ * [jcarreira] I think this is a bad idea, in general. Actions should specify the exact things they need and have them supplied, not just ask for the "world" (the ActionContext is the world the action lives in). * [mrdon] While I agree more specific is generally better, I like the idea of the user being able to subclass ActionContext for their particular application. Tapestry has the Visit object (I think that's the name) I've always liked. * [plightbo] Tim's suggestion of allowing actions to get the ActionContext without referencing the thread local is a good one. This is in line with other requests to reduce the number of situations where users have to deal with ThreadLocals. + * [tm_jee] I think its ok, if we allow action to implements say ActionContextAware and have an interceptor "inject" the ActionContext into it. 1. HTML analog tags should stick to HTML attributes. I don't mean they shouldn't have more functionality, but the attributes should be identical where possible, and they shouldn't do things like render a label and an input. Keeping them more like regular HTML tags makes them easier to ramp up on, and more non-developer friendly * [MJ] I see the following options when it comes to tags. (1) Use plain HTML + implicit scoped variables like "actionName", "actionAddress", etc. to create dynamic values; this looks pretty compact with JSP 2.0. (2) Use 1:1 relation between WW tags and HTML tags. (3) Use 1:M relation between WW tags and HTML tags, like to create data entry form or a table. (4) Use non-HTML-looking tags + more abstract attributes + "media" attribute, thus creating something like JSF renderer for different media. Choosing between (1) and (2) I prefer the first one. * [jcarreira] I'd encourage people to give the ww: tags a spin... they're really much more powerful than the JSTL or previous struts tags and you don't need so many tags to do things. On being closer to HTML attributes, do you have some examples? * [mrdon] +1 for aligning attributes with HTML attributes + * [tm_jee] -1. If I'm not mistaken I think WW's tag are doing stuff in a broader perspective, typically in a theme perspective and I hope we could still keep it that way, if possible. A textfield for example, merely says its a textfield, how it behaves is entirel
[Struts Wiki] Update of "RoughSpots" by Eric Molitor
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by Eric Molitor: http://wiki.apache.org/struts/RoughSpots -- 1. [molitor] Modular Ant Build, I've started working on this using the build files that Jason supplied (which were forwarded on to me). Allows the project to build in whole or in part with seperate build files that extend a set of common/parent build files. Should parallel the maven build. * [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get familiar with Maven and would like to keep an alternate optiona available. :-) + 1. [molitor] Ability to use values on the stack to override/define configuration options. My patch for the StreamResult is just one application of this, there are many others. + + 1. [molitor] Ability to invoke an action without an execute method. If I annotate a class with @assume_success (or something like @assumed result=SUCCESS) I shouldn't need an execute method. In XML this could be achieved something like this.{{{ +showPerson.jsp +addPerson.jsp + }}}The ValidationInterceptor should still cause an input result to occur but if we make it through to invoking the action and there is no execute method we return the value of the configured assumed result. + == What JDK Version? == * [jcarreira] We've been using JDK 1.5 on Tomcat 5+ for over a year... Everything we write and wire together is using generics and annotations. @@ -442, +449 @@ * [crazybob] You're right. That's actually been my experience, too. I'm fine with supporting 1.4 (though I'd prefer not to have to write the code as I haven't used it for some time). * [rainerh] +1 for Java 5 support * [tm_jee] +1 + * [molitor] +1 for JDK 1.5+ * [niallp] +1 for JDK 1.5 (btw I did a [http://mail-archives.apache.org/mod_mbox/struts-user/200601.mbox/[EMAIL PROTECTED] POLL on what jdk people used] in Jan). Although it will prevent some users upgrading, maybe for others it will be part of the ''tipping point'' to encourage them to move to 1.5. Also what will the JDK landscape look +1 year from now - I believe most users take their time before upgrading, so thats probably a realistic timescale for the vast majority to consider SAF2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] I can attest that the Spring scoped components work well with WebWork. It's what we use at work for maintaining session or request state. * [plightbo] Let's not dismiss Tim's comments too quickly. While we might not implement a solution exactly like he suggests, his point is valid that handling state management in WebWork has always been a very week area. The ScopeInterceptor isn't a great option either, especially considering one of my other issues specifically asks that we avoid having to create custom interceptor stacks for various actions. * [jcarreira] I'm open to hearing good ideas for state management. Especially short-lived wizard type state. Long lived session state (things like your user profile) work really well as Spring session-scoped components, but state which is just used for the next 4 or 5 pages isn't such a good fit. + * [MJ] I think talking in terms of pages does not really get us further from ancient SAF1 practices. A web resource can have one view (page) or ten. A wizard can have ten pages defined, but it can use only 3 or 5 of them depending on current state and transitions. It is better to think in terms of web resources, and when it goes out of scope. A wizard is a distinct web resource, who cares how many pages it has. I have built a wizard engine a year ago, and it proved its viability and robustness. No XML, by the way. Check the [http://www.superinterface.com/wizard/signupWizard.do sample]. Try to break it with Reload, Back and Forward buttons. The wizard code hasn't been changed for almost a year, which shows the maturity. I can provide the code and the docs if there is interest. I know that Tim as well as Jason dislike session-scoped data. I hope you guys change your point of view. + * [MJ] In regards to wizards and Redirect-After-Post pattern, does Webwork have something like FlashScope? FlashScope works for only one redirect call, so there may be something longer than FlashScope, but shorter than session. At best, it would be great if a stateful component like a wizard, could be assigned to its own FlashScope+ . 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and maybe more importantly, it wouldn't automatically be available to helper classes as it is as a !ThreadLocal. That would address my concern about "inappropriate" usage of !ActionContext. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by JasonCarreira
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by JasonCarreira: http://wiki.apache.org/struts/RoughSpots -- 1. Do we want to keep `ModelDriven`? * [Gabe] Absolutely YES! `ModelDriven` allows us to build forms and populate the model without a prefix. It's simple. It also allows for security interceptors to zero in on one method for `ModelDriven` actions to determine what to secure. * [plightbo] I think we should give some serious thought to this. Look around the internal implementation of WebWork/XWork as well as the number of questions that come up on the mailing lists. It's a very confusing thing, especially when interacting with setting or getting values of form fields. + * [jcarreira] yes, it makes the internal implementation more complex, but it makes things easier for the user of the framework in a lot of cases. If people are confused by it, they can choose not to use it. 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. * [mrdon] Keys are fine, as long as you can do parameter replacement easily enough later. Not all apps need L18N, so I'm kinda against the fail fast. Perhaps in devMode, we add a clear warning? @@ -266, +267 @@ 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? * [mrdon] +1, at least in some form. This was the goal of the generic ActionContext, I believe. Cocoon has been struggling with the same issue, and they are leaning towards implementing the HttpServletRequest, et al with a portlet impl to solve this problem. They used to have this generic "Environment" api, but they are in the process of giving that up, I believe, favoring this servlet api approach. I wonder if we shouldn't find out more about their results and adopt them. * [plightbo] +1. we should keep this in mind when designing the API. + * [jcarreira] -1 to using the HttpServletRequest... Why do we need it? We've got a nice abstraction with the Maps for parameters, session, and application scopes, I think. Why tie to the servlet API and make a phony one to proxy to Portlets? 1. Add "action" and "method" attributes to the submit button tag so users don't have to know about the "action:Name" and "method:name" conventions. * [plightbo] We already do this :) @@ -296, +298 @@ * [jcarreira] I think we should have some pre-defined ones for standard things: view vs. CRUD vs. "action" -> do somthing that's not CRUD. We should then use annotations to make it where you can declaratively associate a particular action method with a "stereotype" which is mapped to an interceptor stack, etc. * [crazybob] "C[R]UD" isn't a good name because "view" == "[R]etrieve". Let's call it "update" for the moment. What will the difference be between "update" and "action"? * [plightbo] I really don't think having a "update" and "action" stack is a good idea. Let's make a single stack and then have the stack behave differently depending on the context in which the action was executed. There are several options (GET vs POST, method names, annotations, etc). + * [jcarreira] I really think this is a bad idea and will lead to great suffering... We put in interceptors to allow people to customize the processing of a request, why move away from that now? I think if we do some thinking we can think of the common use-cases that cover 80+% of the action cases, and make it very easy for an action developer to tag this action as using one of that small number of stereotypical uses. The action will then pick up the configuration set up for that stereotype (which could include things like defaulting the result pages to go to, etc.) == Gabe's Issues == 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name="view*" where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in ex
[Struts Wiki] Update of "StrutsMaintenanceMaven" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Add link to the Maven book -- == References == + * [http://www.mergere.com/m2book_download.jsp Better Builds With Maven] - free book from Mergere (requires registration) * [http://www.developer.com/open/article.php/10930_3552026_2 This article] provides a good introduction to Maven 2 and lists some other useful goals. * StrutsMavenRelease - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMaintenanceMaven" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Add notes on the apps-it module -- '''NOTE:''' The 'assembly:assembly' goal must be run from action/assembly. Somehow, this needs to be coordinated with release:prepare and release:perform, so that the assembly will contain the same jars that were just deployed to the repository. - - === Source Assembly === - - * The source code is included in struts-action-x.x.x-all.zip. - - * Wait for v2.1 of maven-assembly-plugin, then consider switching to the action/assembly/src/main/assembly/src.xml and dep.xml descriptors for separate -bin and -src assemblies. - - * See StrutsMaven2Plan for some additional thoughts on assemblies. - == Integration Testing == The Maven 2 [http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html build lifecycle] includes a phase for integration testing. Currently, a module may contain only unit tests ''or'' integration tests, but not both. See the [http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies testing strategies] page for discussion and proposals. @@ -88, +79 @@ === Apps === - Tests for the '''apps''' module are not currently automated with Maven 2. + The integration/apps-it module contains tests to confirm that each example app starts and displays its default page: + {{{ +~/svn/struts/current/action/integration/apps-it +mvn -P perform-itest + }}} - However, each module inherits Cargo plugin configuration (from apps/pom.xml) which will start Tomcat 5.x and deploy the app: + In addition, each module inherits Cargo plugin configuration (from apps/pom.xml) which will start Tomcat 5.x and deploy the app: {{{ + ~/svn/struts/current/action/apps/[module] mvn package cargo:start }}} Then visit http://localhost:8080/webappname in your browser. This requires that the cargo.tomcat5x.home system property is set, usually either on the command line (-Dcargo.tomcat5x.home=...) or in ~/.m2/settings.xml. See the Suggested Settings section, below. @@ -133, +129 @@ cargo-config - c:/java/apache-tomcat-5.5.16 + c:/java/apache-tomcat-5.5.17 c:/java/jakarta-tomcat-4.1.31 @@ -161, +157 @@ == References == * [http://www.developer.com/open/article.php/10930_3552026_2 This article] provides a good introduction to Maven 2 and lists some other useful goals. + * StrutsMavenRelease == TODO == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMaintenanceMaven" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Drop several TODOs that are either done, in progress, or in JIRA. -- * Consolidate some of the example apps to reduce the size of the distribution (?Suggested by Don?) * Create a custom deployment plugin to handle promoting our test builds from cvs.apache.org/maven-snapshot-repository to www.apache.org/dist/maven-repository. * http://www.nabble.com/Re%3A-m2-Releases-and-test-builds-p3824610.html - * Finish converting the xdocs to src/site/site.xml and src/site/xdoc, figure out how the Struts Action site will be arranged and put redirects in .htaccess if necessary. * Figure out how to run the Cactus tests in 'integration/el-it' against the strutsel-exercise-taglib webapp which is in the 'apps' module. * http://www.nabble.com/Cargo-and-Maven-2-and-Cactus-t1420342.html * Fix the Cactus tests for Struts Taglib * Revisit the war plugin configuration for including the source code in the example webapps under WEB-INF/src. This is currently being done with an execution of the antrun plugin in apps/pom.xml. Martin mentions that a element is present in the war plugin source, but it does not appear to be available in the latest released version. * http://www.nabble.com/-m2-Including-the-source-code-in-a-war-t1409417.html * http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html - * Document the Struts Maven 2 release process: StrutsMavenRelease - * Integration tests for the webapps under various container/JDK combinations - * Remove the Tiles dependency from EL (Move the tiles-el tags to Struts Tiles) - * Use in action/trunk/pom.xml to control version numbers. Modules then declare only / for dependencies. + * Use in action/trunk/pom.xml to control version numbers. Modules then declare only / for dependencies. (A brief look says there isn't as much duplication as I thought; this might not be necessary.) - * Add section to action/trunk/pom.xml and generate Javadoc and other reports for the website. - * Reorganize any files found in conf/java and src/conf into src/main/resources and remove the tags from pom.xml. - * Update the Struts Action Blank Archetype (groupId & dependencies) and move it out of the sandbox to action/archetypes/action-blank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by NiallPemberton
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by NiallPemberton: http://wiki.apache.org/struts/RoughSpots The comment on the change is: Comment on JDK 1.5 -- * [crazybob] You're right. That's actually been my experience, too. I'm fine with supporting 1.4 (though I'd prefer not to have to write the code as I haven't used it for some time). * [rainerh] +1 for Java 5 support * [tm_jee] +1 + * [niallp] +1 for JDK 1.5 (btw I did a [http://mail-archives.apache.org/mod_mbox/struts-user/200601.mbox/[EMAIL PROTECTED] POLL on what jdk people used] in Jan). Although it will prevent some users upgrading, maybe for others it will be part of the ''tipping point'' to encourage them to move to 1.5. Also what will the JDK landscape look +1 year from now - I believe most users take their time before upgrading, so thats probably a realistic timescale for the vast majority to consider SAF2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well * [Gabe] -1 I believe XWork should be moved over to Apache and more importantly, the final decision on whether to do so should be made now rather than later. However, I don't believe it should be merged with the former webwork. - - /!\ '''Edit conflict - other version:''' * [phil] -1 - - /!\ '''Edit conflict - your version:''' - - /!\ '''End of edit conflict''' 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 - - /!\ '''Edit conflict - other version:''' * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). - - /!\ '''Edit conflict - your version:''' - * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). * [Gabe] +1 Hopefully, this would only be a modification in our PropertyAccessors to include enums. Here is one place where we will want to figure out a way that we can add these things but remain 1.4 compatible. - /!\ '''End of edit conflict''' 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) @@ -291, +279 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) - - /!\ '''Edit conflict - other version:''' * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. - /!\ '''Edit conflict - your version:''' - - /!\ '''End of edit conflict''' 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. * [Gabe] +1 I've created an XWork issue related: [http://jira.opensymphony.com/browse/XW-388] @@ -318, +301 @@ 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name="view*" where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the push tag to simplify the API. More detail here: [http://jira.opensymphony.com/browse/XW-329] and here: [https://issues.apache.org/struts/browse/WW-1133]. * [plightbo] I still don't
[Struts Wiki] Update of "RoughSpots" by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] You're kidding, right? We've discussed this already * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well + * [Gabe] -1 I believe XWork should be moved over to Apache and more importantly, the final decision on whether to do so should be made now rather than later. However, I don't believe it should be merged with the former webwork. + + /!\ '''Edit conflict - other version:''' * [phil] -1 + + /!\ '''Edit conflict - your version:''' + + /!\ '''End of edit conflict''' 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + + /!\ '''Edit conflict - other version:''' * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). + + /!\ '''Edit conflict - your version:''' + * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). + * [Gabe] +1 Hopefully, this would only be a modification in our PropertyAccessors to include enums. Here is one place where we will want to figure out a way that we can add these things but remain 1.4 compatible. + + /!\ '''End of edit conflict''' 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) @@ -276, +291 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) + + /!\ '''Edit conflict - other version:''' * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. + + /!\ '''Edit conflict - your version:''' + + /!\ '''End of edit conflict''' 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. * [Gabe] +1 I've created an XWork issue related: [http://jira.opensymphony.com/browse/XW-388] @@ -297, +318 @@ 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name="view*" where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the push tag to simplify the API. More detail here: [http://jira.opensymphony.com/browse/XW-329] and here: [https
[Struts Wiki] Trivial Update of "RoughSpots" by Phil
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by Phil: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] If we agree that supporting file uploads out of the box is important, then this is just a nice feature for that support to let the user know how much of the file has been uploaded, etc. 1. Better error checking for UI tags. The freemarker error message, while great for freemarker users, look like gibberish. People should not be forced to learn freemarker. So in such cases, the tags themselves should check the parameters and report back sane messages, even if that check is duplicated in the templates - [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. " Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue]" -> that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. + * [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. " Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue]" -> that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is * [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. @@ -238, +238 @@ * [jcarreira] You're kidding, right? We've discussed this already * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well + * [phil] -1 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). 1. Clean up documentation. Focus on quality not quantity. @@ -274, +276 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) + * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file
[Struts Wiki] Update of "RoughSpots" by plightbo
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by plightbo: http://wiki.apache.org/struts/RoughSpots -- [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. " Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue]" -> that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is - [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [plightbo] Agreed - examples, default results, etc should be JSP. However, we need to keep UI tags in a template language so they can be used in all view technologies. Right now that is FreeMarker, though if we can find a template language that is more like JSP (say, without the scripplets), I would like to switch to that. 1. Get rid of the validation framework. it's stupid and pointless, validate methods are good enough. * [jcarreira] -1 I take offense at this... It's neither stupid NOR pointless, and we use it extensively. It's the best validation framework I've seen out there, and NO, validate methods are NOT enough. For instance, we define reusable validations for our domain models and use them for both the web front end as well as web services and batch imports. * [tmjee] -1 If possible please don't do so. I use it and like it. I guess (for me at least), sometimes for simple validation it is nice to be able to just describe it (using xml or annotation). Plus the validation could be tied to DWR for ajax support. Being able to write custom validator is really cool. Please reconsider this. :-) * [frankz] -1 as well. If you had said the validation framework could stand to be enhanced and expanded on a bit, I'd agree, but I definitely think it should be there, not pointless or stupid at all. Declarative validation is a fantastic approach, especially with validator being a separate Commons component. For instance, we are working on a project at work that is going to use Validator and the CoR implementation in JWP as the basis for a rules engine... I put together a proof of concept showing how we could use the exact same validations in the web front-end via AJAX calls as in the Web Service interface for other systems to call on. Being able to write those validations in XML without having to write actual code was a great thing. * [crazybob] I think sharing validations between AJAX and Java more than justifies the framework. I would like to see us replace most if not all of the XML with annotations. - * [rainerh] -1 on removing the valdation framework. This is one of the best, if not the best validation framework I've seen so far. + * [rainerh] -1 on removing the validation framework. This is one of the best, if not the best validation framework I've seen so far. 1. Ditch xwork as a separate project, nobody uses it or cares about it * [jcarreira] You're kidding, right? We've discussed this already @@ -243, +244 @@ * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) + * [plightbo] The reference docs are great, but we failed terribly on th
[Struts Wiki] Update of "StrutsMavenRelease" by JamesMitchell
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by JamesMitchell: http://wiki.apache.org/struts/StrutsMavenRelease The comment on the change is: Add item for testing the apps with Wendy's new super-cool-webapp-tester-thingee -- 1. Create the new directory on cvs.apache.org, for example cvs.apache.org/dist/struts/action/v1.3.x (no, don't actually use 'x') 1. Ensure that your settings.xml contains a for apache-maven-test-builds (see the Suggested Settings section on StrutsMaintenanceMaven) 1. Clear out your local Maven repo - 1. Build all jar and war artifacts, including -sources and -javadoc, and deploy them to maven-snapshot-repository. + 1. Build all jar and war artifacts, including -sources and -javadoc, + 11. verifiy war files + 111. cd to {your struts checkout}/action/integration/apps-it + 111. run $mvn -P perform-itest + 11. deploy them to maven-snapshot-repository. 1. Build and deploy the website 1. Create the assembly and upload it to cvs.apache.org/dist 1. Make sure that everything under maven-snapshot-repository/org/apache/struts is group writeable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of "RoughSpots" by Phil
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by Phil: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] If we agree that supporting file uploads out of the box is important, then this is just a nice feature for that support to let the user know how much of the file has been uploaded, etc. 1. Better error checking for UI tags. The freemarker error message, while great for freemarker users, look like gibberish. People should not be forced to learn freemarker. So in such cases, the tags themselves should check the parameters and report back sane messages, even if that check is duplicated in the templates + [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. " Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue]" -> that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by Eric Molitor
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by Eric Molitor: http://wiki.apache.org/struts/RoughSpots -- xmlAddPerson.jsp }}}I'd prefer using this approach instead of having the xmlAction chain to another. * [tm_jee] Sounds cool. It would probably be an overkill to extend this idea into the interceptor as well, wouldn't it. + * [molitor] Agree, falls on the short side of the 80/20 rule 1. [molitor] Modular Ant Build, I've started working on this using the build files that Jason supplied (which were forwarded on to me). Allows the project to build in whole or in part with seperate build files that extend a set of common/parent build files. Should parallel the maven build. * [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get familiar with Maven and would like to keep an alternate optiona available. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) 1. Do we want to keep `ModelDriven`? + * [Gabe] Absolutely YES! `ModelDriven` allows us to build forms and populate the model without a prefix. It's simple. It also allows for security interceptors to zero in on one method for `ModelDriven` actions to determine what to secure. 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. * [mrdon] Keys are fine, as long as you can do parameter replacement easily enough later. Not all apps need L18N, so I'm kinda against the fail fast. Perhaps in devMode, we add a clear warning? @@ -291, +292 @@ 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. * [Gabe] It is an advantage for Interceptors to be able to clean up at the end of a request, but it isn't great how they do that either. Take for example an action chain. If you have a create connection Interceptor surrounding each of the chained actions, you will open two connections, which besides being wasteful could cause problems with other resource types. I wonder if we can create some sort of request scoped ResourceManager class that can allow Interceptors to create resources or access them if they exist and specify how they should be destroyed at the end of the request. Thus in the connection case, the Interceptor could check if the resource manager had one and if not create it and add it to the resource manager for other objects to use. (Another option of course is an inversion of control approach) - * [jcarreira] Interceptors can still change the result... Implement PreResultListener and in your callback, change the resultCode and voila! The result executed will be changed. The PreResultListener interface lets you register your interceptor to get a callback after the action and before the result is executed. Oh, and on the ConnectionInterceptor -> It's just like AOP. You have to check if it's been done already and know not to create a new one or close it on the way out. I do this all the time in AOP interceptors, so why should this be different? Personally, I'd rather use the same connection across all of the actions in a chain than clean it up after each one and use a new one per action. For request scoped resources, take a look at Spring's scoped components. I'm using them at work and they work pretty well (a few issues I'm working through with them notwithstanding). + * [jcarreira] Interceptors can still change the result... Implement PreResultListener and in your callback, change the resultCode and voila! The result executed will be changed. The PreResultListener interface lets you register your interceptor to get a callback after the action and before the result is executed. Oh, and on the ConnectionInterceptor -> It's just like AOP. You have to check if it's been done already and know not to create a new one or close it on the way out. I do this all the time in AOP interceptors, so why should this be different? Personally, I'd rather use the same connection across all of the actions in a chain than clean it up after each one and use a new one
[Struts Wiki] Update of "RoughSpots" by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? * [mrdon] +1, at least in some form. This was the goal of the generic ActionContext, I believe. Cocoon has been struggling with the same issue, and they are leaning towards implementing the HttpServletRequest, et al with a portlet impl to solve this problem. They used to have this generic "Environment" api, but they are in the process of giving that up, I believe, favoring this servlet api approach. I wonder if we shouldn't find out more about their results and adopt them. + + 1. Add "action" and "method" attributes to the submit button tag so users don't have to know about the "action:Name" and "method:name" conventions. == Patrick's issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/RoughSpots -- 1. Do we want to keep `ModelDriven`? 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. + * [mrdon] Keys are fine, as long as you can do parameter replacement easily enough later. Not all apps need L18N, so I'm kinda against the fail fast. Perhaps in devMode, we add a clear warning? 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? + * [mrdon] +1, at least in some form. This was the goal of the generic ActionContext, I believe. Cocoon has been struggling with the same issue, and they are leaning towards implementing the HttpServletRequest, et al with a portlet impl to solve this problem. They used to have this generic "Environment" api, but they are in the process of giving that up, I believe, favoring this servlet api approach. I wonder if we shouldn't find out more about their results and adopt them. == Patrick's issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) + + 1. Do we want to keep `ModelDriven`? + + 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. + + 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? == Patrick's issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- /${actionNamespace} }}} My point is this feature enables a new style of development, one closer to RoR and, IMO, easier for the newbie, without affecting anyone else. + * [crazybob] Assuming you have a `getResult()` method and you've defined a global result, your second example could look like this: {{{ + result = ActionRedirectResult("bar", "foo"); + return CUSTOM; + }}} A Ruby on Rails analog would look like this: {{{ + public void execute() { + ... + if (foo) { + redirectToAction("foo", "bar"); + } + else { + forwardToAction("tee"); + } + } + }}} If the user doesn't call a result method, we would use an intelligent default. You could implement this using an interceptor and an action support class. However, I'm with Jason: I've never needed this and I like the seperation. == Nice to haves == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/RoughSpots -- I'm new around here, so be nice ;) I probably have a lot less WW experience than most, so I apologize in advance if I'm flat out wrong about some of the things here. 1. How does WW help the user with state management? As far as I can tell, if I want to keep a 'user' object around I have to interact with the map returned by ActionContext.getSession(). Actions should in general have a type-safe and transparent way to do this, e.g. by subclassing ActionContext and providing getUser()/setUser() which store the user in session. This allows for re-working of the storage strategy (e.g. write a cookie and lookup the user each time) without affecting actions. - * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor` to pull an object off the session and pass it to your action. Or you can use Spring to inject session-scoped objects into your action (though I would avoid Spring personally). - * [jcarreira] I can attest that the Spring scoped components work well with WebWork. It's what we use at work for maintaining session or request state. 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and maybe more importantly, it wouldn't automatically be available to helper classes as it is as a !ThreadLocal. That would address my concern about "inappropriate" usage of !ActionContext. * [jcarreira] I think this is a bad idea, in general. Actions should specify the exact things they need and have them supplied, not just ask for the "world" (the ActionContext is the world the action lives in). + * [mrdon] While I agree more specific is generally better, I like the idea of the user being able to subclass ActionContext for their particular application. Tapestry has the Visit object (I think that's the name) I've always liked. + - 1. HTML analog tags should stick to HTML attributes. I dont' mean they shouldn't have more functionality, but the attributes should be identical where possible, and they shouldn't do things like render a label and an input. Keeping them more like regular HTML tags makes them easier to ramp up on, and more non-developer friendly + 1. HTML analog tags should stick to HTML attributes. I don't mean they shouldn't have more functionality, but the attributes should be identical where possible, and they shouldn't do things like render a label and an input. Keeping them more like regular HTML tags makes them easier to ramp up on, and more non-developer friendly * [MJ] I see the following options when it comes to tags. (1) Use plain HTML + implicit scoped variables like "actionName", "actionAddress", etc. to create dynamic values; this looks pretty compact with JSP 2.0. (2) Use 1:1 relation between WW tags and HTML tags. (3) Use 1:M relation between WW tags and HTML tags, like to create data entry form or a table. (4) Use non-HTML-looking tags + more abstract attributes + "media" attribute, thus creating something like JSF renderer for different media. Choosing between (1) and (2) I prefer the first one. - * I'd encourage people to give the ww: tags a spin... they're really much more powerful than the JSTL or previous struts tags and you don't need so many tags to do things. On being closer to HTML attributes, do you have some examples? + * [jcarreira] I'd encourage people to give the ww: tags a spin... they're really much more powerful than the JSTL or previous struts tags and you don't need so many tags to do things. On being closer to HTML attributes, do you have some examples? + * [mrdon] +1 for aligning attributes with HTML attributes 1. Actions should return concrete objects, not symbolic results. Symbolic results might have been optimal when you had one event/method per action and the outcomes were always whole-page views, but they get in the way now. Wh
[Struts Wiki] Update of "RoughSpots" by JasonCarreira
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by JasonCarreira: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] We've implemented this at work with WebWork fileupload + DWR + a class that looks at the file as it's uploading to see how big it is on disk * [frankz] Just an opinion, but this seems to me too specific a use case for a framework to encapsulate. I think having an example showing how to do it, perhaps what jcarreira has done at work, would be great, but I for one wouldn't like the framework offering this out of the box... I think it is possible for a framework to be able to do TOO much! * [tm_jee] I think this is pretty use case specific as well, but a progress monitor ui component would be nice. + * [jcarreira] If we agree that supporting file uploads out of the box is important, then this is just a nice feature for that support to let the user know how much of the file has been uploaded, etc. 1. Better error checking for UI tags. The freemarker error message, while great for freemarker users, look like gibberish. People should not be forced to learn freemarker. So in such cases, the tags themselves should check the parameters and report back sane messages, even if that check is duplicated in the templates @@ -280, +281 @@ 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. * [Gabe] It is an advantage for Interceptors to be able to clean up at the end of a request, but it isn't great how they do that either. Take for example an action chain. If you have a create connection Interceptor surrounding each of the chained actions, you will open two connections, which besides being wasteful could cause problems with other resource types. I wonder if we can create some sort of request scoped ResourceManager class that can allow Interceptors to create resources or access them if they exist and specify how they should be destroyed at the end of the request. Thus in the connection case, the Interceptor could check if the resource manager had one and if not create it and add it to the resource manager for other objects to use. (Another option of course is an inversion of control approach) + * [jcarreira] Interceptors can still change the result... Implement PreResultListener and in your callback, change the resultCode and voila! The result executed will be changed. The PreResultListener interface lets you register your interceptor to get a callback after the action and before the result is executed. Oh, and on the ConnectionInterceptor -> It's just like AOP. You have to check if it's been done already and know not to create a new one or close it on the way out. I do this all the time in AOP interceptors, so why should this be different? Personally, I'd rather use the same connection across all of the actions in a chain than clean it up after each one and use a new one per action. For request scoped resources, take a look at Spring's scoped components. I'm using them at work and they work pretty well (a few issues I'm working through with them notwithstanding). == Tim's Issues == I'm new around here, so be nice ;) I probably have a lot less WW experience than most, so I apologize in advance if I'm flat out wrong about some of the things here. @@ -288, +290 @@ * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor` to pull an object off the session and pass it to your action. Or you can use Spring to inject session-scoped objects into your action (though I would avoid Spring personally). + * [jcarreira] I can attest that the Spring scoped components work well with WebWork. It's what we use at
[Struts Wiki] Update of "StrutsJavaOne2006" by GregReddin
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by GregReddin: http://wiki.apache.org/struts/StrutsJavaOne2006 -- ||'''Tuesday (Apr 16)'''|| || || || ||Times || Event || Location || Who plans to attend? || - || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || Halls B & C|| JM || + || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || Halls B & C|| JM, GR || ||'''Wednesday (Apr 17)'''|| || || || - || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || || || + || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || ||GR || - || 5:30 PM - 6:30 PM || Struts BOF || Pavilion || DB, JM|| + || 5:30 PM - 6:30 PM || Struts BOF || Pavilion || DB, JM, GR|| - || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM || + || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM, GR || ||'''Thursday (Apr 18)'''|| || || || ||'''Friday (Apr 19)'''|| || || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsJavaOne2006" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsJavaOne2006 -- || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || Halls B & C|| JM || ||'''Wednesday (Apr 17)'''|| || || || || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || || || - || 5:30 PM - 6:30 PM || Struts BOF || || DB, JM|| + || 5:30 PM - 6:30 PM || Struts BOF || Pavilion || DB, JM|| || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM || ||'''Thursday (Apr 18)'''|| || || || ||'''Friday (Apr 19)'''|| || || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsJavaOne2006" by JamesMitchell
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by JamesMitchell: http://wiki.apache.org/struts/StrutsJavaOne2006 New page: What are you going to attend at !JavaOne this year? Current list of Struts happenings and interests. Please add your name to sessions you think you'd like to see. If the session is not listed, please add it. ||'''Tuesday (Apr 16)'''|| || || || ||Times || Event || Location || Who plans to attend? || || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || Halls B & C|| JM || ||'''Wednesday (Apr 17)'''|| || || || || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || || || || 5:30 PM - 6:30 PM || Struts BOF || || DB, JM|| || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM || ||'''Thursday (Apr 18)'''|| || || || ||'''Friday (Apr 19)'''|| || || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "FrontPage" by JamesMitchell
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by JamesMitchell: http://wiki.apache.org/struts/FrontPage The comment on the change is: JavaOne baby!! -- * StrutsFunStuff -- Miscellaneous, generally off-topic pages * StrutsWikiTips -- Tips to more effectively use this wiki * StrutsJobJar -- Help wanted + * StrutsJavaOne2006 -- Struts specific hangouts/parties and anything else related to Struts at JavaOne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- 1. Remove `destroy()` and `init()` from `Interceptor`. They don't make much sense until the interceptor lifecycle is specified (see next item). I've never needed them, yet it's a pain to implement empty methods every time I implement an interceptor. Users can use the constructor/finalizer or we can create additional lifecycle interfaces. * [plightbo] I don't really care. This ties more in to the next item... + * [tm_jee] I'd prefer to keep them as a separate optional implementable interface as Bob advised, such that Interceptor interface implementor are not required to implement them, and for the minority who needs them, its there. 1. Specify `Interceptor` lifecycle. Right now if we apply an interceptor to a single action, we get a new instance every time. If we define an interceptor in a stack, the same instance gets reused. * [jcarreira] A new instance per action configuration, right? Not per-invocation... * [crazybob] Last I tested it was per invocation (I remember because it surprised me). This is actually a non-issue. We'll create a custom `ConfigurationProvider` for Struts which won't have this problem. * [plightbo] Agreed, by abstracting most configuration out, we can control the lifecycle. I think the lifecycle should be either once per interceptor or once per invocation. Currently the implementation is too cumbersome (once per unique action configuration). - * [tm_jee] I'd prefer to keep them as a separate optional implementable interface as Bob advised, such that Interceptor interface implementor are not required to implement them, and for the minority who needs them, its there. + 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods doesn't make things simpler. It reduces flexibility. We can't return a different result. You can't handle exceptions cleanly. The actual interceptor class doesn't appear in the stack trace (we see `AroundInterceptor` over and over). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] A new instance per action configuration, right? Not per-invocation... * [crazybob] Last I tested it was per invocation (I remember because it surprised me). This is actually a non-issue. We'll create a custom `ConfigurationProvider` for Struts which won't have this problem. * [plightbo] Agreed, by abstracting most configuration out, we can control the lifecycle. I think the lifecycle should be either once per interceptor or once per invocation. Currently the implementation is too cumbersome (once per unique action configuration). + * [tm_jee] I'd prefer to keep them as a separate optional implementable interface as Bob advised, such that Interceptor interface implementor are not required to implement them, and for the minority who needs them, its there. 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods doesn't make things simpler. It reduces flexibility. We can't return a different result. You can't handle exceptions cleanly. The actual interceptor class doesn't appear in the stack trace (we see `AroundInterceptor` over and over). @@ -99, +100 @@ to write applications that work for portlets too? I would hope that we all work towards a world where direct access to the underlying servlet API objects is considered an anti-pattern. * [crazybob] Another good point. + 1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would be a better name. @@ -111, +113 @@ * [crazybob] Does "specified" == "documented"? Can you elaborate on "easily knowing when you're done" and why we can't address that use case with one interface? We should expose the user to one interface: `Invocation`. We can have as many objects as we like when it comes to the internal implementation. * [plightbo] Big +1. I would add the ValueStack to this list as well. Let's have one object for each invocation, and also make "sub invocations" (chaining or ww:action calls) a first class citizen through child/parent invocation relationships. * [jcarreira] Let's have an interactive design session on this... I'm not sure it's as easy as you think to merge them all into one (although behind one interface should be doable). + * [tm_jee] Sorry, I don't get this bit. :-P We could just expose ActionInvocation. ActionProxy could be obtained from ActionInvocation. Or maybe just expose ActionProxy's method in ActionInvocation, but actually its just delegating to ActionProxy. Did I miss something? 1. Should `ActionInvocation.getResult()` recurse over chain results? Maybe we should have two methods? `getResult()` and `getFinalResult()`. Is there a good use case for this? @@ -129, +132 @@ * [mrdon] I dunno, are you planning to make protected getters/setters for every field? I've found protected fields to be invaluable when extending frameworks (again, subscribing to the believe we should let the user do what they want and not artifically restrict them). I do wish you could declare the fields _only_ available to subclasses and not to the whole package. * [crazybob] Absolutely, methods instead of fields. Methods enable us to hook access if need be, change the underlying implementation, manage thread safety, protect our own code against unexpected conditions/states, etc. Fields are OK within a package, but when it comes to public APIs, better safe than sorry a year from now. * [jcarreira] Oops, I was translating "fields" -> "properties" and thinking of getters and setters. + * [tm_jee] I am kindof thinking in the same line as Don. 1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is better. @@ -140, +144 @@ * [plightbo] The name doesn't bother me, but the implementation is far too complex. I would propose we cut it down from all the crazy package/interface/model-driven stuff we have now to a simple i18n RB loading approach that uses 0 or more global bundles as well as bundles associated with the _view_ (NOT the action, since that never made much sense). * [mrdon] I'd like to see this re-evaluated as well. For one, I want to make it easier to provide an impl that gets messages from a Struts bundle, which really isn't possible now. * [jcarreira] +1 to simplifying. We started with lots of separate resource bundles for per-action texts, but we're moving to one resource bundle per module. It's too much hassle. + * [tm_jee] I like the feature WebWork has that allows resource bundle to be overriden at different levels through inheritance hierarchy, package hierarchy and a global level. If possible, please keep them. :-)
[Struts Wiki] Update of "RoughSpots" by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- xmlAddPerson.jsp }}}I'd prefer using this approach instead of having the xmlAction chain to another. + * [tm_jee] Sounds cool. It would probably be an overkill to extend this idea into the interceptor as well, wouldn't it. 1. [molitor] Modular Ant Build, I've started working on this using the build files that Jason supplied (which were forwarded on to me). Allows the project to build in whole or in part with seperate build files that extend a set of common/parent build files. Should parallel the maven build. - [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get familiar with Maven and would like to keep an alternate optiona available. :-) + * [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get familiar with Maven and would like to keep an alternate optiona available. :-) == What JDK Version? == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- }}}I'd prefer using this approach instead of having the xmlAction chain to another. 1. [molitor] Modular Ant Build, I've started working on this using the build files that Jason supplied (which were forwarded on to me). Allows the project to build in whole or in part with seperate build files that extend a set of common/parent build files. Should parallel the maven build. + [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get familiar with Maven and would like to keep an alternate optiona available. :-) == What JDK Version? == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by tmjee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by tmjee: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] You had me until the abstract class bit... Does it have to be abstract? Also, this limits testability in not-ok-ways... * [crazybob] It only has to be abstract if you want your action to be able to call methods on the mixin without casting. If it doesn't need to call those methods, there's no need for your action to explicitly implement that interface. You could also say `((ValidationAware) this).addActionError()`. I personally don't mind making the action abstract. In IntelliJ, you just make a mock class that extends your action and it will automatically generate stubs for the methods. * [plightbo] As mentioned earlier, you might be able to do this by using the value stack. For example, you could stick in a single "ValidationSupport" object at the bottom of the stack and then all classes would add error messages there. By adding a simple *Aware interface, actions could get a handle to that for adding error messages. - - * [jcarreira] Very nice idea... +1 ... We already do something like that. There's always a default TextProvider pushed onto the bottom of the stack for getting default texts... makes localized texts work with Sitemesh, for instance, when you're not hitting an action. Of course, that will be a problem when we're not using ThreadLocals. + * [jcarreira] Very nice idea... +1 ... We already do something like that. There's always a default TextProvider pushed onto the bottom of the stack for getting default texts... makes localized texts work with Sitemesh, for instance, when you're not hitting an action. Of course, that will be a problem when we're not using ThreadLocals. + * [tm_jee] What about keeping ActionSupport but instead have an AbstractActionSupport which ActionSupport extends off which consisting of getter/setters for the plugable strategy (like setValidatable(...) setValidationAware(...) setTextProvider(...) etc). There will be a default for those if none is set. We could then wired them in through Spring since Sprinc is now the recommended IOC container. + 1. [molitor]Extends support on actions in xml (Configuration Inheritance). Occasionally I want to utilize an existing action but only change one parameter. It would be nice to do something as simple as.{{{ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of "StrutsMavenRelease" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMavenRelease -- {may have to deploy the site for each module individually} cd assembly mvn assembly:assembly - scp target/assembly/out/* people.apache.org:/www/cvs.apache.org/dist/struts/action/v.1.3.x + scp target/assembly/out/* people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.x }}} == 2. Releasing the struts-parent pom == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMavenRelease" by JamesMitchell
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by JamesMitchell: http://wiki.apache.org/struts/StrutsMavenRelease The comment on the change is: make the version a bit generic -- == 1. Releasing Struts Action == - 1. Create the new directory on cvs.apache.org, for example cvs.apache.org/dist/struts/action/v1.3.2 + 1. Create the new directory on cvs.apache.org, for example cvs.apache.org/dist/struts/action/v1.3.x (no, don't actually use 'x') 1. Ensure that your settings.xml contains a for apache-maven-test-builds (see the Suggested Settings section on StrutsMaintenanceMaven) 1. Clear out your local Maven repo 1. Build all jar and war artifacts, including -sources and -javadoc, and deploy them to maven-snapshot-repository. @@ -21, +21 @@ {may have to deploy the site for each module individually} cd assembly mvn assembly:assembly - scp target/assembly/out/* people.apache.org:/www/cvs.apache.org/dist/struts/action/v.1.3.2 + scp target/assembly/out/* people.apache.org:/www/cvs.apache.org/dist/struts/action/v.1.3.x }}} == 2. Releasing the struts-parent pom == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of "StrutsActionRelease132" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 -- || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || (./) || - || A5. || Update all pom.xml files to "1.3.3-SNAPSHOT" || || + || A5. || Update all pom.xml files to "1.3.3-SNAPSHOT" || (./) || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || (./) || || A7. || Post release-quality vote on dev@ and user@ lists || (./) || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of "StrutsActionRelease133" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease133 -- == Release Manager == - The release manager is '''Don Brown''' + The release manager is '''Wendy Smoak''' == How to Help == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease133" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease133 New page: = Struts Action 1.3.3 Release = == Info == 1. Struts [http://struts.apache.org/releases.html#Releases Release Guidelines] 2. [http://wiki.apache.org/incubator/SigningReleases Signing Releases] 3. Apache [http://apache.org/dev/mirrors.html Mirroring Guidelines] == Release Manager == The release manager is '''Don Brown''' == How to Help == Everyone in the Struts community, users, developers, and committers, is encouraged to test a release, report any issues, and post to dev@ any comments on the overall quality of the release. To help everyone get started with Struts Action 1.3.3 (when it is available), here are the simplest installation instructions that can possibly work: * Download the Struts 1.3.3 distribution from http://svn.apache.org/dist/struts/action/v1.3.3/ (when it is available.) (Until then, try a [http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/ snapshot].) * Extract the distribution to a likely location (/opt/struts-action-1.3.3) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME * Install Apache Tomcat * http://wiki.apache.org/struts/StrutsMaintenanceMaven * Change to the new folder (e.g., /opt/struts-action-1.3.3/src) * $ mvn * Wait about five minutes for Maven to download and build everything ** If you see any error messages, please do a quick search of the mail archives and/or post them on the Dev list, and if they appear to be newly introduced issues, a Jira tickets will need to be created so we can track and resolve the issue as quickly as possible. Oh, and THANK YOU for your help. == Outstanding Bugs == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10121&fixfor=21710 == TO DO == == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || || 1. || Announce plan to dev@ list || || || 2. || Review/Resolve Outstanding Bugs || || || 3. || Update Release Notes || || || 4. || Check Dependencies || || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the "beta/release-candidate/final" process. Likewise, the [http://httpd.apache.org/dev/release.html HTTPD Release Guidelines] is a helpful "overall process" backgrounder, but HTTPD does not use a test-build stage. External Dependency versions for this release: || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' || || Antlr || 2.7.2 || Released || Struts Validator || || Commons !BeanUtils || 1.7.0 || Released || core (!ActionServlet, configuration, !DynaActionForm) || || Commons Chain || 1.0 || Released || core (!RequestProcessor) || || Commons Digester || 1.6 || Released || core (!ActionServlet, configuration) || || Commons !FileUpload || 1.1 || Released || Struts Upload || || Commons IO || 1.1 || Released || Required by Commons !FileUpload || || Commons Logging || 1.0.4 || Released || core (logging all over) || || Commons Validator || 1.3.0 || Released || Struts Validator || || Jakarta Oro || 2.0.8 || Released || Commons Validator || == Testing Checklist == === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || || || 2. || Run Cactus Tests (see below) || || || 3. || Play test examples application (TC 5.0.x) || || === Cactus Tests === || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Status''' || || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || || || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || || || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || || || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || || == Test Build Checklist (A) == See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || || A0. || Update all pom.xml files to omit "-SNAPSHOT" || || || A1. || Tag release in svn: STRUTS_ACTION_1_3_3 || || || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.3 || || || A5. || Update all pom.xml files to "1.3.4-SNAPSHOT" || || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || || A7. || Post release-quality vote on dev@ and user@ lists || || == Vote (A) == || PMC Member || Quality || Voting thread is _ If release vote fails, including for a lack of quorum, remove from dist folder. == Point Release Checklist (B) == || '''#''' || '''Description''' || '''Completed''' || || B1. || Create Sums and Sign Dist
[Struts Wiki] Trivial Update of "StrutsReleasePlans" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsReleasePlans -- * StrutsTaglibRelease131 - ''Struts Taglib Version 1.3.1'' (cancelled) * StrutsExtrasRelease131 - ''Struts Extras Version 1.3.1'' (cancelled) * StrutsActionRelease132 - ''Struts Action Version 1.3.2'' + * StrutsActionRelease133 - ''Struts Action Version 1.3.3'' == 1.2.x == * StrutsRelease122 - ''Struts Version 1.2.2'' * StrutsRelease123 - ''Struts Version 1.2.3'' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease132" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 -- || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || (./) || || A5. || Update all pom.xml files to "1.3.3-SNAPSHOT" || || - || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || + || A6. || Announce the Test Build on dev@ and user@ lists (optional) || (./) || - || A7. || Post release-quality vote on dev@ and user@ lists || || + || A7. || Post release-quality vote on dev@ and user@ lists || (./) || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease132" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 -- To help everyone get started with Struts Action 1.3.2 (when it is available), here are the simplest installation instructions that can possibly work: * Download the Struts 1.3.2 distribution from http://svn.apache.org/dist/struts/action/v1.3.2/ (when it is available.) (Until then, try a [http://cvs.apache.org/builds/struts/maven/trunk/nightly/struts-action/ snapshot].) - * Extract the distribution to a likely location (\opt\struts-action-1.3.2) + * Extract the distribution to a likely location (/opt/struts-action-1.3.2) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME * Install Apache Tomcat @@ -88, +88 @@ See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || - || A0. || Update all pom.xml files to omit "-SNAPSHOT" || || + || A0. || Update all pom.xml files to omit "-SNAPSHOT" || (./) || - || A1. || Tag release in svn: STRUTS_ACTION_1_3_2 || || + || A1. || Tag release in svn: STRUTS_ACTION_1_3_2 || (./) || - || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || + || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || (./) || - || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || || + || A3. || Deploy Test Build to cvs.apache.org/maven-snapshot-repository || (./) || - || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || || + || A4. || Upload Distribution to people.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || (./) || || A5. || Update all pom.xml files to "1.3.3-SNAPSHOT" || || || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || || A7. || Post release-quality vote on dev@ and user@ lists || || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMaintenanceMaven" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsMaintenanceMaven The comment on the change is: Added the for apache-site -- yourid /path/to/private/key + + apache-site + yourid + /path/to/private/key + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsActionRelease132" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsActionRelease132 -- == Preparation Checklist == || '''#''' || '''Description''' || '''Status''' || - || 1. || Announce plan to dev@ list || || + || 1. || Announce plan to dev@ list || (./) || - || 2. || Review/Resolve Outstanding Bugs || || + || 2. || Review/Resolve Outstanding Bugs || (./) || - || 3. || Update Release Notes || || + || 3. || Update Release Notes || (./) || - || 4. || Check Dependencies || || + || 4. || Check Dependencies || (./) || The Commons [http://jakarta.apache.org/commons/releases/prepare.html Preparation Guide] is a helpful preparation backgrounder, but Commons uses the "beta/release-candidate/final" process. @@ -61, +61 @@ || Commons !FileUpload || 1.1 || Released || Struts Upload || || Commons IO || 1.1 || Released || Required by Commons !FileUpload || || Commons Logging || 1.0.4 || Released || core (logging all over) || - || Commons Validator || 1.2.0 || Released || Struts Validator || + || Commons Validator || 1.3.0 || Released || Struts Validator || || Jakarta Oro || 2.0.8 || Released || Commons Validator || == Testing Checklist == @@ -69, +69 @@ === Testing Summary === || '''#''' || '''Description''' || '''Completed''' || - || 1. || Run Unit Test targets || || + || 1. || Run Unit Test targets || (./) || - || 2. || Run Cactus Tests (see below) || || + || 2. || Run Cactus Tests (see below) || All fail || - || 3. || Play test examples application (TC 5.0.x) || || + || 3. || Play test examples application (TC 5.0.x) || (./) || === Cactus Tests === || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Status''' || - || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || _ || + || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || N/A || - || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || _ || + || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || N/A || - || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || _ || + || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || N/A || - || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || _ || + || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || N/A || == Test Build Checklist (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMaintenanceMaven" by DonBrown
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsMaintenanceMaven -- The Cactus tests for Struts Taglib are located in the action/integration/taglib-it module. To run the tests, you must provide a value for the 'cargo.tomcat5x.home' System property, for example: {{{ -~/svn/struts/current/action/integration +~/svn/struts/current/action/integration/taglib-it $ mvn -P perform-itest -Dcargo.tomcat5x.home=c:/java/apache-tomcat-5.5.16 }}} - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "SAF1RoughSpots" by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/SAF1RoughSpots -- 1. '''SAF1 lifecycle''' [MichaelJ] The lifecycle of SAF1 is quite simple, for a user's perspective it includes just reset/populate/validate functions. Consider to call all lifecycle functions explicitly from an action class, no more automatic population. * [FrankZ] I personally would not want to see the auto-population and validation and such go away. I think them being declarative is a powerful notion. I DO however agree that a developer should be able to turn them off declaratively and do it all manually. + * [MichaelJ] Considering to call lifecycle functions explicitly does not mean removing autopopulation from the next release :) 1. '''Automatic validation''' [MichaelJ] Deprecate automatic validation, newbies always stumble upon the fact that their action class is not called when validation fails. Instead, promote explicit validation. * [FrankZ] Definite -1 from me. Again, I'm +1 to being able to turn it on and off, but I very much believe it should be there. Perhaps there is some room for better logging in the cases you mention? + * [MichaelJ] Deprecating autovalidation does not mean removing that feature from the next release :) I hope you reconsider your "-1" or do you want me to remove "deprecate" word entirely? I think that without autovalidation things will be clearer: action class will always be called, and different error conditions with different targets can be supported. 1. '''Input attribute''' [MichaelJ] Deprecate "input" attribute of "action" tag in struts-config.xml. At least, rename it to "error" or something. A frequent misconception is to think that the lifecycle starts with displaying an "input" page, which is obviously not true. * [FrankZ] +0. I don't disagree with you at all, and I think there are probably other things that could similarly be changed. However, I think it is very important that anything done with SAF1 be evolutionary and take backwards-compatibility into consideration in a big way. I think if you want revolution you go for SAF2 (a minor revolution in that it's theoretically still compatible) or Shale. + * [MichaelJ] Hey Frank, now ''you'' are writing me off the boat? ;) What if I want some revolution staying within SAF1 codebase? 1. '''Form attribute''' [MichaelJ] Add "form" attribute with the same meaning as "name" attribute; deprecate "name". * [FrankZ] +0. Same comment as the above point. + * [MichaelJ] Again, "add" means add. It does not mean removing "name" in the next release. 1. '''Differentiate forward from redirect in mappings''' [MichaelJ] "forward" tag implements both forward and redirect, this is confusing. Implement two separate tags like "render" for forward and "transfer" for redirect. "forward" tag still can be kept for compatibility purposes. * [FrankZ] Hmm, I'm not sure how I feel about that. Maybe simply adding a type attribute, ala Webwork, would do the trick? "forward" or "redirect" as values? + * [MichaelJ] Check out this mapping from one of the users of Struts Dialogs 1.x (he uses Tiles too): + {{{ + + + + + + + + + + + + + + + }}} + + This mapping use new format for action mapping. "component" is essentially "action" with different defaults and some new elements. This is 1:1 correspondence between mapping and action class. Same action class handles input phase as well as render phase (I saw your remark about Redirect-After-Post, here it is, implemented). + - 1. '''DispatchActions''' [MichaelJ] Having that many dispatching actions in the distro, all of them but !EventDispatchAction and more generic EventActionDispatcher should be deprecated. + 1. '''!DispatchActions''' [MichaelJ] Having that many dispatching actions in the distro, all of them but !EventDispatchAction and more generic EventActionDispatcher should be deprecated. 1. '''Tiles improvements''' [MichaelJ] Improve Tiles to support real components, that can be fully independent of composite page, can process user input, and can render themselves. 1. '''Per-request Action instantiation''' [FrankZ] Actions should be instantiated for each request, therefore removing the thread safety concerns that exist today. + * [MichaelJ] +0. Not sure that this bothers me anymore :) 1. '''Pure POJO !ActionForms''' [FrankZ] An !ActionForm should not need to extend !ActionForm. The framework would have to be smart enough to not call validate() and such in that case. This would allow for the Action to be the !ActionForm as well, and this is really the underlying goal because many people view them
[Struts Wiki] Update of "SAF1RoughSpots" by FrankZammetti
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by FrankZammetti: http://wiki.apache.org/struts/SAF1RoughSpots -- == Code Issues == - 1. The suckiest part of SAF1 is I/O conversion. !FormDef seem to solve most conversion/validation issues, so bring !FormDef into Struts core and consider using dynaforms with nested business objects as a best practice. + 1. '''I/O conversion''' [MichaelJ] The suckiest part of SAF1 is I/O conversion. !FormDef seem to solve most conversion/validation issues, so bring !FormDef into Struts core and consider using dynaforms with nested business objects as a best practice. - 1. The lifecycle of SAF1 is quite simple, for a user's perspective it includes just reset/populate/validate functions. Consider to call all lifecycle functions explicitly from an action class, no more automatic population. + 1. '''SAF1 lifecycle''' [MichaelJ] The lifecycle of SAF1 is quite simple, for a user's perspective it includes just reset/populate/validate functions. Consider to call all lifecycle functions explicitly from an action class, no more automatic population. + * [FrankZ] I personally would not want to see the auto-population and validation and such go away. I think them being declarative is a powerful notion. I DO however agree that a developer should be able to turn them off declaratively and do it all manually. - 1. Deprecate automatic validation, newbies always stumble upon the fact that their action class is not called when validation fails. Instead, promote explicit validation. + 1. '''Automatic validation''' [MichaelJ] Deprecate automatic validation, newbies always stumble upon the fact that their action class is not called when validation fails. Instead, promote explicit validation. + * [FrankZ] Definite -1 from me. Again, I'm +1 to being able to turn it on and off, but I very much believe it should be there. Perhaps there is some room for better logging in the cases you mention? - 1. Deprecate "input" attribute of "action" tag in struts-config.xml. At least, rename it to "error" or something. A frequent misconception is to think that the lifecycle starts with displaying an "input" page, which is obviously not true. + 1. '''Input attribute''' [MichaelJ] Deprecate "input" attribute of "action" tag in struts-config.xml. At least, rename it to "error" or something. A frequent misconception is to think that the lifecycle starts with displaying an "input" page, which is obviously not true. + * [FrankZ] +0. I don't disagree with you at all, and I think there are probably other things that could similarly be changed. However, I think it is very important that anything done with SAF1 be evolutionary and take backwards-compatibility into consideration in a big way. I think if you want revolution you go for SAF2 (a minor revolution in that it's theoretically still compatible) or Shale. - 1. Add "form" attribute with the same meaning as "name" attribute; deprecate "name". + 1. '''Form attribute''' [MichaelJ] Add "form" attribute with the same meaning as "name" attribute; deprecate "name". + * [FrankZ] +0. Same comment as the above point. - 1. "forward" tag implements both forward and redirect, this is confusing. Implement two separate tags like "render" for forward and "transfer" for redirect. "forward" tag still can be kept for compatibility purposes. + 1. '''Differentiate forward from redirect in mappings''' [MichaelJ] "forward" tag implements both forward and redirect, this is confusing. Implement two separate tags like "render" for forward and "transfer" for redirect. "forward" tag still can be kept for compatibility purposes. + * [FrankZ] Hmm, I'm not sure how I feel about that. Maybe simply adding a type attribute, ala Webwork, would do the trick? "forward" or "redirect" as values? - 1. Having that many dispatching actions in the distro, all of them but !EventDispatchAction and more generic EventActionDispatcher should be deprecated. + 1. '''DispatchActions''' [MichaelJ] Having that many dispatching actions in the distro, all of them but !EventDispatchAction and more generic EventActionDispatcher should be deprecated. - 1. Improve Tiles to support real components, that can be fully independent of composite page, can process user input, and can render themselves. + 1. '''Tiles improvements''' [MichaelJ] Improve Tiles to support real components, that can be fully independent of composite page, can process user input, and can render themselves. + + 1. '''Per-request Action instantiation''' [FrankZ] Actions should be instantiated for each request, therefore removing the thread safety concerns that exist today. + + 1. '''Pure POJO !ActionForms''' [FrankZ] An !ActionForm
[Struts Wiki] Trivial Update of "FrontPage" by FrankZammetti
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by FrankZammetti: http://wiki.apache.org/struts/FrontPage -- * StrutsArchives (Archives Carrying Struts Lists ) * StrutsMaintenance -- Notes for committer project maintenance tasks * StrutsCodeAudits -- Links to reports on code syntax and quality - * Action1RoughSpots -- A discussion of the areas where the Struts Action1 framework needs work to continue its evolution === Future Ideas and Extensions === * [:Shale:StrutsShale] -- A proposal for a next generation Struts architecture @@ -56, +55 @@ * ["StrutsMoreAboutJSF"] -- JSF vs. Struts (Is this still relevant?) * StrutsAction2 -- Discussion on plans/tasks for Struts Action 2.0 * StrutsWhiteboard -- Project proposals and discussion - * ["SAF1RoughSpots"] -- what can be improved in Struts 1.x + * ["SAF1RoughSpots"] -- Discussions of what can be done to continue the evolution of Struts Action1 Framework * SetupItems -- Struts extension to better handle dropdown list setup * AjaxStruts -- Ajax using XMLHttpRequest and Struts * StandaloneTiles -- Ideas how to separate Tiles from Struts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "Action1RoughSpots" by FrankZammetti
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by FrankZammetti: http://wiki.apache.org/struts/Action1RoughSpots -- - The purpose of this page is for people, anyone, to post their thoughts on what they would like to see happen in Struts Action1 framework (that is, the non-Webwork, non-Shale version of Struts). As the name implies, it should be a list of current "rough spots". + deleted - * '''Per-request Action instantiation''' [FrankZ] Actions should be instantiated for each request, therefore removing the thread safety concerns that exist today. - - * '''Pure POJO !ActionForms''' [FrankZ] An !ActionForm should not need to extend !ActionForm. The framework would have to be smart enough to not call validate() and such in that case. This would allow for the Action to be the !ActionForm as well, and this is really the underlying goal because many people view them being separate as a rough spot. - - * '''Built-in AJAX support''' [FrankZ] I am not entirely sure what the best form for this is, although I believe the !AjaxTags paradigm still has a great deal of merit. In any case, in today's world, not offering some degree of AJAX out of the box is probably a rough spot for many. - - * '''Custom attributes on tags''' [FrankZ] All Struts tags that render HTML should allow for arbitrary attributes. I again propose a "specCompliant" attribute on the tag. When true, no arbitrary attributes are allowed (this would be the default if the attribute is not present). If false, any attribute can be added. This has been a hassle for me a couple of times where I wanted to store some custom information on a tag for client-side purposes. - - * '''The ability to switch off auto-form population''' [FrankZ] The idea here is that Struts would still instantiate an !ActionForm and call reset(), but that's it. This can be useful if you want to use an !ActionForm only as an output object, but want to handle input manually. This came up for me converting a non-Struts app to Struts, where there was no notion of an !ActionForm in the previous framework. - - * '''Built-in dependency injection''' [FrankZ] This should be modeled after what is offered in JSF. If we took the code from the !DependencyFilter in Java Web Parts, added in true injection (shouldn't be a terribly big deal), I believe we would have even better capabilities than in JSF. Spring is of course still out there for those that need/want more! This may not be so much a rough spot as just a fairly low-hanging piece of fruit (because most of the work is already done by virtue of leveraging !DependencyFilter) that I think people would appreciate having. - - * '''!ThreadLocal !ActionContext''' [FrankZ] Yes, I think this is one place we should flat-out rip off Webwork :) Backwards-compatibility would have to be considered, but I'd like Actions to have to deal with a single object, and for that object to be accessible via the !ThreadLocal mechanism. This should also open the door for POJO Actions. - - * '''Built-in support for RAP (Redirect After Post) pattern''' [FrankZ] I'm not sure how best to accomplish this, but this should be a very easy thing for a developer to do, the framework should do any required heavy lifting. Again, not so much a rough spot as it is something I think a lot of people would appreciate. - - * '''Pre and post-processing abilities''' [FrankZ] A developer should be able to specify a class and method to call before and after an Action executes, on a per-mapping basis. This should be independant of modifying a chain. Should just amount to adding the appropriate config file changes and two commands to the default chain. This is for handling things like common setup of view-type Actions, etc. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "Action1RoughSpots" by FrankZammetti
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by FrankZammetti: http://wiki.apache.org/struts/Action1RoughSpots New page: The purpose of this page is for people, anyone, to post their thoughts on what they would like to see happen in Struts Action1 framework (that is, the non-Webwork, non-Shale version of Struts). As the name implies, it should be a list of current "rough spots". * '''Per-request Action instantiation''' [FrankZ] Actions should be instantiated for each request, therefore removing the thread safety concerns that exist today. * '''Pure POJO !ActionForms''' [FrankZ] An !ActionForm should not need to extend !ActionForm. The framework would have to be smart enough to not call validate() and such in that case. This would allow for the Action to be the !ActionForm as well, and this is really the underlying goal because many people view them being separate as a rough spot. * '''Built-in AJAX support''' [FrankZ] I am not entirely sure what the best form for this is, although I believe the !AjaxTags paradigm still has a great deal of merit. In any case, in today's world, not offering some degree of AJAX out of the box is probably a rough spot for many. * '''Custom attributes on tags''' [FrankZ] All Struts tags that render HTML should allow for arbitrary attributes. I again propose a "specCompliant" attribute on the tag. When true, no arbitrary attributes are allowed (this would be the default if the attribute is not present). If false, any attribute can be added. This has been a hassle for me a couple of times where I wanted to store some custom information on a tag for client-side purposes. * '''The ability to switch off auto-form population''' [FrankZ] The idea here is that Struts would still instantiate an !ActionForm and call reset(), but that's it. This can be useful if you want to use an !ActionForm only as an output object, but want to handle input manually. This came up for me converting a non-Struts app to Struts, where there was no notion of an !ActionForm in the previous framework. * '''Built-in dependency injection''' [FrankZ] This should be modeled after what is offered in JSF. If we took the code from the !DependencyFilter in Java Web Parts, added in true injection (shouldn't be a terribly big deal), I believe we would have even better capabilities than in JSF. Spring is of course still out there for those that need/want more! This may not be so much a rough spot as just a fairly low-hanging piece of fruit (because most of the work is already done by virtue of leveraging !DependencyFilter) that I think people would appreciate having. * '''!ThreadLocal !ActionContext''' [FrankZ] Yes, I think this is one place we should flat-out rip off Webwork :) Backwards-compatibility would have to be considered, but I'd like Actions to have to deal with a single object, and for that object to be accessible via the !ThreadLocal mechanism. This should also open the door for POJO Actions. * '''Built-in support for RAP (Redirect After Post) pattern''' [FrankZ] I'm not sure how best to accomplish this, but this should be a very easy thing for a developer to do, the framework should do any required heavy lifting. Again, not so much a rough spot as it is something I think a lot of people would appreciate. * '''Pre and post-processing abilities''' [FrankZ] A developer should be able to specify a class and method to call before and after an Action executes, on a per-mapping basis. This should be independant of modifying a chain. Should just amount to adding the appropriate config file changes and two commands to the default chain. This is for handling things like common setup of view-type Actions, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "FrontPage" by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/FrontPage -- * ["StrutsMoreAboutJSF"] -- JSF vs. Struts (Is this still relevant?) * StrutsAction2 -- Discussion on plans/tasks for Struts Action 2.0 * StrutsWhiteboard -- Project proposals and discussion + * ["SAF1RoughSpots"] -- what can be improved in Struts 1.x * SetupItems -- Struts extension to better handle dropdown list setup * AjaxStruts -- Ajax using XMLHttpRequest and Struts * StandaloneTiles -- Ideas how to separate Tiles from Struts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "SAF1RoughSpots" by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/SAF1RoughSpots New page: Struts Action 1 (a.k.a. Struts Classic) is a well-known framework. It has its deficiencies, but workarounds are known as well. For many, continuing to use SAF1 makes sense even after release of SAF2. This page tries to summarize major issues with SAF1 and possibilities to fix them or provide better workarounds. == Code Issues == 1. The suckiest part of SAF1 is I/O conversion. !FormDef seem to solve most conversion/validation issues, so bring !FormDef into Struts core and consider using dynaforms with nested business objects as a best practice. 1. The lifecycle of SAF1 is quite simple, for a user's perspective it includes just reset/populate/validate functions. Consider to call all lifecycle functions explicitly from an action class, no more automatic population. 1. Deprecate automatic validation, newbies always stumble upon the fact that their action class is not called when validation fails. Instead, promote explicit validation. 1. Deprecate "input" attribute of "action" tag in struts-config.xml. At least, rename it to "error" or something. A frequent misconception is to think that the lifecycle starts with displaying an "input" page, which is obviously not true. 1. Add "form" attribute with the same meaning as "name" attribute; deprecate "name". 1. "forward" tag implements both forward and redirect, this is confusing. Implement two separate tags like "render" for forward and "transfer" for redirect. "forward" tag still can be kept for compatibility purposes. 1. Having that many dispatching actions in the distro, all of them but !EventDispatchAction and more generic EventActionDispatcher should be deprecated. 1. Improve Tiles to support real components, that can be fully independent of composite page, can process user input, and can render themselves. == Documentation Issues == 1. Struts 1.3.x introduces the concept of chain of commands, but there is no comprehensive documentation on how this new architecture can be used for initial request processing (as a substitute to solid RequestProcessor) as well as for business processing (using Commands instead of Actions, etc). 1. Taglib reference uses too many words for simple things. Words like "attribute", "value", "property" used in different contexts, which does not help much in understanding how the tags really work. 1. Taglib docs should show one best way of doing things instead of saying that one can use this, or this or this in combination with this. 1. Tags that render widgets should have examples and pictures. Here is some initial work in attempt to improve this: StrutsWidgets. == Best Practices Issues == 1. Instead of having several ways to do things, SAF1 should focus on one best and the most common way, even if it involves a couple more lines of code. Less is more. 1. Up until now SAF1 best practices center around a View, usually a JSP page. Instead, best practices should teach the webresource-centered approach. 1. Dispatch-action style request processing should become a cornerstone technique instead of "yet another way of doing things". It works especially well in data entry form processing or menu processing. See DataEntryForm. 1. Best practices should explain that there is nothing wrong in having session-scoped action forms. Best practices should teach how to build stateful web resources. 1. It is possible to build stateful and independent web components with SAF1. Best practices should teach how to do that. 1. !ActionForm should be used as I/O buffer instead of simply collecting user input from request. 1. Emphasize using of nested properties, using business objects as nested properties, using dynaforms holding business objects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of "FrontPage" by FrankZammetti
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by FrankZammetti: http://wiki.apache.org/struts/FrontPage -- * StrutsArchives (Archives Carrying Struts Lists ) * StrutsMaintenance -- Notes for committer project maintenance tasks * StrutsCodeAudits -- Links to reports on code syntax and quality + * Action1RoughSpots -- A discussion of the areas where the Struts Action1 framework needs work to continue its evolution === Future Ideas and Extensions === * [:Shale:StrutsShale] -- A proposal for a next generation Struts architecture - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StandaloneTiles" by GregReddin
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by GregReddin: http://wiki.apache.org/struts/StandaloneTiles The comment on the change is: Removed several classes from list of classes with Servlet API dependencies. -- The purpose of this enhancement is to remove Tiles' dependency on the Servlet APIs. The following classes have an API dependency on the Servlet APIs. By that, I mean that the API in these classes must change to remove the dependency on the Servlet APIs. The reason for removing the Servlet API dependency is to make Tiles accessible in a Portlet world. The services provided by the Servlet API will be included in a new Context object yet to be created. - src/java/org/apache/tiles/!ComponentDefinitionsFactory.java[[BR]] src/java/org/apache/tiles/!Controller.java[[BR]] src/java/org/apache/tiles/!ControllerSupport.java[[BR]] - src/java/org/apache/tiles/definition/!ComponentDefinitionsFactoryWrapper.java[[BR]] - src/java/org/apache/tiles/definition/!ReloadableDefinitionsFactory.java[[BR]] src/java/org/apache/tiles/!DefinitionsUtil.java[[BR]] src/java/org/apache/tiles/filter/!TilesFilter.java[[BR]] src/java/org/apache/tiles/servlets/!TilesServlet.java[[BR]] src/java/org/apache/tiles/taglib/util/!TagUtils.java[[BR]] src/java/org/apache/tiles/!TilesUtilImpl.java[[BR]] src/java/org/apache/tiles/!UrlController.java[[BR]] - src/java/org/apache/tiles/xmlDefinition/!DefinitionsFactory.java[[BR]] - src/java/org/apache/tiles/xmlDefinition/!FactorySet.java[[BR]] - src/java/org/apache/tiles/xmlDefinition/!I18nFactorySet.java[[BR]] src/java/org/apache/tiles/util/!RequestUtils.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- 1. Allow indexable parameters similar to how it works in struts (with indexed="true") but being able to take advantage of XWork's advanced type conversion features. See: [https://issues.apache.org/struts/browse/WW-1189]. This is unfortunately not trivial at all. 1. Get rid of the use of static constant variables that are used in the key in the stack and accessed all over the place like XWorkNullHandler.CREATE_NULL_OBJECTS etc. I've started to do that with the OgnlContextState class, but it's not complete and I'm not sure if that's the best way to do it. 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. - * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. + * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. + * [Gabe] It is an advantage for Interceptors to be able to clean up at the end of a request, but it isn't great how they do that either. Take for example an action chain. If you have a create connection Interceptor surrounding each of the chained actions, you will open two connections, which besides being wasteful could cause problems with other resource types. I wonder if we can create some sort of request scoped ResourceManager class that can allow Interceptors to create resources or access them if they exist and specify how they should be destroyed at the end of the request. Thus in the connection case, the Interceptor could check if the resource manager had one and if not create it and add it to the resource manager for other objects to use. (Another option of course is an inversion of control approach) == Tim's Issues == I'm new around here, so be nice ;) I probably have a lot less WW experience than most, so I apologize in advance if I'm flat out wrong about some of the things here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by RainerHermanns
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by RainerHermanns: http://wiki.apache.org/struts/RoughSpots -- lets you get the functionality of a ViewController interface without having to say "implements ViewController" in your action class. * [crazybob] +1 for keeping the `Action` interface--it enforces that `execute()` is the default method. + * [rainerh] +1 for keeping the `Action` interface and +1 for moving the result constants out. 1. Only put classes in root package that most users need to know about. For example, most don't need to know about `Default*` or `ObjectFactory`. * [plightbo] +1 on this - sounds like Bob has a good handle on what it takes to make a nice API. I'll defer to him on this. @@ -40, +41 @@ depend on versus those extending the framework should be allowed to extend. The latter category of folks can be presumed to be smaller, as well as more willing to deal with occastional API breakages. * [crazybob] +1 for "impl" package naming convention. I think we should focus on the application developer API for the initial release and then introduce a more featureful extension API in a later release. + * [rainerh] +1 for "impl" packages as well 1. Only make classes/members public if we're willing to guarantee future compatibility. Everything else should be package-private or excluded from the Javadocs. @@ -66, +68 @@ * [crazybob] It's kind of hard to forget to call `invocation.invoke()`; you have to return something. ;) Interceptors are already an "expert" feature anyway. * [plightbo] Big +1. * [mrdon] +1 as well + * [rainerh] +1 from me as well 1. Try to get rid of thread locals: `ActionContext` and `ServletActionContext`. At least make them package-private. Sometimes interceptors need access to the servlet API. In this case, they should implement a servlet-aware interceptor interface. For example: {{{ class MyInterceptor implements HttpInterceptor { @@ -100, +103 @@ 1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would be a better name. * [plightbo] Eh, it's not a big deal to me. Errors wouldn't be accurate either though, since there are also generic messages that you can add. + * [rainerh] What about ValidationMessages? 1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at least from the users' perspective). Better specify what happens during chaining/action tags. @@ -153, +157 @@ * [jcarreira] That one always has been confusing... * [mrdon] Or #requestScope keeping in line with JSTL/JSP + * [rainerh] +1 for JSTL/JSP like naming 1. Warnings and failing silently is not the best practice. For example, if we can't find a method in a given action class, blow up ASAP (at load time). We shouldn't be fuzzy and do stuff like try to find a method named `doXxx()` when we can't find a method named `xxx()` (WebWork had backward compatibility restrictions, but we don't need to perpetuate them). * [plightbo] +1, everything should be much more proactive about failing fast and failing with a nice error message. * [mrdon] Agreed, and we have done a lot of work lately on this issue. + * [rainerh] Better error reporting for developers is a very important issue. Latest additions to xwork will help here but could be improved a lot. 1. Add better support for file uploads. @@ -209, +215 @@ * [tmjee] -1 If possible please don't do so. I use it and like it. I guess (for me at least), sometimes for simple validation it is nice to be able to just describe it (using xml or annotation). Plus the validation could be tied to DWR for ajax support. Being able to write custom validator is really cool. Please reconsider this. :-) * [frankz] -1 as well. If you had said the validation framework could stand to be enhanced and expanded on a bit, I'd agree, but I definitely think it should be there, not pointless or stupid at all. Declarative validation is a fantastic approach, especially with validator being a separate Commons component. For instance, we are working on a project at work that is going to use Validator and the CoR implementation in JWP as the basis for a rules engine... I put together a proof of concept showing how we could use the exact same validations in the web front-end via AJAX calls as in the Web Service interface for other systems to call on. Being able to write those validations in XML without having to write actual code was a great thing. * [crazybob] I think sharing validations between AJAX and Java more than justifies the framework. I would like to see us replace most if not all of the XML with annotations. + * [rainerh] -1 on
[Struts Wiki] Update of "ShaleCoreLibrary" by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/ShaleCoreLibrary The comment on the change is: Record another one of Craig's answers. :) -- + = Shale Core Library = + - == Shale Core Library JSF Components and Tags == + == JSF Components and Tags == * [http://struts.apache.org/struts-shale/shale-core/tagreference-taglib.html Tag Reference] @@ -14, +16 @@ }}} + == View Controller == + + === When to use init(), preprocess() and prerender() === + + In [http://www.nabble.com/Re%3A-Shale-AbstractViewController-for-Dummies-p4073019.html this thread], Craig suggests asking yourself the following questions: +1. Do I need the results of this computation in order to process a form submit? +1. Do I need the results of this computation in order to render the page? + + Then, based on your answers, +* Use init() for ''(1) and (2)'' +* Use preprocess() for ''(1) only'' +* Use prerender() for ''(2) only'' + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- 1. Allow indexable parameters similar to how it works in struts (with indexed="true") but being able to take advantage of XWork's advanced type conversion features. See: [https://issues.apache.org/struts/browse/WW-1189]. This is unfortunately not trivial at all. 1. Get rid of the use of static constant variables that are used in the key in the stack and accessed all over the place like XWorkNullHandler.CREATE_NULL_OBJECTS etc. I've started to do that with the OgnlContextState class, but it's not complete and I'm not sure if that's the best way to do it. 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. - + * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. == Tim's Issues == I'm new around here, so be nice ;) I probably have a lot less WW experience than most, so I apologize in advance if I'm flat out wrong about some of the things here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "RoughSpots" by GabrielZimmerman
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification. The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots -- 1. Remove OGNL Map attributes (and List/Set to be consistent) such as size, isEmpty, iterator. These can be accessed by size(), empty, and iterator() respectively and the way it works now you can never have myMap['size'] because it will just get the size not the value of the map with key 'size'. 1. Allow indexable parameters similar to how it works in struts (with indexed="true") but being able to take advantage of XWork's advanced type conversion features. See: [https://issues.apache.org/struts/browse/WW-1189]. This is unfortunately not trivial at all. 1. Get rid of the use of static constant variables that are used in the key in the stack and accessed all over the place like XWorkNullHandler.CREATE_NULL_OBJECTS etc. I've started to do that with the OgnlContextState class, but it's not complete and I'm not sure if that's the best way to do it. + 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. == Tim's Issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]