You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Steve Raeburn <sr...@apache.org> on 2004/04/27 06:02:11 UTC
Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
I'm posting this to the dev-list rather than carrying on with Bugzilla,
since it looks like there might be some further discussion :-)
I have no position on whether this should be considered core or an
add-on, but if it's to be an add-on, why not bring it into Struts as a
new sub-project? It would be a good way to increase its visibilty and
acceptance while leaving it as an optional addition to the core Struts
product.
Other add-ons, could similarly be brought into the project, if their
communities wanted.
Steve
> -----Original Message-----
> From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: April 26, 2004 7:57 PM
> To: dev@struts.apache.org
> Subject: DO NOT REPLY [Bug 28609] - Scriptable Actions Support
>
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=28609>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28609
>
> Scriptable Actions Support
>
>
>
>
>
> ------- Additional Comments From dgraham@apache.org
> 2004-04-27 02:57 -------
> Why should this move into the Struts project? Why isn't the
> SourceForge project
> a good home for this action? I admit that this seems pretty
> neat but Struts has
> a large dependency list as it is. It would be nice if Struts
> could avoid the
> language-flavor-of-the-week syndrome that other projects
> suffer from. A solid
> core framework with satellite add-on projects seems to be
> working well so far.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Steve Raeburn [mailto:sraeburn@apache.org]
> Sent: Monday, April 26, 2004 9:02 PM
> To: Struts Developers List
> Subject: Adding new Struts features/sub-projects (was [Bug 28609] -
> Scriptable Actions Support)
>
>
> I'm posting this to the dev-list rather than carrying on with Bugzilla,
> since it looks like there might be some further discussion :-)
;-)
> I have no position on whether this should be considered core or an
> add-on, but if it's to be an add-on, why not bring it into Struts as a
> new sub-project? It would be a good way to increase its visibilty and
> acceptance while leaving it as an optional addition to the core Struts
> product.
We've talked about this type of thing in the context of the migrated Struts
CVS structure (which we don't have yet ;). I don't have a strong feeling one
way or the other for this particular addition, but I do feel strongly that
we need to clearly define the criteria for what qualifies to be brought into
Struts proper, before we start bringing things in.
My concern is that we don't want to end up with people expecting that any
old addition will be accepted, and we also don't want to end up with a
myriad unrelated little add ons that bear no relation to each other or to
any particular use cases of Struts other than someone's current project at
the time they created it.
(BTW, just to be clear, I am not casting aspersions on Scriptable Actions!
:)
--
Martin Cooper
> Other add-ons, could similarly be brought into the project, if their
> communities wanted.
>
> Steve
>
> > -----Original Message-----
> > From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> > Sent: April 26, 2004 7:57 PM
> > To: dev@struts.apache.org
> > Subject: DO NOT REPLY [Bug 28609] - Scriptable Actions Support
> >
> >
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > <http://issues.apache.org/bugzilla/show_bug.cgi?id=28609>.
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > INSERTED IN THE BUG DATABASE.
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=28609
> >
> > Scriptable Actions Support
> >
> >
> >
> >
> >
> > ------- Additional Comments From dgraham@apache.org
> > 2004-04-27 02:57 -------
> > Why should this move into the Struts project? Why isn't the
> > SourceForge project
> > a good home for this action? I admit that this seems pretty
> > neat but Struts has
> > a large dependency list as it is. It would be nice if Struts
> > could avoid the
> > language-flavor-of-the-week syndrome that other projects
> > suffer from. A solid
> > core framework with satellite add-on projects seems to be
> > working well so far.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by David Graham <gr...@yahoo.com>.
> > Another way to go might be to just add it to the core. It would
> > creates a runtime dependency on the bsf.jar, but I could live with
> that.
>
> I'd be astonished if this happened. Really. We've just recently ditched
> a
> dependency on Commons Collections, which I personally think was a big
> mistake. If people object to depending on a Commons component that was
> actually created from Struts code in the first place, I simply can't
> imagine
> adding a dependency on something like BSF to the core.
Struts doesn't really need collections other than those provided by the
JDK so removing the dependency on Commons Collections makes sense, IMO.
Struts relies mostly on FastHashMap which I think should be changed in 2.x
because it doesn't work on all Java platforms.
David
>
> --
> Martin Cooper
>
>
> >
> > -Ted.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Wednesday, May 26, 2004 10:21 PM
> To: Struts Developers List
> Subject: Re: Adding new Struts features/sub-projects (was [Bug 28609] -
> Scriptable Actions Support)
>
>
> The sad truth is that many teams that do use Struts cannot also
> use whatever other goody they find on SourceForge or on some
> other open source host.
>
> Many do have permission to use Struts, but getting permission to
> use another product is a difficult task.
>
> I believe we have an obligation to the community to solicit the
> best and brightest extensions and invite them to join the Struts project.
Interesting comment. I'm not really interested in getting into a discussion
of the social aspects of open source development right now (mostly because I
just don't have the time), but I couldn't help noticing the juxtaposition of
"obligation to the community" and the open source mantra of "stratch your
own itch".
> Obviously, we are not going to accept all of the extensions now
> available for Struts, and all of the extensions would not want to
> donate their code to Apache anyway. But when there is an
> extension what some or all of us want to support, or has
> developers we might want to nominate as committers, then we
> should bring them on.
>
> What criteria do we apply? The same as always. Is it something
> that fits within our charter, that benefits our community, and
> that we can support over the longterm.
>
> I think the scriptable actions meet the usual criteria, and would
> make for a good starter subproject. It's useful and small and
> easy to do. I think a lot of us would be willing to support the
> code once it is here. I know I would.
I honestly don't mean to throw jacks in the road, but I think we need to
sort ourselves out a bit before we start bringing things in from outside.
For example, we need to get our web site under struts.apache.org, and we
need to create the new CVS repo structure we discussed a while ago. Once our
own new house is in order, we can have a housewarming party and invite some
interested guests to come talk to us. ;-)
> I would also agree with Don in that this product does not seem
> like something that needs to go through the Incubator, since it
> was developed solely by Apache committers. But, it was created
> and released outside an Apache CVS, and we could offer to sponsor
> it through the incubator. I'd help with that too.
Not the incubator, no. However, I do think a software grant might be
appropriate, since we're moving a project from SourceForge. That's just a
piece of paper that makes a legal statement to the effect that everybody is
happy. It's really very lightweight to deal with, but I think would be a
good thing to put in place. If nothing else, it would demonstrate to the
board that we are properly overseeing the project that we have so recently
been granted custody over.
> Another way to go might be to just add it to the core. It would
> creates a runtime dependency on the bsf.jar, but I could live with that.
I'd be astonished if this happened. Really. We've just recently ditched a
dependency on Commons Collections, which I personally think was a big
mistake. If people object to depending on a Commons component that was
actually created from Struts code in the first place, I simply can't imagine
adding a dependency on something like BSF to the core.
--
Martin Cooper
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Don Brown [mailto:mrdon@twdata.org]
> Sent: Tuesday, April 27, 2004 2:10 PM
> To: Struts Developers List
> Subject: Re: Adding new Struts features/sub-projects (was [Bug 28609] -
> Scriptable Actions Support)
>
>
> I think it goes without saying I'd be on the list, but just in case...
> :) So, in this scripting subproject, could this perhaps someday host a
> continuations-based scripting flow implementation? Dave Johnson has
> been doing some good work pulling Cocoon's flow out of Cocoon and I
> think a Struts port would be a great asset for developing complex
> wizard-style workflows.
Now that sounds cool! It's not clear to me where the glue should live
though - see my earlier message.
--
Martin Cooper
> Normally, I'd get something working then add it
> to the Struts SF project, but with a whole scripting subproject, perhaps
> it might be more relevant there.
>
> BTW, I really like the guidelines Steve was working on and recommend we
> polish them up and post them on our site to make the distinctions clear
> to everyone. Specific mention of the SF site's role in Struts
> development would be very helpful as well.
>
> Don
>
> Joe Germuska wrote:
>
> >> I'd be happy to be one of the Committers named on a proposal to
> >> create a scripting subproject.
> >
> >
> > You can add me to that list.
> >
> > Joe
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Adding new Struts features/sub-projects (was [Bug 28609] -
Scriptable Actions Support)
Posted by Don Brown <mr...@twdata.org>.
I think it goes without saying I'd be on the list, but just in case...
:) So, in this scripting subproject, could this perhaps someday host a
continuations-based scripting flow implementation? Dave Johnson has
been doing some good work pulling Cocoon's flow out of Cocoon and I
think a Struts port would be a great asset for developing complex
wizard-style workflows. Normally, I'd get something working then add it
to the Struts SF project, but with a whole scripting subproject, perhaps
it might be more relevant there.
BTW, I really like the guidelines Steve was working on and recommend we
polish them up and post them on our site to make the distinctions clear
to everyone. Specific mention of the SF site's role in Struts
development would be very helpful as well.
Don
Joe Germuska wrote:
>> I'd be happy to be one of the Committers named on a proposal to
>> create a scripting subproject.
>
>
> You can add me to that list.
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Adding new Struts features/sub-projects (was [Bug 28609] -
Scriptable Actions Support)
Posted by Joe Germuska <Jo...@Germuska.com>.
>I'd be happy to be one of the Committers named on a proposal to
>create a scripting subproject.
You can add me to that list.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by Ted Husted <hu...@apache.org>.
On Tue, 27 Apr 2004 22:31:20 -0700, Martin Cooper wrote:
> I would hope that we would think *very* carefully before following
> the same or similar procedures as these projects. These are all
> "umbrella" projects, and the first two, at least, have clearly
> demonstrated the problems with such projects. (I haven't tracked
> the Incubator closely enough to know whether or not it has had the
> same issues.) The last thing I want to see is Struts becoming
> another umbrella project
Let's not throw out the baby with the bathwater, either. :)
An umbrella project is a granfaloon. It's an arbitrary collection of products that do not share a common community.
There was a theory that there was a "Java community" that could support something like Jakarta. In practice, we found that a common language doesn't build a common community (in the Apache sense of the word). It's not Java that binds developers together, but what we are *doing* with Java. In our case, Struts is what we are doing, and Struts is the foundation of our community.
A Struts project composed of subprojects for the Struts Core and several "standard" extensions that depend on that core would not be an "umbrella" project. It is a modular approach to distributing the Struts products maintained by the ASF. Another way to look at it is that we would be distributing the core and one or more "plugins" that people could use, or not. (Plugins in the generic sense, not the Struts class.)
It is very important to me that we continue to rationalize the Struts project. Once we cut a new Validator release, we can move directly to the Struts 1.2.1 release. (And I'l roll that release too, if no one else has the time.) Once that is done, we will be in a position to prototype a new CVS layout for 1.3.x, as agreed, that will better support Maven builds and can also break out the Core from Taglibs.
In the 1.3.x series, we can also bring Struts-Chain up from Contrib (as agreed), and start looking at alternatives to Actions. Whatever alternatives we find, if there is any coding involved, then I'm sure they could be scriptable too. :)
The stumbling block had been the Validator release. Now that we know it's ready for release, we can remove that impediment and move things along <yeah!/>
-Ted.
[And at any time during all this, I invite anyone interested to start laying code for 2.x.x. Test-first, please. :)]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Tuesday, April 27, 2004 1:17 PM
> To: Struts Developers List
> Subject: Re: Adding new Struts features/sub-projects (was [Bug 28609] -
> Scriptable Actions Support)
>
>
> We might just follow the same general procedure we've used for
> Jakarta, the Commons, and the Incubator.
I would hope that we would think *very* carefully before following the same
or similar procedures as these projects. These are all "umbrella" projects,
and the first two, at least, have clearly demonstrated the problems with
such projects. (I haven't tracked the Incubator closely enough to know
whether or not it has had the same issues.) The last thing I want to see is
Struts becoming another umbrella project.
--
Martin Cooper
> * A Struts subproject is created in response to a proposal to the
> DEV list.
>
> * The proposal must be made by a Struts Committer and name two
> other Struts Committers who are willing to support the subproject.
>
> * At least one of the three Committers must also be a Struts PMC member.
>
> * The proposal is subject to a consensus vote, like any other
> product change.
>
> (A consensus vote is subject to a binding veto. A majority vote,
> like we use for releases, is not.)
>
> Of course, there are going to be other implicit criteria, like
> the code being donated to the ASF, the subproject being relevant
> and wildly popular, and so forth. But I don't think we need to
> spell all that out. So long as we have three willing vict -err-
> volunteers and a proposal subject to consensus, it'll sort itself out :)
>
> I'd be happy to be one of the Committers named on a proposal to
> create a scripting subproject.
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by Ted Husted <hu...@apache.org>.
We might just follow the same general procedure we've used for Jakarta, the Commons, and the Incubator.
* A Struts subproject is created in response to a proposal to the DEV list.
* The proposal must be made by a Struts Committer and name two other Struts Committers who are willing to support the subproject.
* At least one of the three Committers must also be a Struts PMC member.
* The proposal is subject to a consensus vote, like any other product change.
(A consensus vote is subject to a binding veto. A majority vote, like we use for releases, is not.)
Of course, there are going to be other implicit criteria, like the code being donated to the ASF, the subproject being relevant and wildly popular, and so forth. But I don't think we need to spell all that out. So long as we have three willing vict -err- volunteers and a proposal subject to consensus, it'll sort itself out :)
I'd be happy to be one of the Committers named on a proposal to create a scripting subproject.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by Ted Husted <hu...@apache.org>.
The sad truth is that many teams that do use Struts cannot also use whatever other goody they find on SourceForge or on some other open source host.
Many do have permission to use Struts, but getting permission to use another product is a difficult task.
I believe we have an obligation to the community to solicit the best and brightest extensions and invite them to join the Struts project.
Obviously, we are not going to accept all of the extensions now available for Struts, and all of the extensions would not want to donate their code to Apache anyway. But when there is an extension what some or all of us want to support, or has developers we might want to nominate as committers, then we should bring them on.
What criteria do we apply? The same as always. Is it something that fits within our charter, that benefits our community, and that we can support over the longterm.
I think the scriptable actions meet the usual criteria, and would make for a good starter subproject. It's useful and small and easy to do. I think a lot of us would be willing to support the code once it is here. I know I would.
I would also agree with Don in that this product does not seem like something that needs to go through the Incubator, since it was developed solely by Apache committers. But, it was created and released outside an Apache CVS, and we could offer to sponsor it through the incubator. I'd help with that too.
Another way to go might be to just add it to the core. It would creates a runtime dependency on the bsf.jar, but I could live with that.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] -
Scriptable Actions Support)
Posted by Joe Germuska <Jo...@Germuska.com>.
> > 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.
I strongly agree with the principle of keeping the Struts core light.
But especially once there's a Struts TLP, there's no reason not to
host the "best and brightest" extensions at struts.apache.org.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by David Graham <gr...@yahoo.com>.
--- Steve Raeburn <sr...@apache.org> wrote:
> Some ideas, not neccessarily complete or well-formed...
>
> > -----Original Message-----
> > From: David Graham [mailto:grahamdavid1980@yahoo.com]
> > 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.
-1 on being in the core and further increasing the dependencies.
>
> 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 ??)
> 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 ;-)
All valid criteria. My main concerns are having criteria to test
potential sub-projects against and not bloating Struts.
>
> > 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.
Sounds great to me as long as struts.jar doesn't include the sub-project
code. If people want to use scriptable actions, they can download the
struts-script.jar (or whatever it's name would be). If they have no
interest in them, they can just use the standard struts.jar.
>
> > 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
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: The future of actions (RE: Adding new Struts
features/sub-projects (was [Bug 28609] - Scriptable Actions
Support))
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
+1
At 09:06 AM 4/28/2004, Joe Germuska wrote:
>I don't think you're heretical at all, Martin. I was at the Wisconsin
>Java Software Symposium a couple of weeks ago, and between the sessions on
>WebWork and Spring and on writing testable Struts code, I came away
>convinced that changing how Actions work was a high priority.
>
>And, along the lines of what David says, I've been thinking about and
>writing about ideas for doing view-preparation in Struts for a while.
>
>To me these are two separate pieces -- I'm not sure if David and I see
>things differently, or if that's just how I read his words.
>
>I think we can make progress in this direction in a pre-2.0 time
>frame. In fact, given the way we work, I'm beginning to wonder if it
>makes sense to declare a 2.0 revolution; I think we can do a lot with
>incremental changes on the 1.x line.
>
>But the first steps are to get 1.2.1 out the door and get the TLP web site
>in order. Is there anything I can do to help with struts.apache.org? I
>don't really have a sense of the tasks, but if someone else does and wants
>to just dole a few out, I could try to help move that forward...
>
>Joe
>
>
>>--- Martin Cooper <ma...@apache.org> wrote:
>>
>><snip/>
>>
>>> 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.
>
>
>At 6:12 AM -0700 4/28/04, David Graham wrote:
>>I agree; I always found Tiles' Controllers to be more useful than Actions
>>for setting up a view because you attach the preparation code to the
>>actual view instead of trying to remember which URL causes this view to be
>>displayed. However, you can't always use a Tiles Controller and need an
>>Action to make decision logic. It would be nice to have a view
>>preparation system in the core and move away from Actions.
>
>--
>Joe Germuska
>Joe@Germuska.com
>http://blog.germuska.com
> "Imagine if every Thursday your shoes exploded if you tied them the
> usual way. This happens to us all the time with computers, and nobody
> thinks of complaining."
> -- Jef Raskin
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
TLP layout (was Re: The future of actions)
Posted by Ted Husted <hu...@apache.org>.
On Wed, 28 Apr 2004 11:06:13 -0500, Joe Germuska wrote:
> But the first steps are to get 1.2.1 out the door and get the TLP
> web site in order. Is there anything I can do to help with
> struts.apache.org? I don't really have a sense of the tasks, but
> if someone else does and wants to just dole a few out, I could try
> to help move that forward...
One of the next big steps will be to prototype a restructured code tree for CVS and post it where others can review it. The prototype would only need to be a filesystem, and wouldn't have to worry about CVS history. Though, we'd want to retain that when we did it for real on the server.
The general idea is that we want to subdivide the project into subprojects, each of which would represent a deliverable or Maven artifact. So at the top, there would probably something like:
* core (including tiles and validator for now)
* apps
* site
* whiteboard (or "sandbox")
* opt-taglib
* opt-el
* opt-faces
We'd want to follow the Maven project layout recommendations for each deliverable. This will be the easiest for everyone to grok in the longrun.
http://maven.apache.org/reference/dirlayout.html
So, under each top-level directory, we would find a layout like
/src
�- java
�- test
�- webapp
/xdocs
/target (generated)
- *.jar
- distributions
- docs
- site
- ...
The example applications tree might be a tad different. Here we might want a master apps directory, with a directory for each application beneath that. This makes it easy for the apps to extend a common Maven project.xml. We could still offer a single zip/tarball with all the applications WARs within.
/apps
�- examples
�- mailreader
�- tilesPortal
�- userdb
This is what I've started to over in Commons Chain, since I envision having a couple of sample applications (using either Servlets or Filters). The Struts one I'd want to bring over here, once we've added a dependency on Chain.
As to "userDb", the UserDatabase code in the MailReader is getting reused in multiple applications these days, so we should make it a separate deliverable.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
The future of actions (RE: Adding new Struts
features/sub-projects (was [Bug 28609] - Scriptable Actions
Support))
Posted by Joe Germuska <Jo...@Germuska.com>.
I don't think you're heretical at all, Martin. I was at the
Wisconsin Java Software Symposium a couple of weeks ago, and between
the sessions on WebWork and Spring and on writing testable Struts
code, I came away convinced that changing how Actions work was a high
priority.
And, along the lines of what David says, I've been thinking about and
writing about ideas for doing view-preparation in Struts for a while.
To me these are two separate pieces -- I'm not sure if David and I
see things differently, or if that's just how I read his words.
I think we can make progress in this direction in a pre-2.0 time
frame. In fact, given the way we work, I'm beginning to wonder if it
makes sense to declare a 2.0 revolution; I think we can do a lot with
incremental changes on the 1.x line.
But the first steps are to get 1.2.1 out the door and get the TLP web
site in order. Is there anything I can do to help with
struts.apache.org? I don't really have a sense of the tasks, but if
someone else does and wants to just dole a few out, I could try to
help move that forward...
Joe
>--- Martin Cooper <ma...@apache.org> wrote:
>
><snip/>
>
>> 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.
At 6:12 AM -0700 4/28/04, David Graham wrote:
>I agree; I always found Tiles' Controllers to be more useful than Actions
>for setting up a view because you attach the preparation code to the
>actual view instead of trying to remember which URL causes this view to be
>displayed. However, you can't always use a Tiles Controller and need an
>Action to make decision logic. It would be nice to have a view
>preparation system in the core and move away from Actions.
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by David Graham <gr...@yahoo.com>.
--- Martin Cooper <ma...@apache.org> wrote:
<snip/>
> 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.
I agree; I always found Tiles' Controllers to be more useful than Actions
for setting up a view because you attach the preparation code to the
actual view instead of trying to remember which URL causes this view to be
displayed. However, you can't always use a Tiles Controller and need an
Action to make decision logic. It would be nice to have a view
preparation system in the core and move away from Actions.
David
<snip/>
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Steve Raeburn [mailto:sraeburn@apache.org]
> 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:grahamdavid1980@yahoo.com]
> > 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by Steve Raeburn <sr...@apache.org>.
Some ideas, not neccessarily complete or well-formed...
> -----Original Message-----
> From: David Graham [mailto:grahamdavid1980@yahoo.com]
> 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.
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 ??)
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
Posted by David Graham <gr...@yahoo.com>.
--- Steve Raeburn <sr...@apache.org> wrote:
> I'm posting this to the dev-list rather than carrying on with Bugzilla,
> since it looks like there might be some further discussion :-)
>
> I have no position on whether this should be considered core or an
> add-on, but if it's to be an add-on, why not bring it into Struts as a
> new sub-project? It would be a good way to increase its visibilty and
> acceptance while leaving it as an optional addition to the core Struts
> product.
What criteria are we using when deciding what to add to the Struts
project? 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? 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.
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.
David
>
> Other add-ons, could similarly be brought into the project, if their
> communities wanted.
>
> Steve
>
> > -----Original Message-----
> > From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> > Sent: April 26, 2004 7:57 PM
> > To: dev@struts.apache.org
> > Subject: DO NOT REPLY [Bug 28609] - Scriptable Actions Support
> >
> >
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > <http://issues.apache.org/bugzilla/show_bug.cgi?id=28609>.
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > INSERTED IN THE BUG DATABASE.
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=28609
> >
> > Scriptable Actions Support
> >
> >
> >
> >
> >
> > ------- Additional Comments From dgraham@apache.org
> > 2004-04-27 02:57 -------
> > Why should this move into the Struts project? Why isn't the
> > SourceForge project
> > a good home for this action? I admit that this seems pretty
> > neat but Struts has
> > a large dependency list as it is. It would be nice if Struts
> > could avoid the
> > language-flavor-of-the-week syndrome that other projects
> > suffer from. A solid
> > core framework with satellite add-on projects seems to be
> > working well so far.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org