> -----Original Message----- > From: Steve Raeburn [mailto:[EMAIL PROTECTED] > Sent: Monday, April 26, 2004 10:55 PM > To: Struts Developers List > Subject: RE: Adding new Struts features/sub-projects (was [Bug 28609] - > Scriptable Actions Support) > > > Some ideas, not neccessarily complete or well-formed... > > > -----Original Message----- > > From: David Graham [mailto:[EMAIL PROTECTED] > > Sent: April 26, 2004 9:44 PM > > To: Struts Developers List > > Subject: Re: Adding new Struts features/sub-projects (was > > [Bug 28609] - > > Scriptable Actions Support) > > > > What criteria are we using when deciding what to add to the Struts > > project? > > Core: > 1. Must make Struts a better controller. (easier to use, more > flexible, more reliable, more performant etc.) > 2. See 1. > > "Scriptable Actions" seems to achieve the first two items in #1, so > under those criteria maybe it should be in the core.
Hmm. These days, I'm leaning towards thinking of Actions as something we retain for backwards compatibility only, once we're in a Struts 2.0 world, so I'm not sure I'd consider a scriptable action, let alone just a plain Action, as something that would go in the core. I should probably elaborate a little on the perhaps heretical statement above. ;-) For a long time now, I have considered Actions as almost an anti-pattern. The need to separate the incoming request handling from the outgoing view preparation is fairly clear to many people, I think. Today, Struts does not provide a real solution to this problem, especially for applications which must be customisable without requiring changes to the Actions themselves. As a result, many, many people try to do this by chaining Actions, and thereby get themselves into trouble that they don't understand. Instead, I'd prefer to see us move away from Actions as the core actionable objects, and towards something like a request handler and view preparer, or, more generally, a chain of commands, a la Commons Chain. Today's Actions would be a degenerate case. Hence, I'm not arguing about the "Scriptable" part of "Scriptable Actions", but more questioning whether or not the "Actions" part is the right granularity. > Sub-projects: > > 1. Must add value to Struts for a good proportion of the Struts user > base. > 2. Must depend on Struts (does this exclude Tiles ??) This is an interesting one. The edge cases (no connection with Struts, or isn't useful without Struts) are obvious, but there's a big grey area in between. For example, it's obvious that Tiles is useful without Struts, but it's also clear that the integration glue is indispensable when using Tiles together with Struts. As a contrasting example, Velocity is obviously useful without Struts, but VelocityStruts makes life a great deal easier for those using Velocity together with Struts. It almost seems more like a question of pre-existing community than anything else. -- Martin Cooper > 3. Must be of sufficient quality to be worthy of the Apache Struts > 'brand' > 4. Must have committers who have demonstrated a commitment to > maintaining the add-on (either existing Struts committers or developers > willing to become Struts committers). I think that, in practice, a few > of the existing committers should at least be familiar with the add-on. > > #1 is the main reason to include a sub-project. It has to justify its > existence by make life easier for Struts users. If it does that, we're > performing an additional service of making it visible to a wider > audience and easing its adoption by making it an "official" Struts > extension. For some reason, that kind of thing means a lot to > pointy-haired types ;-) > > > The questions I asked in the bugzilla posting haven't been > > addressed. Why should the Struts team be expected to house > > and support extra add-on projects? > > I don't see that, in this case, the Struts team is being expected to > make any additional effort since it's already being maintained by two of > us. Presumably, any other project would also come with developers who > have been maintaining it separately. They could not only continue to do > so, but also contribute to Struts core. > > > We've been making good progress moving code out of > > Struts into the commons and focusing on a smaller core of > > functionality. > > I'd hate to reverse that trend and start bloating Struts again. > > Sub-projects should depend on Struts core, but not the other way around. > So sub-projects would not bloat Struts core. Don't forget that one > source for Struts sub-projects is the existing Struts codebase, thus > de-bloating core Struts further. > > > IMO, the BSF actions are a perfect example of a core Struts > > feature (ie. Actions) allowing many neat implementations that > > don't have to be supported by the core project. > > But to make life easier for Struts' users, we can provide useful, > trusted, proven extensions from the same place they already get Struts. > > > > > David > > Steve > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
