Re: Downloading Applications and Struts

[Frank W. Zammetti]

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 actions package are specific subclasses of those core 
elements.

I don't think downloading a file is quite as complex as uploading one, 
unless you want to grab a BLOB field from a database or something along 
those lines, but that's the beauty IMHO of Martin's contribution... It's 
a very easy matter to make use of the underlying concept in any which 
way you want, as my contributed sample app does.

The debate about what constitutes bloat in any framework is a difficult 
one, as is the debate about what makes sense as part of the framework 
and what is just a clever usage of it.  In my mind, a framework should 
be as lightweight as possible BUT should provide as much common 
functionality out-of-the-box as possible.  Where you draw the lines 
demarking all these different concerns is difficult to be sure.  In 
simplest terms, if it doesn't add required work for a developer and 
doesn't impact performance or server load if a particular piece of the 
framework is not utilized, I don't really consider it bloat, assuming 
the functionality in question does fulfill a commonly-needed function. 
Certainly we can agree that downloading files is a common enough activity?

Look at it this way... If someone adds something to Struts that fulfills 
a need that comes up commonly, you could rightly call that addition a 
pattern.  We don't consider pattern-based development bloat anywhere 
else, why would we here?  Having common implementations of patterns 
included in Struts makes it easier for a developer, makes it more of a 
one-stop shopping proposition.  I would agree you have to be careful 
in what you add because it IS easy to add things that probably shouldn't 
be, but that decision is never an easy one I suspect.

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Michael McGrady wrote:
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 indirectly, reference.  Such an application, also in my 
opinion, should distinguish and decouple distinct behaviors as, for 
example, the distinction between the io functions and the management 
functions such as access control, choice between zip, folder and 
database sources, etc.  The demands of such applications, in my opinion, 
are too different from the purpose of the Action class to work well in 
the end in an Action class.  Shouldn't, for example, any cool solution 
for either downloading or uploading in the end be multithreaded?  Is 
getting or managing the receipt or sending of a file really within the 
proper scope of the Action class?

Michael McGrady
-
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]

Re: Downloading Applications and Struts

[Craig McClanahan]

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 it, the action package are the core classes and interfaces of
 Struts, while the actions package are specific subclasses of those core
 elements.
 

The distinction you are drawing is indeed correct, and significant.  However ...

 I don't think downloading a file is quite as complex as uploading one,
 unless you want to grab a BLOB field from a database or something along
 those lines, but that's the beauty IMHO of Martin's contribution... It's
 a very easy matter to make use of the underlying concept in any which
 way you want, as my contributed sample app does.
 
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
other than a database?  If's fine to generalize the names of the
tables and columns, but an extensible framework for building
download-some-recorded-data portions of an application will probably
need to define some interface that includes ways to abstract where the
data comes from, what the output content type should be, how to
determine the content length, whether (and how) to create a
Content-Disposition header, and a myriad of other details.

 The debate about what constitutes bloat in any framework is a difficult
 one, as is the debate about what makes sense as part of the framework
 and what is just a clever usage of it.  In my mind, a framework should
 be as lightweight as possible BUT should provide as much common
 functionality out-of-the-box as possible.  Where you draw the lines
 demarking all these different concerns is difficult to be sure.  In
 simplest terms, if it doesn't add required work for a developer and
 doesn't impact performance or server load if a particular piece of the
 framework is not utilized, I don't really consider it bloat, assuming
 the functionality in question does fulfill a commonly-needed function.
 Certainly we can agree that downloading files is a common enough activity?

I would suggest that downloading *static* content (from a file on the
server) is something that a web server, or a servlet container,
already takes care of -- it doesn't need any extra support from a
framework like Struts.  The window of opportunity is around static
data that is stored in a fashion not supported by the default
functionality of the server on which the application is running.

Of course, one could also argue that serving static content doesn't
need an app framework at all -- it can be implemented (for example) by
a standalone servlet that is totally unaware of Struts.  That is also
a reasonable position; one would have to articulate why this
functionality needs to be incorporated into the controller for the
user interactions.  Such arguments can be made, but I don't think they
are going to be universally applicatabe.

 Look at it this way... If someone adds something to Struts that fulfills
 a need that comes up commonly, you could rightly call that addition a
 pattern.  We don't consider pattern-based development bloat anywhere
 else, why would we here?  Having common implementations of patterns
 included in Struts makes it easier for a developer, makes it more of a
 one-stop shopping proposition.  I would agree you have to be careful
 in what you add because it IS easy to add things that probably shouldn't
 be, but that decision is never an easy one I suspect.
 

I agree with you that the o.a.s.actions package is built *on top of*
the framework, instead of *being* the framework.  However, the
proposed code doesn't strike me as sufficiently general, yet, for
inclusion -- perhaps we could look more at defining the general
problem of how can we create an abstraction for a response that might
be acquired from some resource, instead of being dynamically created
by the execution of a JSP page.  In the purest sense, the fact that
you can return null from an Action (indicating that the response has
already been created) means that Struts itself doesn't need anything
extra.  That being said, a design pattern standard action, equally
at home with data extracted from a database, a directory server, an
XSLT transformation, static files, web services calls, a return from
an EJB, or execution of some method on a JavaBean, ... would be more
appropriate for inclusion in Struts itself.  Such an approach
(defining a Provider interface of some sort) would also enable the use
of any of the currently popular IoC frameworks to provide an
appropriate implementation, instead of burying all the functionality
for JDBC access directly in the proposed Action itself.

Is it feasibe to 

Re: Downloading Applications and Struts

[Michael McGrady]

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 interfaces 
of Struts, while the actions package are specific subclasses of those 
core elements.
The next things, though, would be a forms package, etc.  There would be 
one, I would bet, if some people had thought of it!  LOL ;-)

I don't think downloading a file is quite as complex as uploading one, 
unless you want to grab a BLOB field from a database or something 
along those lines, but that's the beauty IMHO of Martin's 
contribution... It's a very easy matter to make use of the underlying 
concept in any which way you want, as my contributed sample app does.
Downloading is just as complex, I think, and fraught with danger.  I 
don't think Martin's approach does exactly what you think, but that is 
not the issue.  I could be right, or you could be right.  If we are 
arguing about whether we like it, it probably should be a CHOICE somehow 
but not in the framework proper.  I am FOR making more choices 
available.  Just HOW to do it is the question.

The debate about what constitutes bloat in any framework is a 
difficult one, as is the debate about what makes sense as part of the 
framework and what is just a clever usage of it.  In my mind, a 
framework should be as lightweight as possible BUT should provide as 
much common functionality out-of-the-box as possible.  Where you 
draw the lines demarking all these different concerns is difficult to 
be sure.  In simplest terms, if it doesn't add required work for a 
developer and doesn't impact performance or server load if a 
particular piece of the framework is not utilized, I don't really 
consider it bloat, assuming the functionality in question does fulfill 
a commonly-needed function. Certainly we can agree that downloading 
files is a common enough activity?
Somethings, however, are useful and have NOTHING to do with Struts.  The 
ImageButtonBean is an example of this.  I also think that Martin's 
DownloadAction is an example of this.  Those things should be available, 
of course.  I am NOT saying they shouldn't.

Look at it this way... If someone adds something to Struts that 
fulfills a need that comes up commonly, you could rightly call that 
addition a pattern.  

We don't consider pattern-based development bloat anywhere else, why 
would we here?  
But, there are Strust oriented patterns and patterns that are not 
related to the framework.  That is what I am saying.  If you have a 
pattern that is (1) related to the Struts framework code and (2) a 
general sort of functionality that is needed, then it belongs.  Other 
things that really are choices that some would like and others would 
hate should be available but not wedded to the framework in a way so 
that they have to be kept in there or deprecated.

Having common implementations of patterns included in Struts makes it 
easier for a developer, makes it more of a one-stop shopping 
proposition.  
We could have MORE NOT LESS solutions if we did not put particular 
solutions into the framework which thereby freezes out competing and 
maybe better solutions.  This is a real problem in my view.

I would agree you have to be careful in what you add because it IS 
easy to add things that probably shouldn't be, but that decision is 
never an easy one I suspect.
I would never add something that is a mere solution to a non-framework 
problem.

Thanks for the discussion, Frank.  I appreciate it.
Michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Downloading Applications and Struts

[Frank W. Zammetti]

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
other than a database?  If's fine to generalize the names of the
tables and columns, but an extensible framework for building
download-some-recorded-data portions of an application will probably
need to define some interface that includes ways to abstract where the
data comes from, what the output content type should be, how to
determine the content length, whether (and how) to create a
Content-Disposition header, and a myriad of other details.
I think this is what Martin's proposed DownloadAction seeks to do, that 
is, define a valid extension point.

I want to be clear on what we are actually discussing... At this point 
we're NOT talking about my original submitted proposal, which did deal 
specifically with serving from a database (because my original thinking 
was that it could be done in a generic way).  Martin's suggested class 
has since bumped my original proposal, but instead I submitted a sample 
app that made use of Martin's class.  This is where this discussion is 
today.  Just wanted to be sure we're all on the same page :)

I would suggest that downloading *static* content (from a file on the
server) is something that a web server, or a servlet container,
already takes care of -- it doesn't need any extra support from a
framework like Struts.  The window of opportunity is around static
data that is stored in a fashion not supported by the default
functionality of the server on which the application is running.
I would agree with this without question.  The situation I'm trying to 
deal with (and what was the genesis for my original proposal) is really 
serving from a database.  I have a system at work that I wrote that 
serves images from a database (for client customization) as well as 
serving PDF's generated on-the-fly, so that's being done from memory. 
The images are certainly static and could be handled by the web server 
(why they aren't in this case is an environment-specific issue).  It is 
this area, the semi-static and the dynamic BLOB-type downloads that I 
think there is an opportunity to do something, as you said.  I would 
durther make the argument that this is such a common activity that to 
include it in Struts in some fashion is beneficial to all that use Struts.

Of course, one could also argue that serving static content doesn't
need an app framework at all -- it can be implemented (for example) by
a standalone servlet that is totally unaware of Struts.  That is also
a reasonable position; one would have to articulate why this
functionality needs to be incorporated into the controller for the
user interactions.  Such arguments can be made, but I don't think they
are going to be universally applicatabe.
Agreed.  There can be such a variety of ways of doing this that a 
general-purpose solution probably isn't possible.  The simple question 
though is at what point is it serving enough people to validate it's 
addition.  I think Martin's approach, perhaps with just a little bit of 
tweaking in some ways, is sufficiently generic and extensible enough to 
warrant inclusion.  I think my sample app, showing the serving of images 
from the file system as well as from a database, proves the flexibility 
of the approach.  Serving from virtually any other source should be a 
simple matter.

I agree with you that the o.a.s.actions package is built *on top of*
the framework, instead of *being* the framework.  However, the
proposed code doesn't strike me as sufficiently general, yet, for
inclusion -- perhaps we could look more at defining the general
problem of how can we create an abstraction for a response that might
be acquired from some resource, instead of being dynamically created
by the execution of a JSP page.  In the purest sense, the fact that
you can return null from an Action (indicating that the response has
already been created) means that Struts itself doesn't need anything
extra.  That being said, a design pattern standard action, equally
at home with data extracted from a database, a directory server, an
XSLT transformation, static files, web services calls, a return from
an EJB, or execution of some method on a JavaBean, ... would be more
appropriate for inclusion in Struts itself.  Such an approach
(defining a Provider interface of some sort) would also enable the use
of any of the currently popular IoC frameworks to provide an
appropriate implementation, instead of burying all the functionality
for JDBC access directly in the proposed Action itself.
I don't think I disagree with that thought, but I do see some statements 
here that are leading me to believe your thinking of my original sample 
app, not the one based on Martin's DownloadAction.  I'd be interested in 

Re: Downloading Applications and Struts

[Frank W. Zammetti]

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 non-framework 
problem and what can be properly thought of as an extension to a 
framework is generally not at all an easy question to answer.  Much of 
what you say I think hinges on your belief in what belongs and what 
doesn't, not concrete technical issues.  Seems like an obvious 
statement, but I'm not sure it is...

For instance, you keep bringing up the ImageButtonBean, and to be honest 
I don't know anything about it, so I can't comment on whether I think 
your right or not technical-speaking.  I'm sure there's been a lot of 
debate about whether including it is right or not.  And who's to say, 
strictly speaking who's right?  Only the committers really in the end.

What criteria is really right to decide by?  I've expressed my 
criteria already... Any addition shouldn't add any unnecassery work for 
a developer if the addition isn't used, it shouldn't have any 
performance or load impact if not used and it should address a 
commonly-encountered issue.  How you define commonly-encountered can 
make all the difference... Is something that 10% of developers run into 
common enough?  25%?  50%?  90%?  Above what percentage is valid and 
below invalid?  Tough to say.

You've said that you believe Struts is going in the wrong direction in 
terms of what is included... Can you give some concrete examples, aside 
from the ImageButtonBean, to substantiate this?  You might be completely 
right and might get a lot of people rallying to your position, but it's 
hard to say without more precise details.

Otherwise it's really just a gut feeling, which is fine, but is no more 
valid than anyone else' gut feeling I think (mine very much included!)

Thanks for the discussion, Frank.  I appreciate it.
Michael
You as well Michael.  Healthy debate is, well, HEALTHY! :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Downloading Applications and Struts

[Martin Cooper]

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 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 actions package are specific subclasses of those core
  elements.
 
 
 The distinction you are drawing is indeed correct, and significant.  However ...
 
  I don't think downloading a file is quite as complex as uploading one,
  unless you want to grab a BLOB field from a database or something along
  those lines, but that's the beauty IMHO of Martin's contribution... It's
  a very easy matter to make use of the underlying concept in any which
  way you want, as my contributed sample app does.
 
 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
 other than a database?  If's fine to generalize the names of the
 tables and columns, but an extensible framework for building
 download-some-recorded-data portions of an application will probably
 need to define some interface that includes ways to abstract where the
 data comes from, what the output content type should be, how to
 determine the content length, whether (and how) to create a
 Content-Disposition header, and a myriad of other details.
 
  The debate about what constitutes bloat in any framework is a difficult
  one, as is the debate about what makes sense as part of the framework
  and what is just a clever usage of it.  In my mind, a framework should
  be as lightweight as possible BUT should provide as much common
  functionality out-of-the-box as possible.  Where you draw the lines
  demarking all these different concerns is difficult to be sure.  In
  simplest terms, if it doesn't add required work for a developer and
  doesn't impact performance or server load if a particular piece of the
  framework is not utilized, I don't really consider it bloat, assuming
  the functionality in question does fulfill a commonly-needed function.
  Certainly we can agree that downloading files is a common enough activity?
 
 I would suggest that downloading *static* content (from a file on the
 server) is something that a web server, or a servlet container,
 already takes care of -- it doesn't need any extra support from a
 framework like Struts.  The window of opportunity is around static
 data that is stored in a fashion not supported by the default
 functionality of the server on which the application is running.
 
 Of course, one could also argue that serving static content doesn't
 need an app framework at all -- it can be implemented (for example) by
 a standalone servlet that is totally unaware of Struts.  That is also
 a reasonable position; one would have to articulate why this
 functionality needs to be incorporated into the controller for the
 user interactions.  Such arguments can be made, but I don't think they
 are going to be universally applicatabe.
 
  Look at it this way... If someone adds something to Struts that fulfills
  a need that comes up commonly, you could rightly call that addition a
  pattern.  We don't consider pattern-based development bloat anywhere
  else, why would we here?  Having common implementations of patterns
  included in Struts makes it easier for a developer, makes it more of a
  one-stop shopping proposition.  I would agree you have to be careful
  in what you add because it IS easy to add things that probably shouldn't
  be, but that decision is never an easy one I suspect.
 
 
 I agree with you that the o.a.s.actions package is built *on top of*
 the framework, instead of *being* the framework.  However, the
 proposed code doesn't strike me as sufficiently general, yet, for
 inclusion -- perhaps we could look more at defining the general
 problem of how can we create an abstraction for a response that might
 be acquired from some resource, instead of being dynamically created
 by the execution of a JSP page.  In the purest sense, the fact that
 you can return null from an Action (indicating that the response has
 already been created) means that Struts itself doesn't need anything
 extra.  That being said, a design pattern standard action, equally
 at home with data extracted from a database, a directory server, an
 XSLT transformation, static files, web services calls, a return from
 an EJB, or execution of some method on a JavaBean, ... would be more
 appropriate for inclusion in Struts itself.  Such an approach
 (defining a Provider interface of some sort) would also enable the use
 of any of the currently popular