[Struts Wiki] Update of "StrutsCatalogInputOutputSeparation" 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/StrutsCatalogInputOutputSeparation
--
What if we need to use one form? Say, we have a wizard or a dialog, which
shares data. No problem, this even easier than to have two forms. Just define
the form with session scope, and it will retain all input data between requests.
attachment:actioncombo08.gif
+ Follows the example from a working CRUD application.
+ {{{
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ }}}
+
+ Let's check out the output action first, editItem. Notice, that it does not
care where it was called from and was it forwarded to or redirected to. All it
knows, that it recieves object id in the ID property of its form bean. Well, I
cheated a little, using the same form bean for input and for output in this
case.
+
+ If item is not found, action forward to error page. If a user reloads error
page, editItem action would try to locate the item again, which does not change
server state, but can improve situation if the item is found. On the other
hand, it would be cleaner to use redirection to error page, so that database
would not be bothered if error page is reloaded. If item is found, editItem
shows it.
+
+ Updated item is submitted to storeItem action. It is an input action and uses
form bean to collect browser data. If data is incorrect, errors are generated
and saved in the session, then control is redirected back to output action,
editItem, which redisplays the item along with the errors. If data is correct,
item is stored in the database and control is redirected to the home page. Home
page can be reloaded, this will not incur item resubmit.
+
+ createItem creates new item. This would be an input action, but it has no
input parameters. It does not have output data either, since it redirects to
editItem which is output action for createItem.
See also: StrutsMultipleActionForms
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsMultipleActionForms" 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/StrutsMultipleActionForms
--
Simon Matic Langford
-
+ See also StrutsCatalogInputOutputSeparation
- Two actions, two forms
-
- I found action chaining with redirection to be the best solution. Chaining
allows to have more fine-grained actions which are less dependent on each
other. Redirection allows to get rid of POSTDATA situation.
-
- attachment:twoacttwoformsredir.gif
-
- {{{
-
-
-
-
-
-
-
- }}}
-
- This design can be used to handle input and output of web applications. The
source action receives the request, the source form validates the input data.
If input is valid, the control is redirected to output action. Output action
loads output data into output form and forwards to JSP.
-
- The control flow in detail:
-
-* Struts calls reset() on the input form bean (1)
-* Struts populates the fields of input form bean using setters (2). Input
form bean does not have to define the getters.
-* Struts calls validate() on input form bean (3)
-* If validate() returns non-empty !ActionErrors object, control is
forwarded (or redirected) to an error page identified by "input" attribute of
the action mapping (4a) Before returning, validate() needs to store error
messages in the session-scoped object, so errors would be available in the
output action.
-* if validate() returns empty !ActionErrors object or null, Struts calls
execute() method of the input action class (4b)
-* execute() updates business and persistent objects.
-* in most cases, execute() cannot simply redirect to a static URL defined
in struts-config.file. Input action must tell output action which object to
show. The object ID can be passed either through session-scoped object or as
parameter of redirected request. If ID is passed as request parameter, then
execute() creates new !ActionForward instance with modified URI of the target
action, adding to it the ID of an object which must be displayed.
-* When execute() returns "OK", Struts redirects to the output action (5)
-* Struts does its usual reset()/populate/validate() sequence on output
bean. Actually there is no populate phase, since request contains no data,
except object ID, which is set in the output bean. And validate() has nothing
to validate in the output form, so it returns null.
-* execute() method of the action class locates business object, using ID
passed with the request, and fills out the fields of the output form.
-* output action returns "OK" and Struts displays the result page (8)
-
- A great side effect of this solution is that output page can be reloaded
without processing the request in input action again. This helps to prevent
double submission of input data.
-
- Choosing between passing object ID in redirected request or in the session
- Passing parameter through the session-scoped object is less flexible. First,
if different form beans are used, this cannot be done through a form bean, thus
ID would have to be stored in the session. Consequently, output action must
know about this session parameter. On the other hand, if output action were
called directly, the ID would be in the request. Thus, output action would have
to check session first to verify if it was redirected to, and if not, read ID
from the request.
-
- This is too complex for my tastes. Passing parameter in the redirected
request makes output action simpler and universal, it just picks the parameter
from the request and uses it. It does not know or care, how exactly it was
called.
-
- Follows the example from a working CRUD application.
-
- {{{
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- }}}
-
- Let's check out the output action first, editItem. Notice, that it does not
care where it was called from and was it forwarded to or redirected to. All it
knows, that it recieves object id in the ID property of its form bean. Well, I
cheated a little, using the same form bean for input and for output in this
case.
-
- If item is not found, action forward to error page. If a user reloads error
page, editItem action would try to locate the item again, which does not change
server state, but can improve situation if the item is found. On the other
hand, it would be cleaner to use redirection to error page, so that database
would not be bothered if error page is reloaded. If item is found, editItem
shows it.
-
- Updated item is submitted to storeItem action. It is an input action and uses
form bean to collect browser data. If data is incorrect, errors are generated
and saved in the session, then control is redirected back to output action,
editItem, which redisplays the item along with the erro
[Struts Wiki] Update of "StrutsCatalogInputOutputSeparation" 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/StrutsCatalogInputOutputSeparation -- attachment:actioncombo08.gif + See also: StrutsMultipleActionForms + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsCatalogInputOutputSeparation" 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/StrutsCatalogInputOutputSeparation -- HTML FORM is submitted from the input page, usually using POST request method. Struts populates form bean (marked with [F]) with request data. Then form bean validates input and if something wrong, it generates error messages. If validate() returns errors, Struts does not bother to call action class. Instead, it forwards to location, which is defined in "input" property of element. If, on the other hand, input data is correct, Struts calls execute() method of the action class. It usually performs model update, then fills out form bean with output values, and forwards to JSP page, which displays output data. - attachment:action_combo_01.gif + attachment:actioncombo01.gif What is wrong with this scheme? Number of things. * Form bean is used both for input and for output. If input and output page uses same fields, this is OK, but usually this is not the case. So, one form has to combine input and output fields. @@ -19, +19 @@ So, as a first step of cleaning up the input/output mess I would suggest getting rid of "input" property and automatic validation. This makes request processing more clear and linear, and allows to have several error pages instead of only one. Also, now you are free to redirect to error page instead of just forwarding to it. - attachment:action_combo_02.gif + attachment:actioncombo02.gif Next step is to separate input and output data. This is not an easy task considering that a form bean should handle both. First, let us consider two exotic choices. First, is to use form bean for input only. Output data will be generated manually and pushed into request object field by field on in a non-Struts bean. - attachment:action_combo_03.gif + attachment:actioncombo03.gif Another choice is to use form bean for output only. In this case action class processes input data directly from request object and fills out form bean with output data. Oh, right, form bean is called first by Struts. This is not a problem, because Struts uses getters and setters to access form bean. So, if you define fields with package scope, and set them directly, you would not need setter. Thus, Struts would not be able to set their values during populate phase. - attachment:action_combo_04.gif + attachment:actioncombo04.gif But these approaches are quite exotic. What if we just have two actions? @@ -35, +35 @@ In this case we can assign a very own form bean for each action class. We would have one input form bean coupled with input action, and one output form bean coupled with output action. - attachment:action_combo_05.gif + attachment:actioncombo05.gif Now, this approach can work. In this sheme each action and form bean performs its own specific task. * Input form bean is populated with input data. @@ -51, +51 @@ The solution is quite simple: to chain actions using redirect instead of forward. - attachment:action_combo_07.gif + attachment:actioncombo07.gif In this case, after input data is processed and domain model is updated, input action redirects to output action. What is special about redirection? * The request has to make a roundrip through browser. @@ -63, +63 @@ What if we need to use one form? Say, we have a wizard or a dialog, which shares data. No problem, this even easier than to have two forms. Just define the form with session scope, and it will retain all input data between requests. - attachment:action_combo_08.gif + attachment:actioncombo08.gif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsCatalogInputOutputSeparation" 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/StrutsCatalogInputOutputSeparation New page: This information is covers almost the same topic, as StrutsMultipleActionForms, but I made it a separate page for clarity. The problem we are trying to solve is how to process input and output data, having only one form bean per action class. == Traditional Struts request/response cycle == First, let us recall the traditional way of processing input and generating output in Struts application. HTML FORM is submitted from the input page, usually using POST request method. Struts populates form bean (marked with [F]) with request data. Then form bean validates input and if something wrong, it generates error messages. If validate() returns errors, Struts does not bother to call action class. Instead, it forwards to location, which is defined in "input" property of element. If, on the other hand, input data is correct, Struts calls execute() method of the action class. It usually performs model update, then fills out form bean with output values, and forwards to JSP page, which displays output data. attachment:action_combo_01.gif What is wrong with this scheme? Number of things. * Form bean is used both for input and for output. If input and output page uses same fields, this is OK, but usually this is not the case. So, one form has to combine input and output fields. * On error action class is not called. This may be useful in some cases, but not always. * On error control is forwarded to location, defined in "input" property. This property itself is a source of misunderstanding for Struts newbies, and makes clean request->processing->response sequence a little fuzzy. * By default, "input" property allows only forwarding, but not redirection. Redirection can be enabled, but for the whole application. * Because in case of error most applications forward to input page instead of redirecting, page is sent back to broswser immediately in response to POST request. This produces POSTDATA effect on reload, which results in double sumbit. So, as a first step of cleaning up the input/output mess I would suggest getting rid of "input" property and automatic validation. This makes request processing more clear and linear, and allows to have several error pages instead of only one. Also, now you are free to redirect to error page instead of just forwarding to it. attachment:action_combo_02.gif Next step is to separate input and output data. This is not an easy task considering that a form bean should handle both. First, let us consider two exotic choices. First, is to use form bean for input only. Output data will be generated manually and pushed into request object field by field on in a non-Struts bean. attachment:action_combo_03.gif Another choice is to use form bean for output only. In this case action class processes input data directly from request object and fills out form bean with output data. Oh, right, form bean is called first by Struts. This is not a problem, because Struts uses getters and setters to access form bean. So, if you define fields with package scope, and set them directly, you would not need setter. Thus, Struts would not be able to set their values during populate phase. attachment:action_combo_04.gif But these approaches are quite exotic. What if we just have two actions? == Two actions and two forms == In this case we can assign a very own form bean for each action class. We would have one input form bean coupled with input action, and one output form bean coupled with output action. attachment:action_combo_05.gif Now, this approach can work. In this sheme each action and form bean performs its own specific task. * Input form bean is populated with input data. * Input action class explicitly calls validate() and updates the domain model. * Then input action class forwards to output action. This is basically a simple action chaining. * Struts would want to populate output form bean, but here is the trick: you do not need to define setters for properties in the output form. Also, the field on the output form are usually different from fields on the input form. * Output form does not define validate() method because there is nothing to validate. * Struts calls output action class, which fills out output form bean with data. Now we have clean input/output separation and each class is doing a small but specific task. This scheme is more maintainable. But, even with this cleaner model we still have POSTDATA and double submit problem, because all processing is performed during a single request/response cycle. From browser's point of view, server receives POST request and responds with result page. When a user wants to refresh the result page, browser has
[Struts Wiki] Update of "StrutsCatalog" 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/StrutsCatalog -- * StrutsCatalogErrorTypes * ["StrutsCatalogHidingPagesUnderWEBINF"] * StrutsCatalogHtmlRewrite + * StrutsCatalogInputOutputSeparation * StrutsCatalogSegmentApplications * StrutsCatalogVariableScreenFields * StrutsCatalogLazyList - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3 "modular" and 1.2.7 "solid"
At 11:38 AM -0700 5/6/05, Michael Jouravlev wrote: Right, Validator was moved to core. I am sure that this decision was well motivated. I never used in in four years, though. But now I finally have a chance to try it ;-) For a long time Struts absorbed things -- Validator, Tiles, etc. We've since realized that this leads to a big release, which has sometimes led to long waits between releases. The goal of the modularization is to free components to release on their own cycle -- this is made much easier since Struts left the Jakarta umbrella to be a "top level" Apache project. If in the future it makes sense to peel Validator or something else out, we are in a position to do that -- but for now we are still feeling out some of the procedural details, so no need to rush it. The fact that Struts' "dependencies" on ANTLR and ORO are only for Validator seem to me one argument for pushing that stuff out. Not a huge deal, but a way to think about it. Still, we need to get some 1.3.x releases cut before we make any other major changes to how we have things organized, and since both of those dependencies are pure run-time dependencies, it's not such a big deal. If you never use the mask or validwhen validators, you will never have a problem if you've left those JARs out of your app. Joe On 5/6/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: - Original Message - From: "Michael Jouravlev" <[EMAIL PROTECTED]> Sent: Friday, May 06, 2005 6:27 PM > According to roadmap, 1.3 distribution will be divided into subprojects: > * core, apps, el, faces, site, taglibs > * flow, scripting (new) It already has been - actually the division into sub-modules is based on the svn repository - which was re-organised that way so we could have separate release cycles. Best way to see how struts is organised is to look at svn: http://svn.apache.org/viewcvs.cgi/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3 "modular" and 1.2.7 "solid"
Right, Validator was moved to core. I am sure that this decision was well motivated. I never used in in four years, though. But now I finally have a chance to try it ;-) On 5/6/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > - Original Message - > From: "Michael Jouravlev" <[EMAIL PROTECTED]> > Sent: Friday, May 06, 2005 6:27 PM > > > According to roadmap, 1.3 distribution will be divided into subprojects: > > * core, apps, el, faces, site, taglibs > > * flow, scripting (new) > > It already has been - actually the division into sub-modules is based on the > svn repository - which was re-organised that way so we could have separate > release cycles. Best way to see how struts is organised is to look at svn: > > http://svn.apache.org/viewcvs.cgi/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts Wiki] Update of "StrutsRelease127" by MichaelJouravlev
Michael, The main purpose of the Release Plans - is as a "working document" for the committers to use during the release process. While theres nothing wrong with having the information you added there - if the purpose is to provide information for the wider community, then it would probably be best put somewhere else - either another part of the wiki or in the user guide: http://struts.apache.org/userGuide/installation.html Niall - Original Message - From: "Apache Wiki" <[EMAIL PROTECTED]> Sent: Friday, May 06, 2005 7:08 PM > 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/StrutsRelease127 > > -- > > Dependency versions for this release: > > - || '''Dependency''' || '''Version''' || '''Status''' || > + || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' || > - || Antlr || 2.7.2 || Released || > + || Antlr || 2.7.2 || Released || Struts Validator || > - || Commons !BeanUtils || 1.7.0 || Released || > - || Commons Digester || 1.6 || Released || > + || Commons !BeanUtils || 1.7.0 || Released || core (!ActionServlet, configuration, !DynaActionForm) || > + || Commons Digester || 1.6 || Released || core (!ActionServlet, configuration) || > - || Commons !FileUpload || 1.0 || Released || > + || Commons !FileUpload || 1.0 || Released || Struts Upload || > - || Commons Logging || 1.0.4 || Released || > + || Commons Logging || 1.0.4 || Released || core (logging all over) || > - || Commons Validator || 1.1.4 || Released || > + || Commons Validator || 1.1.4 || Released || Struts Validator || > - || Jakarta Oro || 2.0.7 || Released || > + || Jakarta Oro || 2.0.7 || Released || Commons Validator || > > == Testing Checklist == > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3 "modular" and 1.2.7 "solid"
- Original Message - From: "Michael Jouravlev" <[EMAIL PROTECTED]> Sent: Friday, May 06, 2005 6:27 PM > According to roadmap, 1.3 distribution will be divided into subprojects: > * core, apps, el, faces, site, taglibs > * flow, scripting (new) It already has been - actually the division into sub-modules is based on the svn repository - which was re-organised that way so we could have separate release cycles. Best way to see how struts is organised is to look at svn: http://svn.apache.org/viewcvs.cgi/struts/ James Mitchel has done alot of work on a new maven build to create the separate distributions, nightly distros for 1.3 are available here: http://svn.apache.org/builds/struts/maven/trunk/nightly/ Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsReleasePlans" 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/StrutsReleasePlans
--
- = Purpose =
+ The purpose of this page is to set up '''checklists''' for Struts releases.
Add a new page for each release in the section below using the the version
number for the release in the page name.
+ Starting from series 1.2.x, Struts adopted the Tomcat style of release. The
quality of each new version is decided by voting. If there are any issues then
they are not fixed in that version, but instead a new version is created. See
the ''Release Grade'' section in the [http://struts.apache.org/bylaws.html
bylaws] and the [http://struts.apache.org/releases.html Release Guidelines] for
more details.
- The purpose of this page is to set up '''checklists''' for Struts releases.
-
- Add a new page for each release in the section below using the the version
number for the release in the page name.
'''NOTE''' For info on cutting a release see the Struts
[http://struts.apache.org/releases.html#Releases Release Guidelines]
- Starting from series 1.2.x, Struts adopted the Tomcat style of release. The
quality of each new version is decided by voting. If there are any issues and
new version does not receive GA ("General Availability") status, it is not
fixed. Instead, a new version with new version number is rolled out.
+ = 1. Struts Release Plans =
- For example, version 1.2.6 was voted only "beta" quality since there were
issues with it. It will not be fixed and will remain forever beta. (explained
by Niall Pemberton)
+ * StrutsRelease122 - ''Struts Version 1.2.2''
+ * StrutsRelease123 - ''Struts Version 1.2.3''
+ * StrutsRelease124 - ''Struts Version 1.2.4''
+ * StrutsRelease125 - ''Struts Version 1.2.5''
+ * StrutsRelease126 - ''Struts Version 1.2.6''
+ * StrutsRelease127 - ''Struts Version 1.2.7''
- = Struts Release Plans =
+ = 2. Struts-Faces Release Plans =
+ * StrutsFacesRelease101 - ''Struts-Faces Version 1.0.1''
- * StrutsRelease122
- * StrutsRelease123
- * StrutsRelease124
- * StrutsRelease125
- * StrutsRelease126
- * StrutsRelease127
- = Struts-Faces Release Plans =
-
- * StrutsFacesRelease101
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsRelease127" 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/StrutsRelease127 -- Dependency versions for this release: - || '''Dependency''' || '''Version''' || '''Status''' || + || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' || - || Antlr || 2.7.2 || Released || + || Antlr || 2.7.2 || Released || Struts Validator || - || Commons !BeanUtils || 1.7.0 || Released || - || Commons Digester || 1.6 || Released || + || Commons !BeanUtils || 1.7.0 || Released || core (!ActionServlet, configuration, !DynaActionForm) || + || Commons Digester || 1.6 || Released || core (!ActionServlet, configuration) || - || Commons !FileUpload || 1.0 || Released || + || Commons !FileUpload || 1.0 || Released || Struts Upload || - || Commons Logging || 1.0.4 || Released || + || Commons Logging || 1.0.4 || Released || core (logging all over) || - || Commons Validator || 1.1.4 || Released || + || Commons Validator || 1.1.4 || Released || Struts Validator || - || Jakarta Oro || 2.0.7 || Released || + || Jakarta Oro || 2.0.7 || Released || Commons Validator || == Testing Checklist == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsReleasePlans" 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/StrutsReleasePlans
--
'''NOTE''' For info on cutting a release see the Struts
[http://struts.apache.org/releases.html#Releases Release Guidelines]
+ Starting from series 1.2.x, Struts adopted the Tomcat style of release. The
quality of each new version is decided by voting. If there are any issues and
new version does not receive GA ("General Availability") status, it is not
fixed. Instead, a new version with new version number is rolled out.
+
+ For example, version 1.2.6 was voted only "beta" quality since there were
issues with it. It will not be fixed and will remain forever beta. (explained
by Niall Pemberton)
= Struts Release Plans =
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3 "modular" and 1.2.7 "solid"
i think that ORO is required by Validator which is a requirement of struts. some validation expressions depend on it. Michael Jouravlev wrote: Also, http://wiki.apache.org/struts/StrutsRelease127 mentions dependency on Jakarta ORO, but looks like this is not the case. The only class that uses ORO is org.apache.struts.taglib.TaglibTestBase which imports org.apache.oro.text.perl.Perl5Util. Test cases are not included in binary distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.3 "modular" and 1.2.7 "solid"
According to roadmap, 1.3 distribution will be divided into subprojects: * core, apps, el, faces, site, taglibs * flow, scripting (new) Is this the final decision on how subprojects will be divided? I am looking at 1.2.7 right now and I see stuff that I do not use, but which is included, like Validator along with Antlr, or FileUpload. These modules are not mentioned as subprojects, but I would like them to be separate. Also, http://wiki.apache.org/struts/StrutsRelease127 mentions dependency on Jakarta ORO, but looks like this is not the case. The only class that uses ORO is org.apache.struts.taglib.TaglibTestBase which imports org.apache.oro.text.perl.Perl5Util. Test cases are not included in binary distribution. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r168613 - /struts/core/branches/STRUTS_1_2_BRANCH/doc/userGuide/installation.xml
Author: niallp Date: Fri May 6 08:01:44 2005 New Revision: 168613 URL: http://svn.apache.org/viewcvs?rev=168613&view=rev Log: Minor doc correction Modified: struts/core/branches/STRUTS_1_2_BRANCH/doc/userGuide/installation.xml Modified: struts/core/branches/STRUTS_1_2_BRANCH/doc/userGuide/installation.xml URL: http://svn.apache.org/viewcvs/struts/core/branches/STRUTS_1_2_BRANCH/doc/userGuide/installation.xml?rev=168613&r1=168612&r2=168613&view=diff == --- struts/core/branches/STRUTS_1_2_BRANCH/doc/userGuide/installation.xml (original) +++ struts/core/branches/STRUTS_1_2_BRANCH/doc/userGuide/installation.xml Fri May 6 08:01:44 2005 @@ -105,7 +105,6 @@ http://jakarta.apache.org/commons/beanutils/";>Jakarta Commons Beanutils (Version 1.7.0) http://jakarta.apache.org/commons/digester/";>Jakarta Commons Digester (Version 1.6) http://jakarta.apache.org/commons/fileupload/";>Jakarta Commons FileUpload (Version 1.0) - http://jakarta.apache.org/commons/logging/";>Jakarta Commons Logging (Version 2.0) http://jakarta.apache.org/commons/logging/";>Jakarta Commons Logging (Version 1.0.4) http://jakarta.apache.org/commons/validator/";>Jakarta Commons Validator (Version 1.1.4) http://jakarta.apache.org/oro/";>Jakarta ORO (Version 2.0.7) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r168612 - /struts/core/branches/STRUTS_1_2_BRANCH/build.xml
Author: niallp Date: Fri May 6 07:55:46 2005 New Revision: 168612 URL: http://svn.apache.org/viewcvs?rev=168612&view=rev Log: Exclude the "lib" directory from the source distro Modified: struts/core/branches/STRUTS_1_2_BRANCH/build.xml Modified: struts/core/branches/STRUTS_1_2_BRANCH/build.xml URL: http://svn.apache.org/viewcvs/struts/core/branches/STRUTS_1_2_BRANCH/build.xml?rev=168612&r1=168611&r2=168612&view=diff == --- struts/core/branches/STRUTS_1_2_BRANCH/build.xml (original) +++ struts/core/branches/STRUTS_1_2_BRANCH/build.xml Fri May 6 07:55:46 2005 @@ -577,6 +577,7 @@ + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsRelease127" 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/StrutsRelease127 -- Dependency versions for this release: || '''Dependency''' || '''Version''' || '''Status''' || + || Antlr || 2.7.2 || Released || || Commons !BeanUtils || 1.7.0 || Released || || Commons Digester || 1.6 || Released || || Commons !FileUpload || 1.0 || Released || || Commons Logging || 1.0.4 || Released || || Commons Validator || 1.1.4 || Released || + || Jakarta Oro || 2.0.7 || Released || == Testing Checklist == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Struts 1.2.7 Test Build Available
The Struts 1.2.7 Test Build is now available here: http://cvs.apache.org/dist/struts/v1.2.7/ The release notes include highlights of changes in this version, as well as the full details of changes and bug fixes: http://struts.apache.org/userGuide/release-notes.html Once feedback has been collected on the stability and quality of this build, a determination will be made as to whether it should be promoted to General Availability (GA) or Beta status, or neither. You are encouraged to download and test this build at your earliest convenience, and provide your feedback via the lists or via the bug database. -- Niall Pemberton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsUpgrade" 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/StrutsUpgrade -- === Upgrading Struts 1.1 to Struts 1.2.4 === - * StrutsUpgradeNotes11to124 - Upgrading to '''Version 1.2.4''' (from ''Version 1.1'') - * StrutsUpgradeNotes124to127 - Upgrading to '''Version 1.2.7''' (from ''Version 1.2.4'') + * StrutsUpgradeNotes11to124 - Upgrade Notes + + === Upgrading Struts 1.2.4 to Struts 1.2.7 === + + * StrutsUpgradeNotes124to127 - Upgrade Notes === Upgrading Struts 1.2.x to Struts 1.3 === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsUpgrade" 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/StrutsUpgrade -- === Upgrading Struts 1.1 to Struts 1.2.4 === - * StrutsUpgradeNotes11to124 - Upgrade Notes + * StrutsUpgradeNotes11to124 - Upgrading to '''Version 1.2.4''' (from ''Version 1.1'') + * StrutsUpgradeNotes124to127 - Upgrading to '''Version 1.2.7''' (from ''Version 1.2.4'') === Upgrading Struts 1.2.x to Struts 1.3 === - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsUpgradeNotes124to127" 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/StrutsUpgradeNotes124to127
New page:
= Upgrading Struts 1.2.4 to Struts 1.2.7 =
== 1. jars ==
Obviously the '''struts.jar''' needs to be upgraded - but in addtion Struts has
changed its dependencies and you will need to deploy the new versions for
''Commons Bean Utils ('''1.7.0''')'', ''Commons Digester ('''1.6''')'' and
''Commons Validator ('''1.1.4''')''. The correct versions of these jars are
shipped in the '''lib''' directory in the ''binary'' distribution.
Addtionally, Struts no longer has a dependency on ''Commons Collections'' or
''Commons Lang'', so unless you have other requirements for them, they no
longer need to be deployed.
== 2. tlds ==
If you deploy the struts tag's tlds, then remember to deploy the new versions
shipped with this version. If you don't you won't be able to use the new tag
attributes added.
== 3. validator-rules.xml ==
Upgrade to the new version of validator-rules.xml.
'''N.B.''' One of the changes in the new validator-rules.xml is that the
Validation methods' signatures have changed to now include a ''Validator''
parameter.
CategoryHomepage StrutsUpgrade
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts Wiki] Update of "DefinePita" by DakotaJack
On 5/6/05, Dakota Jack <[EMAIL PROTECTED]> wrote: > Your note, Ted, seems to make an assumption that I am talking about > some "we" which includes you and the community. That is not true. I > find almost all the people on this list exemplary, hekpful, > insightful, and plain just dandy.. And, I really have no difficulty > in myself with you either, although I find you philosophy lacking. I > was adding values which I think are real and which are commonly > breached by a few people. I think we can leave this to consensus? First, I should apologize for posting the additional definitions here. At this point, the right path seems to be to move these to the Apache Incubator area, and, as mentioned, add some definitions for other Apache words and phrases. We've gotten away from the scope of the Struts project, and into the scope of the Apache Incubator. The only motivation for the new entries was happenstance. While looking for something else, I happened to come across an old post by Ken Coar (a longtime member of the HTTPD team, ASF officer, and ApacheCon organizer) to members@, where he mentioned that someone was "not interested in the Truth, only in Being Right", and that Ken wasn't going to respond to any more of that person's "trolls". So, having posted PITA here, I went ahead and added Trolls. But, I think it's time for these "daffy-nitions" to move to the Incubator, where they belong. As our XP friends say, "Do it right the first time." Again, I apologize for wasting Struts bandwidth with this, and, hopefully, we can now return the business of this forum to the forthcoming 1.2.7 and 1.3.0 releases :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "StrutsRelease127" 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/StrutsRelease127 -- || '''#''' || '''Description''' || '''Completed''' || || 1. || Run Unit Test targets || (./) || || 2. || Run Cactus Tests (see below) || (./) || - || 3. || Play test bundled applications (TC 5.0.x) || No || + || 3. || Play test bundled applications (TC 5.0.x) || (./) || TODO: A Canoo !WebTest for the applications would be great! @@ -92, +92 @@ See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || - || A1. || Tag release in cvs: STRUTS_1_2_7 || No || + || A1. || Tag release in svn: STRUTS_1_2_7 || (./) || - || A2. || Run Distribution Target || No || + || A2. || Run Distribution Target || (./) || - || A3. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/1.2.7 || No || + || A3. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/1.2.7 || (./) || || A4. || Post release-quality vote on dev@ and user@ lists || No || == Vote (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts Wiki] Update of "DefinePita" by DakotaJack
Your note, Ted, seems to make an assumption that I am talking about some "we" which includes you and the community. That is not true. I find almost all the people on this list exemplary, hekpful, insightful, and plain just dandy.. And, I really have no difficulty in myself with you either, although I find you philosophy lacking. I was adding values which I think are real and which are commonly breached by a few people. I think we can leave this to consensus? -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
