[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 -- * 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 dependencyManagement in action/trunk/pom.xml to control version numbers. Modules then declare only groupId/artifactId for dependencies. + * Add reporting section to action/trunk/pom.xml and generate Javadoc and other reports for the website. - 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 -- * Remove the Tiles dependency from EL (Move the tiles-el tags to Struts Tiles) * Use dependencyManagement in action/trunk/pom.xml to control version numbers. Modules then declare only groupId/artifactId for dependencies. * Add reporting 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 resource 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 StrutsAction2 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/StrutsAction2 -- General thoughts on Webwork * ActionContext - Webwork provides an !ActionContext, which is a wrapper around a number of important objects. This may sound a little mundane, but it's not! Read on! - + * RoughSpots - Things to clean up before 2.0.0. + References * [http://www.mail-archive.com/dev%40struts.apache.org/msg13815.html Original Proposal] - The original !WebWork merger proposal on the Struts dev mailing list * [http://www.opensymphony.com/webwork WebWork] - The Webwork site at !OpenSymphony - 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 New page: Describe RoughSpots here. - 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
--
- Describe RoughSpots here.
+ * Looking up a `ResultConfig` should be a one-liner. Right now you have to:
{{{
+ ActionConfig config = invocation.getProxy().getConfig();
+ Map results = config.getResults();
+ ResultConfig resultConfig;
+ synchronized (config) {
+ resultConfig = (ResultConfig) results.get(resultCode);
+ }
+ }}}
-
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
--
- * Looking up a `ResultConfig` should be a one-liner. Right now you have to:
{{{
+ * Looking up a `ResultConfig` should be a one-liner. Right now you have to:
{{{
ActionConfig config = invocation.getProxy().getConfig();
Map results = config.getResults();
ResultConfig resultConfig;
-
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
--
- * Looking up a `ResultConfig` should be a one-liner. Right now you have to:
{{{
+ 1. Looking up a `ResultConfig` should be a one-liner. Right now you have
to: {{{
- ActionConfig config = invocation.getProxy().getConfig();
+ ActionConfig config = invocation.getProxy().getConfig();
- Map results = config.getResults();
+ Map results = config.getResults();
- ResultConfig resultConfig;
+ ResultConfig resultConfig;
- synchronized (config) {
+ synchronized (config) {
- resultConfig = (ResultConfig) results.get(resultCode);
+ resultConfig = (ResultConfig) results.get(resultCode);
- }
+ }
}}}
+ 1. We don't really need the `Action` interface anymore. Should we get rid
of it? It has constant fields for result names. Should we move these to a class
named `ResultNames` and encourage users to static import them as needed?
+
+ 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`.
+
+ 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.
+
+ 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.
+
+ 1. Specify `Interceptor` lifecycle. Right now if you apply an interceptor
to a single action, you get a new instance every time. If you define an
interceptor in a stack, the same instance gets reused.
+
+ 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods
doesn't make things simpler. It reduces flexibility. You can't return a
different result. You can't handle exceptions cleanly. The actual interceptor
class doesn't appear in the stack trace (you see `AroundInterceptor` over and
over).
+
+ 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 {
+ public String intercept(HttpInvocation i) {
+ HttpServletRequest request = i.getRequest();
+ ...
+ }
+ }
+ }}}
+
+ 1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would
be a better name.
+
+ 1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at
least from the users' perspective). Better specify what happens during
chaining/action tags.
+
+ 1. I'm not sure I'd expect `ActionInvocation.getResult()` to recurse over
chain results. Maybe we should have two methods? `getResult()` and
`getFinalResult()`. I've never needed this so I don't know.
+
+ 1. `ActionInvocation.invokeActionOnly()`. Does this need to be public?
Sounds dangerous.
+
+ 1. Eliminate non-private fields. Protected fields in `ActionConfig` for
example.
+
+ 1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is
better.
+
+ 1. `TextProvider` is a bad name. The JDK refers to these as messages
everywhere.
+
+ 1. Come up with a clean way to separate view actions from update
actions. For example, you may have `view()` and `update()` methods in the same
action class. Right now XWork has `MethodFilterInterceptor`, but that's not a
very clean solution. You don't want validation or the
`DefaultWorkflowInterceptor` to run for the `view()` method. My current project
has separate interceptor stacks, but it would be nice if there was some first
class support for this. We could flag action invocations as view or update
(using an enum). We could automatically choose a mode based on whether the
request is an HTTP GET or POST. Or we could set the mode based on an annotation
on the action method. Or some other way...
+
+ 1. On the OGNL value stack `#request` refers to request attributes and
`#parameters` refers to the parameters. I think we should rename these
`#request` for request parameters and `#requestAttributes` for request
attributes.
+
+ == Nice to haves ==
+
+ 1. Inheritance is a sucky way to reuse code between actions. It would be
nice if the framework had built-in support for mixins using cglib or Spring.
For example, instead of me extending a class that implements `ValidationAware`,
Struts can extends my action class at runtime and implement the
`ValidationAware` methods by delegating them to another object
[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. On the OGNL value stack `#request` refers to request attributes and
`#parameters` refers to the parameters. I think we should rename these
`#request` for request parameters and `#requestAttributes` for request
attributes.
+ 1. Warnings and failing siltently sucks. 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).
+
+ 1. Add better support for file uploads.
+
+ 1. Don't eat/wrap exceptions. Throw them through to the container. Don't
eat exceptions that occur in getters.
+
+ 1. Modify `ParametersInterceptor` to sort parameter names by depth (using
bucket sort) and then map them in that order (shallowest first), so we can
create objects and then map fields to those objects in the same action
invocation without hacks like applying the `ParametersInterceptor` twice or
chaining.
+
== Nice to haves ==
- 1. Inheritance is a sucky way to reuse code between actions. It would be
nice if the framework had built-in support for mixins using cglib or Spring.
For example, instead of me extending a class that implements `ValidationAware`,
Struts can extends my action class at runtime and implement the
`ValidationAware` methods by delegating them to another object (a mixin): {{{
+ 1. Inheritance is a sucky way to reuse code between actions. I've actually
had to use the strategy pattern to swap in different implementations of stuff
like `ValidationAware`. It would be nice if the framework had built-in support
for mixins using cglib or Spring. For example, instead of me extending a class
that implements `ValidationAware`, Struts can extend my action class at runtime
and implement the `ValidationAware` methods by delegating them to another
object (a mixin): {{{
abstract class MyAction implements Validateable, ValidationAware {
public void validate() {
addActionError(...);
}
}
- }}}
+ }}} You could specify mixin implementation classes by convention (defaults),
in the `struts.xml`, or using annotations.
-
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 -- addActionError(...); } } - }}} You could specify mixin implementation classes by convention (defaults), in the `struts.xml`, or using annotations. + }}} You could specify mixin implementation classes by convention (defaults), in the `struts.xml`, or using annotations. This could also be a simpler alternative to action chaining in many cases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial 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
--
== Nice to haves ==
- 1. Inheritance is a sucky way to reuse code between actions. I've actually
had to use the strategy pattern to swap in different implementations of stuff
like `ValidationAware`. It would be nice if the framework had built-in support
for mixins using cglib or Spring. For example, instead of me extending a class
that implements `ValidationAware`, Struts can extend my action class at runtime
and implement the `ValidationAware` methods by delegating them to another
object (a mixin): {{{
+ 1. Inheritance is a sucky way to reuse code between actions. I've actually
had to use the strategy pattern to swap in different implementations of stuff
like `ValidationAware`. It would be nice if the framework had built-in support
for mixins using cglib or Dynaop. For example, instead of me extending a class
that implements `ValidationAware`, Struts can extend my action class at runtime
and implement the `ValidationAware` methods by delegating them to another
object (a mixin): {{{
abstract class MyAction implements Validateable, ValidationAware {
public void validate() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of EventActionDispatcher 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/EventActionDispatcher -- /** * Instantiate event dispatcher */ - protected ActionDispatcher dispatcher = + protected ActionDispatcher dispatcher = - new EventActionDispatcher (this, false); + new EventActionDispatcher(this); /** * Use event dispatcher to call an appropriate event handler. - 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 The comment on the change is: Plugged in EventActionDispatcher information -- 1. `TextProvider` is a bad name. The JDK refers to these as messages everywhere. - 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... + 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... (MJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. Also, these links might help: DataEntryForm, EventActionDispatcher) 1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. I think we should rename these `#request` for request parameters and `#requestAttributes` for request attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of FormView by angelozerr
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 angelozerr: http://wiki.apache.org/struts/FormView -- * add style class error to the field which has error. * set focus to the first field which has error. + FormView can be used without Struts (JSP Only), by using FormView Servlet, to load your configuration (like Plugin Struts). + You can find FormView Web Site at http://formview.sourceforge.net/ and download JAR at http://sourceforge.net/projects/formview. - 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. `TextProvider` is a bad name. The JDK refers to these as messages everywhere. - 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... (MJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. Also, these links might help: DataEntryForm, EventActionDispatcher) + 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... + * MJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. Also, these links might help: DataEntryForm, EventActionDispatcher + * crazybob: Triggering an event should still be a POST (though the framework should make it easy). From the HTTP spec.: GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. 1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. I think we should rename these `#request` for request parameters and `#requestAttributes` for request attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsAction2 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/StrutsAction2 -- General thoughts on Webwork * ActionContext - Webwork provides an !ActionContext, which is a wrapper around a number of important objects. This may sound a little mundane, but it's not! Read on! - * RoughSpots - Things to clean up before 2.0.0. + * RoughSpots - Some things that could be addressed before 2.0.0. References * [http://www.mail-archive.com/dev%40struts.apache.org/msg13815.html Original Proposal] - The original !WebWork merger proposal on the Struts dev mailing list - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of RoughSpots 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/RoughSpots
The comment on the change is:
Conform pronouns to use we throughout
--
+ Some things that could be addresssed before Action 2.0.0.
+
- 1. Looking up a `ResultConfig` should be a one-liner. Right now you have
to: {{{
+ 1. Looking up a `ResultConfig` should be a one-liner. Right now we have to:
{{{
ActionConfig config = invocation.getProxy().getConfig();
Map results = config.getResults();
ResultConfig resultConfig;
@@ -17, +19 @@
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.
- 1. Specify `Interceptor` lifecycle. Right now if you apply an interceptor
to a single action, you get a new instance every time. If you define an
interceptor in a stack, the same instance gets reused.
+ 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.
- 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods
doesn't make things simpler. It reduces flexibility. You can't return a
different result. You can't handle exceptions cleanly. The actual interceptor
class doesn't appear in the stack trace (you see `AroundInterceptor` over and
over).
+ 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).
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 {
@@ -34, +36 @@
1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at
least from the users' perspective). Better specify what happens during
chaining/action tags.
- 1. I'm not sure I'd expect `ActionInvocation.getResult()` to recurse over
chain results. Maybe we should have two methods? `getResult()` and
`getFinalResult()`. I've never needed this so I don't know.
+ 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?
1. `ActionInvocation.invokeActionOnly()`. Does this need to be public?
Sounds dangerous.
@@ -42, +44 @@
1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is
better.
- 1. `TextProvider` is a bad name. The JDK refers to these as messages
everywhere.
+ 1. Is `TextProvider` a good name? The JDK refers to these as messages
everywhere.
- 1. Come up with a clean way to separate view actions from update
actions. For example, you may have `view()` and `update()` methods in the same
action class. Right now XWork has `MethodFilterInterceptor`, but that's not a
very clean solution. You don't want validation or the
`DefaultWorkflowInterceptor` to run for the `view()` method. My current project
has separate interceptor stacks, but it would be nice if there was some first
class support for this. We could flag action invocations as view or update
(using an enum). We could automatically choose a mode based on whether the
request is an HTTP GET or POST. Or we could set the mode based on an annotation
on the action method. Or some other way...
+ 1. Come up with a clean way to separate view actions from update
actions. For example, we might have `view()` and `update()` methods in the same
action class. Right now XWork has `MethodFilterInterceptor`, but that's not a
very clean solution. Do we want validation or the `DefaultWorkflowInterceptor`
to run for the `view()` method? One solution is separate interceptor stacks,
but it would be nice if there were some first class support for this. We could
flag action invocations as view or update (using an enum). We could
automatically choose a mode based on whether the request is an HTTP GET or
POST. Or we could set the mode based on an annotation on the action method. Or
some other way...
* MJ: Using GET for render and POST for submit works well unless you want
to trigger event with a link. Also, these links might help:
[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
--
- Some things that could be addresssed before Action 2.0.0.
+ Some things that could be addresssed before Action 2.0.0. (If we don't
address them, we'll be stuck supporting them throughout all eternity or until
Struts 3.0.0, whichever comes first. ;))
1. Looking up a `ResultConfig` should be a one-liner. Right now we have to:
{{{
ActionConfig config = invocation.getProxy().getConfig();
-
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. We don't really need the `Action` interface anymore. Should we get rid
of it? It has constant fields for result names. Should we move these to a class
named `ResultNames` and encourage users to static import them as needed?
+ [jcarreira] I'm not sure about this... The Action interface is kind of just a
marker interface, but at least it gives us SOMETHING to point users to
+
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`.
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.
@@ -21, +23 @@
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...
+
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).
+
+ [jcarreira] The idea was that people would forget to do invocation.invoke()
and be confused... Easier for users just to implement a before() method when
that's all they need. I agree on the stack traces though.
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 {
@@ -32, +38 @@
}
}}}
+ [jcarreira] These 2 are orthogonal... Getting rid of ThreadLocals is
problematic. I think we'd end up breaking 90% of old WebWork apps if we did,
and it's still not clear that everything could be covered if we did... I like
the idea though, and Patrick and I really wanted to do this out of the gate,
but backwards compatibility with WebWork 1.x at a macro-level made us think
otherwise...
+
1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would
be a better name.
1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at
least from the users' perspective). Better specify what happens during
chaining/action tags.
+ [jcarreira] It __is__ well specified... There are some things that the
ActionProxy / ActionInvocation let you do that a merged one doesn't... for
instance easily knowing when you're done :-)
+
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?
+
+ [jcarreira] See the TokenSessionInterceptor and the stuff it does to
re-render the same result if you post the form more than once. That was the
reason for the complexity in finding the result to execute. It's a nice
feature, but I agree it makes the code harder to read.
1. `ActionInvocation.invokeActionOnly()`. Does this need to be public?
Sounds dangerous.
+ [jcarreira] Not sure... This may be part of the same TokenSession stuff...
can't remember exactly.
+
1. Eliminate non-private fields. Protected fields in `ActionConfig` for
example.
+ [jcarreira] We don't want to allow for extension?
+
1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is
better.
+
+ [jcarreira] Most users don't see these... Let's not change names on a whim,
since it will be more work for the power users who already use them.
1. Is `TextProvider` a good name? The JDK refers to these as messages
everywhere.
1. Come up with a clean way to separate view actions from update
actions. For example, we might have `view()` and `update()` methods in the same
action class. Right now XWork has `MethodFilterInterceptor`, but that's not a
very clean solution. Do we want validation or the `DefaultWorkflowInterceptor`
to run for the `view()` method? One solution is separate interceptor stacks,
but it would be nice if there were some first class support for this. We could
flag action invocations as view or update (using an enum). We could
automatically choose a mode based on whether the request is an HTTP GET or
POST. Or we could set the mode based on an annotation on the action method. Or
some other way...
+
+ [jcarreira] This is where I think the power of annotations can be
[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] You had me until the abstract class bit... Does it have to be abstract? Also, this limits testability in not-ok-ways... + + == 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] Trivial 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
The comment on the change is:
fixed comment formatting so numbers stay intact.
--
1. We don't really need the `Action` interface anymore. Should we get rid
of it? It has constant fields for result names. Should we move these to a class
named `ResultNames` and encourage users to static import them as needed?
- [jcarreira] I'm not sure about this... The Action interface is kind of just a
marker interface, but at least it gives us SOMETHING to point users to
+ * [jcarreira] I'm not sure about this... The Action interface is kind of
just a marker interface, but at least it gives us SOMETHING to point users to
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`.
@@ -23, +23 @@
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...
+ * [jcarreira] A new instance per action configuration, right? Not
per-invocation...
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).
- [jcarreira] The idea was that people would forget to do invocation.invoke()
and be confused... Easier for users just to implement a before() method when
that's all they need. I agree on the stack traces though.
+ * [jcarreira] The idea was that people would forget to do
invocation.invoke() and be confused... Easier for users just to implement a
before() method when that's all they need. I agree on the stack traces though.
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 {
@@ -38, +38 @@
}
}}}
- [jcarreira] These 2 are orthogonal... Getting rid of ThreadLocals is
problematic. I think we'd end up breaking 90% of old WebWork apps if we did,
and it's still not clear that everything could be covered if we did... I like
the idea though, and Patrick and I really wanted to do this out of the gate,
but backwards compatibility with WebWork 1.x at a macro-level made us think
otherwise...
+ * [jcarreira] These 2 are orthogonal... Getting rid of ThreadLocals is
problematic. I think we'd end up breaking 90% of old WebWork apps if we did,
and it's still not clear that everything could be covered if we did... I like
the idea though, and Patrick and I really wanted to do this out of the gate,
but backwards compatibility with WebWork 1.x at a macro-level made us think
otherwise...
1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would
be a better name.
1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at
least from the users' perspective). Better specify what happens during
chaining/action tags.
- [jcarreira] It __is__ well specified... There are some things that the
ActionProxy / ActionInvocation let you do that a merged one doesn't... for
instance easily knowing when you're done :-)
+ * [jcarreira] It __is__ well specified... There are some things that the
ActionProxy / ActionInvocation let you do that a merged one doesn't... for
instance easily knowing when you're done :-)
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?
- [jcarreira] See the TokenSessionInterceptor and the stuff it does to
re-render the same result if you post the form more than once. That was the
reason for the complexity in finding the result to execute. It's a nice
feature, but I agree it makes the code harder to read.
+ * [jcarreira] See the TokenSessionInterceptor and the stuff it does to
re-render the same result if you post the form more than once. That was the
reason for the complexity in finding the result to execute. It's a nice
feature, but I agree it makes the code harder to read.
1. `ActionInvocation.invokeActionOnly()`. Does this need to be public?
Sounds dangerous.
- [jcarreira] Not sure... This may be part of the same TokenSession stuff...
can't remember
[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
The comment on the change is:
Responses to Jason's comments.
--
Some things that could be addresssed before Action 2.0.0. (If we don't
address them, we'll be stuck supporting them throughout all eternity or until
Struts 3.0.0, whichever comes first. ;))
+
+ We have a small number of existing WebWork users compared to the number of
Struts users we'll (hopefully) eventually have. This is a new framework (if
only in name) and a major release. This is our one chance to break
compatibility. We must get it right now, because we will *not* be able to fix
most of these problems later (the cost of breaking existing Struts users will
almost always outweigh the value of the fix).
+
+ We do not need to expose Struts users to XWork; they do not care. At the very
least we should build a thin abstraction layer to isolate users from XWork.
XWork should be an implementation detail not part of the SAF API. We can make
most of the following changes in SAF's abstraction layer and avoid breaking
existing XWork users.
1. Looking up a `ResultConfig` should be a one-liner. Right now we have to:
{{{
ActionConfig config = invocation.getProxy().getConfig();
@@ -14, +18 @@
1. We don't really need the `Action` interface anymore. Should we get rid
of it? It has constant fields for result names. Should we move these to a class
named `ResultNames` and encourage users to static import them as needed?
* [jcarreira] I'm not sure about this... The Action interface is kind of
just a marker interface, but at least it gives us SOMETHING to point users to
+ * [crazybob] I'll buy that. We do need to move the constants out and
encourage users to use static import (Effective Java Item 17).
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`.
@@ -24, +29 @@
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.
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).
* [jcarreira] The idea was that people would forget to do
invocation.invoke() and be confused... Easier for users just to implement a
before() method when that's all they need. I agree on the stack traces though.
+ * [crazybob] It's kind of hard to forget to call `invocation.invoke()`;
you have to return something. ;) Interceptors are already an expert feature
anyway.
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 {
@@ -39, +46 @@
}}}
* [jcarreira] These 2 are orthogonal... Getting rid of ThreadLocals is
problematic. I think we'd end up breaking 90% of old WebWork apps if we did,
and it's still not clear that everything could be covered if we did... I like
the idea though, and Patrick and I really wanted to do this out of the gate,
but backwards compatibility with WebWork 1.x at a macro-level made us think
otherwise...
+ * [crazybob] Interceptors need access to the servlet API. They shouldn't
have to call a `ThreadLocal` if we can avoid it and they shouldn't need to
cast. We shouldn't worry about breaking old WebWork apps (see new opening
paragraphs). Let's get it right the first time around because we will not be
able to fix it later.
1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would
be a better name.
1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at
least from the users' perspective). Better specify what happens during
chaining/action tags.
* [jcarreira] It __is__ well specified... There are some things that the
ActionProxy / ActionInvocation let you do that a merged one doesn't... for
instance easily knowing when you're done :-)
+ * [crazybob] Does specified ==
[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] I'm not sure that's useful... We discussed it at some length on the mailing list and it wasn't clear. mapping the param interceptor twice isn't for that problem, though, it's for model-driven actions. * [crazybob] I'm not sure what you discussed, but it's *very* useful, and there should be no reason not to do it. Say for example my form has a 'userId' and fields to set on the user 'user.name', 'user.address'. With the sorting, 'userId' gets set first at which point we load a `User` object. Then the other parameters get mapped to that `User` object. Without the sorting, there's no guarantee on the ordering. You have to load the user in one action and then chain to another. This is a common use case; might as well make it simple. + * [Gabe] Discussion here: [http://forums.opensymphony.com/thread.jspa?messageID=32084] Basically, I think we can come up with a better way to accomplish this than requiring setter methods to be used for business logic and depending on parameter ordering. == Nice to haves == - 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 The comment on the change is: XML-free configuration if JDK 1.5 is the target -- * [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. * [crazybob] +1 for JDK 1.5 since it came out. I have a lot of code I could contribute which depends on the new concurrency libraries, etc. + * [MJ] With JDK 1.5 as a requirement for SAF2-based projects, users may be inclined to take a look at [http://stripes.mc4j.org/confluence/display/stripes/Home Stripes] first. It is compact, it features event-dispatching, built-in validation and conversion, Action and !ActionForm being one entity, and it allows to forgo XML config files by using annotations. The last feature alone is worth sack o'gold. If SAF2 is going to require JDK 1.5, it should allow XML-free configuration, at least for simple use cases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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
--
}
}}}
+ * [plightbo] The overall
RuntimeConfiguration/ConfigurationManager/ConfigurationProvider/Configuration
stuff is very confusing. As long as we abstract it away, I don't care if it
stays or goes. One thing I would note is that the APIs should try to pass
around a fully populated ActionConfig where possible (currently some APIs
simply take a String namespace and String actionName - leaving out the method
name).
+
1. We don't really need the `Action` interface anymore. Should we get rid
of it? It has constant fields for result names. Should we move these to a class
named `ResultNames` and encourage users to static import them as needed?
* [jcarreira] I'm not sure about this... The Action interface is kind of
just a marker interface, but at least it gives us SOMETHING to point users to
* [crazybob] I'll buy that. We do need to move the constants out and
encourage users to use static import (Effective Java Item 17).
+ * [plightbo] Related to this, I would encourage us to try to find a
solution (using Bob's mix-in suggestion below, or possibly just taking
advantage of the value stack) that would make ActionSupport much simpler. This
would encourage using POJOs more.
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.
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.
+ * [plightbo] + 1 again.
+
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...
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).
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).
* [jcarreira] The idea was that people would forget to do
invocation.invoke() and be confused... Easier for users just to implement a
before() method when that's all they need. I agree on the stack traces though.
* [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.
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 {
@@ -47, +57 @@
* [jcarreira] These 2 are orthogonal... Getting rid of ThreadLocals is
problematic. I think we'd end up breaking 90% of old WebWork apps if we did,
and it's still not clear that everything could be covered if we did... I like
the idea though, and Patrick and I really wanted to do this out of the gate,
but backwards compatibility with WebWork 1.x at a macro-level made us think
otherwise...
* [crazybob] Interceptors need access to the servlet API. They shouldn't
have to call a `ThreadLocal` if we can avoid it and they shouldn't need to
cast. We shouldn't worry about breaking old WebWork apps (see new opening
paragraphs). Let's get it right the first time around because we
[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
--
* [jcarreira] I'm not sure about this... The Action interface is kind of
just a marker interface, but at least it gives us SOMETHING to point users to
* [crazybob] I'll buy that. We do need to move the constants out and
encourage users to use static import (Effective Java Item 17).
* [plightbo] Related to this, I would encourage us to try to find a
solution (using Bob's mix-in suggestion below, or possibly just taking
advantage of the value stack) that would make ActionSupport much simpler. This
would encourage using POJOs more.
+ * [mrdon] Regardless whether we remove Action or not, I like the idea of
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.
+ * [mrdon] +1
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.
* [plightbo] + 1 again.
+ * [mrdon] This I don't agree with. From a framework developer, I
understand the logic, but from a user, it is arrogant. I think we should allow
people to extend Struts in ways we haven't imagined, and restricting access
like this says, We know more than you and will force you to do it our way.
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.
@@ -45, +48 @@
* [jcarreira] The idea was that people would forget to do
invocation.invoke() and be confused... Easier for users just to implement a
before() method when that's all they need. I agree on the stack traces though.
* [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
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 {
@@ -58, +62 @@
* [jcarreira] These 2 are orthogonal... Getting rid of ThreadLocals is
problematic. I think we'd end up breaking 90% of old WebWork apps if we did,
and it's still not clear that everything could be covered if we did... I like
the idea though, and Patrick and I really wanted to do this out of the gate,
but backwards compatibility with WebWork 1.x at a macro-level made us think
otherwise...
* [crazybob] Interceptors need access to the servlet API. They shouldn't
have to call a `ThreadLocal` if we can avoid it and they shouldn't need to
cast. We shouldn't worry about breaking old WebWork apps (see new opening
paragraphs). Let's get it right the first time around because we will not be
able to fix it later.
* [plightbo] By running our interceptors and other objects through the
same factories and lifecycle managers that the action classes go through, this
should be a non issue.
+ * [mrdon] This I'd like to see. I've found myself using these objects so
often in wierd little places, I'd be loath to remove them unless we could prove
100% that their information can be retrieved elsewhere.
1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would
be a better name.
@@ -83, +88 @@
* [jcarreira] We don't want to allow for extension?
* [crazybob] Extension through interfaces and methods? Yes.
Public/protected fields? Absolutely not!
+ * [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.
1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is
better.
@@ -92, +98 @@
1. Is `TextProvider` a good name? The JDK refers to these as messages
everywhere.
* [plightbo] The name doesn't bother me, but the implementation is far
[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 -- * [plightbo] + 1 again. * [mrdon] This I don't agree with. From a framework developer, I understand the logic, but from a user, it is arrogant. I think we should allow people to extend Struts in ways we haven't imagined, and restricting access like this says, We know more than you and will force you to do it our way. + * [crazybob] I don't think we should make everything final or anything, but I do think we should differentiate between the published API and the implementation through package organization, excluding stuff from the Javadocs, etc. Users can know that we won't change the published API out from under them, but that if they depend on implementation classes, we may break them (reluctantly). It's the polite thing to do, and it frees us up to refactor and improve our implementation. 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. @@ -89, +90 @@ * [jcarreira] We don't want to allow for extension? * [crazybob] Extension through interfaces and methods? Yes. Public/protected fields? Absolutely not! * [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. 1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is better. @@ -170, +172 @@ * [MJ] With JDK 1.5 as a requirement for SAF2-based projects, users may be inclined to take a look at [http://stripes.mc4j.org/confluence/display/stripes/Home Stripes] first. It is compact, it features event-dispatching, built-in validation and conversion, Action and !ActionForm being one entity, and it allows to forgo XML config files by using annotations. The last feature alone is worth sack o'gold. If SAF2 is going to require JDK 1.5, it should allow XML-free configuration, at least for simple use cases. * [plightbo] I use JDK 1.5 as well. I think we really should think about doing this. Non-1.5 options exist (WebWork 2.2 and Struts 1.3), and we're really at a close point where it is no longer unreasonable to require 1.5 (1.6 will have been out for almost 6 months by the time we hit a final release). * [mrdon] I'd like to use Java 5, but use retroweaver to continue to support 1.4. If we keep XML in addition to annotations, that should be very doable. + * [crazybob] Sounds good. We'll also need to handle JDK-1.5 only APIs (concurrency for example). - 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 -- * [crazybob] I'm not sure what you discussed, but it's *very* useful, and there should be no reason not to do it. Say for example my form has a 'userId' and fields to set on the user 'user.name', 'user.address'. With the sorting, 'userId' gets set first at which point we load a `User` object. Then the other parameters get mapped to that `User` object. Without the sorting, there's no guarantee on the ordering. You have to load the user in one action and then chain to another. This is a common use case; might as well make it simple. * [Gabe] Discussion here: [http://forums.opensymphony.com/thread.jspa?messageID=32084] Basically, I think we can come up with a better way to accomplish this than requiring setter methods to be used for business logic and depending on parameter ordering. * [plightbo] As Gabe said, we already discussed this. And the last post on the subject was that we should do it. We still should. + * [Gabe] I've created an XWork JIRA for a solution to the same use case here. [http://jira.opensymphony.com/browse/XW-387] I'd be happy to contribute the code. == Patrick's issues == - 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 -- * [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. 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] 1. Address the confusing issue of the validation/workflow lifecycle and different methods (this is mentioned in more detail above, but it is something that is problematic). Right now we sort of hack it by making the input method a special case in webwork-default.xml. * [jcarreira] +1 : Carlos at G**gle had some good ideas for this... basically stuff like if your action method is foo() then you'd have prepareFoo() and validateFoo(), but then I added that the prepare() and validate() methods should be the defaults that we call for all action methods. * [crazybob] Interesting idea. Might be overkill (i.e. at that point, the user should probably create another action class). 1. Don't encourage lots of interceptor stacks. Ideally the normal user should never need to deal with them. It is better to have a larger stack that has optional features that could be turned on through annotations or marker interfaces than to encourage users to build their own stacks. * [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. + + == 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 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] + 1. Hope I know what I'm talking about with this one: Provide a way that request parameters can be used as a form element value in case of error. If you submit a form with a text field that requires a numeric value but you enter a non numeric value and errors are returned, you lose the value entered when the type conversion happens. + 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. + + == Nice to haves == 1. Inheritance is not a good way to reuse code between actions. One work around is to use the strategy pattern to swap in different implementations of interfaces like `ValidationAware`. It would be nice if the framework had built-in support for mixins using cglib or Dynaop. For example, instead of extending a class that implements `ValidationAware`, SAF could extend an action class at runtime
[Struts Wiki] Update of Shale/JsfResources 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/JsfResources -- * [http://myfaces.apache.org MyFaces Project] - JSF implementation, components, mailing lists, and more * [http://www.jamesholmes.com/JavaServerFaces James Holmes' JSF Resources] - Extensive listing of articles, components, FAQs, presentations, tutorials, etc. * [http://jsfcentral.com JSFCentral.com] - Huge catalog of articles, FAQs, tutorials, samples +* [http://www.java201.com/resources/browse/72-all.html JSF Related Resources] - Collection of links about JSF resources. Includes articles, books, presentations, tutorials and more. - 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
The comment on the change is:
Posting comments on behalf of Hani.
--
* [plightbo] As Gabe said, we already discussed this. And the last post
on the subject was that we should do it. We still should.
* [Gabe] I've created an XWork JIRA for a solution to the same use case
here. [http://jira.opensymphony.com/browse/XW-387] I'd be happy to contribute
the code.
+ 1. Allow paths in action names. For example `action
name=reports/myreport`.
+
+ 1. Enable Java package import in configuration so you don't have to repeat
the same package name over and over (like WW1 does).
+
+ 1. The ajax support is pitiful. Have a look at how stripes does it. Ajax
for validation is trivial and not that impressive, but people are going to want
to do real ajax work, and webwork does absolutely nothing to help in that
regard. I'd like to for example be able to easily invoke actions and get at
some kind of result to display, and have webwork provide at least some of the
wiring
+
+ 1. The default theme for the ui tags should be simple. The current stuff is
too dumb to get right on the first go, which gives an awful impression. It's
NOT intuitive to write: {{{
+ table
+ ww:textfield label=Enter blah /
+ /table
+ }}}
+
+ 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.
+
+ 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
+
+ 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
+
+ 1. Get rid of the validation framework. it's stupid and pointless, validate
methods are good enough.
+
+ 1. Ditch xwork as a separate project, nobody uses it or cares about it
+
+ 1. Add java5 support to ognl. It's silly that it still doesn't handle enums
(that I know of).
+
+ 1. Clean up documentation. Focus on quality not quantity.
+
== Patrick's issues ==
My concerns aren't as detailed as Bob's, but I would like to see these
general themes promoted by the framework:
@@ -160, +186 @@
1. Address the confusing issue of the validation/workflow lifecycle and
different methods (this is mentioned in more detail above, but it is something
that is problematic). Right now we sort of hack it by making the input method
a special case in webwork-default.xml.
* [jcarreira] +1 : Carlos at G**gle had some good ideas for this...
basically stuff like if your action method is foo() then you'd have
prepareFoo() and validateFoo(), but then I added that the prepare() and
validate() methods should be the defaults that we call for all action methods.
* [crazybob] Interesting idea. Might be overkill (i.e. at that point,
the user should probably create another action class).
+ * [hani] No magic method names. If you want to do that, use annotations
so you have a good chance of IDE support dealing with it. For example
@Validate/@Prepare etc, with parameters to indicate what request you'd like it
involved for, in the case where you need multiples of them
1. Don't encourage lots of interceptor stacks. Ideally the normal user
should never need to deal with them. It is better to have a larger stack that
has optional features that could be turned on through annotations or marker
interfaces than to encourage users to build their own stacks.
* [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.
-
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
--
* [Gabe] I've created an XWork JIRA for a solution to the same use case
here. [http://jira.opensymphony.com/browse/XW-387] I'd be happy to contribute
the code.
1. Allow paths in action names. For example `action
name=reports/myreport`.
+ * [jcarreira] Why do you want this? Isn't this part of the namespace of
the action?
1. Enable Java package import in configuration so you don't have to repeat
the same package name over and over (like WW1 does).
+ * [jcarreira] +1 if it can be made sane... It can get confusing. It also
makes tool support worse (i.e. IDEA can find it as a fully qualified class name)
1. The ajax support is pitiful. Have a look at how stripes does it. Ajax
for validation is trivial and not that impressive, but people are going to want
to do real ajax work, and webwork does absolutely nothing to help in that
regard. I'd like to for example be able to easily invoke actions and get at
some kind of result to display, and have webwork provide at least some of the
wiring
+ * [jcarreira] Well, that's a relatively simple usecase, and I think it IS
supported... at least we use it at work?
1. The default theme for the ui tags should be simple. The current stuff is
too dumb to get right on the first go, which gives an awful impression. It's
NOT intuitive to write: {{{
table
ww:textfield label=Enter blah /
/table
}}}
+ * [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.
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
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
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
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.
1. Ditch xwork as a separate project, nobody uses it or cares about it
+ * [jcarreira] You're kidding, right? We've discussed this already
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
1. Clean up documentation. Focus on quality not quantity.
+ * [jcarreira] Didn't you read the book? ;-)
== Patrick's issues ==
@@ -187, +196 @@
* [jcarreira] +1 : Carlos at G**gle had some good ideas for this...
basically stuff like if your action method is foo() then you'd have
prepareFoo() and validateFoo(), but then I added that the prepare() and
validate() methods should be the defaults that we call for all action methods.
* [crazybob] Interesting idea. Might be overkill (i.e. at that point,
the user should probably create another action class).
* [hani] No magic method names. If you want to do that, use annotations
so you have a good chance of IDE support dealing with it. For example
@Validate/@Prepare etc, with parameters to indicate what request you'd like it
involved for, in the case where you need multiples of them
+ * [jcarreira] I think RoR has shown that convention over configuration is
liked by lots of people... these should be straightforward to figure out
without annotations.
+
1. Don't encourage lots of interceptor stacks. Ideally the normal user
should never need to deal with them. It is better to have a larger stack that
has optional features that could be turned on through annotations or marker
interfaces than to encourage users to build their own stacks.
* [jcarreira] I think we should have some pre-defined ones for standard
things: view vs. CRUD vs. action - do
[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. 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. :-) 1. Ditch xwork as a separate project, nobody uses it or cares about it * [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. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsTools by YannCebron
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 YannCebron: http://wiki.apache.org/struts/StrutsTools -- http://www.common-controls.com/en/index.php - The Common-Controls form a Java™ Presentation Framework based on Java Servlets, Java Serverpages (JSP™) and Struts. The Presentation Framework contains the most common control elements like lists, trees, tabfolders, menus and forms, which are required for the development of J2EE™ applications with HTML frontends. - http://www.intellij.org/twiki/bin/view/Main/StrutsPluginDevelopment - Struts Plugin for IntelliJ IDEA 5 provides inspections to check struts-config.xml-files and Struts specific code on-the-fly (also available via the integrated plugin manager). + http://www.intellij.org/twiki/bin/view/Main/StrutsPluginDevelopment - Provides full integration of Struts in IntelliJ IDEA 5/6 for configuration files and JAVA code (navigation, highlighting, autocompletion, inspections, ..) - 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
--
* [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.
+ 1. 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.{{{action
name=addPerson class=com.opensymphony.webwork.showcase.person.AddPerson
+interceptor-ref name=validationStack/
+param name=dataSourcepeople/param
+resultshowPerson.jsp/result
+result name=inputaddPerson.jsp/result
+result name=errorerrorOnAddPerson.jsp/result
+result type=redirectlogin.action/result
+ /action
+
+ action name=xmlAddPerson extends=addPerson
+result name=inputxmlAddPerson.jsp/result
+ /action}}}I'd prefer using this approach instead of having the xmlAction
chain to another.
+
+
== 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 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
--
* [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.
- 1. 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.{{{action
name=addPerson class=com.opensymphony.webwork.showcase.person.AddPerson
+ 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.{{{action
name=addPerson class=com.opensymphony.webwork.showcase.person.AddPerson
interceptor-ref name=validationStack/
param name=dataSourcepeople/param
resultshowPerson.jsp/result
@@ -243, +243 @@
result name=inputxmlAddPerson.jsp/result
/action}}}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.
== What JDK Version? ==
-
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 -- result name=inputxmlAddPerson.jsp/result /action}}}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. + 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. == What JDK Version? == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by MartinCooper
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 MartinCooper: http://wiki.apache.org/struts/RoughSpots -- * [mrdon] I'd like to use Java 5, but use retroweaver to continue to support 1.4. If we keep XML in addition to annotations, that should be very doable. * [crazybob] Sounds good. We'll also need to handle JDK-1.5 only APIs (concurrency for example). * [Gabe] I am required to use 1.4 at work. To me the question of whether to require 1.5 comes down to whether the same shops that are stuck using 1.4 are also not going to let people use Struts 2.0, because it is too bleeding edge anyway. In that case it doesn't make sense to allow 1.4, because the only people who would be using it would also have access to 1.5 anyway. I don't know if that is the case though. + * [martinc] The big issue with the JDK version is app servers. This comes in two parts. First is whether all of the major app server vendors have products available that support the desired SDK version. I believe we're OK in that regard with JDK 1.5. The bigger issue is customer acceptance. Enterprise customers, especially, tend to standardise on their app server, and they are not quick to upgrade. Unless the application vendor has a great deal of influence over the customer's infrastructure, the vendor has to live with whatever app server version is in use at the customer site. It is rare, then, that the application vendor can dictate the JDK version. On the other hand, the customer usually couldn't care less what version of Struts the application was built with. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of RoughSpots by MartinCooper
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 MartinCooper: http://wiki.apache.org/struts/RoughSpots The comment on the change is: Add link to Retroweaver -- * [crazybob] +1 for JDK 1.5 since it came out. I have a lot of code I could contribute which depends on the new concurrency libraries, etc. * [MJ] With JDK 1.5 as a requirement for SAF2-based projects, users may be inclined to take a look at [http://stripes.mc4j.org/confluence/display/stripes/Home Stripes] first. It is compact, it features event-dispatching, built-in validation and conversion, Action and !ActionForm being one entity, and it allows to forgo XML config files by using annotations. The last feature alone is worth sack o'gold. If SAF2 is going to require JDK 1.5, it should allow XML-free configuration, at least for simple use cases. * [plightbo] I use JDK 1.5 as well. I think we really should think about doing this. Non-1.5 options exist (WebWork 2.2 and Struts 1.3), and we're really at a close point where it is no longer unreasonable to require 1.5 (1.6 will have been out for almost 6 months by the time we hit a final release). - * [mrdon] I'd like to use Java 5, but use retroweaver to continue to support 1.4. If we keep XML in addition to annotations, that should be very doable. + * [mrdon] I'd like to use Java 5, but use [http://retroweaver.sourceforge.net/ Retroweaver] to continue to support 1.4. If we keep XML in addition to annotations, that should be very doable. * [crazybob] Sounds good. We'll also need to handle JDK-1.5 only APIs (concurrency for example). * [Gabe] I am required to use 1.4 at work. To me the question of whether to require 1.5 comes down to whether the same shops that are stuck using 1.4 are also not going to let people use Struts 2.0, because it is too bleeding edge anyway. In that case it doesn't make sense to allow 1.4, because the only people who would be using it would also have access to 1.5 anyway. I don't know if that is the case though. * [martinc] The big issue with the JDK version is app servers. This comes in two parts. First is whether all of the major app server vendors have products available that support the desired SDK version. I believe we're OK in that regard with JDK 1.5. The bigger issue is customer acceptance. Enterprise customers, especially, tend to standardise on their app server, and they are not quick to upgrade. Unless the application vendor has a great deal of influence over the customer's infrastructure, the vendor has to live with whatever app server version is in use at the customer site. It is rare, then, that the application vendor can dictate the JDK version. On the other hand, the customer usually couldn't care less what version of Struts the application was built with. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by TimFennell
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 TimFennell: http://wiki.apache.org/struts/RoughSpots The comment on the change is: Added some my issues, and commented on existing ones. -- * [crazybob] I'll buy that. We do need to move the constants out and encourage users to use static import (Effective Java Item 17). * [plightbo] Related to this, I would encourage us to try to find a solution (using Bob's mix-in suggestion below, or possibly just taking advantage of the value stack) that would make ActionSupport much simpler. This would encourage using POJOs more. * [mrdon] Regardless whether we remove Action or not, I like the idea of moving the result constants out. + * [tfenne] I think removing Action would be a bad idea. If you're going to try and get away from requiring XML configuration or listing out all your Actions somewhere, you'll probably want to have someway of discovering your Actions. An interface is the easiest option - an annotation would do too, but would feel a little stranger I think. 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. @@ -213, +214 @@ 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. + == 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. + + 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. + 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(). + 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. 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. + + == Nice to haves == 1. Inheritance is not a good way to reuse code between actions. One work around is to use the strategy pattern to swap in different implementations of interfaces like `ValidationAware`. It would be nice if the framework had built-in support for mixins using cglib or Dynaop. For example, instead of extending a class that implements `ValidationAware`, SAF could extend an action class at
[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 -- Some things that could be addresssed before Action 2.0.0. (If we don't address them, we'll be stuck supporting them throughout all eternity or until Struts 3.0.0, whichever comes first. ;)) - We have a small number of existing WebWork users compared to the number of Struts users we'll (hopefully) eventually have. This is a new framework (if only in name) and a major release. This is our one chance to break compatibility. We must get it right now, because we will *not* be able to fix most of these problems later (the cost of breaking existing Struts users will almost always outweigh the value of the fix). + We have a small number of existing !WebWork users compared to the number of Struts users we'll (hopefully) eventually have. This is a new framework (if only in name) and a major release. This is our one chance to break compatibility. We must get it right now, because we will *not* be able to fix most of these problems later (the cost of breaking existing Struts users will almost always outweigh the value of the fix). We do not need to expose Struts users to XWork; they do not care. At the very least we should build a thin abstraction layer to isolate users from XWork. XWork should be an implementation detail not part of the SAF API. We can make most of the following changes in SAF's abstraction layer and avoid breaking existing XWork users. @@ -220, +220 @@ 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. 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(). 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 + * [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. 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots 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/RoughSpots
--
* [plightbo] By running our interceptors and other objects through the
same factories and lifecycle managers that the action classes go through, this
should be a non issue.
* [mrdon] This I'd like to see. I've found myself using these objects so
often in wierd little places, I'd be loath to remove them unless we could prove
100% that their information can be retrieved elsewhere.
* [jcarreira] +1 to Patrick's point... we may need to introduce some more
advanced *Aware interfaces, though, to give people access to the guts if they
really want it.
+ * [frankz] !ActionContext being !ThreadLocal was one of the first cool
things I noticed about WW. I'd hate to see that change. The only thing I can
think of that would make me agree to change that is that I think we may find
developers using it in inappropriate ways, i.e., an Action calls a business
delegate and the delegate uses !ActionContext. My bet is most people would
agree it should be a best practice to not do that. Still, it's cool that you
can!
1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would
be a better name.
@@ -117, +118 @@
* [crazybob] Triggering an event should still be a POST (though the
framework should make it easy). From the HTTP spec.: GET and HEAD methods
SHOULD NOT have the significance of taking an action other than retrieval.
* [jcarreira] I think it's great that you want to take the HTTP spec at
its word... most users don't care though.
* [crazybob] I'm not arguing semantics. There are real security
implications to using GET when you should use POST, not to mention products
like Google Web Accelerator will reak havok on your site. As framework
developers, we should make using POST as easy as GET for users. To not help
users do the right thing in this situation would be irresponsible, and not in
the letter of the law sense.
+ * [frankz] Perhaps a new attribute on the action mapping?
type=view or type=update? This would really make the mapping of a specific
various type, not the underlying Action, which might be better because the type
is abstracted from the actual implementation and the Action class itself can
house both types of functions (i.e., something like a !DispatchAction), but the
framework can know to treat them differently as appropriate. I'm not one of
those no XML config! folks, I actually still prefer it to annotations, but
having an analogous annotation would be a good idea too.
1. On the OGNL value stack `#request` refers to request attributes and
`#parameters` refers to the parameters. We could rename these `#request` for
request parameters and `#requestAttributes` for request attributes.
@@ -155, +157 @@
1. The ajax support is pitiful. Have a look at how stripes does it. Ajax
for validation is trivial and not that impressive, but people are going to want
to do real ajax work, and webwork does absolutely nothing to help in that
regard. I'd like to for example be able to easily invoke actions and get at
some kind of result to display, and have webwork provide at least some of the
wiring
* [jcarreira] Well, that's a relatively simple usecase, and I think it IS
supported... at least we use it at work?
+ * [frankz] I would ask what real AJAX work means, because that would
really determine what path makes sense.
1. The default theme for the ui tags should be simple. The current stuff is
too dumb to get right on the first go, which gives an awful impression. It's
NOT intuitive to write: {{{
table
@@ -165, +168 @@
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
+ * [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!
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
@@ -173, +177 @@
1. Get rid of the validation framework. it's
[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:
Update assembly instructions
--
}}}
=== Binary and Source Assembly ===
- To build the -all assembly, first enable the 'pre-assembly' profile, which
will cause the javadoc and source artifacts to be produced:
+ To build the -all assembly, enable the 'pre-assembly' profile (which produces
the javadoc and source artifacts), and execute both 'install' and 'site':
{{{
~/svn/struts/current/action
-$ mvn -P pre-assembly
+$ mvn install site -P pre-assembly
}}}
And then create the assembly:
{{{
@@ -56, +56 @@
=== Source Assembly ===
- * The -sources jars are included in struts-action-x.x.x-all.[zip|tar.gz].
+ * The source code is included in struts-action-x.x.x-all.zip.
- * Wait for v2.1 of maven-assembly-plugin, then switch to the
action/assembly/src/main/assembly/src.xml and dep.xml descriptors for separate
-bin and -src assemblies.
+ * 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.
-
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:
The site must be built before the assembly.
--
1. Ensure that your settings.xml contains a server 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 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. Create and upload signatures for all .jar and .pom files in
maven-snapshot-repository, and the .zip, and .tar.gz files.
@@ -16, +17 @@
rm -rf $M2_REPO/org/apache/struts/action
mvn deploy -P pre-assembly
{about 20 minutes later...}
+ mvn site site:deploy
+ {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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by CraigMcClanahan
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 CraigMcClanahan: http://wiki.apache.org/struts/RoughSpots -- * [plightbo] Related to this, I would encourage us to try to find a solution (using Bob's mix-in suggestion below, or possibly just taking advantage of the value stack) that would make ActionSupport much simpler. This would encourage using POJOs more. * [mrdon] Regardless whether we remove Action or not, I like the idea of moving the result constants out. * [tfenne] I think removing Action would be a bad idea. If you're going to try and get away from requiring XML configuration or listing out all your Actions somewhere, you'll probably want to have someway of discovering your Actions. An interface is the easiest option - an annotation would do too, but would feel a little stranger I think. + * [craigmcc] You can actually have this one both ways, as we do in Shale -- define an Action interface for + the JDK 1.4 users, and provide an optional JavaSE 5 layer that lets you define the appropriate callbacks + with annotations instead. For a detailed example, take a look at how Shale's Tiger Extensions package + lets you get the functionality of a ViewController interface without having to say implements + ViewController in your action class. 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. * [mrdon] +1 + * [craigmcc] In Shale, I adopted the convention of package org.apache.shale.foo for public APIs, and + org.apache.shale.foo.impl for things like default implemetnation classes. However, there is an additional + subtlety here to take into account -- there is a difference between APIs that application developers should + 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. 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. @@ -35, +45 @@ * [mrdon] This I don't agree with. From a framework developer, I understand the logic, but from a user, it is arrogant. I think we should allow people to extend Struts in ways we haven't imagined, and restricting access like this says, We know more than you and will force you to do it our way. * [crazybob] I don't think we should make everything final or anything, but I do think we should differentiate between the published API and the implementation through package organization, excluding stuff from the Javadocs, etc. Users can know that we won't change the published API out from under them, but that if they depend on implementation classes, we may break them (reluctantly). It's the polite thing to do, and it frees us up to refactor and improve our implementation. * [jcarreira] +1 published public vs. private APIs are a good thing, and a contract with the user of what can change. + * [craigmcc] See comments on the previous bullet related to APIs that application developers use versus those + who are extending the framework might use. 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. @@ -68, +80 @@ * [mrdon] This I'd like to see. I've found myself using these objects so often in wierd little places, I'd be loath to remove them unless we could prove 100% that their information can be retrieved elsewhere. * [jcarreira] +1 to Patrick's point... we may need to introduce some more advanced *Aware interfaces, though, to give people access to the guts if they really want it. * [frankz] !ActionContext being !ThreadLocal was one of the first cool things I noticed about WW. I'd hate to see that change. The only thing I can think of that would make me agree to change that is that I think we may find developers using it in inappropriate ways, i.e., an Action calls a business delegate and the delegate uses !ActionContext. My bet is most people would agree it should be a best practice to not do that. Still, it's cool that you can! + * [craigmcc] JSF likes the thread local approach to a per-request context object (FacesContext in this
[Struts Wiki] 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 -- '''NOTE''' For info on cutting a release see [http://struts.apache.org/releases.html#Releases Struts Release Guidelines] and StrutsMavenRelease. - = 1. Struts Action 1.3.x Release Plans = - + = 1. Struts Action = + == 1.3.x == * StrutsClassicRelease130 - ''Struts Version 1.3.0'' * StrutsActionRelease131 - ''Struts Action Version 1.3.1'' * StrutsTaglibRelease131 - ''Struts Taglib Version 1.3.1'' (cancelled) * StrutsExtrasRelease131 - ''Struts Extras Version 1.3.1'' (cancelled) * StrutsActionRelease132 - ''Struts Action Version 1.3.2'' + == 1.2.x == - - = 2. Struts-Faces Release Plans = - - * StrutsFacesRelease101 - ''Struts-Faces Version 1.0.1'' - - = 3. Struts Action 1.2.x Release Plans = - * StrutsRelease122 - ''Struts Version 1.2.2'' * StrutsRelease123 - ''Struts Version 1.2.3'' * StrutsRelease124 - ''Struts Version 1.2.4'' @@ -28, +22 @@ * StrutsRelease127 - ''Struts Version 1.2.7'' * StrutsRelease128 - ''Struts Version 1.2.8'' * StrutsRelease129 - ''Struts Version 1.2.9'' + == Miscellaneous == + * StrutsFacesRelease101 - ''Struts-Faces Version 1.0.1'' + * StrutsScriptingRelease100 - ''Struts Scripting Version 1.0.0'' + * StrutsScriptingRelease101 - ''Struts Scripting Version 1.0.1'' - = 4. Struts Shale Release Plans = + = 2. Struts Shale = * ShaleRelease100 - ''Struts Shale Version 1.0.0'' * ShaleRelease101 - ''Struts Shale Version 1.0.1'' * ShaleRelease102 - ''Struts Shale Version 1.0.2'' - = 5. Struts Scripting Release Plans = - - * StrutsScriptingRelease100 - ''Struts Scripting Version 1.0.0'' - * StrutsScriptingRelease101 - ''Struts Scripting Version 1.0.1'' - - 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 New page: = Struts Action 1.3.2 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.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) * 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 * * http://wiki.apache.org/struts/StrutsMaintenanceMaven * Change to the new folder (e.g., \opt\struts-action-1.3.2) * $ mvn * Wait about five minutes for Maven to download and build everything ** If you see any error messages, see if they are known issues by comparing your log with ours at http://svn.apache.org/builds/struts/maven/trunk/nightly/logs/ == Outstanding Bugs == http://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10121fixfor=21699 == 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.2.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 action and build, project.xml and pom.xml to omit -SNAPSHOT || || || A1. || Tag release in svn: STRUTS_ACTION_1_3_1, STRUTS_BUILD_1_3_1 || || || A1.1 || Modify svn:externals for 'build' on STRUTS_ACTION_1_3_1 tag || || || A2. || Check out a clean copy using the 'tag' created in A1 and and run Distribution Target || || || A3. || Update action and build, project.xml and pom.xml to 1.3.2-SNAPSHOT || || || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.1 || || || A5. || Announce the Test Build on dev@ and user@ lists (optional) || || || A6. || 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 Distributions [2] || || || B2. || Create a new JIRA version level (1.3.3) || || || B3. || Update Acquiring page on website and Test Downloads || || == Vote (B) == || PMC Member || Quality
[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 -- || '''#''' || '''Description''' || '''Completed''' || || A0. || Update action and build, project.xml and pom.xml to omit -SNAPSHOT || || - || A1. || Tag release in svn: STRUTS_ACTION_1_3_1, STRUTS_BUILD_1_3_1 || || + || A1. || Tag release in svn: STRUTS_ACTION_1_3_2 || || - || A1.1 || Modify svn:externals for 'build' on STRUTS_ACTION_1_3_1 tag || || || A2. || Check out a clean copy using the 'tag' created in A1 and and run Distribution Target || || - || A3. || Update action and build, project.xml and pom.xml to 1.3.2-SNAPSHOT || || + || A3. || Update action and build, pom.xml to 1.3.3-SNAPSHOT || || - || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.1 || || + || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || || || A5. || Announce the Test Build on dev@ and user@ lists (optional) || || || A6. || 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 StrutsActionRelease132 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/StrutsActionRelease132 The comment on the change is: The Maven 1 logs (even if there were any) will look nothing like Maven 2 logs -- * Change to the new folder (e.g., \opt\struts-action-1.3.2) * $ mvn * Wait about five minutes for Maven to download and build everything - ** If you see any error messages, see if they are known issues by comparing your log with ours at http://svn.apache.org/builds/struts/maven/trunk/nightly/logs/ + ** 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 == - 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: Update checklists, add link to snapshot. -- 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) + * 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) * Install Java and set JAVA_HOME * Install Maven 2 and set MAVEN_HOME * Install Apache Tomcat - * * http://wiki.apache.org/struts/StrutsMaintenanceMaven + * http://wiki.apache.org/struts/StrutsMaintenanceMaven - * Change to the new folder (e.g., \opt\struts-action-1.3.2) + * Change to the new folder (e.g., /opt/struts-action-1.3.2/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. @@ -88, +88 @@ See also Commons [http://jakarta.apache.org/commons/releases/release.html Step-by-Step Guide] || '''#''' || '''Description''' || '''Completed''' || - || A0. || Update action and build, project.xml and pom.xml to omit -SNAPSHOT || || + || A0. || Update all pom.xml files to omit -SNAPSHOT || || || A1. || Tag release in svn: STRUTS_ACTION_1_3_2 || || - || A2. || Check out a clean copy using the 'tag' created in A1 and and run Distribution Target || || + || A2. || Check out a clean copy using the 'tag' created in A1 and see StrutsMavenRelease || || - || A3. || Update action and build, pom.xml to 1.3.3-SNAPSHOT || || + || A3. || Update all pom.xml files to 1.3.3-SNAPSHOT || || || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || || || A5. || Announce the Test Build on dev@ and user@ lists (optional) || || || A6. || Post release-quality vote on dev@ and user@ lists || || @@ -110, +110 @@ || '''#''' || '''Description''' || '''Completed''' || || B1. || Create Sums and Sign Distributions [2] || || - || B2. || Create a new JIRA version level (1.3.3) || || + || B2. || Create a new JIRA version level (1.3.2) || || || B3. || Update Acquiring page on website and Test Downloads || || == Vote (B) == @@ -124, +124 @@ || '''#''' || '''Description''' || '''Completed''' || || C1. || Copy Distribution to Mirrored Directories [3] || _ || - || C2. || Deploy JAR and POM to Apache Java-Repository || _ || + || C2. || Promote Test Build from maven-snapshot-repository to dist/maven-repository || _ || || C3. || After 24 hours, update Acquiring page on website || _ || || C4. || Post an announcement to lists and website || _ || - 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: Updated test build checklist -- || A0. || Update all pom.xml files to omit -SNAPSHOT || || || 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 || || + || 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 || || - || A3. || Update all pom.xml files to 1.3.3-SNAPSHOT || || + || A5. || Update all pom.xml files to 1.3.3-SNAPSHOT || || - || A4. || Upload Distribution to cvs.apache.org:/www/cvs.apache.org/dist/struts/action/v1.3.2 || || - || A5. || Announce the Test Build on dev@ and user@ lists (optional) || || + || A6. || Announce the Test Build on dev@ and user@ lists (optional) || || - || A6. || 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 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 -- with annotations instead. For a detailed example, take a look at how Shale's Tiger Extensions package 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. 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. @@ -38, +39 @@ subtlety here to take into account -- there is a difference between APIs that application developers should 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. 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. @@ -89, +91 @@ you are in exactly the same boat. The Servlet API considers this a feature rather than a bug, because a Filter can actually wrap the incoming request and response objects to provide extra functionality -- this at least wouldn't be possible in the case of a thread-local state object. + * [crazybob] Good point (Though it is possible with a thread local API. Your code can set the thread local to your wrapped object and then restore the original object in a finally block. Not ideal.) * [craigmcc] Interceptors need access to the servlet API -- doesn't anyone care about making it possible 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. @@ -143, +147 @@ * [jcarreira] I think it's great that you want to take the HTTP spec at its word... most users don't care though. * [crazybob] I'm not arguing semantics. There are real security implications to using GET when you should use POST, not to mention products like Google Web Accelerator will reak havok on your site. As framework developers, we should make using POST as easy as GET for users. To not help users do the right thing in this situation would be irresponsible, and not in the letter of the law sense. * [frankz] Perhaps a new attribute on the action mapping? type=view or type=update? This would really make the mapping of a specific various type, not the underlying Action, which might be better because the type is abstracted from the actual implementation and the Action class itself can house both types of functions (i.e., something like a !DispatchAction), but the framework can know to treat them differently as appropriate. I'm not one of those no XML config! folks, I actually still prefer it to annotations, but having an analogous annotation would be a good idea too. + * [crazybob] In addition to view and update, we might want chained view and chained update. Can anyone else think of more stereotypes? Can you think of a better name than stereotype? Strategy? 1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. We could rename these `#request` for request parameters and `#requestAttributes` for request attributes. @@ -178, +183 @@ 1. Enable Java package import in configuration so you don't have to repeat the same package name over and over (like WW1 does). * [jcarreira] +1 if it can be made sane... It can get confusing. It also makes tool support worse (i.e. IDEA can find it as a fully qualified class name) + * [crazybob] Regarding tool support, I like writing less code, and this doesn't preclude using fully qualified class names if you still want to. Hopefully this new exposure will bring us real tool support and this won't be an issue. 1. The ajax support is pitiful. Have a look at how stripes does it. Ajax for validation is trivial and not that impressive, but people are going to want to do real ajax work, and
[Struts Wiki] Trivial 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. 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` which pulls an object of the session and passed it to your action. Or you can use Spring. + * [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). 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. @@ -313, +313 @@ * [martinc] The big issue with the JDK version is app servers. This comes in two parts. First is whether all of the major app server vendors have products available that support the desired SDK version. I believe we're OK in that regard with JDK 1.5. The bigger issue is customer acceptance. Enterprise customers, especially, tend to standardise on their app server, and they are not quick to upgrade. Unless the application vendor has a great deal of influence over the customer's infrastructure, the vendor has to live with whatever app server version is in use at the customer site. It is rare, then, that the application vendor can dictate the JDK version. On the other hand, the customer usually couldn't care less what version of Struts the application was built with. * [tfenne] I think you *have* to support JDK 1.5, and it should be the default. If it's not too hard to provide 1.4 compatibility great, but I think all examples, defaults etc. should leverage 1.5. Generics allow you to do much more for the user without asking for configuration information. If a user wants to use JDK 1.5 enums, it should work, etc. etc. If it's extra work on the user's part to make 1.5 features work, simplicity goes out the window. * [frankz] I think this is one of those things to be really careful about the perception people may form. If Action1 is going to continue to develop and be supported, even if to a lesser degree, then forcing 1.5 for Action2 is probably fine. However, I know at my company, we are stuck on 1.4, and won't be changing for a long time. I also know that we are not unique in this regard. If we can't move to Action2. so long as Action1 is still around and being supported, that's fine. But if we can't move to Action2 and it even '''seems''' like Action1 isn't getting enough attention, that wouldn't look so good to us. Ultimately, if both can be supported, I think that is still the best answer. I definitely think the points made about moving to 1.5 are totally valid, but I think that may lock out a lot of people who might otherwise use Action2, so if that can be avoided, so much the better. - * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too. With a little time, 1.4 will become irrelevant. I'm fine with supporting 1.4, but 1.5 should be the priority, and we shouldn't let 1.4 support drive design decisions. + * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too.
[Struts Wiki] Update of RoughSpots 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/RoughSpots -- * [tfenne] I think you *have* to support JDK 1.5, and it should be the default. If it's not too hard to provide 1.4 compatibility great, but I think all examples, defaults etc. should leverage 1.5. Generics allow you to do much more for the user without asking for configuration information. If a user wants to use JDK 1.5 enums, it should work, etc. etc. If it's extra work on the user's part to make 1.5 features work, simplicity goes out the window. * [frankz] I think this is one of those things to be really careful about the perception people may form. If Action1 is going to continue to develop and be supported, even if to a lesser degree, then forcing 1.5 for Action2 is probably fine. However, I know at my company, we are stuck on 1.4, and won't be changing for a long time. I also know that we are not unique in this regard. If we can't move to Action2. so long as Action1 is still around and being supported, that's fine. But if we can't move to Action2 and it even '''seems''' like Action1 isn't getting enough attention, that wouldn't look so good to us. Ultimately, if both can be supported, I think that is still the best answer. I definitely think the points made about moving to 1.5 are totally valid, but I think that may lock out a lot of people who might otherwise use Action2, so if that can be avoided, so much the better. * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too. With a little time, 1.4 will become irrelevant. I'm fine with supporting 1.4, but 1.5 should be the priority, and we shouldn't let 1.4 support negatively impact design decisions. +* [gdinwiddie] WRT if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too, I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. - 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 -- * [tfenne] I think you *have* to support JDK 1.5, and it should be the default. If it's not too hard to provide 1.4 compatibility great, but I think all examples, defaults etc. should leverage 1.5. Generics allow you to do much more for the user without asking for configuration information. If a user wants to use JDK 1.5 enums, it should work, etc. etc. If it's extra work on the user's part to make 1.5 features work, simplicity goes out the window. * [frankz] I think this is one of those things to be really careful about the perception people may form. If Action1 is going to continue to develop and be supported, even if to a lesser degree, then forcing 1.5 for Action2 is probably fine. However, I know at my company, we are stuck on 1.4, and won't be changing for a long time. I also know that we are not unique in this regard. If we can't move to Action2. so long as Action1 is still around and being supported, that's fine. But if we can't move to Action2 and it even '''seems''' like Action1 isn't getting enough attention, that wouldn't look so good to us. Ultimately, if both can be supported, I think that is still the best answer. I definitely think the points made about moving to 1.5 are totally valid, but I think that may lock out a lot of people who might otherwise use Action2, so if that can be avoided, so much the better. * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too. With a little time, 1.4 will become irrelevant. I'm fine with supporting 1.4, but 1.5 should be the priority, and we shouldn't let 1.4 support negatively impact design decisions. -* [gdinwiddie] WRT if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too, I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. + * [gdinwiddie] WRT if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too, I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. + * [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). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots 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/RoughSpots -- 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. * [crazybob] There's no reason we can't support both `String` and `Result` return types for action methods. I think we should encourage `String` though. Can you provide some example use cases for when `String` isn't enough? + * [frankz] A few that come to mind... the ability to choose between redirect and forward based on decisions made in code (you could argue that you can have two result's defined, one with type redirect and one with type forward, but then that starts to clutter the config file I think)... the ability to add parameters to a forwarded result (i.e., if you wanted to forward to another action, how can you add parameters just by returning a String? Well, unless the processor expects and can deal with a query string appended I support)... the ability to add an anchor name to the response... the opportunity to include additional objects in the response (i.e., what if you had some sort of ViewSupport object that the presentation can make use of... it might be more intuitive to add it to a Result than to directly add it as a request attribute, and that also makes for better abstraction from the servlet API). I'm sure there's more, and I'm sure there are ways to accomplish most of these things without returning an object, but I think the clarity of the resultant code is greater by returning a Result object, and it opens up possibilities I can't think of (i.e., functionality encapsulated in that object independant of tbe interceptor stack). == 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
--
* [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.
* [crazybob] There's no reason we can't support both `String` and
`Result` return types for action methods. I think we should encourage `String`
though. Can you provide some example use cases for when `String` isn't enough?
* [frankz] A few that come to mind... the ability to choose between
redirect and forward based on decisions made in code (you could argue that you
can have two result's defined, one with type redirect and one with type
forward, but then that starts to clutter the config file I think)... the
ability to add parameters to a forwarded result (i.e., if you wanted to forward
to another action, how can you add parameters just by returning a String?
Well, unless the processor expects and can deal with a query string appended I
support)... the ability to add an anchor name to the response... the
opportunity to include additional objects in the response (i.e., what if you
had some sort of ViewSupport object that the presentation can make use of... it
might be more intuitive to add it to a Result than to directly add it as a
request attribute, and that also makes for better abstraction from the servlet
API). I'm sure there's more, and I'm sure there are ways to accomplish most
of these things without returning an object, but I think the clarity of the
resultant code is greater by returning a Result object, and it opens up
possibilities I can't think of (i.e., functionality encapsulated in that object
independant of tbe interceptor stack).
-
+ * [mrdon] For further reading:
http://forums.opensymphony.com/thread.jspa?threadID=23621tstart=45
== Nice to haves ==
1. Inheritance is not a good way to reuse code between actions. One work
around is to use the strategy pattern to swap in different implementations of
interfaces like `ValidationAware`. It would be nice if the framework had
built-in support for mixins using cglib or Dynaop. For example, instead of
extending a class that implements `ValidationAware`, SAF could extend an action
class at runtime and implement the `ValidationAware` methods by delegating them
to another object (a mixin): {{{
-
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
--
* [crazybob] There's no reason we can't support both `String` and
`Result` return types for action methods. I think we should encourage `String`
though. Can you provide some example use cases for when `String` isn't enough?
* [frankz] A few that come to mind... the ability to choose between
redirect and forward based on decisions made in code (you could argue that you
can have two result's defined, one with type redirect and one with type
forward, but then that starts to clutter the config file I think)... the
ability to add parameters to a forwarded result (i.e., if you wanted to forward
to another action, how can you add parameters just by returning a String?
Well, unless the processor expects and can deal with a query string appended I
support)... the ability to add an anchor name to the response... the
opportunity to include additional objects in the response (i.e., what if you
had some sort of ViewSupport object that the presentation can make use of... it
might be more intuitive to add it to a Result than to directly add it as a
request attribute, and that also makes for better abstraction from the servlet
API). I'm sure there's more, and I'm sure there are ways to accomplish most
of these things without returning an object, but I think the clarity of the
resultant code is greater by returning a Result object, and it opens up
possibilities I can't think of (i.e., functionality encapsulated in that object
independant of tbe interceptor stack).
* [mrdon] For further reading:
http://forums.opensymphony.com/thread.jspa?threadID=23621tstart=45
+ * [crazybob] I'm not sold on this. 1) The result pulls values from the
value stack, not the request attributes. 2) I ran into a case recently where I
''thought'' I wanted to return a real object at first: I wanted the action to
dynamically select a redirect URL. I ended up doing this: {{{
+ result name=... type=redirect${url}/result
+ }}} 3) Enabling users to return either a real object or a string is going to
impact the interceptor API, too. :( 4) Wait a second... you can do what you
want right now! Create a new result type which looks up a `Result` object on
the value stack and delegates to it. Then map a global result to the new type.
For example, you could return `CUSTOM`, and the the result type would execute
the `Result` returned from `getCustomResult()` on your action. ;)
+
== Nice to haves ==
1. Inheritance is not a good way to reuse code between actions. One work
around is to use the strategy pattern to swap in different implementations of
interfaces like `ValidationAware`. It would be nice if the framework had
built-in support for mixins using cglib or Dynaop. For example, instead of
extending a class that implements `ValidationAware`, SAF could extend an action
class at runtime and implement the `ValidationAware` methods by delegating them
to another object (a mixin): {{{
-
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]
[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 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 @@ /h:form }}} + == 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 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 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 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 html:html 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 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 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 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 server for apache-site -- usernameyourid/username privateKey/path/to/private/key/privateKey /server +server + idapache-site/id + usernameyourid/username + privateKey/path/to/private/key/privateKey +/server /servers profiles - 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 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] 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 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=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10121fixfor=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 Distributions [2]
[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] 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] 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 server 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 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 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.{{{action
name=addPerson class=com.opensymphony.webwork.showcase.person.AddPerson
interceptor-ref name=validationStack/
-
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 -- /action}}}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 -- action name=xmlAddPerson extends=addPerson result name=inputxmlAddPerson.jsp/result /action}}}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 -- * [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. :-) 1.
[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 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 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 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 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 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. When you
[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
--
param name=namespace/${actionNamespace}/param
/result
}}} 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 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 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. 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 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 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 -- result name=inputxmlAddPerson.jsp/result /action}}}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] 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 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 server 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] 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 the
[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 - it's
[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:
[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 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 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 webResources 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 dependencyManagement in action/trunk/pom.xml to control version numbers. Modules then declare only groupId/artifactId for dependencies. + * Use dependencyManagement in action/trunk/pom.xml to control version numbers. Modules then declare only groupId/artifactId for dependencies. (A brief look says there isn't as much duplication as I thought; this might not be necessary.) - * Add reporting 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 resource 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 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 @@
profile
idcargo-config/id
properties
-
cargo.tomcat5x.homec:/java/apache-tomcat-5.5.16/cargo.tomcat5x.home
+
cargo.tomcat5x.homec:/java/apache-tomcat-5.5.17/cargo.tomcat5x.home
cargo.tomcat4x.homec:/java/jakarta-tomcat-4.1.31/cargo.tomcat4x.home
/properties
/profile
@@ -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: 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]
