A downloading application utilizing Struts, in my opinion, like the
uploading applications, should have its basic classes somewhere else,
like uploading is in commons. Such an application, in my opinion,
should merely present an interface that subclasses of Struts Actions
can, directly or
You are referring to Martin's DownloadAction I believe... Note that he
didn't place it in the action package, he placed it in the actions
package. It's a subtle difference, but an important one. As I
understand it, the action package are the core classes and interfaces of
Struts, while the
On Wed, 29 Sep 2004 00:07:06 -0400, Frank W. Zammetti
[EMAIL PROTECTED] wrote:
You are referring to Martin's DownloadAction I believe... Note that he
didn't place it in the action package, he placed it in the actions
package. It's a subtle difference, but an important one. As I
understand
Frank W. Zammetti wrote:
You are referring to Martin's DownloadAction I believe... Note that he
didn't place it in the action package, he placed it in the actions
package. It's a subtle difference, but an important one. As I
understand it, the action package are the core classes and
Craig McClanahan wrote:
The proposed example is a good first step, but the hard part of
building a framework, as opposed to an application, is figuring out
where to define the extension points. An example issue relevant to
the current proposal -- what if I want to load my data from somewhere
Michael McGrady wrote:
I would never add something that is a mere solution to a non-framework
problem.
But this is really the crux of the debate, and is also the reason I find
myself simultaneously agreeing and disagreeing with you :)
The distinction between what is a mere solution to a
Way down there...
On Tue, 28 Sep 2004 21:51:55 -0700, Craig McClanahan [EMAIL PROTECTED] wrote:
On Wed, 29 Sep 2004 00:07:06 -0400, Frank W. Zammetti
[EMAIL PROTECTED] wrote:
You are referring to Martin's DownloadAction I believe... Note that he
didn't place it in the action package, he