Re: Struts Toolkit (was SuccessAction)

[Ted Husted <hu...@apache.org>]

First, I don't think there's anything "wrong" with our defining the term 
success to indicate a nominal outcome. Java does the same with terms 
like "true" and "false". I'd also submit that that SUCCESS and FAILURE 
in Globals would be a clear demonstration of an important best practice: 
Use formally-defined Statics for programming elements, such as the names 
of ActionForwards.

But, at the same time, I would caution against shoveling a lot of 
toolkit components into the Actions package. I think the complex 
dispatch-like Actions are fine. But things like a SuccessAction or a 
DefaultAction, et al, might really belong in a "toolkit" package with 
its own release cycle.

I don't think this would be the best time for us to stake out another 
package to distribute. But, when I get to back to work on the Struts 
University thing, I do know that a number of these types of toolkit 
classes will be needed, if best practices are to be demonstrated.

Joe G and I have been talking about setting up a Struts-Toolkit 
distribution on the Struts SourceForge site. This can be home to things 
like "SuccessAction" and some of the more useful Scaffold things, and so 
forth. We can try to release this about the same time as Struts 1.2.0.

The Sourceforge Struts site using a open-door Commons approach. Any 
developer with a *working* Struts-related component to donate is 
eligible for membership as a developer, with write access to everything. 
Though, the binding votes are between the Admin group. Any Struts 
Committer is eligible to be Struts SourceForge Admin (just send us your 
SF ID).

-Ted.



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

RE: Struts Toolkit (was SuccessAction)

[Steve Raeburn <sr...@apache.org>]

I think the functionality that SuccessAction provides should be part of the
core distribution, particularly as we're encouraging linking only to
actions. This make it a whole lot easier.

I'm sure there's a whole lot of things that can go into a toolkit, but would
it be very different from Scaffold?

Steve

> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: August 9, 2003 6:52 AM
> To: Struts Developers List
> Subject: Re: Struts Toolkit (was SuccessAction)
>
>
> First, I don't think there's anything "wrong" with our defining the term
> success to indicate a nominal outcome. Java does the same with terms
> like "true" and "false". I'd also submit that that SUCCESS and FAILURE
> in Globals would be a clear demonstration of an important best practice:
> Use formally-defined Statics for programming elements, such as the names
> of ActionForwards.
>
> But, at the same time, I would caution against shoveling a lot of
> toolkit components into the Actions package. I think the complex
> dispatch-like Actions are fine. But things like a SuccessAction or a
> DefaultAction, et al, might really belong in a "toolkit" package with
> its own release cycle.
>
> I don't think this would be the best time for us to stake out another
> package to distribute. But, when I get to back to work on the Struts
> University thing, I do know that a number of these types of toolkit
> classes will be needed, if best practices are to be demonstrated.
>
> Joe G and I have been talking about setting up a Struts-Toolkit
> distribution on the Struts SourceForge site. This can be home to things
> like "SuccessAction" and some of the more useful Scaffold things, and so
> forth. We can try to release this about the same time as Struts 1.2.0.
>
> The Sourceforge Struts site using a open-door Commons approach. Any
> developer with a *working* Struts-related component to donate is
> eligible for membership as a developer, with write access to everything.
> Though, the binding votes are between the Admin group. Any Struts
> Committer is eligible to be Struts SourceForge Admin (just send us your
> SF ID).
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org